Written by readmanr the 6 Mar 10 at 21:00.

Move the buttons back over to the top right for the final Ubuntu 10.04 release.

Move the buttons back over to the top right for the final Ubuntu 10.04 release.

Written by Akerbos the 6 Mar 10 at 21:38.

I think it is most intuitive if the buttons are ordered the same in relation to the window center ("To close, click the outermost button"), so

Right: min-max-close

relates to

Left: close-max-min

I think it is most intuitive if the buttons are ordered the same in relation to the window center ("To close, click the outermost button"), so Right: min-max-close relates to Left: close-max-min

Written by jeffd1830 the 7 Mar 10 at 08:56.

I think having the buttons on both sides would also be a viable option. I understand that this would detract visually from the simplicity, but maybe if the buttons were subdued until the mouse hovers over the bar?

(I feel less than confident about this solution, but thought it needed mentioning.)

I think having the buttons on both sides would also be a viable option. I understand that this would detract visually from the simplicity, but maybe if the buttons were subdued until the mouse hovers over the bar? (I feel less than confident about this solution, but thought it needed mentioning.)

Written by Long Lazuli the 7 Mar 10 at 11:34.

In xubuntu, user cas can choose where are the button on the titlebar.

In xubuntu, user cas can choose where are the button on the titlebar.

Written by la_serpe the 7 Mar 10 at 16:29.

It can be movable so the user could change it intuitively

It can be movable so the user could change it intuitively

Written by Vlad_Alfredov the 8 Mar 10 at 11:13.

Well the title pretty much says it...Default is to have it on right, but to include an option in "Change Desktop Background" >> Theme >> Customize, to move the buttons to a user defined position.

Well the title pretty much says it...Default is to have it on right, but to include an option in "Change Desktop Background" >> Theme >> Customize, to move the buttons to a user defined position.

Written by marvo the 10 Mar 10 at 10:28.

There are some themes that look better when the buttons are placed on the left side (like Ambiance, Radiance and Gorilla) and there are some themes that look better with the buttons being on the right side (like Glider, Human, Clearlooks or SphereCrystal).

So i propose to set the default alignment depending on the chosen theme and make it easily switchable.

The current way to change the alignment of the buttons back to the right by typing
gconftool-2 --type string --set /apps/metacity/general/button_layout "menu:minimize,maximize,close"
is a bit tedious.

There are some themes that look better when the buttons are placed on the left side (like Ambiance, Radiance and Gorilla) and there are some themes that look better with the buttons being on the right side (like Glider, Human, Clearlooks or SphereCrystal). So i propose to set the default alignment depending on the chosen theme and make it easily switchable. The current way to change the alignment of the buttons back to the right by typing gconftool-2 --type string --set /apps/metacity/general/button_layout "menu:minimize,maximize,close" is a bit tedious.

Written by Lex the 10 Mar 10 at 11:04.

Put Close button in the corner - depending on chosen solution will be left or right corner or window.

Put Close button in the corner - depending on chosen solution will be left or right corner or window.

Written by euxneks the 11 Mar 10 at 01:31.

I think that Minimize and Maximize are more similar to the menu anyway, so put them on the left, and put the close button on the right, this harkens back to the days of old Unix and I think would still allow the theme to stand out.

I think that Minimize and Maximize are more similar to the menu anyway, so put them on the left, and put the close button on the right, this harkens back to the days of old Unix and I think would still allow the theme to stand out.

Written by tsm1248 the 11 Mar 10 at 05:11.

This is all preference here.

Leave the buttons on the left as default and give them the option to move it to the right.

