unity-design team mailing list archive
-
unity-design team
-
Mailing list archive
-
Message #02690
Re: Fwd: Open Letter: The issues with client-side-window-decorations
On Mon, 2010-06-07 at 18:09 +0200, Martin Gräßlin wrote:
> Am Montag 07 Juni 2010, 17:11:32 schrieb Ted Gould:
> > Sure, but I think that implies that the change doesn't create a
> > "permanent split" more a "temporary split." There's no reason that Qt
> > couldn't support CSD and I imagine that they largely do because of their
> > device support which won't have a window manager (no X).
>
> But there is also no reason why Qt should implement it. Do you think Nokia
> will spent money on implementing it just because Ubuntu thinks they need CSD?
> Especially if KDE tells them "We don't need it, we don't want it"?
I think that Nokia will add it eventually because there are platforms
that don't have window managers and separate decorations and Qt's
overall goals are to be cross-platform and not only the KDE toolkit.
> And even if
> Qt added support for it: what about all the other toolkits? You don't think
> they will all start to add it, just because Ubuntu thinks it's needed, do you?
I think that with increased popularity the speed of growth in the Linux
desktop is growing exponentially. I think that applications that aren't
using one of the major toolkits will quickly find themselves out of sync
visually with the rest of the desktop no matter what. Sure, you can
point to CSD as a realization of this, but in reality almost everything
Linux desktop-wide is creating the same effect. Applications that want
to be promoted in distros really need to be in a major toolkit.
<snip>
> > Let's look at Chrome. They've created a very nice experience by
> > integrating the top level tabs with a half-height title bar. This isn't
> > possible without CSD. But, today it's on its own "theme island" and
> > there isn't a way that they could be consistent if they wanted. To do
> > this next generation of integration, we need support in to toolkit to
> > make it consistent.
>
> No we don't! KWin supports window tabbing and I plan to provide a public API
> to interact with the window tabs from within the applications for 4.6. And
> window tabbing is way more useful than application tabs. With Chrome I can
> just group windows of the same application, but I can't group e.g. one website
> with an editor, because they semanticaly belong together.
I think that you're missing my point here, it isn't about tabs. But
about applications being able to use the integration between these area
in new and interesting ways. One example is how Chrome had some really
neat ideas about how tabs should work. They won't be the last. Saying
that KWin has solved the tabs problem does not mean that the generic
issue is solved.
> > On the integration front, there is currently no way to reasonably make
> > the window have a texture that integrates cleanly with the title bar.
> > Even something as simple as a hash pattern would likely end up looking
> > awful much less something sophisticated like the brushed metal look in
> > many OS X applications. I'm not saying we should do either of those,
> > but the fact that we can't is a little ridiculous.
>
> And also this is not true. Just again look at KDE. We are able to blend the
> widget style with the decoration. In the same way we would be able to do a
> pattern or a Mac OS X like theme. E.g. look at Bespin [0].
Bespin is a great example. Why can't the application generated circles
extend into the title bar? I think it would be really cool if they
could.
--Ted
> [0]: http://kde-look.org/content/show.php/Bespin?content=63928
Attachment:
signature.asc
Description: This is a digitally signed message part
References