Qt 5.0 Beta Released

[phoronix]

Phoronix: Qt 5.0 Beta Released

At long last, the Qt 5.0 beta has been released...

http://www.phoronix.com/vr.php?view=MTE3MTg

[RealNC]

Then a hanging application still can be resized but the program no longer knows where the ?close rectangle? is, meaning the x button will be purely cosmetic but the ?close rectangle? position will be left unchanged.

So many tradeoffs just to get a single feature: slightly smoother window resizing. As if users constantly resize their windows...

As if applications are constantly hanging...

And you can close them from the task bar to begin with, as was already mentioned.

[Ancurio]

Hackish = Awkward workaround for a broken design choice.

I don't see how it's a workaround. If that's your definition of "hackish", then Xorg with all its extensions must be an undead shitfest to you.
The wayland devs didn't just jump up and say "hey! let's write another X11".
The idea that a resize can only happen through attachment of a resized buffer is pretty much ingrained in wayland.
Therefore, what I said is just one solution to hanging apps, if you have a better one go ahead and post it.

It's going to even more ?genius? on applications with GUI separated from program logic. Then a hanging application still can be resized but the program no longer knows where the ?close rectangle? is, meaning the x button will be purely cosmetic but the ?close rectangle? position will be left unchanged.

For a GUI to resize, it needs to communicate with the compostior. And if it can communicate, it can also sent a message to update the rectangle.
I don't really get what you're talking about.

So many tradeoffs just to get a single feature: slightly smoother window resizing. As if users constantly resize their windows? The windows are either maximized or in window mode.

Nothing you wrote so far convinced me that there will be no shitstorm from users once Wayland arrives to the mainstream if Wayland?s default behavior is not tweaked.

Where exactly did I say that's the only feature Wayland is designed for? It was merely an example that stood out to me personally.
I can try to explain why wayland is being done, but I don't give a rat's ass if you like it or not. Xorg won't magically die,
so you and everyone else repulsed by the new protocol can go ahead and maintain the old codebase, I'm sure the Xorg devs
will appreciate it a lot.

I really hope my predictions of inconsistent title bars etc. are wrong. Well? wait and see. The worst thing that could happen is that I was right and I can with all confidence say ?I told you so? or I will be positively surprised?

Yeah, I hope so too, I spend around 94% of my time looking at them. Them being different would totally screw up my workflow.

[Awesomeness]

Hackish = Awkward workaround for a broken design choice.
It's going to even more ?genius? on applications with GUI separated from program logic. Then a hanging application still can be resized but the program no longer knows where the ?close rectangle? is, meaning the x button will be purely cosmetic but the ?close rectangle? position will be left unchanged.

So many tradeoffs just to get a single feature: slightly smoother window resizing. As if users constantly resize their windows? The windows are either maximized or in window mode.

Nothing you wrote so far convinced me that there will be no shitstorm from users once Wayland arrives to the mainstream if Wayland?s default behavior is not tweaked.

I really hope my predictions of inconsistent title bars etc. are wrong. Well? wait and see. The worst thing that could happen is that I was right and I can with all confidence say ?I told you so? or I will be positively surprised?

[Ancurio]

OMG! Can it get more hackish than that?

What do you mean, "hackish"? It would be part of the official protocol,
no hacks needed.
It's the same really as with specifying where a surface can be grabbed
for moving.

[Awesomeness]

There has already been a proposed solution to hanging apps. They can specify a rect denoting the x button,
and if there is no reply to a ping, the app will be deemed unresponsive and a terminate dialog might pop up.

OMG! Can it get more hackish than that?

[Ancurio]

Yes, he meant a library but a library can't run independent and allow hanging apps to minimize/close.

There has already been a proposed solution to hanging apps. They can specify a rect denoting the x button,
and if there is no reply to a ping, the app will be deemed unresponsive and a terminate dialog might pop up.
Also, as someone said earlier, you can always minimize with shortcuts/the panel.

Seems that applications have to be shitty as well to become unsnappy. By your own account only a few applications such as Inkscape are really impaired by that lag.

It's not a matter of Inkscape being shitty, it just has a lot of UI + vector graphics to draw.
The thing about snappiness isn't the only merit Wayland brings. It also flushes out a lot of unnecessary complexity.
I'm sure you've read all this here already though

[Awesomeness]

There was never any talk of a daemon. I'm pretty sure what RealNC meant was a library, not a daemon.

Yes, he meant a library but a library can't run independent and allow hanging apps to minimize/close.

No one can stop devs from building shitty applications.
The important part is that there now isn't anything fundamental in the way anymore to implement snappy ones.

Seems that applications have to be shitty as well to become unsnappy. By your own account only a few applications such as Inkscape are really impaired by that lag.

[Ancurio]

That could be worked around by, and here's the reply to RealNC and ?his? fdo standardization idea, developing a deamon which handles the decorations which would result in something that basically is a server-side decoration, only on another level. And there is nothing any Wayland dev could do about it. So much you ?Wayland works that way and deal with it? shouters?

There was never any talk of a daemon. I'm pretty sure what RealNC meant was a library, not a daemon.
If developers want to hand decorations to a daemon, so be it. No one can stop devs from building shitty applications.
The important part is that there now isn't anything fundamental in the way anymore to implement snappy ones.

[RealNC]

That's an advantage that comes at the price of a disadvantage. Currently if an application hangs (not crashed but busy doing stuff) it's still possible to minimize it and do something different until it's done. With CSD that is no longer possible. In the age of demanding JavaScript applications I experienced the need to minimize the web browser more often than to resize windows all the time.
Hanging applications can no longer be minimized because in CSD world the application has to agree first. This is also basically the same topic killing applications.

This is taken care of by the task bar. All DEs have one. If you want to kill an app, right click on its task bar entry and select "Close" or "Quit". This could even preempt the common decoration layer (if there's going to be one.) Right now with X11, if the WM hangs, you're screwed because all windows will suffer from that. With client-side decorations, this can't happen.

That could be worked around by, and here's the reply to RealNC and “his” fdo standardization idea, developing a deamon which handles the decorations which would result in something that basically is a server-side decoration, only on another level. And there is nothing any Wayland dev could do about it. So much you “Wayland works that way and deal with it” shouters…

I don't think that Wayland cares how the client-side implements decorations. A client-side decoration layer wouldn't be a "workaround", it would be intended behavior.