I feel configure events and requests are messed up

[Giovanni Campagna]

Il giorno ven, 09/09/2011 alle 09.30 +0200, Benjamin Franzke ha scritto:
> 2011/9/9 Giovanni Campagna <scampa.giovanni at gmail.com>:
> > Il giorno gio, 08/09/2011 alle 17.36 -0400, Matthias Clasen ha scritto:
> >> On Thu, 2011-09-08 at 22:35 +0200, Giovanni Campagna wrote:
> >>
> >> >
> >> > Probably I forgot to mention, but at the Desktop Summit it was agreed
> >> > that client-side decorations won't happen, neither in KWin nor Mutter,
> >> > so the client does not need to worry about what edges it should draw.
> >>
> >> I think it is time for you to slow down and reconsider a bit.
> >> Whether client-side decorations happen in gtk and/or mutter is not for
> >> you or the kwin maintainers to decide.
> >
> > True, but I expect that if client-side decorations won't happen in KDE,
> > they won't happen in GNOME as well, as we don't want another
> > incompatibility, plus all the code duplication in Gtk, Mutter, Qt and
> > whatnot.
> > Nobody complained last time I raised this point in gnome-shell-list, so
> > I understood that the GNOME community was not against keeping
> > server-side windows.
> > Of course, there is still plenty of time for discussions, but after a
> > BOF where this was the most prominent issue, and after reaching
> > consensus even with the one wayland dev present, who was original in
> > favour of CSD, I considered it closed.
> 
> I guess you mean me, so thats not true.
> I've never agreed with those "arguments" [offtopic] about enforcing
> server side decorations
> (in a god-like behaviour) to prevent inconsistency, nor with server
> side decorations at all,
> and always stated we want CSD:
> As Matthias said, KDE nor Gnome shouldnt think they are dictators, nor
> behave that way.
> Starting a BoF with "Its decided that we do server-side decorations" ridiculous.
> [/offtopic]
> Also stop implying server-side decorations in general arguments, this
> is really not decided.

Yes, I meant you. I'm sorry if I misunderstood (probably it was because
we were out of time and didn't really finish the discussion).
I'm not saying we should dictate anything, but, being the desktop (shell
and compositor), we're allowed to "make the rules" and expect
applications to comply - except that different desktop should (should!)
have similar rules, to aid in app development. If KDE is not doing CSD,
GNOME cannot do them blindly: someone has to change their mind.
Furthermore, server-side decorations are what we currently have, and
therefore it is reasonable to keep them for a first step in direction of
wayland. Then, once mutter-wayland is complete and wayland is stable, we
can think of moving decoration code down to Gtk and Qt.

Anyway, I'm not convinced that client-side decorations are technically
superior, therefore I'll start a new thread, to have a final discussion
with all interested parties. Mutter makes some deep assumptions on
framing, for sizing policies and for event handling, and I'd like to
clear them out before going further.

> You're saying cogl/gdk communicatiion relies on libX11 providing state.
> We had similar problems in libEGL, wherefore libwayland-egl was born.
> Nowadays wayland-egl became pretty small (it had more tasks in the beginning),
> and we want to get rid of it by extending EGL to take over the rest.
> The main Problem here is that EGL, cogl, gdk are all designed against
> existing underlying libs (e.g. x11),
> and the wayland way of _not_ caching isnt respected yet.
> I dont think wayland has to be fixed to do this, just because older
> software did it that way,
> but the wayland users need to be adjusted.
> To conclude, I see relying on wayland to chache state as broken.

Why do you think it is so broken to have wayland-client cache state, as
long as it is automatically updated when externally changed, the API
users have some notification of change, and the code is completely
auto-generated?
If a toolkit does not want to use cached state, it can keep consistency
with the notifications. On the other hand, toolkits that want to rely
more on libwayland-client are allowed to do so.

Giovanni


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110909/aa7ff26e/attachment-0001.pgp>