Qt 5.1 To Feature Improved Support For Wayland

Quote:

---

Originally Posted by asdx

Qt, not QT.

Learn to write please.

---

Learn to write, please. Seems to me he knows how to write just fine--although, he may not necessarily know how the name of a certain toolkit (Qt) is written, or is otherwise lazy.

Quote:

---

Originally Posted by smitty3268

There is a way to tell that applications are not responding (or otherwise something like a busy cursor wouldn't be possible).

It's entirely legal (and was proposed on the wayland list) for the compositor (Weston, KWin, etc.) to override the default appearance of the app in that case.

That allows the compositor to stick custom menus, or draw it's own titlebar + buttons on top of the hung app, and the compositor is free to force close, minimize, help drag the window, etc. to it's hearts content.

I don't have a link, but i'm sure you can google to find it if you want.

---

I think it work something like that on windows. It works but at least on windows 7 it give some sort of alien feeling when the application misbehave. In linux today with client side yada a frozen application has a more native behaviour.

Quote:

---

Originally Posted by smitty3268

There is a way to tell that applications are not responding (or otherwise something like a busy cursor wouldn't be possible).

---

Last time I looked they were supposed to be using polling to determine if windows were responsive or not (I believe this works the same way as in android).

Quote:

---

Originally Posted by liam

Last time I looked they were supposed to be using polling to determine if windows were responsive or not (I believe this works the same way as in android).

---

Yup, one of the worst techniques to do anything in computing.

Just like sending commands is always better for network use than sending pixmaps (scraping pixels, VNC-style), polling is just about always the worst possible solution. But it's probably the only possible one, forced by Wayland's design, just like the pixel-scraping for networking (or the other proposition, per-toolkit thing which nobody will implement, or with which every toolkit will be incompatible with each other. Seriously, it's a huge advantage to have network support for *every* app by default, not just those compiled with toolkit foo.)

Quote:

---

Originally Posted by curaga

Yup, one of the worst techniques to do anything in computing.

Just like sending commands is always better for network use than sending pixmaps (scraping pixels, VNC-style), polling is just about always the worst possible solution. But it's probably the only possible one, forced by Wayland's design, just like the pixel-scraping for networking (or the other proposition, per-toolkit thing which nobody will implement, or with which every toolkit will be incompatible with each other. Seriously, it's a huge advantage to have network support for *every* app by default, not just those compiled with toolkit foo.)

---

In Real Time Systems, where determinism is everything, polling is the preferred method and usually, as in safety critical systems, interrupts are forbidden.

In RT systems your app is usually the only important thing on the whole system. So its efficiency and monopolizing the cpu doesn't matter there.

Quote:

---

Originally Posted by smitty3268

Please do some research. This is just plain false.

---

I did research. Wayland will only allow to kill unresponsive apps, not allow to minimize them.

Quote:

---

Originally Posted by Awesomeness

I did research. Wayland will only allow to kill unresponsive apps, not allow to minimize them.

---

Link, or please explain why the simple process above won't work.

Quote:

---

Originally Posted by curaga

Yup, one of the worst techniques to do anything in computing.

Just like sending commands is always better for network use than sending pixmaps (scraping pixels, VNC-style), polling is just about always the worst possible solution. But it's probably the only possible one, forced by Wayland's design, just like the pixel-scraping for networking (or the other proposition, per-toolkit thing which nobody will implement, or with which every toolkit will be incompatible with each other. Seriously, it's a huge advantage to have network support for *every* app by default, not just those compiled with toolkit foo.)

---

I wouldn't argue about polling being a bad idea in general but sending commands isn't the best way for dumb retinal situations. Additionally, I don't know how well sending 3d commands would work from a performance POV.

I'm not sure polling is there only option. Heck I'm not sure they settled on it. Only that it seemed to be the path they were going to use first.


Hopefully there will be an fdo proposal made for sending drawing instructions across networks for those who want it but I'm fine with sending diffs.

Quote:

---

Originally Posted by smitty3268

Link, or please explain why the simple process above won't work.

---

I thought you were all so omniscient and yet do do not know that?
Check the Wayland video from the last Xorg conference, you genius! Michael recorded the entire conference and the videos were heavily featured and yet you missed that?