"animations" in oxygen style

Hi,

I've been committing changes to oxygen window decoration and oxygen
style for the last few month now. In the decoration to include most of
the features that were in the "nitrogen" windeco; in the style, mostly
to fix bugs. For kde 4.4, I'd like to add a bunch of (on/off) switchable
"animations" to the style, cause I've always disliked "instantaneous"
state changes. I'm thinking of
- 'smooth' (as opposed to immediate) glow of buttons, sliders,
scrollbars, everything that glows, on hover
- same thing when getting focus
- smooth transition between active and inactive state

Most of it I already implemented in a style called nitrogen (forked from
oxygen) available at
http://www.kde-look.org/content/show.php/Nitrogen-style?content=112652,
and had quite some (although less) positive feedback.

Since this is a somewhat 'sensitive' topic (see, e.g. bespin), and since
a style is much more 'breakable' than a window decoration, I wonder
what's the procedure to do such a thing:

- make a fork of oxygen in kde-playground ?
- submit patches to kde reviewboard (and if yes, under which group ?)
- commit directly to kdebase/runtime/styles/oxygen ?
(which is what's been done so far for the bug fixing, but animations
being "new" features, I'd understand that another procedure is required)

Any preference ?

Hugo
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[John Tapsell-3]

2009/10/23 Hugo Pereira Da Costa <hugo.pereira@...>:

> Hi,
>
> I've been committing changes to oxygen window decoration and oxygen
> style for the last few month now. In the decoration to include most of
> the features that were in the "nitrogen" windeco; in the style, mostly
> to fix bugs. For kde 4.4, I'd like to add a bunch of (on/off) switchable
> "animations" to the style, cause I've always disliked "instantaneous"
> state changes. I'm thinking of
> - 'smooth' (as opposed to immediate) glow of buttons, sliders,
> scrollbars, everything that glows, on hover
> - same thing when getting focus
> - smooth transition between active and inactive state

Out of interest, have any UI designers given their input on this subject?

I personally don't like the animations because it makes everything
feel very 'heavy'.  E.g. if I hover over a scrollbar/button and there
is a delay before it's glowing, I'm going to feel that the machine is
being slow and unresponsive.

IMHO

John
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On October 22, 2009, John Tapsell wrote:
> I personally don't like the animations because it makes everything
> feel very 'heavy'.  E.g. if I hover over a scrollbar/button and there
> is a delay before it's glowing, I'm going to feel that the machine is
> being slow and unresponsive.

this has everything to do with the style, framerate and speed of the
animation. animations done poorly make things feel heavy. animations done
right make things feel responsive.

btw, what do you think of the highlight-on-hover anims in the tasks widget?

--
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


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

John Tapsell wrote:

> 2009/10/23 Hugo Pereira Da Costa <hugo.pereira@...>:
>  
>> Hi,
>>
>> I've been committing changes to oxygen window decoration and oxygen
>> style for the last few month now. In the decoration to include most of
>> the features that were in the "nitrogen" windeco; in the style, mostly
>> to fix bugs. For kde 4.4, I'd like to add a bunch of (on/off) switchable
>> "animations" to the style, cause I've always disliked "instantaneous"
>> state changes. I'm thinking of
>> - 'smooth' (as opposed to immediate) glow of buttons, sliders,
>> scrollbars, everything that glows, on hover
>> - same thing when getting focus
>> - smooth transition between active and inactive state
>>    
>
> Out of interest, have any UI designers given their input on this subject?
>
> I personally don't like the animations because it makes everything
> feel very 'heavy'.  E.g. if I hover over a scrollbar/button and there
> is a delay before it's glowing, I'm going to feel that the machine is
> being slow and unresponsive.
>
> IMHO
>  

just to be precise: we're talking of 50 -> 200 msec (max) transitions,
and naturally, they could be switched off.

as for 'UI' designer, I've been talking with Nuno about this, who likes
the idea (because it would make 'glow' more 'physical'), and dislike
some more fancy animations I put into Nitrogen (like the toolbar hover
square following the mouse rather than fading in/out).

I think that well-done animations, meaning: they represent a "natural"
behavior of the object you interact with (as opposed to: my widgets
starts to do fancy useless things, spin around, escape the mouse, etc),
then improve user interaction, rather than makes the system look heavy.
See, e.g. Qt toolbars detach/attach animations.
Now, as to define what is "natural" animation, is where discussing with
people comes into play (hence the email)

> John
>  
>  
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>>>      
>
>
>  

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[John Tapsell-3]

2009/10/23 Aaron J. Seigo <aseigo@...>:
> On October 22, 2009, John Tapsell wrote:
>> I personally don't like the animations because it makes everything
>> feel very 'heavy'.  E.g. if I hover over a scrollbar/button and there
>> is a delay before it's glowing, I'm going to feel that the machine is
>> being slow and unresponsive.
>
> this has everything to do with the style, framerate and speed of the
> animation. animations done poorly make things feel heavy. animations done
> right make things feel responsive.

Usually I'd agree - for most animations 300ms is considered
nearly-instant.  However this does not apply for clicking/hovering
animations.  When typing on a keyboard, for example, a delay of a mere
100ms between touching and response is already considered to be felt
as a very heavy keyboard.  60ms is tolerable, and most people prefer
30ms responses.

I see no reason why the same doesn't apply here.  You need instant
response and highlighting.  You can then animate something
additionally on top if you wish, but the initial highlighting must be
near instant (e.g. around 50ms).

John
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On October 22, 2009, Hugo Pereira Da Costa wrote:

> I've been committing changes to oxygen window decoration and oxygen
> style for the last few month now. In the decoration to include most of
> the features that were in the "nitrogen" windeco; in the style, mostly
> to fix bugs. For kde 4.4, I'd like to add a bunch of (on/off) switchable
> "animations" to the style, cause I've always disliked "instantaneous"
> state changes. I'm thinking of
> - 'smooth' (as opposed to immediate) glow of buttons, sliders,
> scrollbars, everything that glows, on hover
> - same thing when getting focus
> - smooth transition between active and inactive state

the static version should probably be turned on by default according to
KGlobalSettings::graphicsEffectsLevel()

i just tried the style and the ideas are nice, imho. there's some refinements
that could be made, perhaps. e.g.:

* the menu animation where it follows the mouse is far too slow; it should
move, but as quickly as possible. e.g. if it is a 50ms anim it should be 50ms
no matter how close or far apart the target items are. right now it looks like
it takes N ms _per_ item?

* don't fade in on the toolbar buttons right away. since you've got
animations, wait ~.3s which allows the use the chance the move the mouse over
and out of the item without triggering the animation. it'll probably feel a
lot less "blinky"

* i don't see any purpose (other than to let people mess it up ;) to allow the
user to set the animation times. nor should all the animations have the same
timings. i'd say just pick good timings for each and go with it.

* the "follows mouse" anims feel very "at home" with what we're doing in
plasma with selection these days.

> Most of it I already implemented in a style called nitrogen (forked from
> oxygen) available at
> http://www.kde-look.org/content/show.php/Nitrogen-style?content=112652,
> and had quite some (although less) positive feedback.

> - make a fork of oxygen in kde-playground ?

i'd suggest making a branch and merging changes over as they become stable and
at least moderately tested (technically, aesthetically and usability,
preferably)

--
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


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[John Tapsell-3]

2009/10/23 Hugo Pereira Da Costa <hugo.pereira@...>:

> John Tapsell wrote:
>> 2009/10/23 Hugo Pereira Da Costa <hugo.pereira@...>:
>>
>>> Hi,
>>>
>>> I've been committing changes to oxygen window decoration and oxygen
>>> style for the last few month now. In the decoration to include most of
>>> the features that were in the "nitrogen" windeco; in the style, mostly
>>> to fix bugs. For kde 4.4, I'd like to add a bunch of (on/off) switchable
>>> "animations" to the style, cause I've always disliked "instantaneous"
>>> state changes. I'm thinking of
>>> - 'smooth' (as opposed to immediate) glow of buttons, sliders,
>>> scrollbars, everything that glows, on hover
>>> - same thing when getting focus
>>> - smooth transition between active and inactive state
>>>
>>
>> Out of interest, have any UI designers given their input on this subject?
>>
>> I personally don't like the animations because it makes everything
>> feel very 'heavy'.  E.g. if I hover over a scrollbar/button and there
>> is a delay before it's glowing, I'm going to feel that the machine is
>> being slow and unresponsive.
>>
>> IMHO
>>
> just to be precise: we're talking of 50 -> 200 msec (max) transitions,
> and naturally, they could be switched off.

Just to be clear, by the time you're talking about 50msec transitions,
on a 60hz display, you're talking 3 frames.  If you can do an
animation is 3 frames, then sure go for it.

John
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On October 22, 2009, Hugo Pereira Da Costa wrote
> I think that well-done animations, meaning: they represent a "natural"
> behavior of the object you interact with (as opposed to: my widgets

this is what we've been calling "organic interfaces" :)

> Now, as to define what is "natural" animation, is where discussing with
> people comes into play (hence the email)

the "rules" we have in plasma are that in a perfect world:

* nothing disappears without a transition

* nothing appears with out an entrance

* nothing turns into a representation of itself, e.g. when dragging you drag
the object not an icon that represents the object

* an item that is perceived to be "The same item" such as a tooltip or a
selection area should not appear and disappear, but travel and adjust itself
so that the illusion that it is "The same item" is reinforced

* when manipulating a visual object, allow the user to manipulate the object
itself or in the worst case something attached to it that can be perceived as
being  part of it; changing something by going into a separate interface is
poor form (the exception to this is many of the pure data settings found in
configuration dialog)

* things should get smaller when they need to, and get bigger when they can;
showing more information or less is optional, but things should have as big a
range of possible sizes as possible

these are the guidelines we're trying to follow when it comes to such things;
the common idea is to pander to visual and mental perception traits that are
generally consistent across our species.

--
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


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

On October 22, 2009, John Tapsell wrote:
> I see no reason why the same doesn't apply here.  You need instant
> response and highlighting.  You can then animate something
> additionally on top if you wish, but the initial highlighting must be
> near instant (e.g. around 50ms).

yes, there's a difference is between visual feedback and result-on-action. and
you'll see this is exactly what we do in the plasma tasks widget, btw.

you can also screw it up by starting an animation that is the result of
passive focus (e.g. hover highlight) too quickly giving it a feeling of being
too jumpy.

--
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


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Aaron J. Seigo wrote:

> On October 22, 2009, John Tapsell wrote:
>  
>> I see no reason why the same doesn't apply here.  You need instant
>> response and highlighting.  You can then animate something
>> additionally on top if you wish, but the initial highlighting must be
>> near instant (e.g. around 50ms).
>>    
>
> yes, there's a difference is between visual feedback and result-on-action. and
> you'll see this is exactly what we do in the plasma tasks widget, btw.
>
> you can also screw it up by starting an animation that is the result of
> passive focus (e.g. hover highlight) too quickly giving it a feeling of being
> too jumpy.
>
>  

In fact Lucas (lmurray) and I had this discussion about the windeco
"shadow" transition. (He complaining that it looked as if the active
window glow would start with a delay after you actually activate the
window). The conclusion was that the first "frame" of your animation
should not be the inactive state, but some (well tuned) fraction of the
final state. Say that if your animations has four/five frames (which is
typically what we get for active/inactive oxygen shadow/glow), the first
one should be about 20% of the final state.
I think the result is quite satisfying IMHO.

To Aaron: the above is actually not implemented in nitrogen style, which
contributes partly to the slowness you mention.

(and then also you want to optimize your code to minimize the delay
between the user taking action and the actual animation to start, but
this is true even without animations).

(btw with QTimeLine and QAnimation, its not you to decide how many
frames you get. You just set the total animation length and Qt tries to
cope with it. Big improvement wrt old QTimer).


> ------------------------------------------------------------------------
>
>  
>  
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>>>      

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[Markus-84]

Am Freitag, 23. Oktober 2009 02:03:15 schrieb Hugo Pereira Da Costa:
> (on/off) switchable "animations" to the style

I like the idea, but why not doing that using slide controls? Give the users
the option to choose freely between 0ms (instant) and eg. 500ms and then tweak
the defaults during the beta cycle.

Markus
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[Aleix Pol-2]

On Fri, Oct 23, 2009 at 4:00 AM, John Tapsell <johnflux@...> wrote:

2009/10/23 Aaron J. Seigo <aseigo@...>:

> On October 22, 2009, John Tapsell wrote:
>> I personally don't like the animations because it makes everything
>> feel very 'heavy'.  E.g. if I hover over a scrollbar/button and there
>> is a delay before it's glowing, I'm going to feel that the machine is
>> being slow and unresponsive.
>
> this has everything to do with the style, framerate and speed of the
> animation. animations done poorly make things feel heavy. animations done
> right make things feel responsive.

Usually I'd agree - for most animations 300ms is considered
nearly-instant.  However this does not apply for clicking/hovering
animations.  When typing on a keyboard, for example, a delay of a mere
100ms between touching and response is already considered to be felt
as a very heavy keyboard.  60ms is tolerable, and most people prefer
30ms responses.

I see no reason why the same doesn't apply here.  You need instant
response and highlighting.  You can then animate something
additionally on top if you wish, but the initial highlighting must be
near instant (e.g. around 50ms).

John

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

By responsiveness you mean that "something happens", it is not necessary that everything happens. The eye just needs some feedback that what was predicted happened. It's not the same as in keyboard responsiveness, because you say that it feels slow if you press a key and _nothing_ happens for 50ms, but nothing is not the same as some-animation-started.

I don't think 200ms is too much.

Aleix

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> - make a fork of oxygen in kde-playground ?
>>    
>
> i'd suggest making a branch and merging changes over as they become stable and
> at least moderately tested (technically, aesthetically and usability,
> preferably)
>
>  
Newbie question:
how do I create a directory for branching ? Do I need special
permissions for that ?
and where ?
kde/branches/work/oxygen-style-animated ?
kde/trunk/playground/artwork/oxygen-style-animated ?
Or any better suited place/name ?

> ------------------------------------------------------------------------
>
>  
>  
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>>>      

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[John Tapsell-3]

2009/10/23 Aleix Pol <aleixpol@...>:

> On Fri, Oct 23, 2009 at 4:00 AM, John Tapsell <johnflux@...> wrote:
>>
>> 2009/10/23 Aaron J. Seigo <aseigo@...>:
>> > On October 22, 2009, John Tapsell wrote:
>> >> I personally don't like the animations because it makes everything
>> >> feel very 'heavy'.  E.g. if I hover over a scrollbar/button and there
>> >> is a delay before it's glowing, I'm going to feel that the machine is
>> >> being slow and unresponsive.
>> >
>> > this has everything to do with the style, framerate and speed of the
>> > animation. animations done poorly make things feel heavy. animations
>> > done
>> > right make things feel responsive.
>>
>> Usually I'd agree - for most animations 300ms is considered
>> nearly-instant.  However this does not apply for clicking/hovering
>> animations.  When typing on a keyboard, for example, a delay of a mere
>> 100ms between touching and response is already considered to be felt
>> as a very heavy keyboard.  60ms is tolerable, and most people prefer
>> 30ms responses.
>>
>> I see no reason why the same doesn't apply here.  You need instant
>> response and highlighting.  You can then animate something
>> additionally on top if you wish, but the initial highlighting must be
>> near instant (e.g. around 50ms).
>>
>> John
>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> unsubscribe <<
>
> By responsiveness you mean that "something happens", it is not necessary
> that everything happens. The eye just needs some feedback that what was
> predicted happened. It's not the same as in keyboard responsiveness, because
> you say that it feels slow if you press a key and _nothing_ happens for
> 50ms, but nothing is not the same as some-animation-started.
>
> I don't think 200ms is too much.

I get your point, but disagree.  I think the only way to settle it
really is to sit users down and ask them which they prefer.  I really
expect that users will feel 200ms is too slow.

:)

John
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[Aleix Pol-2]

On Sat, Oct 24, 2009 at 3:33 AM, John Tapsell <johnflux@...> wrote:

2009/10/23 Aleix Pol <aleixpol@...>:

> On Fri, Oct 23, 2009 at 4:00 AM, John Tapsell <johnflux@...> wrote:
>>
>> 2009/10/23 Aaron J. Seigo <aseigo@...>:
>> > On October 22, 2009, John Tapsell wrote:
>> >> I personally don't like the animations because it makes everything
>> >> feel very 'heavy'.  E.g. if I hover over a scrollbar/button and there
>> >> is a delay before it's glowing, I'm going to feel that the machine is
>> >> being slow and unresponsive.
>> >
>> > this has everything to do with the style, framerate and speed of the
>> > animation. animations done poorly make things feel heavy. animations
>> > done
>> > right make things feel responsive.
>>
>> Usually I'd agree - for most animations 300ms is considered
>> nearly-instant.  However this does not apply for clicking/hovering
>> animations.  When typing on a keyboard, for example, a delay of a mere
>> 100ms between touching and response is already considered to be felt
>> as a very heavy keyboard.  60ms is tolerable, and most people prefer
>> 30ms responses.
>>
>> I see no reason why the same doesn't apply here.  You need instant
>> response and highlighting.  You can then animate something
>> additionally on top if you wish, but the initial highlighting must be
>> near instant (e.g. around 50ms).
>>
>> John
>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> unsubscribe <<
>
> By responsiveness you mean that "something happens", it is not necessary
> that everything happens. The eye just needs some feedback that what was
> predicted happened. It's not the same as in keyboard responsiveness, because
> you say that it feels slow if you press a key and _nothing_ happens for
> 50ms, but nothing is not the same as some-animation-started.
>
> I don't think 200ms is too much.

I get your point, but disagree.  I think the only way to settle it
really is to sit users down and ask them which they prefer.  I really
expect that users will feel 200ms is too slow.

:)

