Hello Everybody, I think there is a lot to like about GNOME Shell, and where the project is going, but I wonder a little about the implementation (though I very much a n00b, so it may in fact be my own ignorance (and, if so I am very sorry)).
At this stage for instance, I don't understand the reason the LookingGlass console doesn't just use an instance of gnome-terminal, that being a much nicer interface to work with IMHO (eg. better wrapping/scrolling support, copy-pasta, etc. - LookingGlass looks like a garage computer game's console to me). After testing a recent build I also wonder whether the proposed interface should really require 3D compositing support (Clutter); yes, it would suffer without it, but I do think that it would still be usable if there was fallback (non-3D / no-compositing) support builtin. I do not want to have to use a different GUI if I lose 3D acceleration - even if I do have to forfeit live 'mini' views of my apps and other niceties! I know this project aims to break new ground, but I do worry about taking things too far in the name of doing so. Respect & Regards, Nat On Thu, Nov 5, 2009 at 11:00 PM, <[email protected]> wrote: > Send gnome-shell-list mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.gnome.org/mailman/listinfo/gnome-shell-list > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gnome-shell-list digest..." > > > Today's Topics: > > 1. Re: Concept attached + ideas (Andre "Osku" Schmidt) > 2. Re: Request for comment (GNOME Shell team): release date for > GNOME 3.0 (Willie Walker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 04 Nov 2009 14:39:20 +0100 > From: "Andre \"Osku\" Schmidt" <[email protected]> > To: [email protected] > Subject: Re: Concept attached + ideas > Message-ID: <1257341960.2674.112.ca...@koala> > Content-Type: text/plain; charset="UTF-8" > > On Mon, 2009-11-02 at 21:19 +0000, Jimmy Forrester-Fellowes wrote: > > > The workspaces could be saved so when you boot up your computer you > > can return to a workspace just the way it was when you left it. > > this is exactly what i wanted to have since i've used computers with > multiple windows. (hey, i started with *-DOS:) > > but, isn't this still a problem in the application ? > (haven't looked/followed on this since years) > > some apps do and some don't save information (or allow control from > outside) on what files were open, where the cursor was, undo/redo, > etc... (i assume window positioning can globally be saved by the window > manager) > > and to tell the apps which saved "workspace" to open, i fear that it > will never happen that major floss apps agree on an api to control this > from outside. (even lash[0] is not much used, and there are not so many > apps in audio space) > > but i really hope i'm just too deep in my cave and missed something, and > it's already (at least, in near future) possible to save the states of > an application in a workspace/file/what ever... > > <obligatory web search> > > found a really interesting tool: http://cryopid.berlios.de/ > sounds like a solution to use right away, hmm... > > cheers > .andre > > [0] http://savannah.nongnu.org/projects/lash > > ps. i have been playing with the idea to make these "workspaces" in a > virtual machine (one workspace = one virtual machine), so i would have > 100% the same workspace as i left it (cause the vm is just "freezed"). > but waiting for like 4 OS'es to boot _after_ the main OS, doesn't sound > much fun... > > > > ------------------------------ > > Message: 2 > Date: Wed, 04 Nov 2009 14:25:02 -0500 > From: Willie Walker <[email protected]> > To: Pi?eiro <[email protected]> > Cc: [email protected], [email protected] > Subject: Re: Request for comment (GNOME Shell team): release date for > GNOME 3.0 > Message-ID: <[email protected]> > Content-Type: text/plain; format=flowed; charset=ISO-8859-1 > > Thanks API! > > I think focusing on GNOME Shell a11y via AT-SPI is a great goal to focus > on rather than puzzling over general clutter a11y. The end result will > be that at least a very specific needed problem will get solved, and > perhaps a more general solution will be created in the process. > > My understanding is that the Shell Toolkit (ST) used by GNOME Shell is > an NBTK fork and is probably the place where AT-SPI/ATK widget work > might live. If you were to look into this space and give us an > evaluation of the work necessary to make ST accessible, it would be > awesome. > > Thanks again, > > Will > > Pi?eiro wrote: > > From: Owen Taylor <[email protected]> > > > >> Accessibility: > >> > >> Two big areas of work here: one is keynav, the second is exposing > >> the user interface tree to AT's. Keynav is partially there, but > >> there's a ton of work to make sure that *everything* is keynavigable. > > > > Anyway, the key navigation, after read some mails in the mailing > > lists, and some comments in the bugzilla, it is not just a > > specific-a11y request, but something that most of the users could > > benefit from. > > > >> Exposing the UI tree will likely fall out of the work that is being > >> done with Cally, though the exact relationship of that with Clutter > >> (is it a separate library) is not, to my knowledge, completely > >> finalized. > > > > No, it is not completely finalized (it is any library completely > > finalized?), but the talk with Joan Marie help me to prioritize the > > missing features to implement. > > > >> But exposing a raw tree of clutter actors is in no way > >> interesting, so there's probably considerably *more* work to make > >> sure that the tree exposed from gnome-shell meaningful represents > >> the objects and actions on them, and likely some AT-side to work to > >> figure out how to interact with objects in gnome-shell that had no > >> correspondence in the GNOME 2 desktop, like the Overview itself. > > > > The fact that all clutter objects are exposed is a issue detected > > since the first time that I saw the full tree (ie: has sense from the > > a11y POV to expose a ClutterBehaviour?), and commented on my GUADEC > > talk [1]. One option could be implement a way to "hide" the objects > > that you don't require, like Webkit folks are doing right now (ie > > [2]). > > > > Anyway, this is not in my list of priorities. AT applications were > > making this kind of filtering for a long time (if you see a tree > > hierarchy of objects with glade in a GTK+ aplication, you would see > > that you don't need to navigate or interact with all the objects, the > > container hierarchy, etc.). > > > > Right now, I think that the priority is get ORCA interacting with the > > GNOME-shell, at least in basic way. > > > > > >> (Editorial: unfortunately, accessibility in GNOME has too often been > >> partial technical solutions and unfulfilled promise. While not > >> regressing on the technical side is important, I don't think that's > >> the interesting thing - the interesting thing is to make progress > >> on the user experience here. So we shouldn't be grading ourself > >> on whether we continue exposing a UI tree to AT's, but whether we > >> have AT's that can take that information and present a coherent > >> user experience based on it.) > > > > Well, I think that it is a two way problem/solution: yes, the AT > > applications will require to take the information and present it in a > > coherent way, but in order to make that, GNOME-Shell requires to > > expose that properly. > > > > A quick example of that, that I can made as recently hildon-desktop > > was being public [3], and it is using cally (well using the old name, > > but using it). > > > > It has a task launcher that, surprisingly, allows you to launch the > > apps. It is basically a grid with several ClutterTexture used as > > buttons. In the past this was just a ClutterActor (this was moved to a > > ClutterGroup two days ago), and the grid was just a object managed by > > it. So, from the AT didn't have any way to get the object, so a custom > > a11y object was required to be created [4]. > > > > This is just a example, and I can't tell if this will be required, as > > I need a deep review GNOME-shell. But in the same way that > > hildon-desktop required some work, and the hildon widgets required > > HAIL, there is a high possibility of that. > > > > However, I agree that right now the a11y support on gnome-shell > > requires more work in the base library (Cally). But, my idea is, after > > solve the issues pointed by Joan Marie in the Boston Summit, orient > > the development of Cally in a real application, in this case, > > gnome-shell, to have a target of evolution, instead of just implement > > atk features inside cally without a specific reason. > > > > To finalize: the other problematic thing not commented here is the > > Gtk-Clutter integration. I made some questions about that on the > > Boston Summit, but I would like to confirm that: > > > > * Right now there are some Gtk elements on the Gnome-shell (ie: the > > user info panel) > > * The idea is remove that in a future. > > > > I'm right? On my tests with gnome-shell, the gail-cally interaction > > gave me some problems. The difference between a mixed clutter-gtk > > application and a pure clutter (or gtk) is really important. A mixed > > environment have several issues to solve. > > > > Best regards, and sorry for the long mail > > > > [1] > http://people.igalia.com/apinheiro/files/cally_guadec_2009_slides.pdf.gz > > [2] https://bugs.webkit.org/show_bug.cgi?id=25897 > > [3] http://maemo.gitorious.org/fremantle-hildon-desktop > > [4] > http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/blobs/master/src/a11y/launcher/hda-launcher-page.c > > > > === > > API ([email protected]) > > > > ------------------------------ > > _______________________________________________ > gnome-shell-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-shell-list > > > End of gnome-shell-list Digest, Vol 13, Issue 7 > *********************************************** >
_______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
