Re: Tool tips ideas
On Sunday 05 April 2009, Emdek wrote: > On Sunday 05-04-2009 22:37:58 Aaron J. Seigo wrote: > >> >> I'm using also middle click > >> >> on preview to close or left to raise it or iconify. > >> > > >> > so hiding tips needs to take hover of tip itself into account (easy to > >> > do :) > >> > and we need some clicked(ToolTipContent) signals > >> > >> Yes, this would be useful, especially if there would be QPoint with > >> location of click event on screen. > > > > do we need a point, or just what was actually activiated? (e.g. which > > link or > > which action) > > Maybe there could be passed with event object as parameter (so we could get > information about position, used mouse buttons etc.)? so that everyone can interpret "what to do" differently? i dunno .. sounds a bit over-engineered and a recipe for inconsistency. > Also there could be > passed enumerator member (for example Preview, Icon, Text) to tell which > widget was activated. yes, that makes complete sense. we'd probably also need to pass a url as well in the case of some text being clicked. > >> Yes, of course I'm interested (especially because I want to use it ;-)) > >> but > >> there is again problem with lack of compiled trunk on my machine... > > > > you should be able to just get kdelibs and just build kdelibs/plasma? > > I could at least try to prepare needed environment during next days (I > could try to prepare full set when I'll format my hard drive at end of > April, this will be it's first full format after four years of use ;-)). :) -- 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: Tool tips ideas
On Sunday 05-04-2009 22:37:58 Aaron J. Seigo wrote: >> >> I'm using also middle click >> >> on preview to close or left to raise it or iconify. >> > >> > so hiding tips needs to take hover of tip itself into account (easy to >> > do :) >> > and we need some clicked(ToolTipContent) signals >> >> Yes, this would be useful, especially if there would be QPoint with >> location of click event on screen. > > do we need a point, or just what was actually activiated? (e.g. which > link or > which action) Maybe there could be passed with event object as parameter (so we could get information about position, used mouse buttons etc.)? Also there could be passed enumerator member (for example Preview, Icon, Text) to tell which widget was activated. >> >> or we don't use KWin >> > >> > this just needs to be pushed into the netwm spec and standardized for >> > usage by >> > others >> >> This would be great. >> Currently also Compiz tries to add them, so with upstream solution this >> could be much cleaner. > > ok, so we need to talk to these various projects. maybe i could blog > about it. Good idea. :-) >> > nothing you've said above requires the ability to put random widgets >> > into the >> > tooltips though, so i think we're good. we just need to work some >> > patches out >> > for the current tip. >> > >> > interested in trying to get some patches put together? :) >> >> Yes, of course I'm interested (especially because I want to use it ;-)) >> but >> there is again problem with lack of compiled trunk on my machine... > > you should be able to just get kdelibs and just build kdelibs/plasma? I could at least try to prepare needed environment during next days (I could try to prepare full set when I'll format my hard drive at end of April, this will be it's first full format after four years of use ;-)). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Tool tips ideas
On Saturday 04 April 2009, Emdek wrote: > On Saturday 04 April 2009 20:07:18 Aaron J. Seigo wrote: > >> In my applet there are launcher together with tasks and > >> for consistency I'm displaying previews of files (for example if there > >> is > >> entry for image or video etc.) and it looks nice only when it is shown > >> in > >> the same way like windows live previews (this could be maybe solved by > >> adding kind of method that adds file preview or set image as preview > >> that > >> looks like current window preview, with frame). > > > > this could be added to the API of ToolTipContent quite easily. > > This would be useful but I think that there should be only possibility to > set QPixmap yes > >> I'm using also middle click > >> on preview to close or left to raise it or iconify. > > > > so hiding tips needs to take hover of tip itself into account (easy to > > do :) > > and we need some clicked(ToolTipContent) signals > > Yes, this would be useful, especially if there would be QPoint with > location of click event on screen. do we need a point, or just what was actually activiated? (e.g. which link or which action) > >> or we don't use KWin > > > > this just needs to be pushed into the netwm spec and standardized for > > usage by > > others > > This would be great. > Currently also Compiz tries to add them, so with upstream solution this > could be much cleaner. ok, so we need to talk to these various projects. maybe i could blog about it. > > nothing you've said above requires the ability to put random widgets > > into the > > tooltips though, so i think we're good. we just need to work some > > patches out > > for the current tip. > > > > interested in trying to get some patches put together? :) > > Yes, of course I'm interested (especially because I want to use it ;-)) but > there is again problem with lack of compiled trunk on my machine... you should be able to just get kdelibs and just build kdelibs/plasma? -- 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: 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
Re: Desktop settings dialog ideas
On Saturday 04 April 2009 23:26:46 Davide Bettio wrote: > The main advantage of your idea is that users are used to a similar UI > so it > might be more usable for users that are already used to Windows or KDE < > 4. Yes of course, this is mainly for users that were already using it in the past. But also for users who want to perform some actions connected to the desktop in one central place but without launching additional application. > On the other hand this paradigm was introduced by microsoft a lot of > time ago I guess that it is not important who did it first. ;-) > and it isn't logical for us. We are just used to it. Plasma team is > working > hard to push innovation to the desktop, and breaking with the (broken) > past is > part of our evolution. Maybe this is not perfect solution and like everything it has drawbacks but fighting with users habits is often very hard. ___ 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