Re: Namespace

Matthias Ettrich wrote:
> > >I want to extend the specs a bit for KDE-2. We need for example support for
> > >"docking" (the small 16x16 icons in the panel near the clock).
> > >
> > >I will design a protocol that fits into the spirit of the NET protocol.
> > >Obviously we will not have the time to agree on that, but I'm wondering what
> > >name one should choose for extensions like that?
> > >
> > >Possibilities are _KDE_xxxxx or _NET_KDE_xxxx
> > >
> > >I would prefer the second one.

Even if it is _KDE_xxxxx, you can put your hint into _NET_HINTS (or
state). _NET_ hints are meant to be extensible. This is the reason I'd
like to see all arbitrary enumerations/bitmasks be atoms.

> > Well, the first question (coming from the uninformed me) is "what does this have to do
> > with the window manager"?
> I was asked to support this via a simple window hint in KDE because it's
> extremely easy this way to support docking from any application written with
> any toolkit.
> A docking window is still a window, managed by the window manager but might
> appear within some other application. This concept gives a lot of stability:
> the panel may die or be restarted, the app may show the dockwindow before the
> panel has been started or later, etc. It will all magically work without any
> higher-level ipc mechanism. Docking is done via XMapWindow, undocking via
> XUnmapWindow. Can't be easier.

This should only be used for windows that appear as normal windows in
nonconforming WMs. For embedding components, this should not be used.
(There should be a target for docking (an ATOM?)).

> Since KDE and many KDE application will use this protocol and it's so easy to
> support in the WM, I expect the majority of window managers to support it
> anyway after the release of KDE-2.0. So I don't really care if we cannot put it
> into the specs now.

I will support it if simple to do.

... GUI: WPS.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]