86

The Linux kernel version 2.6.28 introduced a new feature called container freezer which allows you to freeze a process or group of processes to freeze to the disk.

http://kernelnewbies.org/Linux_2_6_28#h ... eb1d36a51f

I think that this feature can be exploited by KDE to provide some very cool features.

1. Undo close application.

Everyone has closed an application which had some sort of state which was lost when it was closed. If KWin froze an application rather than closing it, an application could be kept running for a predefined length of time, during this time it could be unclosed by unfreezing the application.

2. Removing the application/document distinction.

People work with documents rather than applications most of the time. Even applications like Konsole which do not use documents have state information contained in the settings which is analogous to a document.

If KDE applications were written so that they were frozen when closed and then that frozen state could be associated with the document and restored when the document is reopened (ie. The application would be unfrozen rather than launching a new copy with the document).

This would mean that even things like undo history and text selection would be retained between the document being closed and reopened. There would also be no need to save documents because they are saved with their current state and if you want to undo, you can reopen the document and undo as if it was never closed.

3. Moving applications across computers.

According to the information I found, there is the possibility that either now or in the future, frozen apps will be able to be defrosted on another machine (I assume a fairly compatible one). It should be possible to move a running application from your desktop to your laptop without skipping a beat.

-

I have done some basic testing on KDE apps and freezing and restoring them works almost perfectly, there are a few problems though.

1. KWin does not unmap the window, this should be fairly easy to fix. It just requires it to know about frozen apps. It would be really cool if it could animate the window fading to grey and moving offscreen. The location it moves to could be the UI to restore a closed application.

2. KDE applications vary a lot on how they manage documents and processes. KCalc is easy to freeze and restore, but Dolphin runs each window as a separate thread within a main process so if you freeze one window, it freezes them all. The same problem applies to applications which use tabs to manage documents. The solution would be to make every application keep to a strict 1 process == 1 main window == 1 document rule. That might be difficult to achieve and will mean that applications would need some way to delegate tab management to the window manager.

3. Networking. I assume that any networked applications will respond badly to being frozen and unfrozen. I think that applications get a signal when they are unfrozen so that they can try to reconnect anything on the network. Maybe Network manager could be involved.

What do you guys think?

This would require per platform support, which KDE is unlikely to implement, since it is now cross platform.

Why not look at progressive enhancement? People using KDE on Windows or OSX are probably a tiny minority so it would be a shame to hold back such a useful feature. If it was popular then maybe someone would implement the feature in Windows userland.

I am sure there are lots of apps that either do not work or do not make sense on Windows. For example is KWin used on Windows? If the hooks are largely in KWin then I cannot see it makes much difference. The Windows and OSX versions of KDE probably do not support multiple desktops either, do they?

The system would also have to cope with Linux machines which either do not support this feature or have it disabled, so there will always be a check to see if the system supports freezing or not. If it is not supported, then everything can just fall back to closing meaning the application is destroyed.

If this brainstorm were tagged KWin then would it bypass the cross platform rule?

If KWin could ask the ( KDE ) application to simply suspend itself, then yes, the idea would be cross platform. Note that only KDE applications would support this.

This would work with non-KDE apps too. It only does not work if an application is threaded rather than using per-process windows. For example Firefox would not work (freezing one window would freeze them all), but Chrome (when it is ported) will work. Even some KDE applications like Dolphin will not work unless they are changed to create a process per window.

It might be possible for KWin to keep a track of how many windows are being provided by an application and only freeze it if there is a 1-1 relationship. Or, it could keep a whitelist of applications initially that are known to work.

I think that the initial proof of concept could be made fairly quickly, but it would take a while to refine it and make sure all applications are compatible. The Dolphin developers might not want this feature because they feel that it is not important, but that is OK.

Initially the feature can just provide undo close window functionality because that should be fairly easy and will not include complications like the network going in and out whilst the app is suspended. I think that Network Manager can handle telling the application to reconnect their network connections, but I am not sure if it can signal to a single application as apposed to the system as a whole.

I have changed the category to KWin because I think that is the only application that would need to be explicitly changed to support the feature.

Only KDE applications could support this, because they would require implementation of a KDE specific system to suspend themselves. Non KDE applications would not be able to acknowledge this. As stated previously KDE will not ( under any cirumstances ) provide support for platform ( and version ) specific features.

The only time an exception is made is when the application is not needed on any other platform, as in the case of KWin ( it uses X, which is not available for Windows, but since Windows provides its own, KWin is not needed )

