You are not logged in.
Have you ever thought of the goodness of a graphics terminal? Like running X-like apps inside it (not X apps, that would be redundant), the ability of having a bit more eyecandy, and of course the ability of displaying images without resorting to dark magic. Yes, I think eyecandy can improve usability, when it can provide a cleaner and clearer user interface. Also, having the possibility of using a better font rendering would reduce eye strain.
I was googling for it, and I have found an interesting article about it, and I share all of the views exposed there: http://www.xs4all.nl/~evbergen/groklaw- … minal.html
I would really like to see a terminal like that around some time. Otherwise I'll develop it myself The only problem is that I'm not a coder/programmer (yet).
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
http://freshmeat.net/projects/blueterm/
not a good idea IMO
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline
That's interesting, but it's not exactly what I meant.
The point is that having the folders or emoticons being displayed in the terminal is quite useless in my view. I would concentrate more on fonts and the whole graphical aspect first. But I guess that's already a step towards that direction.
The features I'm looking for are those which improve usability, more than fancy eyecandy. That should be optional and come only in the second place, if at all
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
give us some examples, then.
Offline
I haven't read the links posted here, but I can only think of an app like elinks which would benefit from that.
Or maybe an ncurses app that could use buttons... but using keys is still nicer I think.
Offline
I thought I had already given some examples. My main priorities would be font rendering and also the ability to show some decoration (even giving a good touch to the ncurses interfaces). The ability to view images would be one of the top priorities. That could lead to the possibility of running X-like applications. For example, imagine you could run something like a spreadsheet application in a terminal, or a nice web browser.
I'm thinking in a direction that would bring a change in the UI world. I don't like most of the GUI apps, I find them unpractical. I like CLI apps, but they're too limited in too many ways for today's needs. Having a graphics capable terminal one could use it more or less like a desktop environment (or let's call it a working environment), but, as the article says, in a more Unix way: you have a system with different tools that don't need to interact with each other, but all work well together.
Think of a graphical terminal as an hybrid between CLI and GUI, like Emacs, Gvim or Conkeror.
Utopic enough?
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
Maybe not exactly what you want but try ratpoison WM.
And I want to say that image viewing in terminal wold be damn cool. And in general more formats in terminal.
We have mplayer it shows that multimedia in terminal is possible. So why not images, or pdf files in terminal?
Last edited by ProzacR (2008-01-24 01:20:43)
Offline
How are things coming along in framebuffer land?
Are there fb WMs yet and are they practical? I once read it needs its own applications (no X app will work).
But wouldn't this allow exactly that, graphics on the console?
Offline
Yeah, I'm a happy Ratpoison user already (but it's not exactly what I want).
You are right. We can even see images and pdfs in the framebuffer (with fbi), but not in the terminal. But the point is that I don't want mere ascii alternatives, I want the full thing. I believe we have enough resources today to develop a terminal with graphical capabilities, but almost everyone is too busy with 3D wobbly windows and such. I think it's about where the energy is concentrated. As I said, if I get good enough, I will start a project like that in the near future, even though for now I don't have a clue about where to start
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
@ Gilneas
Well, the framebuffer land is another land
I think it's useless to concentrate on that, exactly because it doesn't support X apps. There seems to be no way to improve that, and I also don't see much of a point of doing that, since we have X for this purpose. It's like reinventing the wheel. X is good, the GUI apps not really.
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
doesnt that defeat the purpose of using CLI? fast, efficient, simple, non-graphical.
Offline
Yes. But you see I browise web with links. And find nice image. So...download it enter startx. Run firefox look image for ~3 secs and then back to terminal.
Acting in this my way is stupid.
Same thing then I get into pdf online. Only solution is to download pdf startx and then read it.
And at all if someone asks my what I lack the most in Linux is pdf in terminal. Not wine 1.0 not native photoshop like most people just * pdf in terminal.
Last edited by ProzacR (2008-01-24 02:17:09)
Offline
Well, it would be surely and hopefully lighter than GUI apps. Of course, one can have bloat even on a ncurses app. I think that's a matter of style.
I am a believer of minimalism, and I think it's a very valuable philosophy, especially when it comes to ergonomics.
Of course, if all the apps work from a terminal, and they are invoked only when needed (a bit like when you issue "ls" or "cd", "mv" and such), then the terminal is still quite light. Even text-only apps can become quite heavy anyway.
As for me the purpose of using the CLI is a matter of design, more than anything else.
@ ProzacR
For the framebuffer you can use fbi to view both images and pdf files We still miss something like that for a X terminal.
Last edited by finferflu (2008-01-24 02:19:35)
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
I'd settle for a terminal that can use non-monospaced fonts and not look like crap.
Offline
For those talking about the Framebuffer: Give DirectFB a try.
Now I think that the term "graphical terminal" is badly chosen, because (my understanding of) the idea is more than just graphics: It's the Unix principle evolved for modern GUIs.
Take something like
ls -sh *.png | sort > file
. You have solved a relatively complex problem with a nifty one-liner, all of you know other examples.
But you are largely restricted to text output. You can format the text and start another program to view an image, watch a video or listen to music, ok.
But particularly in terms of information presentation and contextual interaktion, a modern GUI has the potential to be a lot more effective than any 80x25 terminal. I implemented a simple webserver in my last C application and used in fact HTML for the presentation of the information, because it allowed me the output of ALL information in a very clear way on my 1280x800 notebook screen, while terminal output would have been almost unusable for this and even a GTK application would be worse in terms of information presentation.
Still, HTML is a bad choice, because there's no reliable rendering anywhere, designing is a PITA and the communication via HTTP is more complicated than it should be for a simple GUI.
A screenshot of my program's output: Try to output the same information in a clear way with another method.
Offline
I think you hit the nail. And I think you are right about the wrongly chosen term. I couldn't find any better one, so I used "graphics terminal" to indicate something between a GUI and a command line environment.
What you say it's exactly what I meant when I said that I like the CLI but I find it too limited. If a CLI approach to computing would be implemented to GUI-like applications, I think usability would be improved a lot.
I thought about some examples. Let's say that for listing the contents of a folder, you can be happy with "ls" or an enhanced version of it, with a better display. Then you could have something like "lsimg" that lets you see all the images in a folder in preview mode. But you don't have to be stuck to a prompt. Ncurses apps have shown us that we can also have user interfaces inside a terminal. So we could have applications that work in a similar way to ncurses. The point of all this is the all-in-one power of the terminal. Where "all" stands for the multiplicity of the Unix tools (one tool does one job), and "in one" stands for the common base for all the tools.
Everything, of course, could be organised in a semantic way. Think about having a dzen2-like prompt, but improved: you type "music" and all the music-related apps turn up with a short description. One could have an approach to the tools similar to the .desktop files, where everything is organised by category. And for managing multiple apps in one screen one could do something similar to GNU Screen, but with more tiling capabilities.
This sounds more like brainstorming to me, but everything is falling in place in my mind.
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
you should put together a quick mock-up. I am still having difficulty in what this "graphical terminal" would look like...
Offline
Maybe one of these does what you want:
CUI
Hotwire
The Hotwire website lists some more: http://code.google.com/p/hotwire-shell/ … tsAndIdeas
Last edited by smoon (2008-01-24 15:06:03)
Offline
@ bionnaki
Yeah, I was thinking about that. I will make one later on today, if I find enough time.
@ smoon
Thanks a lot, the last link is very interesting, I will look in all of those links.
I have installed Hotwire, but it crashes before it starts, the CUI's donwload page is empty, so I don't know how to get it...
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
[...]
@ smoon
Thanks a lot, the last link is very interesting, I will look in all of those links.
I have installed Hotwire, but it crashes before it starts, the CUI's donwload page is empty, so I don't know how to get it...
CUI's download page works for me: ftp://linux.pte.hu/pub/CUI/cuiterm-0.9.10.tar.gz
Have you tried the Hotwire PKGBUILD in AUR?
Offline
Ah well, it oddly showed me an empty archive, but your direct link works. Thanks
As for Hotwire, I have used that PKGBUILD in AUR, yes, and it crashes. There's my comment on the package page in AUR.
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
No luck with CUI. I have made a PKGBUILD, but the build fails (last few lines):
GtkTextBuffer*text_buffer;
the GtkTextBuffer holding the text
GtkTextView*text_view;
the GtkTextView holding the terminal text
Background*background;
the background for this terminal
CuiGenerator*command_generator;make[2]: *** [html-build.stamp] Error 1
make[2]: Leaving directory `/var/abs/local/cuiterm/src/cuiterm-0.9.10/gtk-doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/abs/local/cuiterm/src/cuiterm-0.9.10'
make: *** [all] Error 2
Have you Syued today?
Free music for free people! | Earthlings
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- A. de Saint-Exupery
Offline
I was wondering if something like this existed. Tanks! Such project might become a new hobby of mine
Offline
No luck with CUI. I have made a PKGBUILD, but the build fails (last few lines):
GtkTextBuffer*text_buffer; the GtkTextBuffer holding the text GtkTextView*text_view; the GtkTextView holding the terminal text Background*background; the background for this terminal CuiGenerator*command_generator;make[2]: *** [html-build.stamp] Error 1 make[2]: Leaving directory `/var/abs/local/cuiterm/src/cuiterm-0.9.10/gtk-doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/abs/local/cuiterm/src/cuiterm-0.9.10' make: *** [all] Error 2
Doing
./configure
make
in the CUI source directory works for me. I can even run it. I bet you're just missing some packages...
Last edited by smoon (2008-01-24 16:58:37)
Offline
I'm not really sure what we're talking about here, so I'll blurt out some ideas that I find interesting.
I agree with the article's idea of applying Unix principles to GUI design. Being able to use the output of any program as the input of any other brings flexibility and power (imagine an Olympic gymnast lifting cars over their head). Using that idea in GUI design (something like the X server?) would enable fast and sensible development of GUIs, and would put the focus in the right place: content first, presentation tacked on. This allows for very pretty and efficient presentation (think of LaTeX).
I agree with the fact that modern GUIs don't seem to be heading the right way. Everyone's busy copying 'de facto standards' instead of thinking about what makes a goof GUI. e.g. X's composite and damage extensions allow for very powerful GUI manipulation. AFAIK, the main project that makes use of it, Compiz, focuses more on bling than usability. They've got useful things like zoom, but so many useless things that look pretty. I'm all for looking pretty, but I'm for usability first.
I think that the keyboard is the best human-computer interface for everyday use. A mouse is sometimes very useful, but the way GUIs are designed, I usually take my hands of the keyboard, grab my mouse, move it for a few seconds, click, then get back to the keyboard. That breaks concentration. Software that I find has a good UI: vim and bash (still haven't tried zsh).
Speech is coming along as a natural and efficient UI. The free options available now don't really come close to competing with the proprietary products (please donate your voice, read a few sentences to improve the free acoustic and language models! http://www.voxforge.org/), but in a few years I think we'll be seeing more common tasks being controlled via a microphone. Right now the X server reacts to keyboard and mouse events. This should be generalised.
I think the user should have the power to customize the UI, but there should be sane defaults. Exposing the guts of the GUI to the user, if they are simple, is a good thing.
etc.
I think it's not complicated to get this done. Probably less complicated than the current GUI "kits".
Last edited by peets (2008-01-25 06:09:12)
Offline