John

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Too slow for what? I don't think anybody waits for these animations to be finished to react.

I don't think anybody is going to test that right now, anyway.

Aleix

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Am Saturday 24 October 2009 schrieb Aleix Pol:
> Too slow for what? I don't think anybody waits for these animations to be
> finished to react.
Actually you do - unwanted - mabye even unregognized, but you do.

However, you also need a short time (~80ms) just to realize that you
"successfully hovered" and animations @120-150 ms can be considered as
unobstrusive for /most/ ppl.

So 200ms is probably -a tiny bit- too long (for focus taking animations)

Animations that are /not/ the the focus of action, the animation can be longer
(as there's a good change that the user doesn't stare on that element anyway
and softer animations (outside the direct viewfield) are even less obstrusive
than harsh changes.

Fade changes can happen faster than slide changes w/o being seen as "fast",
i.e. a 100ms crossfade is a calm animation, while even a 200ms 24px slide is
not

Thomas
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[Dmitry Suzdalev-2]

Hi!

On Saturday 24 October 2009 05:33:21 John Tapsell wrote:
> I get your point, but disagree.  I think the only way to settle it
> really is to sit users down and ask them which they prefer.  I really
> expect that users will feel 200ms is too slow.
>
> :)
John, did you actually try the nitrogen style that was mentioned at the start
of the thread? Does it really feel slow for you?