The system for suspending is not KDE specific, I can freeze a non-KDE app just as easily, all we need is cooperation from KWin to unmap the window once it is frozen. Then plasma could provide a GUI to show the recently frozen apps and even managing killing them after a certain amount of time, even if it didn't then a background process or KWin could do it.

I think this idea falls within the exceptions that you have stated. It only needs to be implemented in KWin and plasma and I do not think that the applications need to know that they were frozen, it is not like closing an application where they get a notification and have to respond to it.

I see this feature as being exactly the same as ACPI suspend which KDE supports even though it only makes sense on Linux and needs hardware and kernel support. Per-process suspend is just an extension of suspending the entire machine.

The feature does not fall inside the exception, because this feature is not supported on any of the *BSD's, earlier versions of the Linux kernel, or where this feature has been disabled by the distribution or administrator. ACPI suspend is done through Solid, and therefore does not need an exception being made, since the feature is supported if the backend supports it.

Doesn't Mac Os X already have this feature, though?

Is there some sort of formal acceptance criteria for brainstorms?

I have to say I feel a bit cheated to be asked for brainstorms, then have the rules explained after I have done the work to explain the idea. There seem to be quite a few ideas here which will only work on Linux, but those ideas have not been dismissed as not cross-platform.

The FAQ does not say anything about having to work on every single OS.

bcooksley wrote:This would require per platform support, which KDE is unlikely to implement, since it is now cross platform.

actually just calling it "Freeze_or_Close" would be sufficient.
On linux it would freeze the application, on other OS it would close the application. No special case needed. Even on Linux users should have the choice to disable "freezing" anyways.
If the developer explicitly wants to do different things depending on the OS she should obviously have the means to query this feature. Just because it is not present on all OS does not mean that programs should not use it.

KDE, Solid, ACPI, kernel, what's the difference this idea is totally cool! +1

mikedee thanks for explaining all that.. I didn't even know this was upcoming in the kernel.

I don't think this idea was necessarily dismissed outright but put to 'unlikely'. Think how unlikely the 'unlikely' can possibly be given how much KDE-supported complex 3D code is going into 3D Desktop that won't see the light of day on non KWin platforms. Rules, schmules.

Nah..maybe it needs to be Solid backend, KWin only, totally 3rd party, I dunno. Posting here wasn't a total waste though.

If you want to, keep shopping it around, and hey if all else fails, get this kind of stuff into freedesktop.org and KDE will find a way to implement an exception, I'm sure. haha

The only Brainstorm rules: Only one idea per thread, and that it is related to KDE.
I am just stating that it is very likely the developers will not accept / implement this feature.

Thanks for the support everyone. I think that the concept of this brainstorm is a bit flawed. I can go and register my own bug/wish in the bug tracker which can be ignored just as easily.

What I think would really help would be if the main developers could commit to at least fleshing out these ideas so that it is easier for other developers who want the feature to do it themselves.

Something like this for the most popular ideas would be ideal.

http://lists.kde.org/?l=kwin&m=123877723411393&w=2

That information could be kept in a wiki so that other developers / interested parties can use it as a source of information on how to go about implementing a feature. I know that I could probably implement this feature myself or pay someone to do it, but it will be 100 times as hard without any guidance.

Why should only students on the GSoC be given help on adding new features?

P.S. If you have not voted for this brainstorm, please click the vote up button at the top of the page

I absolutely love your ideas Mike!

I must say, I am also disappointed by the responses of many. It seems like there's a bunch of flaming hoops to get through before ideas are considered or appreciated.

I've always thought that Linux lovers were also idea lovers; that innovation was the core of our belief and community participation was hugely encouraged, but too often find a bunch of legacy idea protectors.

I tried to suggest some changes to Kdevelop but got told that "none of the core of the app would be changing". No reason provided.

I'd like to get past the Enuchs at the gate and get to the guys who want to make history together. I see this as a pivotal time in OS deployment where hoards of people are disillusioned with Windows and are looking elsewhere. With our current pervading attitude, my guess is they will bypass the Linux lab rats on the way to Mac OSX because we have seized experimentation over innovation and diversity over cohesion.

Ideas like Mike's will push us into an area of innovation that will discern us from Mac and Windows. Grab a hold of great stuff like this, regardless of how it's presented. This is not an English comprehension!

I am a fervent Linux user, by the way.

My similar ideas lie dormant, over-criticised, under-encouraged, unsupported and undiscovered at http://brainstorm.ubuntu.com/idea/19668/