Qt 5.1 To Feature Improved Support For Wayland

[smitty3268]

All Wayland proponents can do is to claim that it will exist some day.

/sigh

All Wayland opponents can do is list off the stuff that isn't currently working and claim it never will.

Wayland isn't done yet. There's a lot of work to finish up before it will be usable by normal end-users. I'm not going to be able to magically add everything tonight in 1 days worth of coding. It will get there eventually, if anyone is interested in adding the feature. For something like minimizing an app, it's pretty obvious that is a feature that people will want. It will be added. Relax.

[jrch2k8]

I did not count how many of the commits are by Intel but Intel is definitively involved in porting all said toolkits to Wayland.

still i don't see your point, assuming ofc you have one to start with

your twisted logic:
intel contributes to mesa/kms/gallium/kernel/other mainstream projects? so on your logic intel should fix sabayon/fedora/ubuntu/etc because intel ppl push code to those important projects
intel contribute/colaborate with nouveau and r600g drivers, so with your logic is intel's fault that r600g is slower than fglrx and nouveau have issues supporting wayland
intel contribute A LOT in X11 too you know[hello!! keith packard works at intel ya know]? so intel is the culprit of all the X11 evilness ofc

Reality:
Wayland/weston is was started/is currently developed by X.org/mesa developers like christian and keith(that for mere casuality work for intel !!OMG) + many community devs completely unrelated to intel.So if you put 3 neurons togheter and understand that fact you will see you tend to see intel ppl in many other projects specially when involved with wayland/X11 is because those intel devs are dedicated to both projects and know lots of the internals from first hand[including many many communuty devs that you don't name because ....?] which is a great asset for developers outside X11/wayland scope to have close to them in case they need help[the same applies to KMS/DRM/Gallium/cairo/libVA/Mesa/etc dependant projects] BUT NOR WAYLAND/X11/KMS/DRM/CAIRO/PIXMAN/MESA/GALLIUM/LIBVA/FFMPEG/ETC ARE INTEL PRODUCTS OR OFFICIAL INTEL PROJECTS NOR QT/GTK/EFL/AND COMPANY ARE PRODUCTS FROM INTEL OR DERIVATED COMPANIES.

so in resume many intel OSC developers along with many community rock stars like marek or luc or tom among many good others choose to contribute and/or improve derivated projects that are linked to their main work projects to help move thing a bit faster[or simply because they want, you know!! maybe keith/paul/brian/etc love Qt/efl/gtk and contribute to it after work hours]

[Awesomeness]

I did not count how many of the commits are by Intel but Intel is definitively involved in porting all said toolkits to Wayland.

[jrch2k8]

Don't act as if Wayland was an isolated island. Wayland is an Intel project and just as Intel ported Clutter, EFL, GTK, and Qt (= the clients) to Wayland, it's therefore also Intel?s responsibility to take care about fixing usability problems resulting from Wayland.
Maybe Intel do not perceive those as problems because ? as I already wrote ? in their eyes Wayland is probably only meant for use on smartphones, tablets, and smart TVs/IVI where titlebars are simply nonexistent.

well to start im pretty sure qt on wayland is part of lighthouse project from quite some time and made it to qt5 recently, as is true that some intels devs helped with the initial wayland port of qt they are hardly the majority(digia/kde/ex-nokia are), care to link?

wayland is an isolated island, its not my fault you cant understand C code (or you are having fun trolling the thread or both) and again WESTON IS NOT FREAKING WAYLAND IS JUST A FREAKING EXAMPLE/REFERENCE COMPOSITOR, what part of your brain dont freaking understand wayland is a library and it doesnt care about your freaking titlebar because that is FREAKING CLIENT SIDE ISSUE and when the times comes KDE/E17/GNOME/Unity/etc will implement the FREAKING TITLEBAR THE FREAKING WAY IN HELL THEY FRICKING WANT, understand? or i need to make a youtube video with muppets and big big letters for you to be able to get it?

[Awesomeness]

i agree with you in the fact that toolkit need to sit and agree in a serie of standard that allow them to exploit all this features but that is outside the scope control of wayland developers cuz is a 100% client side problem and so are all the questions made in this thread ... 100% client side issues and entirely outside wayland scope.

Don't act as if Wayland was an isolated island. Wayland is an Intel project and just as Intel ported Clutter, EFL, GTK, and Qt (= the clients) to Wayland, it's therefore also Intel?s responsibility to take care about fixing usability problems resulting from Wayland.
Maybe Intel do not perceive those as problems because ? as I already wrote ? in their eyes Wayland is probably only meant for use on smartphones, tablets, and smart TVs/IVI where titlebars are simply nonexistent.

[jrch2k8]

I was referring to usage of the titlebar buttons and Kristian only mentioned plans to specify rectangle coordinates on the titlebar for the close button and provide kill support for hanging apps.

Aside from this, no implementation for getting consistent titlebar designs is available anywhere. All Wayland proponents can do is to claim that it will exist some day.
You guys better produce facts before claiming otherwise. If you all are so elite Wayland experts, go and write libdeco and prove me wrong.

wayland is not Weston, lets start here
weston is not wayland, in case you had doubts

Weston is a toy reference implementation, so developers can check how to interact with wayland within their own code(kwin/compiz/etc) and as other function weston works as an wayland test plataform/QA but both projects are 100% unrelated like Qt is not dependant of kwin, kwin just uses Qt.

As i mentioned before wayland is a protocol not a server, meaning all is created client side and rendered FB side with 0 middle mans, so how to detect hang apps or minimize or render bugs bunny snapping a windows with an Acme hammer is done/decided and rendered from the wayland client(Qt/GTK/etc) in the way the respective project find it better(and not necesarilly in the way that weston do it).

another thing is that wayland don't control what the wayland clients can do beyond handling the GPU framebuffer back and forth, again is not a server. Meaning that most likely kwin/compiz and the likes will just adapt their existing hang app detection routines to render in a wayland texture instead of an X11 object and properly inform the compositor.

Weston require this patches just for the sake of having a minimalistic C reference compositor that can do in wayland something close enough to his big brother do using way more complete codebases(Qt/gtk/etc), if you bother in read kwin code or metacity code you won't find the hang detection code to be terrificaly tied to X11 at all(beyond the fact there is a bazillion ways to detect a hung up app without even need to bother the GPU and complicate things).

so in resume:
1. wayland dont control the apps
2. wayland dont poll the apps
3. wayland dont manage windows at user level, only at fb object level
4. wayland dont handle decorations/buttons/widgets/pixmaps/porn/youtube/openoffice
5. wayland is not a compositor
6. wayland only provides low level protocol to manage efficient render in the GPU, everything else is client side
7. wayland dont decide what an app will/can/can't/wont/ever will/etc do, its just render and process input/render events
8. in wayland the compositor is not forced to render nor the renderer is forced to composite. aka Qt and GTK apps can render the decorations for their apps and kwin/compiz/shell just composite the scene without interfere in the render process
9. for wayland everything is literaly a texture and input events and that open many doors previously closed in X11

i agree with you in the fact that toolkit need to sit and agree in a serie of standard that allow them to exploit all this features but that is outside the scope control of wayland developers cuz is a 100% client side problem and so are all the questions made in this thread ... 100% client side issues and entirely outside wayland scope.

if you are literate in C code read the wayland code and you will see what i mean and if you bother in read weston code you will inmediately realize is just a reimplementation of the oprations that any well established window manager do but a lot simplier and in plain C, thing is just fine cuz is nothing more than an example well documented. After all for an window manager developer is faster see a working example of the basics for wayland API than just read API docs

[Nobu]

Objects:

Theme	{
	Name: Str,
	Desc: Str,
	i18n: File,
	Theme_Details,
	}

Theme_Details
	{
	Borders:{
		Radius: (optional) int,
		Top: color|gradient|texture,
		Right: (...),
		Bottom: (...),
		Left: (...)
		},

	Buttons:{
		(same as Borders)
		},

	Menus:	{
		(same as Borders)
		},

	Ticks:	{
		(same as Borders),
		Mark: character|texture|img
		},

	Radios:	{
		(same as Borders),
		Mark: character|texture|img
		},

	Input_Field:
		{
		(same as Borders)
		},

	Scroll_Bars:
		{
		(same as Borders)
		},

	Title_Bar:
		{
		Side: top|right|bottom|left,
		Inside_Edge: color|gradient|texture
		},

	Colors:	{
		Borders:	rgb|hsl|hexcolor,
		Buttons:	(...),
		Menus:		(...),
		Ticks:		(...),
		Radios:		(...),
		Input_Field:	{bg:(...),fg:(...)},
		Title_Bar:	{bg:(...),fb:(...)}
		}
	}

Now all we need is an actual header file which defines these objects, and a library which reads a configuration file (structured similarly to this pseudo-code) and hands this information over to the toolkit. Text in parenthesis are comments, "(...)" means same as above.

Any takers.

[Awesomeness]

You must have misunderstood Kristian or something, or I might be missing something.
With the patches that add the minimize support, I can move and minimize a frozen app, but I have to initialize it from the panel. I tested it. It works. It's even on my live cd, so you can test it if you don't believe me

I was referring to usage of the titlebar buttons and Kristian only mentioned plans to specify rectangle coordinates on the titlebar for the close button and provide kill support for hanging apps.

Aside from this, no implementation for getting consistent titlebar designs is available anywhere. All Wayland proponents can do is to claim that it will exist some day.
You guys better produce facts before claiming otherwise. If you all are so elite Wayland experts, go and write libdeco and prove me wrong.

[nerdopolis]

Likewise!


Doesn't change the fact that in the XDC 2012 video Kristian announced absolutely no plans to provide minimize support for hanging applications, only to kill them.

You must have misunderstood Kristian or something, or I might be missing something.
With the patches that add the minimize support, I can move and minimize a frozen app, but I have to initialize it from the panel. I tested it. It works. It's even on my live cd, so you can test it if you don't believe me

[Nobu]

I guess if I came in here and said "foo thought of bar input system which made baz work better than X11 or Wayland with CSD and async communication" you'd say "Oh, it doesn't exist yet and must be non-trivial so it'll never work," huh?

If we gave up on everything because it's "non-trivial" or "doesn't exist yet" then we would never have come up with arrows, let alone bows and swords. :/

edit: fyi, window rotate is a relatively trivial operation; it has been done many times in various other applications before wayland. Adopting it here would be fairly simple.