From a usability perspective, it would be beneficial if message box buttons would contain a brief summary of the action that would follow instead of the default text "Yes", "No", "Continue", ... Example: For a message box that warns the user that a file will get overwritten, the code may look like this: KMessageBox::warningYesNo(this, i18n("Overwrite file?")); showing only "Yes" and "No" as button labels. Given that overwriting a file may imply loosing data, the user should be made aware more clearly of the consequences. The box's buttons should be instead labeled of the actions that will follow: KMessageBox::warningYesNo(this, i18n("Overwrite file?"), QString(), KGuiItem(i18n("Overwrite file")), KGuiItem(i18n("Keep file"))); This problem exists across all KDE applications. However, it can be easily fixed and changes have virtually no effect of the surrounding code and can be done by someone with only basic skills. This makes this "bug" a perfect junior job. As an enhancement, this bug can be enlarged by requiring that similar message box have similar text and content across all KDE applications. There exist multiple variants of "Overwrite file" message box in KDE. Maybe the most common types of message boxs (again as an example "Overwrite file") should be refactored into the KMessageBox class using a static function where you would e.g. specify the filename as well. Reproducible: Always
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.