Re: [Ayatana] CSD and the pressure to innovate
On 08/07/10 00:10, Sam Spilsbury wrote: Why exactly do we want the WM to be handling tabs here? Trying to do tabbed applications within the window manager for the sake of having tabs is a huge waste of memory, especially when the application itself can already do tabs. ... the result is a whole bunch of major inconsistencies in the user experience of tabs. Where is the close button? What are the key bindings to move between tabs, and to move tabs around? How does one move a tab between two windows of the same app? The typical path for something like tabs is that they are invested somewhere, then implemented individually in a bunch of apps, then become part of the system. We need to make that last step happen. It also does not make sense from a design perspective. the whole point of tabbed windows (as it is implemented in both Compiz and KWin) is to allow multiple /applications/ to be shoved into one window, applications which the user delegates themselves as related. Confusing documents and windows here doesn't help at all. You're right at the start: tabs are multiple applications in one window. They are whole things that you want to navigate between with keystrokes, see previews of, etc. They are systemic objects, and they deserve to be treated as such. Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
On Wed, Jul 7, 2010 at 5:42 PM, Apoorva Sharma appi2...@gmail.com wrote: On Jul 7, 2010, at 6:10 PM, Sam Spilsbury smspil...@gmail.com wrote: Why exactly do we want the WM to be handling tabs here? Trying to do tabbed applications within the window manager for the sake of having tabs is a huge waste of memory, especially when the application itself can already do tabs. Standardizing a tabbing system would save memory, since individual apps don't have to manage them, and so unnecessary code could be removed. No, the removal of code to do internal tabbing has nothing to do with memory wastage. First of all, you are still going to be linking against the GTK or QT libs for any application and have fun getting any of them to remove their tabbing widgets. So that code isn't going to be saved. Second of all, window managers know nothing about documents, they only know about X11 windows (which are just huge images as far as they are concerned). If you want to standardize tabbing into the window manager that is fine, but keep in mind that the window manager has to keep the pixmaps of those windows around at all times in order to tab between them. This in itself is huge memory wastage. If you keep things within the toolkit as they are already done so now, then the toolkit knows about documents and knows what bits of memory it does and doesn't need when switching between documents. In addition, you have /one/ pixmap rather multiple pixmaps. It also does not make sense from a design perspective. the whole point of tabbed windows (as it is implemented in both Compiz and KWin) is to allow multiple /applications/ to be shoved into one window, applications which the user delegates themselves as related. Confusing documents and windows here doesn't help at all. I agree. However, what do tabs in firfox, chrome, and nautilus do? They allow one to combine multiple windows into one. Thus, the current tabbing system used by compiz should be scrapped (at least to me, it provides no benefits by combining two applications into one window) and there should be a system where all windows are tabbed into one like Chrome does it. It saves space, allows apps to use less code, and provides a way to unify tab behavior across applications. They don't combine multiple windows into one. They combine multiple /documents/ into one. Document != Window. A document just so happens to be the thing you are doing operations on. A window includes that document, but /also/ includes tools to operate on that document, such as cut, copy, paste, toolbars etc. Also if you just want to tab items in a singular application, then why not use the tabs implementation we already have? Toolkits have been able to do this for years, and because applications already use toolkits, the implementation is already consistant! There, no more ugly window manager hacks required. Kind Regards, Sam I hope that this alternate description helps. -- Sam Spilsbury ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
On 8 July 2010 08:50, Sam Spilsbury wrote: If you want to standardize tabbing into the window manager that is fine, but keep in mind that the window manager has to keep the pixmaps of those windows around at all times in order to tab between them. This in itself is huge memory wastage. If you keep things within the toolkit as they are already done so now, then the toolkit knows about documents and knows what bits of memory it does and doesn't need when switching between documents. In addition, you have /one/ pixmap rather multiple pixmaps. Tab management in the toolkit only benefits applications that use the toolkit to have tabs. The reason to extend tabs to the WM is to provide tabbing for applications that didn't use the toolkit. In that case, the memory usage due to the pixmaps is exactly the same, as those applications would have a pixmap per window anyway. Tabbed applications would continue to use the toolkit so they won't add memory requirements. It also does not make sense from a design perspective. the whole point of tabbed windows (as it is implemented in both Compiz and KWin) is to allow multiple /applications/ to be shoved into one window, applications which the user delegates themselves as related. Confusing documents and windows here doesn't help at all. I agree. However, what do tabs in firfox, chrome, and nautilus do? They allow one to combine multiple windows into one. Thus, the current tabbing system used by compiz should be scrapped (at least to me, it provides no benefits by combining two applications into one window) and there should be a system where all windows are tabbed into one like Chrome does it. It saves space, allows apps to use less code, and provides a way to unify tab behavior across applications. They don't combine multiple windows into one. They combine multiple /documents/ into one. Document != Window. A document just so happens to be the thing you are doing operations on. A window includes that document, but /also/ includes tools to operate on that document, such as cut, copy, paste, toolbars etc. That's true just when all documents are of the same kind. Kwin and Compiz allow having tabs for documents of different kinds in the same window, with each document having the appropriate tools. This grouping of several documents makes sense when they belong in the same task. If you think of it, it's the same grouping provided by the task bar. The task bar is a tabbed interface joining together all open documents that are placed in the same virtual workspace. In this sense, window tabs are just a similar grouping one level below. So you have three hierarchical levels for grouping windows: the virtual desktop, the taskbar, and the window tabs. The desktop environment would benefit for having these three levels as much homogeneous as possible, instead of having artificial restrictions (only documents of the same kind) in one of those levels. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
On 7 July 2010 07:32, Philipp Wendler wrote: How would you handle the advanced application-specific features related to tabs? In Firefox for example, there are quite a few actions when you right-click on the tab bar: - reload tab - make tab into a bookmark - undo tab closing Creating a standard protocol for tabs that allows collaboration between application and the WM. Applications without tabs support would delegate all tabbing functions to the window manager. On the opposite side, apps with advanced tab management could handle everything and just notify the names of existing tabs to the WM so that it can use them in the task bar, Alt+tab switcher, Exposé-like effects... ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
On 06/07/10 02:02, Frederik Nnaji wrote: I thought it didn't depend on window decoration anymore!? Doesn't Global Menu read its items idenpendently already? Our Global Menu requires the application to publish it's menu using a protocol we have designed and implemented, over d-bus. For Gtk and Qt, the aim is to make that automatic (i.e. the app doesn't have to do anything special unless it really wants to). The issue for Firefox is that it will need to implement this for itself, it doesn't use Qt or Gtk. Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
On 07/07/10 09:29, Diego Moya wrote: On 7 July 2010 07:32, Philipp Wendler wrote: How would you handle the advanced application-specific features related to tabs? In Firefox for example, there are quite a few actions when you right-click on the tab bar: - reload tab - make tab into a bookmark - undo tab closing Creating a standard protocol for tabs that allows collaboration between application and the WM. Exactly! We already do this in a couple of places, where an app can use an existing framework then extend it with additional options. For example, in the Music Menu, an app can add menu items related to the current-playing-track, or the app as a whole. Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
On Jul 7, 2010, at 6:10 PM, Sam Spilsbury smspil...@gmail.com wrote: Why exactly do we want the WM to be handling tabs here? Trying to do tabbed applications within the window manager for the sake of having tabs is a huge waste of memory, especially when the application itself can already do tabs. Standardizing a tabbing system would save memory, since individual apps don't have to manage them, and so unnecessary code could be removed. It also does not make sense from a design perspective. the whole point of tabbed windows (as it is implemented in both Compiz and KWin) is to allow multiple /applications/ to be shoved into one window, applications which the user delegates themselves as related. Confusing documents and windows here doesn't help at all. I agree. However, what do tabs in firfox, chrome, and nautilus do? They allow one to combine multiple windows into one. Thus, the current tabbing system used by compiz should be scrapped (at least to me, it provides no benefits by combining two applications into one window) and there should be a system where all windows are tabbed into one like Chrome does it. It saves space, allows apps to use less code, and provides a way to unify tab behavior across applications. I hope that this alternate description helps. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
Since tabs in firefox and nautilus are just ways of combining multiple windows into one, why not have the window manager handle tabs for all apps? Maybe apps like firefox or nautilus etc could tell the window manager that they want tabbed windows, and it could be done for them. This would make tabbed interfaces consistent and more easily read for integration with the taskbar (like win7). Just a thought. On Jul 5, 2010, at 2:07 AM, Mark Shuttleworth m...@ubuntu.com wrote: On 04/07/10 11:54, Sense Hofstede wrote: The mock-ups for Firefox 4 seem also to be using CSD. That's the only way I can think of to get that menu up there in the title bar. https://wiki.mozilla.org/Firefox/4.0_Linux_Theme_Mockups Indeed. Again, if we have a consistent solution for the things they are trying to address, we can reasonably expect them to adopt it if they want to be a default option on Ubuntu. Mark ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
Hello, Am 07.07.2010 04:52, schrieb Apoorva Sharma: Since tabs in firefox and nautilus are just ways of combining multiple windows into one, why not have the window manager handle tabs for all apps? Maybe apps like firefox or nautilus etc could tell the window manager that they want tabbed windows, and it could be done for them. This would make tabbed interfaces consistent and more easily read for integration with the taskbar (like win7). How would you handle the advanced application-specific features related to tabs? In Firefox for example, there are quite a few actions when you right-click on the tab bar: - reload tab - make tab into a bookmark - undo tab closing Also there are a lot of extension that would not be possible to use anymore. I use ChromaTabs (colors the background of the tab button in the tab bar according to the favicon to make it easier to locate the tab) and PermaTabs (prevents accidental closing of certain marked tabs). And when you look on addons.mozilla.org for addons in the category tabs, there are 433 of them. I doubt that it will be possible to implement them if the window manager manages the tabs. Greetings, Philipp ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
On 04/07/10 11:54, Sense Hofstede wrote: The mock-ups for Firefox 4 seem also to be using CSD. That's the only way I can think of to get that menu up there in the title bar. https://wiki.mozilla.org/Firefox/4.0_Linux_Theme_Mockups Indeed. Again, if we have a consistent solution for the things they are trying to address, we can reasonably expect them to adopt it if they want to be a default option on Ubuntu. Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
On 04/07/10 19:29, David Hamm wrote: In 10.10, we'll take a big step forward in the netbook edition, by moving the menu into the top panel and combining it with the titlebar for maximised windows. This will be very nice! Thanks Dev's. Defiantly going on my laptop, even tho its 12, tabs will finally hit the edge of the screen. Assuming I read that right. In 11.04 that's feasible, yes. Not in 10.10. signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
On 04/07/10 11:54, Sense Hofstede wrote: The mock-ups for Firefox 4 seem also to be using CSD. That's the only way I can think of to get that menu up there in the title bar. https://wiki.mozilla.org/Firefox/4.0_Linux_Theme_Mockups Indeed. Again, if we have a consistent solution for the things they are trying to address, we can reasonably expect them to adopt it if they want to be a default option on Ubuntu. Mark Firefox 4 will continue to have the toolbar mode. but by default will be hidden on the orange button. ubuntu would be nice if in default mode, the toolbar was present in the upper panel (consistency again). Light Graphite (design studio)Daniel Planas.A http://lightgraphite.uphero.com/ ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] CSD and the pressure to innovate
On 29/06/10 07:19, Conscious User wrote: I think that makes two of two implementations that nicely illustrate the concern that CSD is harmful for workspace consistency. I have to agree on this one. Visual inconsistency is one of the oldest complaints against Songbird. I think there's a difference between cases where the application takes all matter into its own hands, and cases where the application implements CSD inside a desktop-wide framework. As you can see, ignoring CSD isn't stopping popular apps from embracing elements of it - inconsistently. My view is that making CSD systemic isn't going to worsen the situation, and likely makes it substantially better. Songbird and Chrome are innovating because the desktop environments are not. In part, the desktop environments are not innovating because (a) Windows and MacOS are too entrenched, and (b) Linux folks can't agree on a direction, and views are vociferous across the spectrum. The direction we have taken with Unity and the netbook interface will, I hope, address some of the issues that have driven the unilateral movement by Songbird, Chrome and others. In other words, by making the window system / desktop environment layout more efficient in the way those app developers care about, we reduce the pressure for them to do things that are radically different, and hence inconsistent. What do they care about? Efficiency. Both Chrome and Songbird have tried to eliminate wasted vertical space, in different ways. Songbird by putting the menu in the window title bar, Chrome, by moving the menu to a much less vertically intrusive form factor. Chrome has gone further, putting tabs into the titlebar area too. In 10.10, we'll take a big step forward in the netbook edition, by moving the menu into the top panel and combining it with the titlebar for maximised windows. The next challenge will be for us to be smarter about tabs, so I think we'll do a bunch of exploration work for 11.04 in that regard. If we can *nail* those things, we'll have the most efficient use of vertical space, and can reasonably expect Chrome and Songbird to embrace it. Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] CSD and the pressure to innovate
In 10.10, we'll take a big step forward in the netbook edition, by moving the menu into the top panel and combining it with the titlebar for maximised windows. This will be very nice! Thanks Dev's. Defiantly going on my laptop, even tho its 12, tabs will finally hit the edge of the screen. Assuming I read that right. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
