Re: Review Request: use buttons instead of links in systray notifications
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/686/ --- (Updated 2009-05-11 03:47:16.790293) Review request for Plasma. Changes --- use a close button to clear the completed jobs Summary --- the links for more/less info and clear all completed jobs looks really ugly, normal pushbuttons seem to look a bit better. Diffs (updated) - /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/jobwidget.h 966519 /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/jobwidget.cpp 966519 /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/applet.cpp 966519 Diff: http://reviewboard.kde.org/r/686/diff Testing --- Screenshots --- http://reviewboard.kde.org/r/686/s/117/ Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: use buttons instead of links in systray notifications
On 2009-05-10 13:18:35, Aaron Seigo wrote: hm.. how about a close symbol in the group header, which would then close the whole group, just as closing one item closes a single item? done, looks nice indeed. but i wonder if it wouldn't cause some accidental clear when the user wants just to hide it tough. - Marco --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/686/#review1102 --- On 2009-05-11 03:47:16, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/686/ --- (Updated 2009-05-11 03:47:16) Review request for Plasma. Summary --- the links for more/less info and clear all completed jobs looks really ugly, normal pushbuttons seem to look a bit better. Diffs - /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/jobwidget.h 966519 /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/jobwidget.cpp 966519 /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/applet.cpp 966519 Diff: http://reviewboard.kde.org/r/686/diff Testing --- Screenshots --- http://reviewboard.kde.org/r/686/s/117/ Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: use buttons instead of links in systray notifications
On 2009-05-10 13:18:35, Aaron Seigo wrote: hm.. how about a close symbol in the group header, which would then close the whole group, just as closing one item closes a single item? Marco Martin wrote: done, looks nice indeed. but i wonder if it wouldn't cause some accidental clear when the user wants just to hide it tough. hopefully there'd be some spacing between them? - Aaron --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/686/#review1102 --- On 2009-05-11 03:47:16, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/686/ --- (Updated 2009-05-11 03:47:16) Review request for Plasma. Summary --- the links for more/less info and clear all completed jobs looks really ugly, normal pushbuttons seem to look a bit better. Diffs - /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/jobwidget.h 966519 /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/jobwidget.cpp 966519 /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/applet.cpp 966519 Diff: http://reviewboard.kde.org/r/686/diff Testing --- Screenshots --- http://reviewboard.kde.org/r/686/s/117/ Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: use buttons instead of links in systray notifications
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/686/ --- Review request for Plasma. Summary --- the links for more/less info and clear all completed jobs looks really ugly, normal pushbuttons seem to look a bit better. Diffs - /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/applet.cpp 965178 /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/jobwidget.h 965178 /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/jobwidget.cpp 965178 Diff: http://reviewboard.kde.org/r/686/diff Testing --- Screenshots --- http://reviewboard.kde.org/r/686/s/117/ Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: use buttons instead of links in systray notifications
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/686/#review1102 --- hm.. how about a close symbol in the group header, which would then close the whole group, just as closing one item closes a single item? - Aaron On 2009-05-10 08:43:39, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/686/ --- (Updated 2009-05-10 08:43:39) Review request for Plasma. Summary --- the links for more/less info and clear all completed jobs looks really ugly, normal pushbuttons seem to look a bit better. Diffs - /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/applet.cpp 965178 /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/jobwidget.h 965178 /trunk/KDE/kdebase/workspace/plasma/applets/systemtray/ui/jobwidget.cpp 965178 Diff: http://reviewboard.kde.org/r/686/diff Testing --- Screenshots --- http://reviewboard.kde.org/r/686/s/117/ Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Some systray notifications ideas
Hello This time I would like to share some of my ideas regarding these infamous progress notifications that were moved to systray starting from KDE 4.2. I don't know how it currently look in trunk so maybe they were already implemented or at least proposed. First idea is about making autohide of progress information dialog optional and defaults to not hide. This is because when it hides people sometimes thing that job is finished with is extremely danger when for example moving data. I've read that there is already added configuration dialog for disabling these notifications at all and show them in traditional way, so maybe there could be added option to disable autohide. Second idea is to make current information icon in systray (shown when there are jobs) animate when job is progressing (like in Amarok 1.4 when playing songs). There could be problem for multiple jobs running simultaneous but then progress could be averaged. Or maybe there could be shown multiple icons, each for one kind of job or separate icons for more danger jobs, like moving and copying files. I've also one question by the way, will be possible to get list of WId of windows connected to entry (if any)? Best regards Michał ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Some systray notifications ideas
On Sun, Apr 5, 2009 at 12:40 PM, Emdek emd...@gmail.com wrote: Hello This time I would like to share some of my ideas regarding these infamous progress notifications that were moved to systray starting from KDE 4.2. I don't know how it currently look in trunk so maybe they were already implemented or at least proposed. First idea is about making autohide of progress information dialog optional and defaults to not hide. This is because when it hides people sometimes thing that job is finished with is extremely danger when for example moving data. I've read that there is already added configuration dialog for disabling these notifications at all and show them in traditional way, so maybe there could be added option to disable autohide. Second idea is to make current information icon in systray (shown when there are jobs) animate when job is progressing (like in Amarok 1.4 when playing songs). There could be problem for multiple jobs running simultaneous but then progress could be averaged. Or maybe there could be shown multiple icons, each for one kind of job or separate icons for more danger jobs, like moving and copying files. now the progress windows are collapsed in only one (with the average) that can be expanded, don't remember if the collapsed progress window is autohidden or not. animated info icon is planned too I've also one question by the way, will be possible to get list of WId of windows connected to entry (if any)? as usual, only with the new spec :p Best regards Michał ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Some systray notifications ideas
On Sunday 05-04-2009 13:02:59 Marco Martin wrote: now the progress windows are collapsed in only one (with the average) that can be expanded, don't remember if the collapsed progress window is autohidden or not. Yes, I've read about collapsing also, but I'm not sure if everyone wants to group all types of jobs but making it configurable also doesn't make too much sense. ;-) animated info icon is planned too Nice. :-) I've also one question by the way, will be possible to get list of WId of windows connected to entry (if any)? as usual, only with the new spec :p Yes, of course I was asking if it will be possible with new spec. ;-) Big respect for all who were fighting with making systrays usable with old spec. :-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systray Notifications
On Sonntag 30 November 2008 23:31:13 Rob Scheepmaker wrote: How come that kopete suddenly decided to spam your screen full of notifications? That sounds more like the real problem here... That is the standard setting, and I was somehow used to being spamed by new mesages spawning notifications, yet in 3.5.X they were smaller. ;) I turned them off now and use Open messages instantly. So imo as long as incoming messages can not be grouped in the notifications Show a message in a popup should not be the standard for Incoming Message. Imo rather Open messages instantly (Behaviour/General/Message Handling) should be default. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systray Notifications
On Samstag 29 November 2008 15:15:58 Rob Scheepmaker wrote: Well, with more notifications then space available stuff will obviously be suboptimal. The question is how often this situation arises. I'm using these notifications in the systray for some time now, and the amount of simultaneous messages has never been very big. Of course with telephone like systems, that situation could occur, and if it does, you can use that icon to hide your notifications so they aren't in your way. Well once I got many Kopete messages and the notifications started flashing (readjusting?). My systray is on a toolbar that is hided automatically and I could not press that button that moment. I logged on to kopete and got many messages, yet I could not hide them, they overlayed the bar. Yes pressing the icon of the notificaiton and then clicking into the chat- window solved that problem, but it's not nice neither. Anyway my point is even if you can hide that imagine -- especially in the future with the option to keep the dialog open -- that you are copying many things around and then hide all the notifications away. After a while you want to see if everything has been finished yet there are too many notifications ... Imo there should be a scrollbar. So all notifications are in one extender/plasmoid themselves. I made a primitive mockup: [1], [2] [1] all notifications are shown, in [2] more notifications were added and only the last are shown. If you want to see the other active notifications simply scroll up. That way you don't lose information yet your screen is not filled with notifications. In the future something like this could be configureable, so that you'd set the space that notifications are allowed to take. [1] http://imagebin.org/32482 [2] http://imagebin.org/32483 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Systray Notifications
Hi, First I know that the systray notifications are very new. Second I have some problems with them ;) [1]: *When logging in some messages telling me that the Ktorrent logs are copied somewhere pop up -- annoying *When clicking an image in a folderview I get _two_ notifications with the note Examining and _one_ Transfering -- so three notifications *When clicking a text file in a folderview I get two notifications (Examining and Copying), saving the text gets me another notification (Moving) I think that in this case the the examing, copying/moving notifications should be hidden from the user as they should not need to know what is happening behind the surface. *If you configure Kopete that a window should pop up in certain situations they are not grouped eg I get a message from XY Hi -- one notification, then How are you -- another notification while the original is still there and so on. I know that is basically the same way it worked like in KDE3 and KDE 4.1 (right?), yet there the windows were not that large. I think that these notifications should be merged if there would be shown more than one of the exact same type. Like if the Hi notification is still there the How are you should be shown in this notification under Hi and the notification should flash once -- or whatever to show that there is a change. Yet the Hi and the How are you text should disappear the time the seperate notifications would disappear. And if there would be too much (like 100 lines ;) ) text the oldest text should be dropped. What would be too much should be imo checked by how much space is left. *The desktop is in some cases (going to elaborate that later with an example) not useable anymore than there are more notifications than place for them -- this can be a big problem for lower resolutions Cheers! [1] everything tested with Beta 1, I had not time to compile everything PS.: Keep on the good work, KDE 4.2 is really shapeing up nicely! :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systray Notifications
On Saturday 29 November 2008 13:55:15 Matthias Fuchs wrote: Hi, First I know that the systray notifications are very new. Second I have some problems with them ;) [1]: *When logging in some messages telling me that the Ktorrent logs are copied somewhere pop up -- annoying *When clicking an image in a folderview I get _two_ notifications with the note Examining and _one_ Transfering -- so three notifications *When clicking a text file in a folderview I get two notifications (Examining and Copying), saving the text gets me another notification (Moving) I think that in this case the the examing, copying/moving notifications should be hidden from the user as they should not need to know what is happening behind the surface. Agreed, Ideally those should be hidden. Something I could do is only let notifications appear after a job has been running for a couple of seconds so all those very short jobs won't bother you, but other then that, there isn't really a way to tell the difference between important and unimportant messages. Any kio job will get registered to kuiserver and I don't think that can be changed without additions to the kio api. (and of course applications marking jobs as 'unimportant') *If you configure Kopete that a window should pop up in certain situations they are not grouped eg I get a message from XY Hi -- one notification, then How are you -- another notification while the original is still there and so on. I know that is basically the same way it worked like in KDE3 and KDE 4.1 (right?), yet there the windows were not that large. I think that these notifications should be merged if there would be shown more than one of the exact same type. Like if the Hi notification is still there the How are you should be shown in this notification under Hi and the notification should flash once -- or whatever to show that there is a change. Yet the Hi and the How are you text should disappear the time the seperate notifications would disappear. And if there would be too much (like 100 lines ;) ) text the oldest text should be dropped. What would be too much should be imo checked by how much space is left. Of course, grouping... I actually have this planned for 4.3. To do this nicely grouping support will have to be added to the extender api. But that feature didn't exist before so at least it is not a regression. *The desktop is in some cases (going to elaborate that later with an example) not useable anymore than there are more notifications than place for them -- this can be a big problem for lower resolutions Well, with more notifications then space available stuff will obviously be suboptimal. The question is how often this situation arises. I'm using these notifications in the systray for some time now, and the amount of simultaneous messages has never been very big. Of course with telephone like systems, that situation could occur, and if it does, you can use that icon to hide your notifications so they aren't in your way. I don't think that there's much else we can do about this (except grouping for 4.3). If you have any suggestions, please tell. :) Regards, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systray Notifications
On Saturday 29 November 2008 15:36:59 Anne-Marie Mahfouf wrote: On Saturday 29 November 2008 15:15:58 Rob Scheepmaker wrote: On Saturday 29 November 2008 13:55:15 Matthias Fuchs wrote: Hi, First I know that the systray notifications are very new. Second I have some problems with them ;) [1]: When one uses the DesktopTheme Details kcm and choose a customized desktop, there are something like 10 notifications (or way more but then they pile up outside my laptop!) that open, they seems to indicate that some theme file is copied somewhere. As those files are copied everytime you change something that makes it very annoying. So there are useless notifications. Useful notifications do not stay long enough to be read (Nepomuk at first start, Phonon stuf sometimes). As stated in my previous mail, I don't believe there's any way to make a distinction between important or unimportant jobs, in the case of kio jobs, besides maybe waiting a couple of seconds before showing one to filter out the really short (and that way probably irrelevant) jobs. Maybe it would be useful to add an api option to kio to mark jobs as important or unimportant. Or we could require every app to register even kio jobs to kuiserver themselves, but that would be unrealistic for 4.2. Clicking stop button makes notification crash. Not here what version are you running and can you provide a backtrace? Thanks :) Clicking somewhere on the notification makes the mouse cursor stay as a hand on plasma. Not sure what clicking triggers this bug but I reproduced after another user said so. Ey, I noticed the cursor staying a hand before, but I never understood how to reproduce it, it just happened to me every once in a while. This will help me a lot in fixing this problem, thanks. :) Regards, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systray Notifications
Rob Scheepmaker wrote: Agreed, Ideally those should be hidden. Something I could do is only let notifications appear after a job has been running for a couple of seconds so all those very short jobs won't bother you, As far as I know this is exactly what happens with the old dialogs. unimportant messages. Any kio job will get registered to kuiserver and I don't think that can be changed without additions to the kio api. (and of course applications marking jobs as 'unimportant') There is a way to know if the progress info should be visible or not, and namely the JobFlags argument for the kio methods. See the API docs (like http://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/namespaceKIO.html#09f67ce3514cc15ed2adcf91704fa55e) and see there: flags,: We support HideProgressInfo here You should take this into the account and not show any progress info if the caller doesn't want to (for most stat, open and sometimes save, etc. cases). Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systray Notifications
On Saturday 29 November 2008 16:41:25 Andras Mantia wrote: There is a way to know if the progress info should be visible or not, and namely the JobFlags argument for the kio methods. See the API docs (like http://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/namespaceKIO.html#09f67 ce3514cc15ed2adcf91704fa55e) and see there: flags,: We support HideProgressInfo here I was unaware that this flag was available. Thanks for pointing this out. :) Regards, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systray Notifications
--- On Sat, 11/29/08, Andras Mantia [EMAIL PROTECTED] wrote: From: Andras Mantia [EMAIL PROTECTED] Subject: Re: Systray Notifications To: plasma-devel@kde.org Date: Saturday, November 29, 2008, 7:41 AM Rob Scheepmaker wrote: There is a way to know if the progress info should be visible or not, and namely the JobFlags argument for the kio methods. See the API docs (like http://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/namespaceKIO.html#09f67ce3514cc15ed2adcf91704fa55e) and see there: flags,: We support HideProgressInfo here You should take this into the account and not show any progress info if the caller doesn't want to (for most stat, open and sometimes save, etc. cases). Andras -- I'll be updating Desktop Theme Details shortly to take advantage of the above flag. Hope this helps, Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systray Notifications
--- On Sat, 11/29/08, Rob Scheepmaker [EMAIL PROTECTED] wrote: From: Rob Scheepmaker [EMAIL PROTECTED] ... I don't think that there's much else we can do about this (except grouping for 4.3). If you have any suggestions, please tell. :) Regards, Rob How about having a max number of notifications shown at the same time? It could show, for example, the latest 3 (or whatever max number) unexpired notifications and all unexpired notifications could be available upon click of the systray notifications icon. This max number *could* be configurable (hidden for 4.2, UI for 4.3). The work on the notifications framework is awesome. Since we're consolidating the different types of notifications into this framework, we could perhaps look at the use cases for the different types of notifications we're consolidating and decide behavior based on that. I imagine many KDE apps have been using jobs the way they have because the impact used to be a minimal: job windows that remained open as long as the job was active - small jobs disappeared before notice. Apps used popups for other reasons. I don't suppose there's a way to tell which of these notifications used to appear as windows, which appeared in popups, etc.? If there is, then perhaps we could replicate the persistence behavior of those notifications to match what they did before (e.g. disappear/expire when complete for jobs that used to appear as windows, expire after some seconds for notifications that used to appear as passive popups, persist indefinitely for notifications that require interaction, etc). Hope this helps, Andrew Lake ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Systray Notifications
On Samstag 29 November 2008 19:29:16 Jamboarder wrote: --- On Sat, 11/29/08, Rob Scheepmaker [EMAIL PROTECTED] wrote: From: Rob Scheepmaker [EMAIL PROTECTED] ... I don't think that there's much else we can do about this (except grouping for 4.3). If you have any suggestions, please tell. :) Regards, Rob How about having a max number of notifications shown at the same time? It could show, for example, the latest 3 (or whatever max number) unexpired notifications and all unexpired notifications could be available upon click of the systray notifications icon. This max number *could* be configurable (hidden for 4.2, UI for 4.3). I think this number should have to do with the resolution -- at least for 4.2 where there can not be a UI for it. Like if you have a netbook with 1024x600 not as many should be shown as if you had a resolution of 1280x1024. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 19:26:22 Sebastian Kügler wrote: Only the ones that open popups automatically. The power management control extender from the battery and the calendar should have focus. (But I think it's fine to make that explicit in the applet itself.) Ok, so we need some function in popup applet which will allow its subclasses to specify desired behavior. Before that I guess we need to find some combination of Qt::WindowFlags or NET::* flags which make popups focusless and don't break extenders at the same time :) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
2008/10/22 Dmitry Suzdalev [EMAIL PROTECTED]: Hello! I just found a real problem with new notifications system. Let me describe it. New notifications are shown using a PopupApplet which is a full-blown window from the KWin POV. So what happens is the following: dimsuz is touch-typing with amazing speed in his kmail window. at the same time he often alt-tabs to kopete to chat with friends, and also types much in konversation in #plasma channel :) At the same time a lot of notifications arrive, and guess what - each of them steals focus from dimsuz's current input widget! Because each of them has a default window role. What do you think dimsuz thinks on each notification appearance? Yeah, he thinks: #%#!!!?#?!!! And then clicks back on the widget he is typing into :) I tried to fix this one, but quickly found that systray (being a PopupApplet) just uses PopupApplet::popup() function. That is systray has no control on the dialog that pops up. I think that it should be able to somehow tell the popup() that this particular popup should be of Qt::Tooltip type or something like that. So I'm thinking what's the best way to do this? A parameter to popup() function? A new function PopupApplet::setPopupAsTooltip(bool)? something else? Note, that i think this is a problem that really needs to be fixed, as it may potentially annoy a lot of our users :) Readers digest version for those of you that don't have lotsa free time: Popup notifications should not steal focus, ever. They are the new round of passivePopups and should behave as so. Dan, Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[PROBLEM] New systray notifications and kwin
Hello! I just found a real problem with new notifications system. Let me describe it. New notifications are shown using a PopupApplet which is a full-blown window from the KWin POV. So what happens is the following: dimsuz is touch-typing with amazing speed in his kmail window. at the same time he often alt-tabs to kopete to chat with friends, and also types much in konversation in #plasma channel :) At the same time a lot of notifications arrive, and guess what - each of them steals focus from dimsuz's current input widget! Because each of them has a default window role. What do you think dimsuz thinks on each notification appearance? Yeah, he thinks: #%#!!!?#?!!! And then clicks back on the widget he is typing into :) I tried to fix this one, but quickly found that systray (being a PopupApplet) just uses PopupApplet::popup() function. That is systray has no control on the dialog that pops up. I think that it should be able to somehow tell the popup() that this particular popup should be of Qt::Tooltip type or something like that. So I'm thinking what's the best way to do this? A parameter to popup() function? A new function PopupApplet::setPopupAsTooltip(bool)? something else? Note, that i think this is a problem that really needs to be fixed, as it may potentially annoy a lot of our users :) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 15:27:18 Dmitry Suzdalev wrote: Hello! I just found a real problem with new notifications system. Let me describe it. New notifications are shown using a PopupApplet which is a full-blown window from the KWin POV. So what happens is the following: dimsuz is touch-typing with amazing speed in his kmail window. at the same time he often alt-tabs to kopete to chat with friends, and also types much in konversation in #plasma channel :) At the same time a lot of notifications arrive, and guess what - each of them steals focus from dimsuz's current input widget! Because each of them has a default window role. What do you think dimsuz thinks on each notification appearance? Yeah, he thinks: #%#!!!?#?!!! And then clicks back on the widget he is typing into :) I tried to fix this one, but quickly found that systray (being a PopupApplet) just uses PopupApplet::popup() function. That is systray has no control on the dialog that pops up. I think that it should be able to somehow tell the popup() that this particular popup should be of Qt::Tooltip type or something like that. Popup Dialogs used to be Qt::Tooltip, only that doesn't function correctly when you want to be able to drag widgets away from the window, as is possible with extender items. But I agree we should avoid the dialog stealing focus. I assume there is some window flag to accomplish that. I will look into that. So I'm thinking what's the best way to do this? A parameter to popup() function? A new function PopupApplet::setPopupAsTooltip(bool)? something else? I think the don't steal focus behavior should be default for all popupapplets. Note, that i think this is a problem that really needs to be fixed, as it may potentially annoy a lot of our users :) Agreed. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008, Dmitry Suzdalev wrote: So I'm thinking what's the best way to do this? A parameter to popup() function? A new function PopupApplet::setPopupAsTooltip(bool)? something setPopupWindowFlags(Qt::WindowFlags)? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 18:54:28 Rob Scheepmaker wrote: Popup Dialogs used to be Qt::Tooltip, only that doesn't function correctly when you want to be able to drag widgets away from the window, as is possible with extender items. But I agree we should avoid the dialog stealing focus. I assume there is some window flag to accomplish that. I will look into that. That would be very nice, thanks! Perhaps use some NET:: flags would help? I think the don't steal focus behavior should be default for all popupapplets. Ah, this makes thing easier (no api modifications required) Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 16:54:28 Rob Scheepmaker wrote: So I'm thinking what's the best way to do this? A parameter to popup() function? A new function PopupApplet::setPopupAsTooltip(bool)? something else? I think the don't steal focus behavior should be default for all popupapplets. Only the ones that open popups automatically. The power management control extender from the battery and the calendar should have focus. (But I think it's fine to make that explicit in the applet itself.) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 19:13:01 Aaron J. Seigo wrote: On Wednesday 22 October 2008, Rob Scheepmaker wrote: So I'm thinking what's the best way to do this? A parameter to popup() function? A new function PopupApplet::setPopupAsTooltip(bool)? something else? I think the don't steal focus behavior should be default for all popupapplets. .. that popup automatically. for popups that are trigerred by user interaction, this could get annoying in all new ways. Ok, but workaround against wrong behaviour of Qt::Popup that Rob talked about still has to be found. That brings us to the question of introducing setPopupWindowFlags(Qt::WindowFlags) - if user will set Qt::Popup, he'll break extenders stuff... Cheers, Dmitry. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008, Rob Scheepmaker wrote: Popup Dialogs used to be Qt::Tooltip, only that doesn't function correctly when you want to be able to drag widgets away from the window, as is possible with extender items. what problems does this cause, exactly? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PROBLEM] New systray notifications and kwin
On Wednesday 22 October 2008 18:36:57 Aaron J. Seigo wrote: On Wednesday 22 October 2008, Rob Scheepmaker wrote: Popup Dialogs used to be Qt::Tooltip, only that doesn't function correctly when you want to be able to drag widgets away from the window, as is possible with extender items. what problems does this cause, exactly? IIRC, when dragging an item away, the dialog gets hidden when you move an item. Isn't one of the NET flag usable to avoid the dialog getting focus? Hmm, I'm starting to doubt if it wasn't Qt::Popup before, instead of Qt::Tooltip. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
