Ever thought of a graphics terminal?

peets · 2008-02-08 03:21:31

I like the "scriptable GUI" proposed in the article. Looks clear and powerful.

finferflu · 2008-02-08 09:56:17

That's a pretty neat article. Surely very inspiring. I also like that "scriptable GUI", it reminds me of the electronic circuits I used to build in high school Surely that would solve many problems, especially if it was able to output the actual code. A piece of code is always more portable than a GUI interface.
I also like some of the concepts of the beginner's terminal. All the ideas are quite interesting, even though I'm still convinced windows are not good. They might be good for a limited set of applications, like the Gimp, Inkscape, or Blender.

finferflu · 2008-03-10 18:02:47

Ok, I have switched back to Gnome. I'm forcing myself to use it for a while. I'm fully WIMP geared, and removed the omnipresent terminal. I want to see what are the things that *really* annoy me and what I could miss. This way I can build up a list of features and start some serious mock up. Summer is getting close

Last edited by finferflu (2008-03-10 18:03:51)

vogt · 2008-03-10 19:23:38

A more abstract version of those combinators you were visualizing (with a pretty? syntax) can be seen in: haskell arrows.

Its just maybe a bit overkill, and has a steep learning curve, but I hear that it works well enough for scripting for some people.

EDIT: Generally, you combine things linearly, which is why pipes (with some tees) work well.

This sort of thing is also like how you set up a modular synthesizer: you can either have visual analogy, like buzz or aldrin....(get it?), against more text oriented systems like csound.

Ultimately, csound more flexible, scriptable, and extendable, but the ones with explicit visual metaphors (arrows) are easier to approach.

Last edited by vogt (2008-03-10 20:09:07)

peets · 2008-03-10 20:10:46

Gnome! You're very... dedicated.

I've been slowly gathering some ideas too. I'll be jobless in May; if I budget well I think I can manage a "vacation".

I don't really understand arrows (yet!). It's another good reason to keep learning Haskell!

finferflu · 2008-03-10 20:24:50

Thanks for your suggestion vogt. I'll start considering which language to begin learning after having a clear idea of what I want. So I can choose the best suited one, hopefully.

peets, I chose Gnome for several reasons: a) I hate myself no, seriously: a) because it looks to me the KISSest one in the WIMPy world; b) because it seems the most coherent in look and feel (see point a); c) because it is quite complete with many integrated apps that seem to communicate well between each other; d) because it's centered around usability and ergonomics.

Last edited by finferflu (2008-03-10 20:26:14)

Arkane · 2008-03-11 10:23:52

(Crashing into the thread, 1 1/2 months late)

The ideas in this thread, as well as dunc's article, got me thinking quite a bit, and I've been trying to come up with a clear concept. Here's some kind of (specification/idea/whatever) I wrote that could be the basis for a real implementation, though the main thing it makes clear is that I wouldn't be able to do it by myself anytime soon ^^'.

But this might at least fuel the discussion:

Multipiping graphical terminal emulator (and GUI wrapper)

        Each program can use an arbitrary number of named input and output streams, including 
        the usual stdin, stdout and stderr (which might be aliased to some of the custom streams 
        or something).
        
        The program also provides hints, obtained by calling it with the --hints option 
        (or maybe from -h?). Those provide, for both input and output, a numbered list of 
        streams, with:
            - their name,
            - the type of the data they carry.
        
        We provide a basic (or not) multipiping shell language, that allows parallel connexion 
        of arbitrary output streams to input streams of other programs.
        
        The shell passes as parameters to a program the file descriptors of each of its pipes 
        (how possible is it to manipulate "anonymous" file descriptors like that around? We'll 
        probably need a library to allow the called programs to understand them).
        
        The simplest way of dealing with data types would be:
            - mimetypes for "real" data, this allows for excellent flexibility
            - one (or several) additional data type for "control signals", i.e. single click-like 
                activation, keyboard presses, etc.; generally, anything that can be considered 
                a "GUI event".
            
        By default, the shell will refuse to connect two ports with different data types. However, 
        we provide an option to force it.

        The shell will also use environment variables to find default handlers for non explictely 
        piped ports. In case no default program is found, the port is connected to /dev/null.
        Also use a single variable which, when set, disables all default bindings.


        The "graphical terminal" itself will consist of:
            - A standard text i/o section
            - A graphical output section
            - A separate popup-style stderr section
            - Possibly other areas. What about a dynamic completion area showing completion 
                possibilities or command options depending on the context?
            
        We could use a modal interface with three modes:
            - Insert mode in the selected application (used to send text input and "clicks" to 
                selected ports). 
            - Raw keyboard input to the selected application.
            - Screen-like(?) task management, output area layout management, etc
        
        The terminal emulator will then provide its own builtin handlers for as many output 
        data types as possible - basically, display graphical content, play sound, etc (and will 
        also connect the stderr of programs to the stderr section of the interface), as well as 
        ways of generating all required types of input.
        
        With this, we have a complete, extensible graphical terminal.
        
        
        
        We will (or might) also provide a cross-toolkit GUI wrapper that allows launching of applications 
        designed for the graphical terminal in their own window, with a "GUI" feel.
        The wrapper will use extended hints specifying a widget to be associated to each port 
        (or possible several at the same time), and its position. These hints are optional; the wrapper 
        will provide an usable default behavior.
        
        
        
        So, here's what we have to take care of:
        
            - Create the multiping shell, and probably a library to allow programs to receive pipe file 
                descriptors as arguments. This is all going to be a real pain.
            
            - Devise the data type format.
            
            - Devise the hints format.
            
            - Write the base, modular terminal emulator, in an X window for now.
            
            - Write data type handlers for the terminal emulator (as modules).
            
            (- The GUI wrapper?)

