[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