New XEmbed classes

[Andreas Aardal Hanssen]

Hi, Leon.

On Fri, 14 Nov 2003, Leon Bottou wrote:
>I just had a look.
>There are nice things here.
>I particularly like:
>- the code to accept/reject a client is cool.
>- the way tab-focus wrap around is detected
>- the support for the _XEMBED_INFO property

Okay; thanks. I've tried to move away from the original code as much as I
could, as I think it's a real mess. Hoping that QtXEmbed can be easier to
maintain. We just need it to get up to speed.

>I spotted a few problems as well:
>- See the recent discussion on kfm-devel about the use of XAddToSaveSet
>and the
>termination of embedding.

Yes, termination of embedding has been an issue for me too.  Calling
XAddToSaveSet on a client does require the client to react correctly when
the container shuts down. But it also gives XEmbed clients the option of
staying on the desktop when the container closes.

I couldn't really see the benefit of a client not being destroyed
somehow when the container died, especially if the client does not speak
XEmbed. :/ Are you aware of any examples where this would be useful?

>- Not all items in the focusData lists are focusable.
>  See recent changes in qxembed.cpp.

I looked up the changes, but couldn't find anything about this; what part
of the code is affected by this issue?

>There is a deeper issue regarding client support:
>* QXEmbed tries to make all toplevel windows support XEMBED.
>  If it was a part of Qt, all Qt applications would then be embeddable.

I'm not following here; all X11 windows are "embeddable", but the only
windows that support XEmbed controlled by Qt / these new classes are those
that inherit QtXEmbedContainer.

Where is it that QXEmbed tries to make windows support XEmbed?

>* The new XEmbed class define a class for XEMBED client windows.
>  The main window must then inherit this class to make an embeddable
>application.
>  This is closer to what is done in GTK.
>Personally I prefer the first option.
>But I can understand other tastes.

The first option, are you referring to the existing QXEmbed classes? The
client->container concept maps very naturally to the idea of having a
seperate class for the client and the container. The code looks, IMHO,
much nicer this way, and from and API stand point it's easier to use for
people who haven't used XEmbed before.

I myself had to spend lots of time trying to figure out how to use the
existing QXEmbed class in KDE. :-P

>Lately I added a lot of documentation and fixes into QXEmbed.
>Please feel free to look at it.  I cannot be certain that I documented
>all the pitfalls, but I discussed a lot of them.

I see. They are very interesting. I'm working myself through the change
log since Matthias' 1.1. There haven't really been that many changes to
qxembed.*, it seems.

>There might be GPL-code versus pure-trolltech-code issues.
>Were this to become a problem, I would be glad to
>relicense my changes under a BSD-like license or make
>adequate arrangements.  The other contributors can be
>retrieved in the CVS log.

These QtXEmbed classes are released under LGPL (see the header)), so this
should not be a problem. I would be glad to aid in maintaining these
classes, were they to be part of KDE. I'm sure that I have something to
add to the XEmbed discussions.

On a side note;

(1) I see these Lnnnn tags in the comments; what are they for?
(2) Is it common for discussions about XEmbed to take part in a list like
KFileManager dev?

Andy :-)

--
Andreas Aardal Hanssen - ahanssen at trolltech.com
Trolltech AS - Waldemar Thranes gt. 98 N-0175 Oslo, Norway