[Konsole-devel] [PATCH] #83974 - incorrect WM_CLASS in Konsole

[Fredrik Höglund]

On Friday 30 July 2004 20:20, Waldo Bastian wrote:
> On Friday 30 July 2004 17:33, Lubos Lunak wrote:
> >  Hello,
> >
> >  currently command-line arguments parsing, taskbar grouping or kwin's
> > window specific settings don't work for Konsole, because of the way the
> > support for real transparency is implemented. The attached Konsole patch is
> > a hack fixing the WM_CLASS property, but I don't see anything that could be
> > done about qAppName() or the arguments parsing other than changing Qt.
> >
> >  Fredrik, has this been reported to TT, will Qt4 have some support for the
> > ARGB visual? The qt_init* code in the Qt4 preview looks the same like in
> > Qt3 to me.
> 
> I rather revert the ARGB stuff in Konsole for KDE 3.3 since it's not only the 
> WM_CLASS property that doesn't get handled correctly, Qt command line 
> arguments aren't parsed either. I don't want hack on hack in konsole, better 
> make sure Qt gets proper support for ARGB.

I personally think it's a better idea to make the --noargb command line option
the default setting, and make konsole use the default KApplication constructor
when the user hasn't specified that he/she wants to use the ARGB visual.

We could mention in the documentation that this feature is experimental and
has some issues.

I don't know which Qt command line options you feel are so important we
can't live without them. Specifying fonts and colors don't work with KDE
applications anyway, and the options for setting the geometry, caption and
style etc. still work since those are handled by KApplication.

Given that the first Xorg release with composite support is scheduled for
August, and the possibility that there will be a long delay before KDE 4 is
released, I don't think reverting this feature over this issue will be popular
among users.

In my opinion, with Lubos' patch, this is a minor issue at best.

> I think the extra KApplication constructor that was added for KDE 3.3 should 
> also be reverted since it is inherently broken.

Since that constructor only provides access to a QApplication ctor I don't
think it can be considered more broken than the one in Qt - you get exactly
the same behavior. The drawbacks of using it should probably be mentioned
in the documentation however.

> Cheers,
> Waldo