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

[Erkin Bahceci]

On 7/7/07, Erkin Bahceci <erkinbah at gmail.com> wrote:
> On 7/7/07, Alyssa Hung <deciare at isisview.org> wrote:
> > 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?
> >
>
> I identified how to solve the situation to accommodate everybody. But
> I will have to either modify match.c in compiz, or do it in the
> Workarounds plugin and include Workarounds in plugins-main. I bet
> David would want the latter solution, and I prefer that too. So my
> question is, can we include the Workarounds plugin in plugins-main?
>
> - Erkin
>

I can also do the workaround in Animation, but I think it belongs in
the Workarounds plugin.