GNOME Bugzilla – Bug 106215
make history windows toplevel window
Last modified: 2004-12-22 21:47:04 UTC
Does it make sense to be able to have more than bookmarks and history window open? Right now these dialogs are per window. Is this correct, or should they be stateful across all browsers. Changing to a one window representation for these would probably require some ui redesign including making both of these top level window with menu bars etc. comments? I'm not sure of the answer really, but a bug to discuss this seems like a good idea to me.
>Does it make sense to be able to have more than bookmarks and history >window open? I'm sorry but I dont understand what you mean with this question. These windows are per window atm but you can still close the window. Problems with having them global are: 1 Where do you open the url on jump to ? 2 Not transient dialogs sucks Maybe it's worth to think to the task one want to get done with these dialog, prioritize them and see if current behavior is bad for the important tasks. Anyway, why you are thinking about this change ? What doesnt work in current behavior ? I bet the answer is in that question I dont understand ;)
Ok maybe i should have been more clear :) Right now it is possible to have open multiple bookmark/history windows per each window. I assume this is easy to fix. However even if this is fixed per window, it still possible to have multiple bookmark windows open (ie. one per window), which could be potentially confusing (I'm not sure yet...).
Created attachment 14443 [details] Screenshot of alternative ui. eg. bookmarks as a top level window
Personally I dont feel having more than one bookmarks dialog confusing. I see the dialog more like a place where you can select the page you want to open in current browser and then close it, than like a central place where you can open several bookmarks from (so that you want to keep open but hidden under the other windows). That's why I believe it should be a transient, per window, dialog. Just brain storming.
explanation of the above mockup: In a design as shown above, the bookmarks window would be a unique (ie. only one bookmarks window can ever be open). Menus: ----- File ----- Open: Opens the currently selected bookmark in the last used window or tab (similar to the current jump to), alternatively we could just follow the user "Open in Tabs" pref and open the bookmark in a new window or tab based on that pref. If no browser windows are open a new window is opened to the selected bookmark. If a key word is selected, all bookmarks in that keyword are opened according to the user's "open in tabs" preferences. Open in New Window(s): Similar behavior to open, but the bookmark is always opened in a new window. Also if a key word is selected the entry changes to "Open in New Windows," opening all bookmarks in the keyword. Open in New Tab(s): Same behavior as "Open in New Window" but uses tabs in the last used browser window. If no windows are currently opened a new window is created. Similarly, selecting a keyword changes the entry to "Open in New Tabs" and opens all bookmarks defined by the keyword in tabs. <separator/> Close: Closes the bookmark window. ------- Edit ------- Undo: Undo the previous action. This would include undoing changes to the Title, Location and Keyword fields as well as the removal of bookmarks. Redo: Redoes undone changes as specified above. <separator/> cut copy Paste: Only used to manipulate text entry fields. These entries are greyed out if focus is not in a text entry box. <separator/> Remove Bookmark(s): Removes the selected bookmark, if a keyword is selected menu changes to "Remove Bookmakrs" and all bookmarks which include the keyword are removed. This entry is greyed out if focus is not the keyword or title trees. <separator/> Select All: Behavior changes depending on context. In text entry boxes it selects all text. In keyword tree all keyword fields. In the title tree it selects all bookmarks. ------ Help ------ Contents: Opens bookmark help About: Generic ephy about entry. ----------------------------------------------------- Using a top level window approach as mentioned here has it's advantages and disadvantages. advantages: 1. Top level window is easier to keep open all the time, as it appears in the window list and is not always ontop of browser windows. This gives users fast access to the bookmark window. 2. Perhaps is slightly less confusing as only one bookmarks window is used for all browser windows. 3. We could epiphany --open-bookmmarks-browser (or something like that) allowing users to add a launcher to the desktop facilitating fast access to bookmarks without having to open a browser window first (ie my bookmarks as a folder idea). Disadvantages: ---------------- The main disadvantage is a slightly more complex ui. Whether the benefits of increased functionality outweight this, requires further consideration (i'm personally not sure which is better yet).
re: previous comments I think we should bring this up on ephy devel, and try to get a handle on the use case. Perhaps my usage patterns are different than the majority?
Sure, it make sense.
Dave, what we do with this ? Bookmarks are done ...
I have a ui proposal for history as a toplevel window floating around my computer, and i would like to consider if/when we make the history ui more similar to the bme. Reading some stuff/talking to mpt is starting to make me think that this is a good idea. Anyway i would move this to future if we had that as a milestone.
Proposal for toplevel history window: File -> _Open in New Window Ctrl+O -> Open in New _Tab Shift+Ctrl+0 -> ------------------------------ -> _Delete -> _Bookmark Page... Ctrl+D -> ------------------------------ -> _Close Ctrl+W Edit -> Cu_t Ctrl+X -> _Copy Ctrl+C -> _Paste Ctrl+P -> Select _All Ctrl+A -> ------------------------------ -> C_lear History View -> (*) _Title -> ( ) _Address -> ( ) T_itle and Address Help -> _Contents F1 -> _About I'll attach a mockup screen shot too.
Created attachment 15695 [details] oh and the column titles should be "Sites" and "Title"
Shouldnt the From stuff be in view in this case ?
In general I'm starting to hate how histories works (any types of them I've seen). Wonder if we will ever find a way to make it not suck ;)
Well my guess (from mostly personal experience) is that if the history dialog went away, very few people would actually complain. History can be useful, but more often than not I find the type ahead in the entry much more useful anyway.
The redesign is done. For problems with it (and additions) is prolly better if we post separate bugs.