LookingGlass: a poor terminal implementation?

["n@" <nathaniel42 gmail com>]

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, <gnome-shell-list-request gnome org> wrote:

Send gnome-shell-list mailing list submissions to
       gnome-shell-list gnome org

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
       gnome-shell-list-request gnome org

You can reach the person managing the list at
       gnome-shell-list-owner gnome org

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" <andre osku schmidt osku de>
To: gnome-shell-list gnome org
Subject: Re: Concept attached + ideas
Message-ID: <1257341960 2674 112 camel 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 <William Walker Sun COM>
To: Pi?eiro <apinheiro igalia com>
Cc: gnome-shell-list gnome org, release-team gnome org
Subject: Re: Request for comment (GNOME Shell team): release date for
       GNOME 3.0
Message-ID: <4AF1D50E 8020908 sun com>
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 <otaylor redhat com>
>
>>  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 (apinheiro igalia com)



------------------------------

_______________________________________________
gnome-shell-list mailing list
gnome-shell-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list


End of gnome-shell-list Digest, Vol 13, Issue 7
***********************************************