Re: [kde-artists] oxygen style and kwin client, svn external

Resending to kde-artists as suggested by Aaron.

On 30.12.09 12:36:42, Aaron J. Seigo wrote:

only to kwin as this is more a technical problem...

> * create a shared lib in runtime that both the kwin client and qstyle can link 
> against. pros: minimal code dupe; cons: ABI would probably need to committed 
> to so that running random combinations of kdebase-runtime and kdebase-
> workspace would work together, means a bit more time spent in runtime linking 
> (though probably not significant)

IMHO thats not necessary, as long as the SOVERSION of the library is
increased as needed(i.e. with each release that breaks binary
compatibility). Then different versions of the shared library can co-exist
without any problem and the workspace-plugin would use X and the
style-plugin would use version Y.

However this also means that headers might need to be installed as
workspace and runtime are supposed to be buildable standalone.

> * create a static lib in runtime that both kwin client and qstyle can link 
> against. pros: the actual source code is shared, no runtime linkage overhead. 
> cons: the code is duplicated in both plugins. 

IIRC linking a static library into a shared object is problematic. It might
require special linking flags (which I think some distro's really really
dislike) and I think there are even platforms that do not support this at
all. (Not sure if KDE or oxygen is built on those platforms at all)

[kde-artists] help request for kmid2

Hi!

KMid2 is a MIDI/karaoke player, currently being developed at 
playground/multimedia, as a reincarnation and revamping of the good old 
classic KMid. Most functionality and some components have been migrated from 
the old codebase, one of them the program icon. I quite like the icon, 
although it doesn't match with Oxygen style, but the main problem is that we 
don't have a scalable version in SVG format. Looks like the current design 
was committed to the repository by "karli" six years ago.

Anyway, if you fellow artists come with a modern version, I would be very 
grateful. I'm also looking for feedback about the action icons used, and the 
overall look of the application.

Regards,
Pedro
______________________________________________________________________________
kde-artists <at> kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists

Re: [kde-artists] please turn off label animations...

On Thursday 24 December 2009 03:20:06 Nuno Pinheiro wrote:
> > Plasma's (digital) clock (also trunk, same rev as oxygen) updates
> > instantaneously.
> > 
> 
> I'M not a marketer, I'm a designer/engineer but if I was I would tell you
>  that  in this day and age the people s attention span as shrunken down to
>  3 seconds. so you better capture the attention of your possible customer
>  in those 3 seconds or become irrelevant.

Ironically, I (being a Marketing dude) have written most of the digital clock :D

Just adding to the confusion ... :)
--

-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
______________________________________________________________________________
kde-artists <at> kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists

Re: [kde-artists] oxygen style and kwin client, svn external

Hi Aaron, others,

> hi everyone ...
>
> a blocker for the git migration is the usage of svn externals. they are a
> broken concept that we need to get away from. there is one in kdebase between
> runtime/kstyles/oxygen/lib and workspace/kwin/clients/oxygen/lib.
>
> in looking at it today, i noticed something odd / interesting in the code
> itself: OxygenAnimation. this can be completely replaced with
> QPropertyAnimation (see attached patch that does this in the kwin client
> code). with Hugo's blessing i'd like to do the same for the oxygen style as
> well.
>
>    
In fact that was the purpose of oxygenanimation to mimic the API of 
QPropertyAnimation and use a qtimeline internally, in order to
- make the transition to QPropertyAnimation easy
- still be able to test with Qt4.5 (to have more feedback, since this 
way you could compile oxygen-trunk against kde4.3).