I tried it and find it perfectly ok and nice. I'm just interested to know are
you basing your replies on real experience with this style or on theory? :)

Not saying theory is bad, but sometimes it leads to rather long threads, which
in the end turn to do nothing practical ;)

Cheers,
Dmitry.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[John Tapsell-3]

2009/10/24 Dmitry Suzdalev <dimsuzkde@...>:

> Hi!
>
> On Saturday 24 October 2009 05:33:21 John Tapsell wrote:
>> I get your point, but disagree.  I think the only way to settle it
>> really is to sit users down and ask them which they prefer.  I really
>> expect that users will feel 200ms is too slow.
>>
>> :)
> John, did you actually try the nitrogen style that was mentioned at the start
> of the thread? Does it really feel slow for you?
>
> I tried it and find it perfectly ok and nice. I'm just interested to know are
> you basing your replies on real experience with this style or on theory? :)
>
> Not saying theory is bad, but sometimes it leads to rather long threads, which
> in the end turn to do nothing practical ;)

I haven't tried it :-D

But, for example, when you press alt-tab to switch applications, the
window switcher animates between which window in the list is
highlighted.  I feel that it's now a lot 'heavier'.  That's a concrete
example of an animation that I feel is way too slow.

John
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Hi,

Newbie question. What's the policy on designing user interfaces (Qt
based) in KDE:
use UI files rather than brute force c++, or indiferent ?
I personally hate Qt designer (for my own reasons) and have been used to
design my UI in brute force c++.
Are there some known disadvantages with this approach ? Or historical
reasons against it ?

Thanks in advance,

Hugo
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[Wagner Sales-2]

Hi Hugo,

This advice are based on my own experience, since this, don't take an
"official" advice.
If you have GUI that's changes a lot dynamically at run time, may be
will be better not use Designer. If not, Designer ( yes, I know you
hate :) ) will be a good friend.
The current Designer's approach are very better than the old Qt 3
Designer's approach. Try to do a little experience with Qt Creator and
Designer to see how the things are done.
I think after some time you'll be very surprised and a lot of time can
be saved. I think more easy to do and and maintain complex but static
GUI by using Designer.

Regards,

Wagner

2009/10/27 Hugo Pereira Da Costa <hugo.pereira@...>:

> Hi,
>
> Newbie question. What's the policy on designing user interfaces (Qt based)
> in KDE:
> use UI files rather than brute force c++, or indiferent ?
> I personally hate Qt designer (for my own reasons) and have been used to
> design my UI in brute force c++.
> Are there some known disadvantages with this approach ? Or historical
> reasons against it ?
>
> Thanks in advance,
>
> Hugo
>

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<