Summary: | JJ:Code review: Use descriptive KGuiItem labels for buttons in calls to KMessageBox | ||
---|---|---|---|
Product: | [I don't know] kde | Reporter: | Thomas Fischer <fischer> |
Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
Status: | RESOLVED LATER | ||
Severity: | minor | CC: | akshay_ratan, cfeck, nate, qprogger123, sahilsehgal1995 |
Priority: | NOR | Keywords: | junior-jobs |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Thomas Fischer
2012-11-08 10:16:04 UTC
On the other hand, I am not sure if porting to KGuiItem is the right direction for future KDE frameworks. Is there another way to relabel the buttons? KGuiItem is the official way of doing it for 4.x (as far as I can see) and it is unlikely that it will be changed (never change established APIs). However, I see some benefit in finding a solution for Qt5 which is more friendly than adding/modifying QPushButtons through QMessageBox. IHMO is KGuiItem quite an acceptable solution. As complementary information, I just checked the official HIG guidelines on messages [1]: "When the user must choose between two actions to continue, use descriptive button labels instead of standard Yes/No or OK/Cancel buttons. For example, if the user must choose to continue or stop an action, provide the buttons "Continue" and "Cancel"." [1] http://techbase.kde.org/Projects/Usability/HIG/Messages#Confirmation_Button_Labels I would like to work on this. I have sufficient experience i feel to attempt this Junior Job. How to contact the relevant mentor ? I may be mistaken, but for junior jobs there is usually no mentor. They are meant to be easy so that anyone with some programming skills and knowledge on how to compile KDE from sources should be able to fix them. The approach I would recommend is to pick one sub-project (e.g. Okular), get the sources from git, make the changes, test it, submit a patch through git.reviewboard.kde.org and hope that someone with commit permissions accepts your patch and commits it to git. All the practical details should be subscribed in http://techbase.kde.org/ The people in the KDE IRC channels are usually helpful if problems persists (read the documentation first before asking questions!). Good luck! Can one task be done twice ? (for the sake of practice) ? i need help . i am new to kde and know quite a lot of qt and c++ . but i am confused as to how to start debugging . can anyone explain to me how to start ?Also tell me which kde to compile and use what libraries. (eg : build kde , install qt , download source code of bug , fix it and push it . ) help will be greatly appreciated Here are some links to get you started developing for KDE: http://community.kde.org/Getinvolved http://community.kde.org/Getinvolved/development http://en.flossmanuals.net/_booki/kde-guide/kde-guide.pdf http://techbase.kde.org/Contribute http://techbase.kde.org/Getting_Started If you read these, you know where to ask further questions. I am clear with what kind of dialog box are you talking about but Can you please add an attachment showing the dialog box which needs some labels and all? If possible, please try if you can find out any dialog box in okular only. Part of this exercise is to scan the source for KMessageBox/QMessageBox calls, and review the labels used. In other words, this certainly is not limited to Okular. This is kind of too broad to be actionable. In general any bug with a subject like "do X thing everywhere" is never going to get done--as you can see from the lack of any progress in 8 years. Individual bug reports for individual apps are far more effective and actionable. |