Now last time I did the switch to QPropertyAnimation, it resulted in 
significantly slower animations (at least on my intel graphics card. 
Reason it seems is that QAnimation tries to push more updates per second 
than QTimeLine. (which kdepepo confirmed in the code). Which is why I 
left it as a QTimeLine.

I'm ok to do the change if there's a concensus.
> there also appears to be something of  a misunderstanding is the usage of
> QPointer in the code. data() is never checked (so it's not actually protecting

Re: [kde-artists] please turn off label animations...

______________________________________________________________________________
kde-artists <at> kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists

Re: [kde-artists] oxygen style and kwin client, svn external

On January 4, 2010, Hugo Pereira Da Costa wrote:
> Now last time I did the switch to QPropertyAnimation, it resulted in
> significantly slower animations (at least on my intel graphics card.
> Reason it seems is that QAnimation tries to push more updates per second
> than QTimeLine. (which kdepepo confirmed in the code). Which is why I
> left it as a QTimeLine.

frame limiting may make a nice addition to kinetic, but i don't see how the 
animations would be slower in this case.

if it takes 100ms to generate a frame in the animation, then the maximum rate 
will be 10 frames/s with kinetic. it doesn't enforce some frame rate, 
regardless of how long it takes to achieve that. it is time based, just like 
with QTimeLine. :)

what can happen is that it uses more cpu to achieve an animation since it may 
generates more frames than you strictly want (if the animation frame 
generation is quick), but the timespan itself should be no different. if 
anything, the animation should be smoother but more cpu intensive.

so, what do you mean by "slower", exactly? because perhaps you have some 
specific impact in mind other than what that means to me on first read :)

> > there also appears to be something of  a misunderstanding is the usage of
> > QPointer in the code. data() is never checked (so it's not actually
> > protecting the code against anything!) and QPointer itself results in a
> > global hash being populated and checked *whenever a QObject is deleted*.
> > this is made even worse since the hash is global to the app it requires
> > aquiring an app-global lock every time it is accessed. oy vey! please
> > use QWeakPointer instead of QPointer, which avoids this problem. and in
> > the case of code like this where the value of data() is never checked,
> > don't bother using a shared pointer at all, it just gives the code a
> > false sense of security at the expense of some overhead.
> 
> Same thing here. I planed to switch to QWeakPointer instead of QPointer,
> which is why I used data() all over the place.

using data() only matters if you actually check the object first. e.g. this:

QWeakPointer<QWidget> *wp = foo;
.. later ...
wp.data()->doSomething();

is jut as dangerous as:

QWidget * p = foo;
... later ...
p->doSomething();

what you need to do is:

QWeakPointer<QWidget> *wp = foo;
.. later ...
if (wp) { wp.data()->doSomething(); }

that wasn't happening anywhere in the code that i looked at and so the usage 
of shared pointers was actually not giving any benefit, just overhead. 
fortunately the "shared" pointers weren't really shared at all in any of the 
window decoration code, so it was trivial to just move to plain c++ pointers 
there. i haven't looked much into the style code, but if the pointers really 
are shared around there, please be certain to check that the pointer is valid 
before using data()

> > thoughts?
> 
> QPointer, I'm ready to change. No big deal, and that was the original idea.

great :)

> OxygenAnimation, its ok too (though I would leave it in lib/ cause I
> added some utility functions (a la "isRunning", "restart" and stuff like
> that, and might benefit a tiny abstraction layer for future changes).

we've been around this same path in Plasma, it's really not worth it. 
isRunning and restart are trivial and don't really save much to warrant the 
addition of a whole other class and QAbstractAnimation is about as abstract as 
one is going to get for an animation base (even to the point of being too 
generic/simple, as it doesn't provide any actual animations framework, just a 
bunch of convenience classes by which to change values over time; this is 
useful and needed, but also very basic :)

> However, this might trigger complains about style animations performing
> poorly. (to be confirmed. So far I have been the only one to test this.
> By the way: any smart idea on how to actually allow people to test both ?)

if OxygenAnimation replicated large parts of the API and had a 
QAbstractAnimation or a QTimeline as an internal member. this makes other 
things really difficult though, such as combining animations. i don't think 
it's worth it.

if we're having issues with Kinetic, let's discuss it with the people working 
on Kinetic (some of them are very much involved with KDE development as well) 
and get improvements there.

also note that QTimeLine uses a separate timer per object while Kinetic uses a 
shared timer. in the case of many animations running simultaneously, having a 
shared timer is usually better for coordination, wakeups, etc.

> I'm confident I can commit both before the branching tomorrow (since
> this was the original plan).

great; i've already got the oxygen style done, so i'll commit that then.

--

-- 
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 Development Frameworks
______________________________________________________________________________
kde-artists <at> kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists

Re: [kde-artists] help request for kmid2

Hello Pedro,

Currently have my plate full with other projects, but I figured I
could help with your request by at least creating a quick-and-dirty
SVG version of the current icon.  I reckon that makes for a good
start, and might motivate someone else to pitch in and fix/replace my
shoddy work.  :P

[see attached]

Sorry to say I can't check Kmid's GUI at the moment, but I would love
to give it a spin when I have the chance.  I still work with MIDI
files from time to time, so a user-friendly MIDI manager is certainly
in order.  ;)

Thanks for your hard work!

--Arturo

______________________________________________________________________________
kde-artists <at> kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists

Re: [kde-artists] oxygen style and kwin client, svn external

On January 4, 2010, Hugo Pereira Da Costa wrote:
> > what can happen is that it uses more cpu to achieve an animation since it
> > may generates more frames than you strictly want (if the animation frame
> > generation is quick), but the timespan itself should be no different. if
> > anything, the animation should be smoother but more cpu intensive.
> 
> well, that's the surprising part. It seems (to me) that the "tab"
> transitions take more time (and is smoother) with QPropertyAnimation
> than with QTimeLine, 

i wonder if it isn't just that there are more frames and therefore more visual 
transitions which then make it _feel_ slower (due to more happening visually). 
this could be completely psychological (so much is with animations ;). it may 
be that with QPropertyAnimation it is possible to shorten the duration of the 
animation for the same degree of quality/effect?

> > uses a shared timer. in the case of many animations running
> > simultaneously, having a shared timer is usually better for
> > coordination, wakeups, etc.
> 
> True.
> 
> >> I'm confident I can commit both before the branching tomorrow (since
> >> this was the original plan).
> > 
> > great; i've already got the oxygen style done, so i'll commit that then.
> 
> It's all committed already. 

ah; that was fast. :) 

(as an aside: i find it's nice to let people commit their own work. it does a 
number of things: it gives them that "huzzah!" moment when the commit goes in 
as a nice reward, it prevents them ending up with conflicts in their checkout 
when you commit it for them and if there are things that need to be fixed 
first you can communicate it to them and have them fix it before committing. 
this way they learn what you want in your code. it's not a big deal in this 
case, but even if it does mean one has to wait some extra time for the other 
person to commit their patch, it's usually a good idea for community / team 
building. :)

as for the shared library thing, i'm happy to help you with that as soon as 
4.5 opens up so that we can get rid of the svn extern. i don't even mind doing 
the entire bit of work needed to make it happen. just let me know :)

> Right now I'm trying to address some of the
> obvious bugs that have been reported.
> (notably that Qt apps do not used a different text color for disabled
> widgets, while kde apps do)

great :) the oxygen theme set is coming along really nicely!

--

-- 
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 Development Frameworks
______________________________________________________________________________
kde-artists <at> kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists

Re: [kde-artists] please turn off label animations...

Hugo Pereira Da Costa wrote:
> - Tab animations are off by default because this is the only animation
> that can alter large fractions of the screen, and thus stress low
> performance systems too much. As far as I know this is not the case for
> labels, hover effects, etc.
>
> - as Nuno mentioned, I don't think label animations alter the display in
> any way that prevent the user to interact with it. If such circumstances
> exist, they should obviously be fixed. Now, yes, this makes label text
> change non instantaneous (which was the original plan).

This /does/ alter the user interaction experience, by delaying the 
display of information. (As an extreme example, try playing a real-time 
video game with a frame delay in effect.) In some cases that may be 
okay. In others it is not. Since this will (I presume) affect Qt-only 
applications as well, I don't think a reactive strategy (disable where 
problematic) is desirable.

> - On the possibility of enabling the animation on a per widget basis, I
> am not sure I get the point. If this is:
> a/ animate some labels and some not, this is not possible without
> modifying applications.

Right. Which is why IMO it should be off by default and opt-in; opt-out 
makes it harder to not have it in the way.

> b/ have three options of "animations" (all kinds), like All; Some (=
> e.g. all and not label, and not tabs); None; this is doable. But one
> will never make every one happy. Some will want labels but not tabs,
> some tabs, but not label, etc. Who decides that ?

