[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Embedding NEdit (was Re: KWin::info.pid)
From:       Nathan Gray <n8gray () caltech ! edu>
Date:       2003-06-27 6:11:08
[Download RAW message or body]

Lubos Lunak wrote:

> On Thursday 26 of June 2003 00:11, Nathan Gray wrote:
>> Lubos Lunak wrote:
>> > On Wednesday 25 of June 2003 00:52, Nathan Gray wrote:
>>
>> I understand now.  It would be nice if the documentation was a little bit
>> more clear about what's required of a client for it to work.  As it
>> stands, the only docs for pid() are in NETWinInfo and they just say
>> "Returns the
>> process id for the client window."  It would be more useful if they said
>> "Returns the process id for the client window if it supports the
>> _NET_WM_PID property, 0 otherwise."
> 
>  In the documentation for the class itself it's said that it's for the
>  NETWM
> spec (a.k.a. EWMH , http://www.freedesktop.org/standards/wm-spec). It
> would be way too much repeating to say it in comment for every method.

With all due respect, I disagree completely.  The wm spec doesn't say
anything to implay that implementations will return zero if a property
isn't supported.  To say that this method returns the pid of the window is
a documentation bug.  Also, in the age of hyperlinked documentation it's
not realistic to think that a user will read all of the documentation for a
class.

>> >> If anybody knows what a client needs to do to make the code
>> >> above work please let me know.  In the meantime I'll try to figure it
>> >> out for myself.
>> >
>> >  I personally think that embedding an application that itself doesn't
>> >  support
>> > being embedded will always be an ugly hack, whichever way you do it.
>>
>> I agree.  I'm hoping there's a way to support nedit in KDevelop without
>> embedding it, but for the moment that's the way the kpart works.  I am an
>> NEdit developer, though, so if it's not too hard to make NEdit embeddable
>> I can try to work on that end too.
> 
>  This indeed simplifies things a lot, because then the comment of mine
>  above
> talking about ugly hacks doesn't apply here. I suggest you add support for
> embedding in the app itself, and stay away from hacks.

That would be ideal, but I haven't investigated it much yet so I don't know
how plausible it will be.

>> > For
>> > this NEdit case, you could try searching windows for NEdit's WM_CLASS
>> > property (xprop | grep WM_CLASS to see what I mean). The Xlib function
>> > is called XGetClassHint(), and you could possibly also read
>> > http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5 , and be aware of
>> > the fact that many apps have this screwed up, and set it differently
>> > than the specification says.
>>
>> Unfortunately that will just identify *any* nedit window, and I need to
>> be
>> able to identify the specific window that I launched.  I cooked up a
>> patch for nedit to support the _NET_WM_PID property but it looks like
>> it's unlikely to get in before the imminent release of nedit 5.4.
> 
>  Have you already managed to embed NEdit at all? I mean, at least as a
>  quick
> hack, just to see how it works? I'm asking because the XEmbed spec talks
> about problems with keyboard focus, etc.
> (http://www.freedesktop.org/standards/xembed/html/rationale.html), how
> XEmbed solves them, and I'm wondering whether you saw any of those
> problems, since I'm assuming NEdit is not a really embedable using the
> XEmbed protocol, but
> it's embedded using the plain protocol  in QXEmbed. Perhaps you'll have to
> add client side XEmbed support to NEdit (**), in which case it would be
> simplest to add --embedid <wid> argument to NEdit, and when it would be
> launched with this arg, it would automatically embed in the given window.

Yes, I've managed to embed it and I've seen focus problems.  I'm just
scratching the surface right now.

>  Even if you wanted to use server side embedding (i.e. whatever launches
>  NEdit
> also embeds it, the way you're trying to do it now), I still suggest you
> add --embed argument, and make NEdit set itself up in such case, but
> instead of showing the window, it should only report its mainwindows ID
> (e.g. print "EMBED WID: xyz" to stdout). The embeder then can read this
> ID, and embed the window, without having to search for it. This will also
> avoid the flicker when the mainwindow shows for a short while as a
> toplevel window, and similar details.
> 
>  (**) I've actually never really used QXEmbed, even though I know the
> internals. I suggest you ask e.g. the KVim people, since they're doing the
> same thing you're trying to do, they should be able to help you with the
> practical side of things.

I've seen some e-mails about QXEmbed w.r.t. KVim.  It sounds like QXEmbed
has some big problems that are sorted out in the latest CVS version.  This
puts a crimp in my hopes for developing an embeddable Nedit, since I'm not
running KDE from CVS and I'm not in a big rush to do so.  I'm going to see
if I can find a non-embedding solution instead, for the time being.

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]