Re: LookingGlass: a poor terminal implementation?

[Colin Walters <walters verbum org>]

On Fri, Nov 6, 2009 at 2:06 AM, n@ <nathaniel42 gmail com> wrote:
>
> 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).

Heh, well; this is an issue with a lot of nuances.  I wouldn't say
terminal emulators are  the end all in highly textual interfaces.  The
terminal grid layout for example actually prevents sane wrapping (you
know how you get line breaks at the end of the display when copying
from a terminal where none existed in the input text?  Yeah).

Also, although the lookingGlass display is not actually one big text
area at the moment, we could in the future add say a little button
next to a result to toggle the display between JSON.stringify and
toString, for example.  Or just format things more nicely.

I think what you're getting at in general is that some of the UI
elements are missing important behavior - and that's absolutely true.
We've been fixing that by reworking the code base on top of an
internal toolkit called "St", which derives from the Moblin toolkit.
This conversion is not complete, but it's progressing.

> 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.

We aren't really exercising the graphics stack in obvious ways as much
as we could be necessarily, but:

> 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!

Very, very hard in general.  I think it makes sense to get the current
interface more complete and fully fleshed out, validate it, and if
we're highly confident in it then we could consider moving parts of
the older GNOME 2 stack closer to it (I could imagine backporting the
application tracking bits, and having an application-based panel say
in just a few weeks of work).