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.
So you tell me that the minimizing thing that is missing from the core protocol is just a lie.
minimize is not part of the protocol and never was, Weston a wayland demo client don't minimize because weston devs have figure out wich of the 300 method for minimize will be more efficient, is just that. beside weston is a toy demo so they dont focus too much on it beyond test code
So you tell me that the minimizing thing that is missing from the core protocol is just a lie.
Minimizing is not working on WESTON. Why? because the minimization is handled by the compositor and the compositor has to implement its own implementation of minimization and weston did not intend to become a full DE.
As far as I know, minimization can be functionnal in wayland, but there I'm not 100% sure. We might get more news soon
minimize is not part of the protocol and never was, Weston a wayland demo client don't minimize because weston devs have figure out wich of the 300 method for minimize will be more efficient, is just that. beside weston is a toy demo so they dont focus too much on it beyond test code
After the whole drama with scott moreau i don't remember anyone implementing the stuff he was trying to add to the protocol and were needed for full DEs. Some E devs were doing stuff but i am not sure about the status of this.
After the whole drama with scott moreau i don't remember anyone implementing the stuff he was trying to add to the protocol and were needed for full DEs. Some E devs were doing stuff but i am not sure about the status of this.
The point is minimization does not need to be implemented in the protocol, because minimization can be handle by so many ways. The implementation is done by the compositor. Example, on kde you can choose the way kwin will minimize windows. With a minimization inside the protocol, that would not be possible, unless you bypass everything like we do on Xorg.
The client can tell the compositor to minimize itself but nothing is handled on weston.
Not exactly true although not exactly false, either. I don't know about GTK, but Qt 5 provides Wayland compositor classes that make it much easier for DE's to write Wayland compositors. So although porting to Qt 5 will not give automatic support, it will make the porting much easier.
That is assuming LXDE doesn't switch to using Kwin. The modularization of frameworks 5 should make this possible, but who knows whether the LXDE camp has any interest.
LXDE is supposed to be lightweight, while KWin is supposed to be full-featured. I don't think that's compatible.
On porting, it still means a port is needed, not only to the toolkit, but on the X specifics.
LXDE is supposed to be lightweight, while KWin is supposed to be full-featured. I don't think that's compatible.
On porting, it still means a port is needed, not only to the toolkit, but on the X specifics.
Kwin with Xrender has became quite lightweight! You would be very suprised of what the last updates brought to the KDE's window manager
Kwin with Xrender has became quite lightweight! You would be very suprised of what the last updates brought to the KDE's window manager
Becoming more lightweight by accident doesn't count, IMO; also, Xrender will not be available on Wayland. The point is where the focus is. KWin tries to provide the most useful features (even if they can do so with a relative lightweight approach), while LXDE, as a lightweight DE, tries to provide a minimalistic approach. This is not something against KWin, but I think the user bases aren't compatible. If you use KWin, you probably want a full featured desktop, like KDE is.
LXDE is supposed to be lightweight, while KWin is supposed to be full-featured. I don't think that's compatible.
On porting, it still means a port is needed, not only to the toolkit, but on the X specifics.
The kwin core is pretty lightweight and getting much lighter. There are a lot of add-ons and effects that make the version used in KDE workspaces heavier.
The primary goal of frameworks 5 in general is to modularize the libraries like kwin so it is easier for developers in other projects to just use what they want. A huge amount of developer work has gone into doing this for kwin under frameworks 5.
Comment