That's not what I meant. I meant it rather w.r.t. opt-out/opt-in; "some" 
would enable animations only when the app requests them for a widget, 
"all" would enable them regardless, and "none" would disable them even 
if requested. (That assumes opt-in, of course.)

> In the meanwhile I would rather keep the label on (and I understand Nuno
> agrees), and fix places where it is broken (since you mention it in your
> original email, don't hesitate to forward such cases. I'd be happy to
> fix, since this is obviously not acceptable).

IMHO it is annoying /everywhere/. (It's especially egregious in 
ksysguard, though.)

> Finally:
> Label text change needing to be instantaneous also applies (with the
> same arguments) to hover, focus, etc, in my opinion.

I disagree. Hover/focus effects are useful, but not critical 
information. The system is usable without them, especially as the user 
can anticipate them. I *cannot* anticipate the next value of an 
important reading, or how quickly the machine will react to an action I 
take. Label animations slow these down and consequently disrupt my 
workflow. (And, frankly, a label change is a lot more distracting than a 
hover effect.)

Actually I would argue that focus change should not be animated for the 
same reason (at least not fade-in; fade-out is marginally more okay).

> So that turning off
> all animations at once because they make the system feels slower does
> not sound so crazy to me. (In other words: I don't understand why label
> transitions should be "more" instantaneous than hover, or focus effects).

I think you are convincing me that /all/ animation should be off by default.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--

-- 
"It's not easy for [Microsoft] to accept [competing fairly]"
   -- Dave Heiner (a Microsoft VP, paraphrased)
______________________________________________________________________________
kde-artists <at> kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists

Re: [kde-artists] oxygen style and kwin client, svn external

On 01/04/2010 04:32 PM, Aaron J. Seigo wrote:
> On January 4, 2010, Hugo Pereira Da Costa wrote:
>    
>>> what can happen is that it uses more cpu to achieve an animation since it
>>> may generates more frames than you strictly want (if the animation frame
>>> generation is quick), but the timespan itself should be no different. if
>>> anything, the animation should be smoother but more cpu intensive.
>>>        
>> well, that's the surprising part. It seems (to me) that the "tab"
>> transitions take more time (and is smoother) with QPropertyAnimation
>> than with QTimeLine,
>>      
> i wonder if it isn't just that there are more frames and therefore more visual
> transitions which then make it _feel_ slower (due to more happening visually).
> this could be completely psychological (so much is with animations ;). it may
> be that with QPropertyAnimation it is possible to shorten the duration of the
> animation for the same degree of quality/effect?
>    
could be.
I actually did shorten the time alocated to the tab transition from 250 
to 150msec after the change to kinetic. (great minds blah blah blah).

>    
>>> uses a shared timer. in the case of many animations running
>>> simultaneously, having a shared timer is usually better for
>>> coordination, wakeups, etc.
>>>        
>> True.
>>
>>      
>>>> I'm confident I can commit both before the branching tomorrow (since
>>>> this was the original plan).
>>>>          
>>> great; i've already got the oxygen style done, so i'll commit that then.
>>>        
>> It's all committed already.
>>      
> ah; that was fast. :)
>
> (as an aside: i find it's nice to let people commit their own work. it does a
> number of things: it gives them that "huzzah!" moment when the commit goes in
> as a nice reward, it prevents them ending up with conflicts in their checkout
> when you commit it for them and if there are things that need to be fixed
> first you can communicate it to them and have them fix it before committing.
> this way they learn what you want in your code. it's not a big deal in this
> case, but even if it does mean one has to wait some extra time for the other
> person to commit their patch, it's usually a good idea for community / team
> building. :)
>
> as for the shared library thing, i'm happy to help you with that as soon as
> 4.5 opens up so that we can get rid of the svn extern. i don't even mind doing
> the entire bit of work needed to make it happen. just let me know :)
>
>    
>> Right now I'm trying to address some of the
>> obvious bugs that have been reported.
>> (notably that Qt apps do not used a different text color for disabled
>> widgets, while kde apps do)
>>      
> great :) the oxygen theme set is coming along really nicely!
>
>    

______________________________________________________________________________
kde-artists <at> kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists