mgraesslin wrote:

hteles wrote:I guess we are not talking about the grandmas PC or the son laptop here running latest kde supra new technology.

Then I do not know what we talk about. Enterprise distributions are still using 4.3 or 4.4, not the "supra new technology" which doesn't ship that feature any more.

hteles wrote:i was talking about running KDE as a DaaS, and if you want to deploy KDE to your customers or inside your organization securely over the internet you surelly will not use krfb

so RHEL or SLED, running 4.3 or even 3.5, so where exactly is the problem?

hteles wrote:In the kde 3 times, kde developers had a completly different vision from the people that are there now, maybe that's why kde trinity desktop fork makes sense.

Right and enterprise systems will use the high quality system produced by 14 developers thinking they can maintain a few million lines of code.

To be quite clear: so far I have not seen any complaint by an enterprise and I'm quite sure that RedHat developers or SUSE developers know how to reach us. And I'm even more sure that we would find a solution for them if they need this feature.

Having a very rare feature which is broken in the default setup combined with a default setup which makes it hardly possible to run a remote system in the first place (note: not KDE's fault) does not make any sense. Even if there is a handful of people who would like to have it. We need to keep more in mind than making all users happy - that is just not possible.

Btw. it's also possible to switch to a different window manager in a remote session.

Okay,

your points are valid and i never wanted to say the contrary,

It's just that the biggest problem is not the resize effect, but when you move a window within a nomachine, or X2go session over a network connection.

We have two kind of systems here, Windows 2008R2 terminal servers tunneled via nx and kde3 Debian Lenny terminal servers via NX also, and both of them draw only the windows borders when you move a window, and that's makes a big difference in CPU usage on the servers, on the connection and offcourse it is a lot faster.

regards,

hteles

hteles wrote:It's just that the biggest problem is not the resize effect, but when you move a window within a nomachine, or X2go session over a network connection.

if you run a current system the fact that the drawbound is not present should in fact be the smallest issue. I could name much more issues, like Alt+Tab using QML, window decorations being complex and with animations, desktop shell using a GraphicsView, more and more applications using GraphicsView.

All this results in the end in submitting a single bitmap over the stream. Applications like Firefox do not support anything else any more. Modern applications are just using a huge canvas and that's independent on whether it's KDE or GNOME applications. That just doesn't work with X protocol any more. I blogged about the general issues of network transparency with modern applications more than a year ago: http://blog.martin-graesslin.com/blog/2 ... ncparency/

It's fine using an old system with network transparency, but for anything modern one should consider to use something else. A nice solution might be the spice protocol. And it's not the window manager which broke it here, it's just that we see that it's broken already.

mgraesslin wrote:

hteles wrote:It's just that the biggest problem is not the resize effect, but when you move a window within a nomachine, or X2go session over a network connection.

if you run a current system the fact that the drawbound is not present should in fact be the smallest issue. I could name much more issues, like Alt+Tab using QML, window decorations being complex and with animations, desktop shell using a GraphicsView, more and more applications using GraphicsView.

All this results in the end in submitting a single bitmap over the stream. Applications like Firefox do not support anything else any more. Modern applications are just using a huge canvas and that's independent on whether it's KDE or GNOME applications. That just doesn't work with X protocol any more. I blogged about the general issues of network transparency with modern applications more than a year ago: http://blog.martin-graesslin.com/blog/2 ... ncparency/

It's fine using an old system with network transparency, but for anything modern one should consider to use something else. A nice solution might be the spice protocol. And it's not the window manager which broke it here, it's just that we see that it's broken already.

Hi Martin,

i surelly will read your blog later tonight.
Maybe i will have to look at spice.

But even with all the problems i've managed to have a very workable solution based on kde 4.8.5 that could be offered against our other solutions based on Winblows 2008r2 to some of our costumers who prefer a safer inexpensive Cloud Desktop - it's almost ready

regards,
hteles

give a try to enable XRender based compositing on the remote system. Maybe it works and even provides a better experience.

hteles wrote:It's just that the biggest problem is not the resize effect, but when you move a window within a nomachine, or X2go session over a network connection.

The issue here is that moving an opaque window on an uncomposited desktop will cause many exposure events on the windows below (try pushing the window to the background and move it using Alt+LMB, w/o bringing it to the front) which cause those windows to repaint (what means many xputimages).
The expensive part is not that the moved window is opaque - the problem are the repainting costs of everything below.

This used to be prevented by the server side backing stores (also reduced flicker on local machines) which are hardly available nowadays.

An empty move will not cause those events, neither will a composited one, XRender compositing should work on NX - just deactivate all effects to get rid of pointless load.
If this should for some other reason not be possible (which?) one could probably compensate that particular case with a dedicated (lightweight) deco plugin which grabs the server and paints the outline into it the legacy way.

Nevertheless, vanilla KDE or Gnome (probably neither E17) and Gtk+ or Qt toolkits are not suited for this task and you'll have to review the desktop setup and be willing to apply some patches anyway in order to efficiently use them this way.

mgraesslin wrote: Btw. it's also possible to switch to a different window manager in a remote session.

Are you saying, that if I want to use remote KDE desktop, that it is better replace Kwin with a different window manager?

Regards,
B*

barta wrote:

mgraesslin wrote: Btw. it's also possible to switch to a different window manager in a remote session.

Are you saying, that if I want to use remote KDE desktop, that it is better replace Kwin with a different window manager?

It is always an option as Plasma Desktop does not require KWin. So if the resize mode is a showstopper it's better to switch to another window manager than to a completely different environment. That is the advantage of free software: there are always multiple options available.

mgraesslin wrote:

barta wrote:

mgraesslin wrote: Btw. it's also possible to switch to a different window manager in a remote session.

Are you saying, that if I want to use remote KDE desktop, that it is better replace Kwin with a different window manager?

It is always an option as Plasma Desktop does not require KWin. So if the resize mode is a showstopper it's better to switch to another window manager than to a completely different environment. That is the advantage of free software: there are always multiple options available.

Hi,

indeed, switching to xfwm4 makes it possible to have the option to not draw window contents while resizing and moving windows

Also please look at here how to activate it http://forum.kde.org/viewtopic.php?f=66&t=95896

Working great here with kde4 from kubuntu 12.04 and x2go

regards,
hteles

Dear Martin et.al,

I can imagine how hard it had to be to drop these important KDE features.

Removing these options is bad for KDE, and for Linux. This makes KDE a lot more expensive to use in terms of performance requirements and bandwidth consumption, this lessens its adoption. In my case I remote a lot of Systems using NX thru my android smartphone by using it as a 3G modem for my laptop, it is a pity that since I upgraded KDE I degraded my computing experience a lot.

KDE is freedom. Kwin is much more than transparent windows and fancy effects, Kwin is KDE´s Window Manager, and that honor should stand above all available effects within Kwin. Said effects are excellent if you enable them on a dedicated PC with 3D acceleration, but I must get rid of them if I plan to engineer a practical VDI/DaaS/Remote Desktop solution based on KDE Plasma in my corporation. Computing nowadays resembles a lot to old mainframes era.

If I use KDE from home or a Desktop computer I will enable the effects.
If I use KDE from NX or other protocol, I do not want to see the updating of contents of windows while being moved or re-sized as its expensive.
If I use KDE in a constrained environment (old hardware where Linux and X11 still runs fine, a Virtual Machine in a VM Server exposing a hundred VMs).

Lets ask the right questions, its Linux & KDE ready for VDI? No as X11 isn´t ready. SPICE is speculation since the very beginning, many years have passed since it was announced. XRDP well done would be awesome. NX is the only serious thing we have, but we need sort of X technology in the client side in order to be able to connect.

Let´s speculate that kick **** KDEmoting will appear in the advent of wayland era, with or without SPICE, or with KDE´s own App Streaming protocol.

A joking reply to my opinion could be to use KDE on Windows, enable don´t show window contents while moving (the option still exists in W7) and use RDP to get my KDE experience!

Thank you very much for your time reading my opinion.

Addendum:
Remoting Linux desktops and/or individual Linux X11 applications is incredibly **** nowadays (IMHO It´s been **** all the time in X11 existence), I wish Linux systems using KDE had equivalent desktop remoting functionality of M$ Windows RDP Terminal Services or SunRay.

LTSP is not a equivalent of SunRay.
Linux-X11-KDE can be remoted by using the following open source **** technologies: XDMCP, VNC/Krfb, XRDP (a false RDP implementation); and by the partially open source NX of NoMachine (this is what I use) and/or X2 (I have heard its sort of a NX fork, not compatible, but with the benefit that it has a Android client).

antornix wrote:Dear Martin et.al,

I can imagine how hard it had to be to drop these important KDE features.

Removing these options is bad for KDE, and for Linux. This makes KDE a lot more expensive to use in terms of performance requirements and bandwidth consumption, this lessens its adoption. In my case I remote a lot of Systems using NX thru my android smartphone by using it as a 3G modem for my laptop, it is a pity that since I upgraded KDE I degraded my computing experience a lot.

KDE is freedom. Kwin is much more than transparent windows and fancy effects, Kwin is KDE´s Window Manager, and that honor should stand above all available effects within Kwin. Said effects are excellent if you enable them on a dedicated PC with 3D acceleration, but I must get rid of them if I plan to engineer a practical VDI/DaaS/Remote Desktop solution based on KDE Plasma in my corporation. Computing nowadays resembles a lot to old mainframes era.

If I use KDE from home or a Desktop computer I will enable the effects.
If I use KDE from NX or other protocol, I do not want to see the updating of contents of windows while being moved or re-sized as its expensive.
If I use KDE in a constrained environment (old hardware where Linux and X11 still runs fine, a Virtual Machine in a VM Server exposing a hundred VMs).

Lets ask the right questions, its Linux & KDE ready for VDI? No as X11 isn´t ready. SPICE is speculation since the very beginning, many years have passed since it was announced. XRDP well done would be awesome. NX is the only serious thing we have, but we need sort of X technology in the client side in order to be able to connect.

Let´s speculate that kick **** KDEmoting will appear in the advent of wayland era, with or without SPICE, or with KDE´s own App Streaming protocol.

A joking reply to my opinion could be to use KDE on Windows, enable don´t show window contents while moving (the option still exists in W7) and use RDP to get my KDE experience!

Thank you very much for your time reading my opinion.

Addendum:
Remoting Linux desktops and/or individual Linux X11 applications is incredibly **** nowadays (IMHO It´s been **** all the time in X11 existence), I wish Linux systems using KDE had equivalent desktop remoting functionality of M$ Windows RDP Terminal Services or SunRay.

LTSP is not a equivalent of SunRay.
Linux-X11-KDE can be remoted by using the following open source **** technologies: XDMCP, VNC/Krfb, XRDP (a false RDP implementation); and by the partially open source NX of NoMachine (this is what I use) and/or X2 (I have heard its sort of a NX fork, not compatible, but with the benefit that it has a Android client).

sorry for full quoting but I'm on my pgone right now.

just want to say that i couldn't agree more and feel the same as you do

Its bad for KDE/Linux and all of us, but i guess that the KDE vision is, ... KDE vision !

I don't think that this is harming KDE or Linux at all and I don't think keeping support for a legacy mode is part of the "KDE vision".

If there is a strong need for this feature in remote setups, I'm sure there are possible solutions. Like for example an approved down-stream patch in an enterprise distribution. But not written by me