Re: _NEW_WM_CURRENT_URI

[Alysander Stanley <alysander gmail com>]

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