[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:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2003-06-27 8:52:48
[Download RAW message or body]

On Friday 27 of June 2003 08:11, Nathan Gray wrote:
> 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.

 The spec doesn't speak about implementations of supporting classes at all, 
and well, the method has to return something even if the property is not 
present. Patches for improving it are welcome. I'll add this to my TODO, but 
it won't get that high.

[snip]
>
> 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.

 You don't need to run KDE CVS to be able to develop with it. I myself right 
now don't have anything from KDE CVS running, only KDE-3.1.2 from packages. 
You can have KDE CVS built next to your normal stable KDE 
(http://developer.kde.org/build/build2ver.html). I personally run one X with 
stable KDE, and other X where I test KDE CVS. If I wouldn't be developing 
KWin, I'd probably even run KDE CVS apps withing stable KDE.

 Other option for solving this could be taking only qxembed.* from kdeui from 
CVS, and putting them in the application you're developing that needs them, 
ELF will take care that this version will take precedence over the one in 
kdeui. Or you could build it for LD_PRELOAD.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/

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