Qt 5.1 To Feature Improved Support For Wayland

[smitty3268]

Previously it was only mentioned the compositor would know the location of the close button - if it has to know everything, that of course changes things.

@smitty3268

The current code would do as I described, no?. The better solution only matters once it is implemented.

Also, if the mentioned solution was obvious, why was it not the first to be implemented, instead of the 15sec wait and friends?

I thought it was. I know i've seen that solution discussed on the Wayland lists, so it's not unknown to the developers. If not, then I'm sure it was just a matter of getting something done quickly, and then fixing it in a better manner later when there is more time.

Note that it's not just click events that it can watch - it can also ping the app whenever the mouse button enters the application window, so that if you are moving the mouse to click on the minimize/close buttons that 100ms timeout will likely hit before the mouse even reaches the buttons. Then it can draw the new UI on top of the window before you click at all.

[Awesomeness]

Idiot.

Likewise!

Wayland doesn't provide ANY ability to minimize apps yet. It's still being added.

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.

The point is nothing will stop it from being able to allow frozen apps from being minimized. Once the functionality to do that for running apps is present, adding it for hung apps is TRIVIAL.

Such is adding a hypothetical libdeco or whatever but the reality is that NONE of the technologies that would remedy usability regressions to X exist at all.
You Wayland fanboys just make that stuff up and tell everyone that everything is going to be alright without providing any proof at all.

If everything is so trivial, why is that all not done yet? Instead Wayland supports to rotate windows almost since day one and – if you bother to watch the XDC video – the argument Kristian gives as to way CSD will be used is that when using the incredibly useless window rotation feature, a single line of pixels can be antialiased.
Whoever the Intel manager is who orders Kristian to implement features a certain way, has absolutely no touch with typical PC use.

[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.

[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

[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.

[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.

[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

[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]

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 did not count how many of the commits are by Intel but Intel is definitively involved in porting all said toolkits to Wayland.