On Tue, 2003-05-06 at 02:51, David Adam Bordoley wrote: > http://mail.gnome.org/archives/wm-spec-list/2003-January/msg00008.html > has the proposed spec (more or less) according to this email > > "The biggest problem I had when saving window state is trying to find a > unique way to identify a window. I eventually came up with an internal > numbering system. Windows are identified by class/name/role/number > where number is simply an integer which grows as similar windows are > placed on the same virtual desktop. This seems to work very well." That's the CURRENT functionality limited by not having a spec for anything better. The same mail also talks about rectifying the spec to support the apps this would break with: "Havoc suggested a window property called: _NET_WM_GEOMETRY_SAVE_ID. If this property is set with a string, my patch uses that as the history identifier. If the property is set with an empty string, my patch does not save any state for the window at all." Then you could tell the WM whatever window id you wanted (encode a bookmark id in it, whatever), or even declare that you want to do window placing yourself, if it really is necessary. I definitely don't buy the idea that it is necessary for a web browser. > However this will break once you start saving document location per > document (instead of based on applications, if we ever get to the panacea > which is a document oriented ui), since documents can be renamed (but their > position should still remain the same). Ideally every single document's > window position should be saved per document. In epiphany's case, this will > never work for the main window, since the title changes based on the viewed > content, but I've already asserted that the main window is special and its > position should probably not be saved. And what you're saying here is basically that you'd want the ephy window(s) bounce around on the screen based on where they were when any given bookmark was last viewed. No thanks. Or if you are saying that the idea doesn't work for the main window, then we're in agreement and I can't understand the discussion - there are no document windows in ephy except for the main window, and because that is not tied to any specific document (or is "Internet content" a document?), there is no need for document-specific window placement. Document oriented UI is nice, but only for document-oriented apps, and there are many that aren't. Another example everyone uses is email. Evolution is basically a single window view to everything about email, so there are no documents. In ancient history, I wrote another type of email app, where each folder was considered its own document, and window positions were remember per folder, which was nice in that you could easily keep track of email in multiple places at the same time, but frankly even I don't multitask at a level where that's necessary (at least not any more I do). > We don't use gconf at all to save state (except for one small case of the > selected node in the bookmarks window and thats a bug). All state info is ok, then I'm confused by gconf keys left by earlier versions, because I do have /apps/epiphany/state/*.. GConf is turning into a bad copy of W95 registry with all kinds of crap staying there forever.. I just hope I'll never see it corrupt itself. > I agree with you on this, but this problem is mainly do to the way users > interact with browsers, and may change in the future as web browser ui's > change to meet a changing internet. If you have some specific ideas of what the future browser interaction will be like, I'd like to hear about them.. -- Osma Ahvenlampi <oa@iki.fi>
This is a digitally signed message part