[FusionDev] KDE and other apps that don't follow standards well

Alyssa Hung deciare at isisview.org
Sun Jul 8 02:54:10 CEST 2007


Hello, everyone.

A series of commits were recently made to the animation plugin that fix 
numerous visual inconsistencies in Gtk+ applications. Specifically:

http://gitweb.opencompositing.org/?p=fusion/plugins/animation;a=commitdiff;h=d48d8c02b1667b805acd71fd9b5ead3dd9d45cf1
(which causes menus and combo boxes to not animate in KDE, reported as 
Bug 155 to bugs.opencompositing.org)

and
http://gitweb.opencompositing.org/?p=fusion/plugins/animation;a=commitdiff;h=a04a40458f8d98b71279a151fd820000601b4618
(which causes menus in KDE/Qt apps to use Create/Close 1 instead of 
Create/Close 2 animations)

This feels like a bit of a conundrum, because KDE isn't following 
standards by making its menus/comboboxes/tooltips type=unknown windows, 
but xine, xpdf, gitk, and other apps that the commit was intended to fix 
are _also_ not following standards. ^^;

By shifting the type=unknown around, we find ourselves in a situation 
where either KDE apps look visually consistent, or a selection of 
non-KDE apps look visually consistent, but not both.

Is there a better way to address this problem than choosing one over the 
other?

Since the number of non-KDE apps that don't conform to standards may 
potentially be much smaller than the number of KDE apps that rely on 
type=unknown, we might use an explicit list for matching Create 1... But 
the default list is quite long as it is, and it's hardly realistic to 
expect to catch everything this way.

I don't think it'd be a good idea to wait for either KDE or the 
developers of those other programs to fix it, either... I heard that 
even KDE4 still uses type=unknown for its menus/lists/tooltips, so a fix 
from them may not be coming soon.

How might we try to accommodate as many users as possible?


~Alyssa


More information about the Dev mailing list