Re: Tool tips ideas

2009-04-05 Thread Aaron J. Seigo
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

2009-04-05 Thread Emdek
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

2009-04-05 Thread Aaron J. Seigo
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

2009-04-05 Thread Emdek
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

2009-04-05 Thread Marco Martin
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

2009-04-05 Thread Emdek
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

2009-04-05 Thread Emdek
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