Sorry for starting new thread but I find no place to hook into previous one. I'd like to discuss a few aspects of use gnome-shell. While all can be implemented as extention I'm not sure if such deep integration will not destroy the integration. Current status is that the gnome-shell is application oriented in similar way as phones under some assumptions and that is bad. Some users don't know what application they're using - I overhear talk when one respond he does not know what program he's using to write text. Forcing the application oriented view instead of file-oriented in GNOME 2[1] (in current shell there is no recent files in overview even). It is IMHO bad for several reasons: - As I said user thinks in terms of writing mail, reading document etc. They don't know what applications they are using so icons showing just the applications are hard to use - If (power)user wants to have many windows it is harder to navigate. And some more-then-normal-but-less-then-super users do (I know 50-year-old person who use multiply windows and regret that Windows does not have always-on-top feature) - It changes application development by π - multiply windows recommended so far makes application harder to use. - It promotes separate application development rather then integration. Application is visible - not part of user experience and implementation detail What can be done: - It would require modifying .desktop files but maybe the icons on LHS should be for documentless applications (gwibber, evolution) and for fields labbeled as 'Open new text document' (for gedit and/or openoffice), 'Open new spreadsheet' (for gnumeric) etc. - Alternatively display GenericName if possible (for example instead of Evolution display Groupware Suite). It would require lookup into .desktop files however. - Allow searching for window titles in overview instead in applications. If I'm editing this e-mail I don't want to get main Evolution screen so searching for 'Wor' should do the trick. - Preferably allow easy and non-js-only way of introducing search hooks (say by zeitgeist, tracker or probably own API). Even if evolution displays my Inbox searching from 'gnome.shell' should go to the newsgroup (I'm viewing it via gmane but it can go to IMAP folder etc.) Other part of the problem is the workspaces. It depends on what particular power user is doing but: - Some separates fullscreen applications by them (personally I think it should be addressed by other mechanism) - Some design one-workspece-per-task. For example if I'm doing 3 projects + 1 work each will have the currently opened text editor, terminal and browser window. Additionally first one will be used on general windows (like mail client). I don't want to be forced to reopen them each time I change task (say finish part of one project, check mail and find bug reported in another one) - ... In following part I'll assume that I'm correct but it may happen there are better use of workspaces. However: - Normal users should be allowed to not notice workspaces at all - Power users should not be alienated - it is them who eventually may contribute back Current gnome-shell model: - Array of workspaces which allow the random deletion but only tail adding - Overview mode have mixed view (displays windows from this workspace but all applications so clicking terminal may switch workspace) What can be done (general): - Specify what exact model we have in mind when we talk about workspaces - Check if it suits the user. If only powerusers use workspaces and they find it too simply it possible time to add some features What can be done (assuming I'm correct): - Make 'Open new <name>' workspace-specific. In my mindset it is inconsistent if the same button either switches task or opens new in current task - Allow persistent workspaces (i.e. if I quit with 4 workspaces log in with 4 opened) - [Extention but guaranteed to not break anything?] Allow rearranging of workspaces - [Possibly?] Allow naming (an searching?) workspaces [Needed by libwnck - needed by EWNH and ICCCM?] Regards [1] http://library.gnome.org/devel/hig-book/2.32/windows-primary.html.en
Attachment:
signature.asc
Description: This is a digitally signed message part