Re: How to enable notification history for an application
On 18 September 2020 17:12:48 BST, David Edmundson wrote: > On Fri, Sep 18, 2020 at 3:45 PM Kai Uwe Broulik > > wrote: > > > Hi, > > > > > > > Is it possible for the application to change its own "show in > history" > > > setting, instead of the user going to System Settings to do this? > > > > It is not. > > > > Let's back up a bit, what's the end goal we're trying to achieve for > the > kalarm notifications that isn't fulfilled out of the box. I'd considered providing a setting to choose between persistent notifications, which wouldn't need to show in history, or for notifications to hide after timeout, which would require them to show in history. If, as you say, the application can't change the history setting, I won't provide the persistent notification option (which in any case could be considered to duplicate the existing functionality using notification windows). -- David Jarvie KAlarm author, KDE developer
Re: How to enable notification history for an application
On Thursday 17 Sep 2020 11:28:13 Kai Uwe Broulik wrote: > Hi, > > by default all well-known applications show in history. > > Having DesktopEntry= in the notifyrc should make it show up in System > Settings. Make sure the notifyrc file is intsalled in the correct > location and the DesktopEntry matches the desktop file name and that the > desktop file isn't marked as Hidden etc. > > Also, applications that aren't properly registered like above but have > sent a notification once will be registered and show up in the list. > > Make sure the desktopFileName in the QApplication/KAboutData is set > correctly. Check the "desktop-entry" hint of the notification emitted by > KAlarm using dbus-monitor if necessary to find out if it sends the > correct hint. Thank you. It turns out that installing it with kdesrc-build was the problem - it installed the notifyrc file into a user directory. After installing it in the system directory, the application shows up in the System Settings list. Is it possible for the application to change its own "show in history" setting, instead of the user going to System Settings to do this? Cheers, -- David Jarvie. KDE developer, KAlarm author.
How to enable notification history for an application
Can somebody help on how Plasma can be configured to show or hide a specific application's notification history, if that application is not already in the list of applications shown in the System Settings Notifications list (ie Konsole, KDevelop, Spectacle, etc). Currently, if an application is not already in the System Settings list, the user has to select whether to show notification history for ALL applications, and cannot as far as I can see select just ONE unlisted application. I want KAlarm itself to be able to set its default to "show notification history", to avoid the user having to know about going to System Settings to do this. If possible, KAlarm would also be able to enable or disable showing its notification history at any time. I've set kalarm.notifyrc to contain a DesktopEntry value, but that hasn't done anything in itself. -- David Jarvie. KDE developer, KAlarm author.
Re: RFC: Running clang-format across all Plasma (and more?) repos
On Thursday 11 Jul 2019 14:18:08 David Edmundson wrote: > One topic discussed at the recent Plasma sprint was that we should run > a code formatting tool (clang-format) over all our repos to ease all > future review comments about whitespace. > > All new contributions simply have to run the same tool and we get > consistent code without having to comment on every minor thing in a > review individually. > > I've written up a wall of text outlining steps, challenges etc. > https://phabricator.kde.org/T11214 > > Does anyone have any thoughts / objections? Presumably this would impose a common coding style throughout all KDE repositories? Or would each project be able to specify its own clang-format configuration? In past discussions about KDE coding style, it was accepted that while Frameworks and PIM libraries would adopt a common style, Applications would be left to decide for themselves. There may be more benefits from what you propose for larger projects, because of the larger number of contributors and larger volume of reviews. But for smaller ones with one or two contributors and few reviews, it bring few benefits. It should be for individual projects to decide whether automatic code formatting would be desirable or useful to them. This will allow projects to continue to use their own coding styles where they wish, and allow for hand- crafted formatting to be left intact where this is desired. -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: CI system maintainability
On 28 March 2019 13:33:59 GMT, laurent Montel wrote: > Le jeudi 28 mars 2019, 09:29:22 CET Kevin Ottens a écrit : > > Hello, > > > > On Thursday, 28 March 2019 09:16:11 CET Ben Cooksley wrote: > > > Please note that the commits in this instance were pushed without > > > review, so restrictions on merge requests wouldn't make a > difference > > > in this case unfortunately. > > > > Maybe it's about time to make reviews mandatory... I know it's > unpopular in > > KDE, and I advocated for "don't force a tool if you can get someone > to look > > at your screen or pair with you" in the past. Clearly this > compromise gets > > somewhat exploited and that's especially bad in the case of a > fragile and > > central component like KDE PIM. > > > > Regards. > > Hi, > > I am against to force mandatory review, as it will create a lot of > lose of > time, and we will not be sure that review is correct (see comment from > Volker > about "transaction lock regression") > > It's necessary to having a big team for doing it. > > Ok a repo was broken, but it was just that fix was created in master > not > 19.04, I didn't see nobody on IRC told us "this package is always > broken", > when I saw it this morning I just cherry pick (2 seconds for fixing > it). > > > For example I works all days on kde (pim or other) when I wake up, or > at noon > after my lunch or the evening, I will not wait several days for a > review > because nobody has time to do it. (we can see a review from zanshin > for > example https://phabricator.kde.org/D16210 we can see that David > waited 2 > months until having an answer...). > > (For example I make ~ 15 commits by days on pim/ruqola/framework, I > don't want > to wait several days/weeks until someone wants to review my patchs) > > I will not lose my time to review some code that I don't understand... > I never > reviewed Akonadi patch as I don't understand this code, and I will > take time > on it just for the pleasure as I prefer fixing bug or adding new > features in > components that I maintain. > > When we have a big team as Qt team it can help but in pim component > where we > don't have any redundant guy, we will lose a lot of time. > > So for each increase version for each package I will wait a review. > For sure > not. > > Each time that I will improve code as coding style I will wait that > someone > wants to review... I agree. Mandatory reviews might work if there is a team of active people working on a project, but if there is only one person with real knowledge of the code, or there is nobody else with much time to spare, who is going to do the review? It is likely to just sit waiting indefinitely. If getting code reviewed is too difficult, the developer may have to give up and abandon the project. Mandatory reviewing could only work if individual projects can decide whether to adopt it or not. -- David Jarvie KAlarm author, KDE developer http://www.astrojar.org.uk/kalarm
[Breeze] [Bug 361885] Kalarm crashes when closing main woindow
https://bugs.kde.org/show_bug.cgi?id=361885 David Jarvie <djar...@kde.org> changed: What|Removed |Added Product|kalarm |Breeze Component|general |general Assignee|djar...@kde.org |plasma-devel@kde.org --- Comment #1 from David Jarvie <djar...@kde.org> --- The crash is in the Breeze style code. Reassigning to Breeze. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Breeze] [Bug 356940] kalarm crash on start up
https://bugs.kde.org/show_bug.cgi?id=356940 David Jarvie <djar...@kde.org> changed: What|Removed |Added Component|general |general Assignee|djar...@kde.org |plasma-devel@kde.org Product|kalarm |Breeze -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasmate:images can now be added to projects
On Sept. 12, 2011, 12:56 p.m., David Jarvie wrote: editors/editpage.cpp, lines 105-106 http://git.reviewboard.kde.org/r/102290/diff/1/?file=31661#file31661line105 KFileDialog::getOpenUrls() is a static function, so it doesn't use 'imageDialog' which you have just constructed. You need to remove the previous line and call KFileDialog::getOpenUrls() with suitable parameters. Giorgos Tsiapaliwkas wrote: thanks,nice catch. Maybe can you tell me why the kfiledialog doesn't open in the $HOME directory? It's because you haven't supplied any directory parameter to KFileDialog::getOpenUrls(). Remember, the 'imageDialog' object is not used by the getOpenUrls() call because it's a static method. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102290/#review6441 --- On Aug. 10, 2011, 6:29 p.m., Giorgos Tsiapaliwkas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102290/ --- (Updated Aug. 10, 2011, 6:29 p.m.) Review request for Plasma and Aaron J. Seigo. Summary --- hello, without this patch a user cannot add an image with plasmate. reproduce,go to files-images-new,the plasmate will open a text editor instead of a dialog,which(the dialog) is able to open an image. With the patch a dialog will open asking for an image. Diffs - editors/editpage.h 7b5dca3 editors/editpage.cpp d4b0082 packagemodel.cpp 8c0907a Diff: http://git.reviewboard.kde.org/r/102290/diff Testing --- the patch is not ready yet,i have noted some questions. Also the plasmate tries to open the image with a text editor.This have to be fixed,but how?Should we make plasmate able to preview images? In addition,when you add something in the list of files(using the different options provided by the files qdockwidget) it names it as new.This has to be fixed and the plasmate has to show the real name of the file.(different request,i just want an approval for this patch). Thanks, Giorgos ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Plasmate:images can now be added to projects
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102290/#review6441 --- editors/editpage.cpp http://git.reviewboard.kde.org/r/102290/#comment5713 KFileDialog::getOpenUrls() is a static function, so it doesn't use 'imageDialog' which you have just constructed. You need to remove the previous line and call KFileDialog::getOpenUrls() with suitable parameters. - David On Aug. 10, 2011, 6:29 p.m., Giorgos Tsiapaliwkas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102290/ --- (Updated Aug. 10, 2011, 6:29 p.m.) Review request for Plasma and Aaron J. Seigo. Summary --- hello, without this patch a user cannot add an image with plasmate. reproduce,go to files-images-new,the plasmate will open a text editor instead of a dialog,which(the dialog) is able to open an image. With the patch a dialog will open asking for an image. Diffs - editors/editpage.h 7b5dca3 editors/editpage.cpp d4b0082 packagemodel.cpp 8c0907a Diff: http://git.reviewboard.kde.org/r/102290/diff Testing --- the patch is not ready yet,i have noted some questions. Also the plasmate tries to open the image with a text editor.This have to be fixed,but how?Should we make plasmate able to preview images? In addition,when you add something in the list of files(using the different options provided by the files qdockwidget) it names it as new.This has to be fixed and the plasmate has to show the real name of the file.(different request,i just want an approval for this patch). Thanks, Giorgos ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Attempt to port KAlarm to KNotificationIcon
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1655/#review2422 --- Yes, KAlarm can run with or without the system tray icon. - David On 2009-09-22 19:24:27, Davide Bettio wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1655/ --- (Updated 2009-09-22 19:24:27) Review request for KDE PIM, Plasma and Marco Martin. Summary --- I've attempted to port KAlarm to KNotificationItem. I don't know how to port some pieces of code. Probably I will post a new patch soon. Diffs - /trunk/KDE/kdepim/kalarm/kalarmapp.h 1024122 /trunk/KDE/kdepim/kalarm/kalarmapp.cpp 1024122 /trunk/KDE/kdepim/kalarm/mainwindow.cpp 1024122 /trunk/KDE/kdepim/kalarm/traywindow.h 1024122 /trunk/KDE/kdepim/kalarm/traywindow.cpp 1024122 Diff: http://reviewboard.kde.org/r/1655/diff Testing --- Thanks, Davide ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
