If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Who cares? Qt is still fucking freedom. The CLA is used to circumvent software freedom. Qt is all about commercial licensing. Fuck Qt.
Funkstar, seriously, enough of the Qt hate man. Qt is under the LGPL with a CLA, yes. HOWEVER the KDE Free Qt Foundation agreement between Digia and KDE ensures--via a legally binding contract-- that if the LGPL version of Qt were to ever fall behind, the KDE Foundation would receive the latest version of Qt under the BSD license.
That right there is the safety net. You can hate on Qt all you want but the reality is its a non-issue because the moment a BSD version of Qt hit the web, "Selling Qt" would no longer be a business model. Its in Digia's best interest to keep the LGPL version of the toolkit updated and continuing.
Yeah, right. Mixing Qt, GTK, EFL, etc. titlesbars will be so very consistent…
client side decorations are not evil by any means if you actually bother in understand them you will see is a better solution that is X11 today.
current X11 limitations:
* drawing paths (decoration and widgets) are actually a mess of hardcore API and protocols extension since this was not part of the original X11 protocol
* Window title are handle by isolated apps and normally are the compositors too, hence each DE enviroment implemented their own(kwin/metacity/e17/compiz/etc)
* title bars and windows are separated X11 objects with lots of hacks included
* everything in the screen with X11 is X11 api + extension and since every DE use a different toolkit wich uses this API differently at C/C++level, hence requiring ABI compatibility or bridges to keep visual consistency(almost non existant today)
* opengl compositing is alien to X11 core protocol(improved with lots of extension and other subsystems API but still not a first class citizen)
* X11 acceleration is at best partial for modern requirements and is very dependant on the driver
* X11 is the middle and intermediary of another middle man that knows an intermediary
thank to this limitations and the fact that the X11 never included a proper compositor each toolkit had to implement their own, forcing you to use API/ABI compatible visuals normally found only when the same TK is used (Qt/kde apps only look good if you run KDE and Kwin, same for efl/gtk/etc), and ofc since every TK has its own compositor and drawing API you get a salad of visuals if you dont use the correct for every app(GIMP is ugly as hell in KDE and calligra make you wanna puke when you are in Gnome3 shell for example).
Wayland pros(some in current development)
* in wayland everything is just a TEXTURE, thereis no low level API, no objects, no ABI, no middleman, no extensions, no visuals dependency, no drawing process or server.
* wayland is drawing language free, you can draw with G/ASM, Opengl, OES, DirectX(if you had a driver ofc) or any other wicked way you want
* wayland is just an assistant that let you talk directly to the a GPU Framebuffer in a coordinated way, nothing else
* wayland is a good damn good compositor and it works at framebuffer level inside the GPU automagically(no extensions or API/ABI or server in the middle)
* window and windows decorations once again are just textures
so with wayland the next predicaments are true
* each toolkit could render the app widgets/window & decoration directly with no need for kwin/metacity/etc except for protocol and events handling(so you kde app look like in running in KDE regardless that you are running gnome3)
* 1 app could look the same regardless the DE and toolkit(true for widget and decoration) just drawing directly in any form you like(GL GLES DX ASM)
* if DE enviroments agree in using a common drawing API that interfaces with Wayland protocol(cairo, GL, etc) to draw widgets/decorations, the DE enviroments just need to implement the skining that can be shared even, so the app looks native regardless the toolkit it was written with and even the themes can be written in a easy lang(js, qml, python, CSS,etc) and loaded by any DE enviroment so your apps looks the same in any DE as long you set same theme or even better 1 theme engine that work in any DE so regardless the TK you used to write your app or the DE you are using all apps will use the selected theme
* wayland dont require anything and is not a process, it just a protocol library aka put a kernel load drm modules and get mesa(if you wanna draw in GL/GLES/openVG/etc) and voila
* wayland dont impose session API/ABI so kdm/gdm/etc just will be needed for da eye candy cuz the session can be handled using PAM/KRB/AD/etc in the background and you dont need to be root for it
* wayland dont handle network rendering, which is very good since is 1500billions times better at TK level and freaking lot more secure than X11 network security blackhole(i know is useful if you use it, so stay with X11 until TK implement theirs)
in easiest words wayland behave like libusb or the tcp library, is just an interface that allows you to talk directly to a piece of hardware in a sequence that the piece of hardware can understand but what you sent to the hardware later is entirely up to you in userspace level (like in tcp/IP library doesnt tell you how to torrent just how to package it in tcp/IP format so the hardware can trasmit/receive whatever your libtorrent library generate in userspace effectively), so in wayand everything is client side not just the decorations aka framebuffer background/widgets/windows/decorations/apps/etc all is client side without execption
Since you probably follow wayland more than most i have a question. What is still missing for desktop use. There was a post by Pekka sometime ago but i believe things have moved forward since that.
What's missing really is some shell protocols, or extensions for better desktop integration. (such as minimize, which is not yet merged and I'm sure there might be a few other such protocols that I can't think of right now...)
Some toolkits don't seem 100% complete, as they don't support features that Wayland has, such as the drag and drop protocol, or the onscreen keyboard protocol. And then there is the issue that QT5 is ported to wayland, so QT4 apps need to be ported to qt5, and many GTK apps have bugs because some of them happen to make X calls directly along with GTK calls when GTK is using the wayland backend causing them to segfault.
If they are not ported to be Wayland native, then they can use the integrated xwayland server, which currently works, but needs some features, and needs to be integrated to work better with Wayland, so that dnd works, and subwindows such as menus don't appear in random parts of the screen.
Are you using "fucking" as a verb or an adverb here?
In case anyone is still confused, Weston isn't used by GTK or Qt...ever. Or, rather, it is completely separate from the two tool-kits. In other words, Qt and GTK will implement window decorations, controls, etc., separately from Weston, because they each implement their own Wayland compositors. OTOH, Qt and GTK apps will run under the Weston compositor fine, because the Wayland protocol allows this (compositors running under other compositors). And, I would imagine, in the future (when/if xorg becomes the fallback) Weston will be replaced by "root" compositors similar in design to GDM, KDM, LightDM.
Weston will still live on, because it is the "reference" compositor.
In case anyone is still confused, Weston isn't used by GTK or Qt...ever. Or, rather, it is completely separate from the two tool-kits. In other words, Qt and GTK will implement window decorations, controls, etc., separately from Weston, because they each implement their own Wayland compositors.
That's the thing about client side decorations, the window manager doesn't impelemt them. So altough both KDE (KWin) and Gnome (Mutter) will have their own Wayland compositors it will have nothing to do with the window decorations (altough KWin might implement server side decorations even on Wayland). It's the toolkits themselves that implemet them; so they are the same no mater what compositor you are using.