Now both parties are satisfied.
Also give the option to organize the buttons (I'v read some comments and looks like that would be a good thing to add).

Left side:
Way more accessible on the left side
Quicker
Buttons start from left, therefore making it easier/quicker for the user to move through the desktop environment

Bottom line give the user the option to switch them and organize them.(SIMPLE)

It's linux let the user decide..more power to them..

This is all preference here. Leave the buttons on the left as default and give them the option to move it to the right. Now both parties are satisfied. Also give the option to organize the buttons (I'v read some comments and looks like that would be a good thing to add). Left side: Way more accessible on the left side Quicker Buttons start from left, therefore making it easier/quicker for the user to move through the desktop environment Bottom line give the user the option to switch them and organize them.(SIMPLE) It's linux let the user decide..more power to them..

Written by i386dx the 14 Mar 10 at 12:50.

Move the Min, Max and Close-buttons back to the right.

Be able to close a window by double-clicking the window-icon at the left. This is much faster than clicking the icon and selecting 'Close' in the menu.

Move the Min, Max and Close-buttons back to the right. Be able to close a window by double-clicking the window-icon at the left. This is much faster than clicking the icon and selecting 'Close' in the menu.

Written by MoebusNet the 15 Mar 10 at 01:04.

Rationale: In VirtualBox without Guest Additions, the right-hand side of the desktop and the lower part of the desktop are not visible until you scroll. Having the above-mentioned buttons on the top-left side of the window by default makes them accessible when (not if) Guest Additions do not work/are unavailable or when scrolling for whatever reason does not work. This is especially true for development versions.

I _am_ in favor of choice, so this should be fairly easy for a user to change (preferably by GUI) to right, left or both.

Just my opinion.

Rationale: In VirtualBox without Guest Additions, the right-hand side of the desktop and the lower part of the desktop are not visible until you scroll. Having the above-mentioned buttons on the top-left side of the window by default makes them accessible when (not if) Guest Additions do not work/are unavailable or when scrolling for whatever reason does not work. This is especially true for development versions. I _am_ in favor of choice, so this should be fairly easy for a user to change (preferably by GUI) to right, left or both. Just my opinion.

Written by neblogas the 16 Mar 10 at 15:58.

Because Mark said that in 10.10 the windows will have something new in the right side, but now, there is no need to change the buttons, and this is LTS release! in 10.10 when you will finish the new mysteriuos window features on the right then you can put the buttons on the left. As I said, there is no need now to change. Its an LTS release and the people and companies won't change until the next LTS, so there won't be for them new mysteriuos windows features on the right!

Because Mark said that in 10.10 the windows will have something new in the right side, but now, there is no need to change the buttons, and this is LTS release! in 10.10 when you will finish the new mysteriuos window features on the right then you can put the buttons on the left. As I said, there is no need now to change. Its an LTS release and the people and companies won't change until the next LTS, so there won't be for them new mysteriuos windows features on the right!

Written by TrueSongMedia the 16 Mar 10 at 17:16.

Yes the button location can be changed via Terminal, but for the average user...the Terminal can be a bit scary. I think it would be appropriate to place a simple option in the Appearance Preferences window.

Something like this:
http://launchpadlibrarian.net/40647960/window_controls_position_gui.png

Yes the button location can be changed via Terminal, but for the average user...the Terminal can be a bit scary. I think it would be appropriate to place a simple option in the Appearance Preferences window. Something like this: http://launchpadlibrarian.net/40647960/window_controls_position_gui.png

Written by ichido the 17 Mar 10 at 17:53.

Move the Top Bar to the Right Side-Vertical Bar and the Bottom Bar would be on the Left Side Vertical.
This would allow for more Vertical Space.
The user would be able to Swap the Left Bar with the Right Bar and also the Size/Thickness of the Bars.
Applications could maintain the Top Bar or a Side or a Bottom bar for their Window.

Move the Top Bar to the Right Side-Vertical Bar and the Bottom Bar would be on the Left Side Vertical. This would allow for more Vertical Space. The user would be able to Swap the Left Bar with the Right Bar and also the Size/Thickness of the Bars. Applications could maintain the Top Bar or a Side or a Bottom bar for their Window.

Written by Wiplash4 the 19 Mar 10 at 12:17.

Hello
I would like to add one idea: Replace the menubar (File, Edit, View, etc.), which can be found in every window, with an icon and put that icon into the titlebar. It worked out for my terminal.
Regards

Hello I would like to add one idea: Replace the menubar (File, Edit, View, etc.), which can be found in every window, with an icon and put that icon into the titlebar. It worked out for my terminal. Regards

Written by Wiplash4 the 19 Mar 10 at 15:02.

Some of my old programms like modelsim use their own windows style. Make all windows use the style installed by the user. Make them use all the buttons ans items of the user theme!

Some of my old programms like modelsim use their own windows style. Make all windows use the style installed by the user. Make them use all the buttons ans items of the user theme!

Written by Wiplash4 the 19 Mar 10 at 16:40.

I figured out that the status bar is only filled up to 1 / 4. Why not put those messages displayed in the status bar in the title bar?

I figured out that the status bar is only filled up to 1 / 4. Why not put those messages displayed in the status bar in the title bar?

Written by a_pirard the 20 Mar 10 at 03:14.

Modify all applications to be consistent with Lucid : move all close buttons to the left, for example, OpenOffice document close, Firefox tab close, File Explorer side pane close, etc... etc...

Modify all applications to be consistent with Lucid : move all close buttons to the left, for example, OpenOffice document close, Firefox tab close, File Explorer side pane close, etc... etc...

Written by a_pirard the 20 Mar 10 at 03:21.

Request Microsoft Windows to move close buttons to the left to avoid the confusion of users migrating to Ubuntu

Request Microsoft Windows to move close buttons to the left to avoid the confusion of users migrating to Ubuntu

Written by LucaDionisi the 11 Mar 10 at 16:15.

We need a platform where an (quite) expert developer could offer himself to help another developer with his first steps.
The platform could help the right person to find each other, by means of various criteria: language, where they live (think about time zone), what kind of program they want to develop (GUI/CLI, GTK/QT, ...)

We need a platform where an (quite) expert developer could offer himself to help another developer with his first steps. The platform could help the right person to find each other, by means of various criteria: language, where they live (think about time zone), what kind of program they want to develop (GUI/CLI, GTK/QT, ...)

Written by timnwells the 11 Mar 10 at 20:54.

Create a website like MSDN for Ubuntu (USDN) and bring together API documentation, code snippets, tutorials, etc. This could be helpful for both developers new to Ubuntu (or Linux in general) and seasoned Ubuntu developers. It could also incorporate Solution #1.

Create a website like MSDN for Ubuntu (USDN) and bring together API documentation, code snippets, tutorials, etc. This could be helpful for both developers new to Ubuntu (or Linux in general) and seasoned Ubuntu developers. It could also incorporate Solution #1.

Written by Apiman the 10 Mar 10 at 12:50.

Nothing else to say

Nothing else to say

Written by dino the 11 Mar 10 at 07:00.

It doesn't matter if it's released on 10th if got blocker bugs. Release is when its done.

It doesn't matter if it's released on 10th if got blocker bugs. Release is when its done.

Written by sirlatrom the 17 Mar 10 at 22:13.

... since we're not in the 1000s :)

... since we're not in the 1000s :)

Written by ubbrainy the 14 Mar 10 at 22:05.

Something like this: http://www.mozilla-europe.org/img/en/tignish/features/find.png

It's much easier to handle, stays open, and doesn't bother you...

Something like this: http://www.mozilla-europe.org/img/en/tignish/features/find.png It's much easier to handle, stays open, and doesn't bother you...

Written by readmanr the 18 Feb 10 at 21:42.

Redhat, Fedora, Mac OS X, and others simply call 64bit "x86_64". It is a clean, neutral name that is accurate no matter which company made the processor, and also does not give free advertising to either company.

Redhat, Fedora, Mac OS X, and others simply call 64bit "x86_64". It is a clean, neutral name that is accurate no matter which company made the processor, and also does not give free advertising to either company.

Written by readmanr the 18 Feb 10 at 21:43.

The generic term x86-64 is sometimes shortened to x64 as another vendor-neutral term for x86-64 processors from any company referring to 64bit.

The generic term x86-64 is sometimes shortened to x64 as another vendor-neutral term for x86-64 processors from any company referring to 64bit.

Written by Goury the 19 Feb 10 at 13:50.

because of arm, powerpc, sparc and others

because of arm, powerpc, sparc and others

Written by Darwin Survivor the 20 Feb 10 at 02:56.

Most users would not know that i386 is 32 bit or what the "x86" part of "x86_64" means (or the x for that matter). In order to make this as easy and simple for users as humanly possible, we should simply label them as "64 bit" and "32 bit". Beside the options would be a "details" or "help" button that would:
-explain the differences (max ram, performance, compatibility, etc)
-give a specific version type (i386/x86_64/etc) for advanced users
-give instructions to find out what their machine supports (VERY important)

This makes it industry neutral, while also making it much simpler for non-technical users to figure it out. We are targetting non-technical people after all, so why all the jargon?

Most users would not know that i386 is 32 bit or what the "x86" part of "x86_64" means (or the x for that matter). In order to make this as easy and simple for users as humanly possible, we should simply label them as "64 bit" and "32 bit". Beside the options would be a "details" or "help" button that would: -explain the differences (max ram, performance, compatibility, etc) -give a specific version type (i386/x86_64/etc) for advanced users -give instructions to find out what their machine supports (VERY important) This makes it industry neutral, while also making it much simpler for non-technical users to figure it out. We are targetting non-technical people after all, so why all the jargon?

Written by jbangert the 23 Feb 10 at 21:34.

Some browsers(in particular one quite popular propietary and Evil product) include the string "x64" in the User Agent on 64-bit hardware (http://www.ubuntu.com/getubuntu/download). We could also provide a platform-dependent download link to a tool that checks for 32-bit / 64-bit ( Windows and Mac mostly - just a simple tool that uses CPUID and then gives a Message Box with 2 links ) .
By default, we should specify 2 download Boxes ( "Ubuntu 32-bit" and "Ubuntu 64-bit" ) giving pros and cons .

Some browsers(in particular one quite popular propietary and Evil product) include the string "x64" in the User Agent on 64-bit hardware (http://www.ubuntu.com/getubuntu/download). We could also provide a platform-dependent download link to a tool that checks for 32-bit / 64-bit ( Windows and Mac mostly - just a simple tool that uses CPUID and then gives a Message Box with 2 links ) . By default, we should specify 2 download Boxes ( "Ubuntu 32-bit" and "Ubuntu 64-bit" ) giving pros and cons .

Written by sandys the 27 Feb 10 at 10:54.

gnome-power-manager already has information about the battery in your system. However, charging is always-on.

Instead power-manager should charge only according to rules (similar to Microsoft ACPI-compliant control method battery tool)

e.g. bug528543 in gnome-power-manager

gnome-power-manager already has information about the battery in your system. However, charging is always-on. Instead power-manager should charge only according to rules (similar to Microsoft ACPI-compliant control method battery tool) e.g. bug528543 in gnome-power-manager

Written by specialcowboy the 14 Mar 10 at 08:54.

I am relatively new to Ubuntu and I understand that in Lucid there are plans or already an implementation for better power management. As I haven't seen the alphas myself I thought I would suggest a few things. Sorry if these are already being implemented and this is redundant. This site: http://salcher.posterous.com/?tag=ubuntu suggests a few ways to optimize batter life using Powertop and manually configuring files in /etc/laptop-mode/conf.d/. I think it would be great if there was a GUI front end for this that allowed adjusting of the settings and creating of various profiles (rather than editing .conf files directly). Similar to the Power Management functionality included on Acer laptops (ie clocking down the processor, disabling card buses, USB, ethernet, wireless, etc.).

I am relatively new to Ubuntu and I understand that in Lucid there are plans or already an implementation for better power management. As I haven't seen the alphas myself I thought I would suggest a few things. Sorry if these are already being implemented and this is redundant. This site: http://salcher.posterous.com/?tag=ubuntu suggests a few ways to optimize batter life using Powertop and manually configuring files in /etc/laptop-mode/conf.d/. I think it would be great if there was a GUI front end for this that allowed adjusting of the settings and creating of various profiles (rather than editing .conf files directly). Similar to the Power Management functionality included on Acer laptops (ie clocking down the processor, disabling card buses, USB, ethernet, wireless, etc.).

Written by mulenmar the 18 Mar 10 at 04:52.

Something as tied to hardware as controlling when the battery charges and when it cuts off should be built into the Linux kernel itself, not tied to a desktop enviroment!

Something as tied to hardware as controlling when the battery charges and when it cuts off should be built into the Linux kernel itself, not tied to a desktop enviroment!

Written by sicofante the 8 Mar 10 at 07:05.

Merging both bars in one will save vertical screen space and won't affect the way we use the windows now.

There's actually no need for more than the three buttons (minimize, maximize, close) since the window menu can be accessed by right clicking on the window's title or no-menu area.

When the window is too narrow for displaying the full title, we can provide a tooltip showing it in full. Also, developers would be careful by choosing what to display as a window title. Name of the application is usually unnecessary (we know what the application is, we launched it...) and usually only the document name is important.

How to technically doing it is out of the scope of this idea (I'm not a developer). Maybe it's just about removing the titlebar altogether (or reducing it to 0 pixels) and add the title and control buttons to the menubar.

Merging both bars in one will save vertical screen space and won't affect the way we use the windows now. There's actually no need for more than the three buttons (minimize, maximize, close) since the window menu can be accessed by right clicking on the window's title or no-menu area. When the window is too narrow for displaying the full title, we can provide a tooltip showing it in full. Also, developers would be careful by choosing what to display as a window title. Name of the application is usually unnecessary (we know what the application is, we launched it...) and usually only the document name is important. How to technically doing it is out of the scope of this idea (I'm not a developer). Maybe it's just about removing the titlebar altogether (or reducing it to 0 pixels) and add the title and control buttons to the menubar.

Written by Klau3 the 10 Mar 10 at 23:25.

Merge title and menu bar like on the screenshot . To see the menu again the user has to click on the “Menu/Options” button in the left corner. Also remove the status bar and replace it by a mouseover information that will appear after a half second – like it is in Lucid right now for the Places menu.

<img src="http://nureineidee.files.wordpress.com/2010/03/nautilus-lucid-lynx-2-mockup.png?w=650" /> Merge title and menu bar like on the screenshot . To see the menu again the user has to click on the “Menu/Options” button in the left corner. Also remove the status bar and replace it by a mouseover information that will appear after a half second – like it is in Lucid right now for the Places menu.

Written by daas88 the 11 Mar 10 at 00:45.

It would be nice if for example the menu bar showed when I press Alt, Alt+M or one of the Fx keys. And there should be a small button in the title bar doing the same thing as the keyboard shortcut.

It would be nice if for example the menu bar showed when I press Alt, Alt+M or one of the Fx keys. And there should be a small button in the title bar doing the same thing as the keyboard shortcut.

Written by Mirek2 the 14 Mar 10 at 14:47.

As someone who has tried a prototype of this, let me tell you that with small windows, small screens, or large menus, it's a nightmare trying to move windows around, if possible at all.
I think Chrome has a good compromise: remove the text from the title bar and make it a lot thinner, but still keep the height big enough so that one can easily move and resize windows without accidentally opening up menus instead.
With maximized windows, the title bar should merge with the menu bar completely, as one can't move a window in maximized state and as it suits the Fitts law nicely (that is, if you remove the top panel in Ubuntu).

As someone who has tried a prototype of this, let me tell you that with small windows, small screens, or large menus, it's a nightmare trying to move windows around, if possible at all. I think Chrome has a good compromise: remove the text from the title bar and make it a lot thinner, but still keep the height big enough so that one can easily move and resize windows without accidentally opening up menus instead. With maximized windows, the title bar should merge with the menu bar completely, as one can't move a window in maximized state and as it suits the Fitts law nicely (that is, if you remove the top panel in Ubuntu).

Written by A.I. the 14 Mar 10 at 23:00.

Install gnome2-globalmenu applet by default to move menubar to top of screen (as in Mac OS X). User can disable it.

Install gnome2-globalmenu applet by default to move menubar to top of screen (as in Mac OS X). User can disable it.

Written by isantop the 16 Mar 10 at 00:22.

Think something similar to UNR. Remove the title from the active window, and display it in the top panel instead, which has wasted space on most systems by default. Long titles can be truncated like in the task list.

Make the titlebar thicker, and put the menubar in it, leaving space to grab and drag, like solution 4. If a windows is narrow, truncate the menu and place a "More..." button, similar to solution #1

Think something similar to UNR. Remove the title from the active window, and display it in the top panel instead, which has wasted space on most systems by default. Long titles can be truncated like in the task list. Make the titlebar thicker, and put the menubar in it, leaving space to grab and drag, like solution 4. If a windows is narrow, truncate the menu and place a "More..." button, similar to solution #1

Written by oddeyed the 7 Mar 10 at 15:37.

Have a repository in the Software Centre that has lots of scripts, descriptions, and screenshots. They should install easily, with the option to install to the whole system (requiring root access) or just to the current user.

There should also be a very easy interface to manage the scripts. Possibly separate to the Software Centre store, it should be able to change the name of the script, have a 1-line description of the script, activation of various scripts, and launch the Software Centre to install more scripts. Under an advanced button, you should also be able do directly edit the script content and function.

Have a repository in the Software Centre that has lots of scripts, descriptions, and screenshots. They should install easily, with the option to install to the whole system (requiring root access) or just to the current user. There should also be a very easy interface to manage the scripts. Possibly separate to the Software Centre store, it should be able to change the name of the script, have a 1-line description of the script, activation of various scripts, and launch the Software Centre to install more scripts. Under an advanced button, you should also be able do directly edit the script content and function.

Written by yzarc the 7 Mar 10 at 17:37.

like in firefox, nautilus should have an extensions manager able to improve the experience of the user by the installing of plugins (script) provided by ubuntu's repors.

like in firefox, nautilus should have an extensions manager able to improve the experience of the user by the installing of plugins (script) provided by ubuntu's repors.

Written by Akerbos the 9 Mar 10 at 12:56.

Allow users to add context menu entries (filtered by MIME type, if necessary) that call usual shell scripts.

Most tasks _can_ be done with one or two simple commands, no need to write complicated plugings. Just bind scripts where you want them.

Allow users to add context menu entries (filtered by MIME type, if necessary) that call usual shell scripts. Most tasks _can_ be done with one or two simple commands, no need to write complicated plugings. Just bind scripts where you want them.

Written by bud the 4 Mar 10 at 20:23.

During install, the installer can store the connection settings in the "new" installed system. At reboot, the network is ready to go!

During install, the installer can store the connection settings in the "new" installed system. At reboot, the network is ready to go!

Written by The_Great_Bunghole the 6 Mar 10 at 05:07.

What If you are like me (& I know some who are), and you like to see what the liveCD environment can do by adding tons of stuff. & then once you see how cool or messed up you can make it, you decide to install it anyways. Wouldn't you like a FRESH install without saving your mistakes and learning from them when you start Ubuntu from the HDD? I think it would be a cool choice to save the configurations that you made to the system, but why not just WRITE DOWN THE WPA KEY?!

I have mine saved in a secure location. that way, I can just get the piece of paper, and type it in. It isn't that difficult to type.

What If you are like me (& I know some who are), and you like to see what the liveCD environment can do by adding tons of stuff. & then once you see how cool or messed up you can make it, you decide to install it anyways. Wouldn't you like a FRESH install without saving your mistakes and learning from them when you start Ubuntu from the HDD? I think it would be a cool choice to save the configurations that you made to the system, but why not just WRITE DOWN THE WPA KEY?! I have mine saved in a secure location. that way, I can just get the piece of paper, and type it in. It isn't that difficult to type.

Written by Gaz Davidson the 19 Feb 10 at 13:21.

Have Nautilus remember which windows have recently been closed so it can open them again in response to a specific key combination.

Ctrl+Shift+T would be an ideal default

Have Nautilus remember which windows have recently been closed so it can open them again in response to a specific key combination. Ctrl+Shift+T would be an ideal default

Written by forteller the 19 Feb 10 at 22:07.

Yes.

Yes.

Written by Lachu the 20 Feb 10 at 15:14.

Change behavior of close button. It should only minimize "closed window" for 10 seconds. After that the window could been closed.

This change should only change way of informing window with DestroyNotify. I don't know how change behavior of main windows of applications.

Change behavior of close button. It should only minimize "closed window" for 10 seconds. After that the window could been closed. This change should only change way of informing window with DestroyNotify. I don't know how change behavior of main windows of applications.

Written by Lachu the 21 Feb 10 at 12:27.

Extend way how application supports sessions. There should exist signals, like HIBERNATE(save session) to file, RESTORE SESSION from file, etc.

Window Managers could use this feature to achieve idea goal, but not all application could been integrated. The behavior is: give application order to save session in $HOME/.sessions-tmp/$CURRENT_DATE/pid/WINDOWID(or whole session if user wanna to close application instead of window).

To restore window, WM's will give only the same location with signal RESTORE.

Extend way how application supports sessions. There should exist signals, like HIBERNATE(save session) to file, RESTORE SESSION from file, etc. Window Managers could use this feature to achieve idea goal, but not all application could been integrated. The behavior is: give application order to save session in $HOME/.sessions-tmp/$CURRENT_DATE/pid/WINDOWID(or whole session if user wanna to close application instead of window). To restore window, WM's will give only the same location with signal RESTORE.

Written by Afroman10496 the 21 Feb 10 at 23:52.

Put a recently closed tray next to the workspace applet that holds the last three (changeable by the user) windows that you closed in the state they were in when you closed it, showing when it was closed and a screenshot of it when you closed it. Clicking on it should open a menu showing options to open, close, minimize, maximize, move, or move it to another workspace.
http://yfrog.com/juscreenshotckp

Put a recently closed tray next to the workspace applet that holds the last three (changeable by the user) windows that you closed in the state they were in when you closed it, showing when it was closed and a screenshot of it when you closed it. Clicking on it should open a menu showing options to open, close, minimize, maximize, move, or move it to another workspace. http://yfrog.com/juscreenshotckp

Written by Darwin Survivor the 23 Feb 10 at 00:02.

When an application closes, it would have the ability to "register" with the window manager that it is now closing and can be resumed by executing .

The window manager is now in complete control over whether or not to offer the session to the user.

This would allow:
-any app to be written to allow session resuming
-the app can de-register itself if the user resumes or creates a new session
-the app actually closes (no sleeping or anything)
-the user could chose how many "closes" to remember (wm disregards anything older)
-backwards compatible (would not affect apps that don't implement it)
-apps that already have a resume command don't need to change their switches (they tell the wm what to call)
-apps could create numerous sessions by registering with different commands (ex: app --resume )

When an application closes, it would have the ability to "register" with the window manager that it is now closing and can be resumed by executing <command>. The window manager is now in complete control over whether or not to offer the session to the user. This would allow: -any app to be written to allow session resuming -the app can de-register itself if the user resumes or creates a new session -the app actually closes (no sleeping or anything) -the user could chose how many "closes" to remember (wm disregards anything older) -backwards compatible (would not affect apps that don't implement it) -apps that already have a resume command don't need to change their switches (they tell the wm what to call) -apps could create numerous sessions by registering with different commands (ex: app --resume <session_id>)