Last edited by Arkane (2008-03-11 10:32:43)

peets · 2008-03-11 18:42:30

I read Tufte's The Visual Display of Quantitative Information over the weekend. It's a book about making good graphs; a lot of the principles apply to GUI design too. Here're some highlights. finferflu (and other Gnome users), they might be things to look for on your Gnome quest.

Edward R. Tufte wrote:

Chapter 1, conclusion
Graphical excellence is the well-designed presentation of interesting data --a matter of substance, of statistics and of design.
Graphical excellence consists of complex ideas communicated with clarity, precision and efficiency.
Graphical excellence is that which gives to the viewer the greatest number of ideas in the shortest time with the least ink in the smallest space.
Graphical excellence is nearly always multivariate.
And graphical excellence requires telling the truth about the data.

Epilogue
What is to be sought in designs for the display of information is the clear portrayal of complexity. Not the complication of the simple, rather the task of the designer is to give visual access to the subtle and the difficult --that is,
the revelation of the complex.

(ot: Tufte thinks this graph is possibly the best he's ever seen. I like it!)

finferflu · 2008-03-11 18:46:20

Too much input guys! my head is gonna explode
I want to assimilate those ideas and see if they can materialise into something.

smurnjiff · 2008-03-12 00:40:28

I've been using dwm for a while but I'm always attracted to the native feel of Gnome. You're right---applications do seem to work better in the Gnome DE.

scj · 2008-03-12 06:51:56

Sounds like finferflu should ditch linux and try Plan 9 instead. They've have a pretty neat interprocess communication mechanism called plumber.

Last edited by scj (2008-03-12 06:58:18)

finferflu · 2008-03-12 07:03:42

Ah! I knew about Plan9, but not enough. I'll dig it, but surely I'm not gonna leave Arch I've noticed there are some ports for Linux, and they're in our repos:

1 community/9base 2-2
    Port of various original Plan9 tools to unix
2 community/plan9port 20051127-1
    Plan 9 from User Space (aka plan9port) is a port of many Plan 9 programs from their native Plan 9  environment to Unix-like operating systems.
3 community/9wm 1.2-1
    window manager made to emulate plan9's 8 1/2

scj · 2008-03-12 07:58:32

Maybe I mistunderstood you, since it seemed like you were willing to throw out the baby with the bathwater and start with a clean slate to get things "right".

finferflu · 2008-03-12 08:02:37

Well, if you read my posts above, you'll see that I wasn't even willing to ditch X11. I don't want to be touching the underlying system, I'd rather use it. I'm not a programmer (yet), so I don't think I would ever manage to actually create a new operating system. In the end I'm only looking for a usable user interface, nothing more.

finferflu · 2008-03-12 14:56:55

Ok, I'm installing Plan9 via Qemu... half an hour is gone and we're still at 5%

Anyway, here is what I gathered so far using Gnome:

My setup is as follows: Gnome + Compiz. I have set the desktop plane to manage 4 desktops (2x2), so I can easily reach them, quickly, with not too many effects. I have created some keyboard shortcuts to access my favourite apps and the 4 desktops: Win+{a,s,z,x} for the destops, Win+i for Firefox, Win+s for Sonata and so on. I don't use more than 2 apps per desktop, so I can easily switch between them. I don't use more than 4 desktops, for the same reason. Usually I try to keep it down to one app per desktop, however, and I use it at fullscreen.

What I like
* The consistent look and feel of the apps. As well as the consistent interaction between them, and between them and the system (i.e. if I press the "play" key on my computer it works in any Gnome-designed app)
* The ability to split my work into different areas.
* Having my favourite applications at hand, namely the system tray and the panel applets.
* Having a nice tidy menu (even if I don't use it).
* The ability to use a terminal emulator

What I don't like
* Even though the apps also work via keyboard shortcuts, they seem to be designed with the mouse in mind, which implies you have to constantly switch between keyboard and mouse, even though you are writing documents and such.
* Moving and resizing windows by hand is horrible.
* Overlapping windows are counter-intuitive.
* There is no "wordy" interaction with the system, and you have to rely on what the buttons/menus allow you to do, which implies that sometimes you are forced to dig down submenus or multiple clicks.
* Having too many applications open creates bloat (not in memory usage, but in window layout).
* Related to point 2: if you need to do things quickly, the desktop becomes bloated easily, because it needs some effort to keep things tidy, i.e. manually moving/resizing windows. So if you're using a lot of applications your desktop is quickly invaded (infested?) by piles of popup and non-popup windows.

Nothing so new, but it's good to refresh my mind. I think I'll quickly come up with something more.

Anyway, the installation froze, so I'm running Plan9 as "live CD", and feeling lost already I don't like this introduction:

To effectively use rio, you need at least a three button mouse.

Aww crap! here we go again X_x

vogt · 2008-03-13 03:41:56

finferflu wrote:

* Moving and resizing windows by hand is horrible.
* Overlapping windows are counter-intuitive.
* There is no "wordy" interaction with the system, and you have to rely on what the buttons/menus allow you to do, which implies that sometimes you are forced to dig down submenus or multiple clicks.
* Having too many applications open creates bloat (not in memory usage, but in window layout).
* Related to point 2: if you need to do things quickly, the desktop becomes bloated easily, because it needs some effort to keep things tidy, i.e. manually moving/resizing windows. So if you're using a lot of applications your desktop is quickly invaded (infested?) by piles of popup and non-popup windows.

compiz-fusion seems to have a bunch of plugins that might help:
- window tiling, grouping, tabs: the interface to these seemed a bit excessive, or maybe it's just that there are so many things to bind to so few keys in compiz-fusion.
- fading other windows (add helper?) maybe. I think it's annoying, but maybe you won't?

or there is the other approach of adding the features to a layout you like . As in gnome with xmonad as the window manager http://haskell.org/haskellwiki/Xmonad/U … d_in_Gnome

To just take a look at the concepts of rio and acme (I don't like them:)). Check out this qemu image, all ready to use...
http://www.oszoo.org/wiki/index.php/Plan9_070107.zip

finferflu · 2008-03-31 16:03:11

I have found an interesting link, which is quite old, but still good, in my opinion: http://www.sigchi.org/chi95/proceedings … m=anti+mac

Arch Linux

#76 2008-02-08 03:21:31

Re: Ever thought of a graphics terminal?

#77 2008-02-08 09:56:17

Re: Ever thought of a graphics terminal?

#78 2008-03-10 18:02:47

Re: Ever thought of a graphics terminal?

#79 2008-03-10 19:23:38

Re: Ever thought of a graphics terminal?

#80 2008-03-10 20:10:46

Re: Ever thought of a graphics terminal?

#81 2008-03-10 20:24:50

Re: Ever thought of a graphics terminal?

#82 2008-03-11 10:23:52

Re: Ever thought of a graphics terminal?

#83 2008-03-11 18:42:30

Re: Ever thought of a graphics terminal?

#84 2008-03-11 18:46:20

Re: Ever thought of a graphics terminal?

#85 2008-03-12 00:40:28

Re: Ever thought of a graphics terminal?

#86 2008-03-12 06:51:56

Re: Ever thought of a graphics terminal?

#87 2008-03-12 07:03:42

Re: Ever thought of a graphics terminal?

#88 2008-03-12 07:58:32

Re: Ever thought of a graphics terminal?

#89 2008-03-12 08:02:37

Re: Ever thought of a graphics terminal?

#90 2008-03-12 14:56:55

Re: Ever thought of a graphics terminal?

#91 2008-03-13 03:41:56

Re: Ever thought of a graphics terminal?

#92 2008-03-31 16:03:11

Re: Ever thought of a graphics terminal?

Board footer