Hi, I am developing a new window manager called Lunchbox (http://code.google.com/p/lunchbox) which among other things gives every new application it's own workspace. Rather than a taskbar, I have two menus: one for switching between programs (called the program menu) and one for recovering windows (the window menu) as well as a title menu for replacing windows (intended as a tab replacement). Ultimately, I want to be able to open the same file in different programs by choosing it from the window menu in a different program. This would avoid the tedious repetition of File->open ... with time consuming folder navigation for something which is already open. So, I would also like to have an additional window type (_NET_WM_WINDOW_TYPE_FILE) that indicated the window represented a file or document with an additional property for the URI.
I would also like to have some new window types to enable WMs to more easily integrate the windows of different programs. I was thinking perhaps a "Status window" (_NET_WM_WINDOW_TYPE_STATUS) which shows status information but is not interactive (so that it won't be confusing side by side with another program's palettes etc. examples of this would clocks and temperature monitors) and "System Window" (_NET_WM_WINDOW_TYPE_SYSTEM) which would be used for system monitors, consoles and so forth which are generally used in conjunction with other programs. Alternatively, a "neutral" type which basically covers both of those properties would work but without the same interesting details - Lunchbox can make different window types look different so a status window might have a thin frame with no titlebar for example. > This last paragraph should be a good reason for having a list of URIs instead > of just one URI - if you really want to be document-based, then you need to > know all documents. If you know only the URI open in app's active tab, then > you care more about the application than the documents. If the pager is to be > document-based, then it needs to know the documents. Going back to the discussion of tabs, I think we should move away from MDI and the "file within one monolithic program" paradigm it implies and have the window manager do the tabs if it wants to. There are lots of problems with MDIs as the current spec already notes so rather than complicating the standard to support something fundamentally flawed I suggest that EWMH properties continue to reflect the details of the currently selected tab. Regards, Alysander Stanley _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list