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
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
--- 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
--- 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
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: 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: Some systray notifications ideas
On Sun, Apr 5, 2009 at 12:40 PM, Emdek 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
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: 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 Sunday 30 November 2008 18:24:56 Matthias Fuchs wrote: > 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 Ok, to be clear: I do agree that a scrollbar there is neat, but it's just that I already got quite some things on my todo for 4.2 and I don't think this one is the most critical. I mean: the oldschool passivepopup notifications don't provide such a feature either, so this isn't a regression in that regard. And if you gather enough notifications at once for this to really be a problem, some app is spamming way to much notifications. I will work on making at least jobs only appear after they've been running 1 or 2 seconds to get rid of some of the unnecessary job spam. How come that kopete suddenly decided to spam your screen full of notifications? That sounds more like the real problem here... Of course, feel free to step up and implement. :) Regards, Rob > > ___ > 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: Systray Notifications
On Sonntag 30 November 2008 18:24:56 Matthias Fuchs wrote: > > [1] http://imagebin.org/32482 > [2] http://imagebin.org/32483 Gna, just realized that I used imagebin, probably not the best idea: [1] http://e.imagehost.org/0398/a.png [2] http://e.imagehost.org/0501/b.png ___ 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
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: 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 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 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
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 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
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). Clicking stop button makes notification crash. 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. Best regards, Anne-Marie ___ 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
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: [PROBLEM] New systray notifications and kwin
On October 27, 2008 02:51:17 Dmitry Suzdalev wrote: > 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 :) I was hacking on the screensaver this weekend and banged my head against window flags for a while. As far as I can tell, Qt::Popup does something magical and wonderful which makes Plasma::Dialogs not break plasma-overlay. I can't find any way to make them work without that flag; the best I can get is input passing straight through them (which is at least better than users having to drop to a tty and kill plasma-overlay). and yet, Qt::Popup also does something magical which breaks extenders. blah. oh, and the flags being used in trunk cause another bug for me: when I clicked the button to bring up hte powerdevil config dialog, the battery popup stayed *above* that and would not go away until I clicked on the battery *applet*. that doesn't happen using plain Qt::Popup. http://chani.ccdevnet.org/sshots/powerdevil.png so just now I tried Qt::Popup | Qt::WindowStaysOnTopHint which doesn't really help :) the popup stayed above the dialog - but this time it went away when I clicked the dialog, which is good. extenders were still broken, though. I'm wondering what exactly triggers the popup-hide that breaks extenders, and if we can isolate it and fix it without breaking other things... but I have to go to school. of course, if anyone can figure out how to make popupapplet work on the screensaver without using Qt::Popup, be my guest :) -- This message brought to you by eevil bananas and the number 3. www.chani3.com ___ 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
> > Isn't one of the NET flag usable to avoid the dialog getting focus? > > probably.. i wonder if the ComboBox type would work better... would have to > experiment.. > > > Hmm, I'm starting to doubt if it wasn't Qt::Popup before, instead of > > Qt::Tooltip. > > probably was Qt::Popup, yes... what I find interesting is that they used to have Qt::X11BypassWindowManagerHint set (not directly, probably as a side- effect of Qt::Popup) but now they don't. if they had that flag again they might magicallly go back to working on the screensaver. however, it'd be nicer if I could find a less... fragile... way to tell the difference between popups and config dialogs. (getting a bit OT here) my problem is that I have to pass input directly to config dialogs for them to work, but I MUST NOT try to do that to popup dialogs or all input gets dropped on the floor somewhere. and since the function that creates the config dialogs is virtual, I don't really know how to tell the difference between these things other than my old hack in shells/screensaver/plasmaapp.cpp. if anyone has a solution to this I'd love to hear it :) I don't really understand the x11 stuff as well as I'd like. -- This message brought to you by eevil bananas and the number 3. www.chani3.com ___ 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: > 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've tried to investigate this problem, and encountered the following on my recent trunk/ build: focus is not stolen when a notification pops up, and I can continue typing, however, while the NET:SkipTaskbar | NET:SkipPager flags are set on the window, and indeed the window is hidden in the taskbar and pager applet, the window does appear in the alt-tab switcher, which is undesirable. But according to http://api.kde.org/4.x-api/kdelibs- apidocs/kdeui/html/classNET.html, this shouldn't be the case: "To set the state of a window, you'll typically do something like: KWindowSystem::setState( winId(), NET::SkipTaskbar | NET::SkipPager ); for example to not show the window on the taskbar and pager (alt-tab dialog). winId() is a function of QWidget()" Is this maybe a bug in kwin? ___ 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: > 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. ah, moving them within the same extender.. hm.. > Isn't one of the NET flag usable to avoid the dialog getting focus? probably.. i wonder if the ComboBox type would work better... would have to experiment.. > Hmm, I'm starting to doubt if it wasn't Qt::Popup before, instead of > Qt::Tooltip. probably was Qt::Popup, yes... -- 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
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 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: > > 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. -- 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 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 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, 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 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 17:31:15 Dan Meltzer wrote: > 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. Hehe, thanks! :) It's great to have our bug-issue in a two forms :) 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
