Ever thought of a graphics terminal?

harlekin · 2008-01-30 13:49:51

Thanks for clarifying, finferflu.

Though I think I understand what you want, I still see no need throw away what other's have created and what we're working with. Also I see no need to create certain standards which break compatibility with existing programs.

As far as I can see, our main focuses are two things:
First we want to provide abilities for drawing in the terminal (and making use of it), efficiently without the hackish xterm / w3m approach.
Second we want to enhance the process-to-process communication lying in user space. But what do we need to change? Can't we make use of the given possibilities maybe enhancing or expanding them?

I think the first point isn't as controversial as the second one. Therefore I'll just try to resume what we've concluded. We want to provide terminal drawing, making the solution of some annoyances we currently suffer from using terminal applications:
Terminals aren't capable of drawing graphics which limits every program that wants to make use of graphics. It has to run out of the terminal, at least is has to creating its own window. mplayer comes to my mind here. I'd love to watch the movie just in the terminal I started it from. Often I end up with the movie's output window and a rather useless terminal I can't close because it'll stop the movie. Ctrl-z and bg % isn't satisfactory either. So we want the movie being drawn directly in the terminal window. Further more we want to possibility to redirect the graphics output of an arbitrary application to another one, processing this image. But this belongs to the second point.

We have to find a solution how this can be implemented. w3m and xterm shows that it is possible, though I like to see a non-hackish solution not just laying invisible windows over the terminal. (I hope this is correct, I haven't read the wiki page. That's just what I understood from the discussion here.)

The more interesting thing to discuss is how to implement the enhanced process to process communication. Either in code-base (concept) as well as in user-base (how the user can make use of the code-base).

As stated earlier I see no need to create something drastically new like creating a working environment inside the window manager nor even ditching X.

By now I am imagining a server-client terminal architecture. First of all, the terminal daemon is aware of every running terminal as the terminal client has to connect to the daemon upon its start. As the daemon is aware of the terminal clients and the running applications, we just could detach the application from it's terminal and leave it to the server like screen does. (It's likely though not the same.) We can then launch another terminal, maybe on a different workspace or even a different machine, connecting to the server and reattaching the application to our new terminal or maybe to more terminals simultaneously.

Further more using a daemon makes quite extensive piping possible. I just use this way of communication as we're familiar with it and its quite a good solution making process-to-process communication possible. I don't think it's the best one. But that'll require further thinking and discussion.

As the server is aware of every terminal, the terminals could be named. I'll use numbers here. Imagine we're working in terminal one. Terminal two and three are connected to the server and we'd like to retrieve a web-page, display it and make a list of links on the page as well. We could issue the following command from terminal one:

get-web-page [url]> $2:display-web-page > $3:extract-urls

Hopefully this pseudo syntax explains what I want to demonstrate. So we take the standard output of the get-web-page command which gets the plain text content of [url]. (curl could handle this for instance.) And then we pipe its standard output to the display-web-page command that takes plain text and displays the web page making use of the graphical drawing ability the terminal provides. This is done in the second terminal. Well, in the third terminal extract-urls is launched which takes the standard input as well and displays the urls it finds there.

Isn't this solution, though it's far away from being perfect and needs definitely do be discussed further, capable of realizing everything we want without hacking massively on existing sources? I think we just should provide a new type of terminal letting other programs integrate as they like.

I don't think the vim-like approach of differencing between modes of text insertion is useful for terminals as we just work on a few lines and not on whole texts. Texts should still be placed in scripts.

Last edited by harlekin (2008-01-30 14:00:58)

peets · 2008-01-30 14:53:49

DirectFB provides its own hardware support!? That looks like a lot of tedious work. I don't know what I'm talking about, but don't the hardware vendors provide drivers with which openGL can interact? I haven't found anything interesting when typing "opengl window manager" into google; mostly compiz and directFB stuff. Still, I'll have to look more into it. Will I find the time?!

Harlekin, I don't think it's useful to draw graphics in a terminal window. Suppose I launch mplayer by calling

mplayer myvid.avi

An mplayer window appears, but it's still attached to the terminal that started it. If I close the terminal window, mplayer dies along with it; I can ctrl-c out of mplayer through that terminal, etc. In finferflu's mockup, it looks like one terminal/command prompt is controlling all the applications, and that the output is intelligently redirected to [pseudo-]files which can be accessed at will (the debug tag in the mockup). I think the hackish graphics-in-terminal solution is not even necessary: you are closer to your goal than you think! )

peets · 2008-01-30 23:36:47

harlekin wrote:

get-web-page [url]> $2:display-web-page > $3:extract-urls

Cool. This could also be done without having the empty terminals pre-loaded. If we have a system that's smart enough, it can load up applications itself (and their "terminals", but I don't like that term. X11 uses "clients", I find that makes more sense).

O.K. I'm giving a shot at understanding Unix, correct me if I'm wrong. Every process must be a child of another process. All user-space processes are descendants of the 'init' process. When a process' parent dies, it dies too (? not sure about this, but it would explain the mplayer-tied-to-the-terminal-which-summoned-it) So if we have a re-parenting terminal, we can detach applications from it. I think this is best done in the way harlekin explains, by having all input prompts communicate with a central daemon/server, which itself will summon the child applications/programs/scripts/processes.

I've never tried urxvtd and urxvtc. Maybe something somewhat like this can be achieved with these? I can't wait to try.

finferflu · 2008-01-31 11:01:31

Gosh, I left this thread for one day, and I already have to catch up a lot of stuff
This is great!

@ varl
The best way I can think of what you call "distro", is a distro like LaTeX distros. A set of packages, but those packages are able to run on any Linux distro, at least.

@ harlekein
I feel the need to throw away all that has been done, because it's been heading in the wrong direction all the time. We need to go the opposite way, and I can't see a better choice than breaking with the past. Otherwise it would be half good and half bad, and what I detest the most, it would be messy. We need some sort of order. We don't need random applications doing random operations. We don't need our platform to adapt to the applications, but applications to adapt to our platform. Isn't more that rational? For once in the history of Open Source let's create a standard that gets respected. What I propose is a very strict standard that breaks compatibility with whatever is not compliant. So we will not end up with half-working applications.
So, what you propose is nice, but I am worried about windows. No way. I don't want to see windows any longer. The only way to abolish them is breaking from them.

@ peets
*Revolution* was the word I wanted to hear!
Do you really think we would need to go as far as creating a new X? I think we need some compatibility with the other apps, but in terms of running our own platform on top of what already exists (and not running the current X apps on our platform!). So wouldn't our platform be able to "transcend" X11? I mean, run on X as a graphical application, but using its own features for process-communication?
However, if X is designed for the current environment, like drawing windows and such, it would be cool to create a X for our own purposes in the future. But as a start, couldn't we try to live with X11?
As for the mock-up, for what it's worth, I was thinking that the prompt at the bottom could communicate with every running process either via special prefixes, like the name of the app followed by the command, or when the application is selected, using a shortcut key to access the app's console.

I really hope we will get somewhere, those ideas are really cool, and I think they are even possible to implement.

finferflu · 2008-01-31 11:04:14

Gosh, I left this thread for one day, and I already have to catch up a lot of stuff
This is great!

@ varl
The best way I can think of what you call "distro", is a distro like LaTeX distros. A set of packages, but those packages are able to run on any Linux distro, at least.

@ harlekein
I feel the need to throw away all that has been done, because it's been heading in the wrong direction all the time. We need to go the opposite way, and I can't see a better choice than breaking with the past. Otherwise it would be half good and half bad, and what I detest the most, it would be messy. We need some sort of order. We don't need random applications doing random operations. We don't need our platform to adapt to the applications, but applications to adapt to our platform. Isn't more that rational? For once in the history of Open Source let's create a standard that gets respected. What I propose is a very strict standard that breaks compatibility with whatever is not compliant. So we will not end up with half-working applications.
So, what you propose is nice, but I am worried about windows. No way. I don't want to see windows any longer. The only way to abolish them is breaking from them.
As peets says, the idea is not that of a graphics-capable terminal, but that of an all-in-one console, with its own built-ins, able to manage its own applications and their I/O.

@ peets
*Revolution* was the word I wanted to hear!
Do you really think we would need to go as far as creating a new X? I think we need some compatibility with the other apps, but in terms of running our own platform on top of what already exists (and not running the current X apps on our platform!). So wouldn't our platform be able to "transcend" X11? I mean, run on X as a graphical application, but using its own features for process-communication?
However, if X is designed for the current environment, like drawing windows and such, it would be cool to create a X for our own purposes in the future. But as a start, couldn't we try to live with X11?
As for the mock-up, for what it's worth, I was thinking that the prompt at the bottom could communicate with every running process either via special prefixes, like the name of the app followed by the command, or when the application is selected, using a shortcut key to access the app's console.

I really hope we will get somewhere, those ideas are really cool, and I think they are even possible to implement.

harlekin · 2008-01-31 11:05:23

@peets: The concept is somehow similar like urxvtd / urxvtc. Though I think urxvt's server-client base is just about gaining speed and saving resources. Not about enhancing piping methods.

As far as I know you're right with the view about processes. A process launched by a process becomes it's child and children die with their parents. Though you could double fork a process to make it init's child (as far as I know). At least, you can work-around the parent child dying relationship. ^-^

But I think it'll be okay, if the terminal server is the parent of every terminal client. You just have to make sure the terminal server is stable.

@finferflu: I still can't see advantages of throwing away stuff. I still think windows aren't bad. Could you provide a example which breaks the current [whatever] concept that can't be make possible with just enhancing current features?

Solid standards are good, but standards can also restrict applications from developing further. I like the approach "create standards but don't break compatibility, so let's the user decide which applications he/she is using" over "create standards and restrict the user to use applications".

Last edited by harlekin (2008-01-31 11:13:16)

finferflu · 2008-01-31 11:49:04

You see, I'm not saying that we can't make it possible without breaking the GUI philosopy. I just want to break it. Why? Because the current GUIs just break usability. You can still create apps with the approach we are discussing similar to the current ones aesthetically, but as a matter of fact, the GUI approach reflects different aims from our own. We discussed, apart from piping I/O, about the WIMP approach to computing. Pointing and clicking not only makes the users dumb, but slows down productivity.
Of course, windows can be a good paradigma for the starter to feel at ease with a new environment, but what looks like to me is just a messy desk with all sorts of papers piled up on top of each other, and drawers full of items. It's just a total mess, which does little to automate what should be automatic. That's why I think that for our approach windows have got to go. If we are proposing a more flexible approach to computing, then windows are too "solid". What seems to me is that in today's world application = window. If users don't see a window when they invoke the application they shout: "Where the hell is the program I have just launched?" More or less.
So we need to conceptualise applications I think. As I said, some apps would still need their own screen space all the time, but if we use the Unix-like approach for our apps, then we would have a set of small tools that do one job, and it's the user who then combines them to accomplish the tasks. I'm not so sure this is very clear yet. So, do feel free to ask more, and more specific questions

As for breaking compatibilty, really, we need to. Using the approach that the user has to decide, we end up with chaos. Before user's choice I believe comes functionality. And if the user's freedom of choice breaks functionality, such freedom itself becomes useless. Let's make a difference. Let's create something that bloody works. The user will like it.
Also, we are trying to create good and flexible standards. They should be enough for creating useful applications that work well. One shouldn't feel restricted, the restriction is just for preventing "pollution". In real life I love diversity and etherogenity, but in computing I strongly believe we need omologation.

peets · 2008-01-31 13:57:56

Instead of talking about what is bad and what we should get rid of, let me describe what I'd like my working environment to be like.

In an immediate future, I'd like to use software that accepts input from many sources (maybe through a server-client separation, like mpd.) I'd like all my software to be able to run without being attached to a window. I'd like my windows to have default positions and sizes that I defined; I always set it up the same way and it's annoying to have to do this manually every time. I'd like to, at the press of a button, be able to get all the windows to "snap back" to their default sizes and positions. I'd like a smart way to change focus from one window to the other (better than alt-tab or dragging the mouse. Pekwm's Mod4+arrow is not so bad). I think all this can be achieved by carefully choosing the applications I use and by writing/finding a good window manager.

A few years from now (5, 10?) I'd like an environment similar to the one described above, but controlled through speech + mouse/pointing device rather than through keyboard alone. WIMP is useful if everything you can normally do with keyboard can now be done with speech.

I'm not asking for much really. I'd just like developers to give more power to the user, instead of wanting them to conform to their own standard or paradigm. I think this can be done by cleanly separating software components, rather than by putting together complex toolkits that try to do it all.

peets · 2008-02-01 14:16:46

Double posting again! I did say I liked this thread

O.K. I'm slowly putting together pieces to make a user-friendly interface (the user is me, and I like writing commands!).
I'm changing from a paradigm that says "I want to do this. I will go to this command's application window, and write the command there" to one that says "I want to do this. Oh, I'm already done writing it in my general purpose command prompt."

I'm using mpd + mpc for music. I have some multimedia keys set up for quick interfacing, but sometimes I also use mpc explicitly like

sleep 7h; mpc play

I'm using btg for bittorrents. I got tired of downloading a torrent, going to the deluge window and clicking 'add', etc. This one allows me to automate things a bit. The clients that come in the standard distro kind of suck, but btg works like mpd; I might crack open the code of existing clients to try and better them, or write a custom client with only the functionality I need.

I wrote a little CLI wrapper for firefox. I must say, I love perl. It took me 2 minutes to write this, and most of this time was spent trying to figure out how to get firefox's bookmarks copied into the script:

#!/usr/bin/perl
use strict;

my $address = shift @ARGV;
my $arg = join("%20", @ARGV);

my %kw = (
        "albn", "http://bbs.archlinux.org/search.php?action=show_new",
        "albs", "http://bbs.archlinux.org/search.php?action=search&keywords=$arg&author=&forum=-1&search_in=all&sort_by=0&sort_dir=DESC&show_as=topics",
        "alw", "http://wiki.archlinux.org/index.php/Special:Search?search=$arg",
        "g", "http://www.google.ca/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=Fa1&q=$arg&meta=",
        "wpe", "http://en.wikipedia.org/wiki/Special:Search?search=$arg",
        "wne", "http://en.wiktionary.org/wiki/Special:Search?search=$arg",
        );

$kw{$address} and $address = "'$kw{$address}'";

exec "firefox-nightly $address &> /dev/null &";

[OT=perlvspython]I don't understand the craze about python. I've just learned it, but I don't know where it does better/easier/faster than perl.[/OT]
[OT=ottags]Just preparing this post so it works well when the OT tags are implemented ;o)[/OT]
Edit: o.k. it actually took me 10 min. to write the perl wrapper: I found a bug after I posted it here!
Edit2: make that 10.5 min. I added the ability to manage spaces in keyword arguments.

Last edited by peets (2008-02-01 14:41:09)

barebones · 2008-02-01 15:45:09

Let me play devil's advocate here for a minute, and give an argument for windows.

The big advantage I see of the whole point and click thing is that menus allow the user to see all of the options and how to use them (mostly) instantaneously. While that might not be a big deal for most of the things I use every single day (pacman, mpd, cd, ls, ect), it is a huge advantage in alot of the programs I have to use for school. For example, could you imagine interacting with an autocad program via the command line? I use Unigraphics NX extensively (wiki) for school work and trying to use the command line for 90% of the work I do there would be a nightmare. Also, things like word processing come to mind. I try to use LaTex for my scholastic writing wherever I can, but when I'm writing a short report for a laboratory experiment, it is not worth my time to try and typeset graphs and tables using LaTex (unfortunately, ms office is the suite of choice here). I'm sure I could do all my typesetting in LaTex, but I really don't have the time to.

So, to put it in short, windows allow the user to quickly use programs that have massive amounts of features or nuances with little time spent on the learning curve. Reading man pages will tell you everything you need to know, but it can be a huge time suck for things you don't plan on using very often.

Last edited by barebones (2008-02-01 15:46:18)

peets · 2008-02-01 18:02:41

barebones wrote:

So, to put it in short, windows allow the user to quickly use programs that have massive amounts of features or nuances with little time spent on the learning curve. Reading man pages will tell you everything you need to know, but it can be a huge time suck for things you don't plan on using very often.

Yes. Plus, like you said, there are many cases where a mouse is necessary, like CAD and graphics.

However, there are many programs that would benefit from being remote controlled or text-driven, yet their programmers limit them to a WIMP interface. The best would be to have many UIs: WIMP, command-lines, or other user-defined events.

This would put a lot of burden on programmers if they had to write all these interfaces themselves. We need to separate program-logic from user interface (separate as in two different processes with a well-defined interface between them) to enable programmers to write what they really want, and leave the other details to others who will be more passionate about them.

On another train of thought: I've had to use Windows Remote Desktop for the first time this week. I have a greater appreciation of the X server now. But more flexibility would be allowed if the X server was split into a Y server managing window/graphics drawing (output) and a Z server managing keyboard and mouse (input). And font rendering should not be managed by X at all (don't they say that they only care about policy, not form?).

I think that developing new platforms or writing new standards for better interoperability is ironic and doomed to failure. Reducing the available "interface area" or the "number of hooks" of applications because we take for granted that others will be based on a similar platform or be used in the same paradigm or follow the same standard leads to less interoperability with applications designed on another platform or following another paradigm. What we should be doing is simplifying programs until they do their mission well, and provide a sane and open interface (I'm not necessarily talking about a user interface here, more of a program-to-program interface). Users could then put together these tools easily to create applications that have the interface they chose themselves, because they are the ones who know what kind of needs and preferences they have. Applications could be called "program distributions", because the app dev's only role will have been to assemble smaller expert programs.

tesjo · 2008-02-01 18:10:06

This is a very interesting thread.

But no need to reinvent the wheel. A new X? Why not a new kernel why your at it?

I like the graphical idea though but why not build on emacs. I can already view png, jpg. pdf viewer in the way of doc-view is available though I haven't tried it. Web browsers and email have been done. All these things could be improved however, and maybe Xapps could be ported to display inside emacs.

I dont know as much vi but maybe it could be done there.

finferflu · 2008-02-01 18:25:18

peets,
that sounds good. I think we're saying the same thing, but in opposite directions. I am mainly focusing on a common platform, and you are focusing on the actual applications. It looks like the chicken and egg dilemma. So, if what you say comes true, namely, we get a good number of simplified application which reflect our ideal client-server approach, then one would be able to implement them in whichever interface, easily and seamlessly. This sounds all good. That way I could even create my own platform to run them, and pursue my dream of getting rid of windows

But there are a couple of issues that come to my mind, which reflect my previous proposals of a common base:
+ would a user be able to use the same applications in the same way on different interfaces?
+ Which leads to the question: how far is the client detached from the server, how much job does the server do, and how much the client?

From what you propose I guess you envision a very powerful server, where the "power" of the client is defined by the one who develops it.

Anyway, I think we have a good direction now. We could focus on the applications as servers, and then we could talk about usability, when talking about clients. This is a great improvement to this discussion I think. As you say, the server should be the highest priority now, since that is where most of the problems reside.

barebones · 2008-02-01 18:56:13

peets wrote:

This would put a lot of burden on programmers if they had to write all these interfaces themselves. We need to separate program-logic from user interface (separate as in two different processes with a well-defined interface between them) to enable programmers to write what they really want, and leave the other details to others who will be more passionate about them.

This is a very important distinction, I believe, between what ideal behind the "graphical terminal" is and what has been discussed so far. If a standard were instead based on this sort of interaction between a back-end and the user interface, allot of progress would be made in the right direction. Here's the idea I just had:

A standard defines what a keyword will signify so that one main program would be able to control multiple back ends. For example, the standard could define the keyword "play" as starting from what ever is queued up in the program. Individual programs could then take this into account and ensure that when they received this command they would start doing whatever they do at the beginning of their queue. Then, one main program could control everything adhering to these standards. Some controlling program (here creatively named "control") could then do all of the following:

control mpd play --- Have mpd start playing
control rtorrent play --- Have rtorrent resume downloading at the same state as when it was last quit
control firefox play --- Have firefox open to it's homepage
control comix play --- Have the comic book reading program comix start at the last bookmarked page
control epdfview play --- Have epdfview open to that last page of last pdf displayed

And so on. This would also make command line control simple and gui development trivial. One gui-program could likewise control multiple programs, laying them all out according to some pre-defined style sheet. For example, some program called gtk-gui could be written so that it doesn't know what to put on the screen, but it knows how and where to put things that it's given. You could give it a style sheet like this:

<row 1 height=10%>
filemenu
<row 2 height = 85%>
<column 1 width=20%>
history
<column 2 width=80%>
display
<row 3 height= 5%>
status

Then it would take what ever is given to it by the output of the filemenu keyword and make a menubar on the top of the page, whatever is given by the history keyword and put it on the left 20% of the middle of the page, and put the main output of the program from the display keyword next to that. Finally, a small status bar on the bottom form the status display would be drawn on the very bottom 5% of the window. This same style sheet would be applicable to many different gui's and require 0 gui development time on the part of the program's creator. Of course, this also could be extrapolated to at graphical terminal approach (gui-gterm).

peets · 2008-02-01 20:23:46

tesjo wrote:

But no need to reinvent the wheel. A new X? Why not a new kernel why your at it?

peets wrote:

While I'm at it: as soon as this is fixed to my liking, I'm moving from Linux to an exo-kernel ;o)

lol Re-inventing X is unfeasable right now, especially by me. However, once I start writing code and gaining experience in good software design, and find some other good people to work with (wink), I might consider this, unless the x.org team has woken up and done something about it already ).

As for emacs, I don't know. I've never tried it. I've been using vim for 1.5 years, and my love for it goes growing. Wouldn't it be restrictive though to run all applications inside emacs? This is a question, I have no idea how emacs works.

barebones wrote:

some program called gtk-gui could be written so that it doesn't know what to put on the screen, but it knows how and where to put things that it's given.

Oh yes. I think this exemplifies my thoughts very well.

But I'm not ready for specifics yet; here are some other general considerations:

1. Some programs provide a one-time service (e.g. ls, grep, cp, wget, etc.)
2. Some programs provide a continuous service mainly focused on presenting data to the user (e.g. music player, web browser, video player, image viewer, pdf viewer, less, etc.)
3. Some programs provide a continuous service mainly focused on collecting input from the user (e.g. text editor, audio/video recorder)
4. Some programs involve a tricky mix of input and presentation (e.g. Image manipulation programs, non-linear video editors, word processors, CAD and 3d suites, music/audio editors, etc.)

As I set out to write this I was going to say, "I'm not sure applications in this last group would benefit from hyper-separation of components," but upon reading over my little list, I can imagine very well how they would be pieced together from independent components. Interestingly enough, these kinds of applications often have their own unique UI toolkit (Gtk was initially written for GIMP; consider blender and cinelerra and audacity). I think most of the job for these kinds of integrated solutions relies in building a good user-interface for all the expert backend features they include. And these backend features should exist as independent programs (usually belonging to group no.1).

Anyway, what I was going to say is that programs from group no.2 would benefit from presenting many input channels (possibly by running as a server/daemon), and would also be very appreciated by myself if they provided mechanisms for selecting a subset of the output data and exporting it to a file or another process etc. (see posts on first and second page with all the pipes).

Programs from group no.3 would usually accept input from only one source, or from similar sources (e.g. speech and keyboard are similar because they can carry the same message, and can be translated one into the other; they are both means of collecting text. However, video and audio are not similar: they do not collect the same information; they each need their own specialized input program)

The raw processing power of a system is limited by programs of class #1, since the programs from other classes are just a whole bunch of #1 programs tied together. I guess.

vogt · 2008-02-01 21:08:49

A couple suggestions for programs that may make CLI stuff more powerful:
If you are still hating screen: a lighter, simpler, and possibly less buggy alternative would be dtach; or there is the wrapper screenie.

Similarly, you can also have decent terminal multiplexing à la dwm with dvtm.

You could certainly unify some of the inconsistent interfaces with shell aliases and function, which would make your project kind of like the fish shell (which is based on zsh) + the good gui elements

Colours seem to bring more functionality to ls et al. than icons, but nobody is stopping you from trying or extending those existing projects named in this thread.

The alternative to bringing all those options into the shell, is to find or make external programs that do what you want; feh for image viewing or thumbnailing being the best example I can think of right now.

But seriously, a good x11 wm (xmonad?) managing firefox+vimperator, plus the right cli apps (optionally multiplexed and/or detached by the programs mentioned above) seems to be able to offer the functionality without changing too much stuff.

Last edited by vogt (2008-02-01 21:10:17)

peets · 2008-02-01 21:55:11

O.K. I'm finally going to give xmonad a look. vogt, like you say, I think to be reasonable it's mostly a matter of picking the right programs.

finferflu · 2008-02-02 14:32:31

@ vogt
Thanks for the tips! I'm quite impressed with the fish shell, and I'm very interested in dvtm.

However I think running external applications outside of the CLI is uncomfortable. I would prefer a more emebedded system, where the CLI is always visible (see my mockup).

As for now I can only think of *what* I want, before I start thinking about *how* I want it (i.e. how to implement it). I'm too ignorant right now, and I need some more education. I'm finally graduating this year (I hope), and I am planning to take one year off, so I will have time to deepen my knowledge, and come up with some prototypes.

vogt · 2008-02-07 04:01:07

This project is sort of like what we are aiming for?

PS. it is in community

it lacks colour, readline-ish keybindings, and the ability to resize.

Other than that, it seems like a decent way to learn those rarely used commands, but then again, what's so bad about:

info *
man *
* --help
* --usage
* -h

Last edited by vogt (2008-02-07 04:14:15)

peets · 2008-02-07 05:23:12

LOL! I don't think finferflu will like this...

It's really not my style of gadget. I guess it suits the author's needs, and it's really cool that all the backends allowed themselves to be GUI'ed like that, but I still prefer typing out my commands.

finferflu · 2008-02-07 09:47:09

Ahah! Peets got it

That's exactly what I don't want. I hate the WIMP interface, that's why I wanted a graphics terminal to start with

Thanks for the suggestion anyway

And since I'm here, let me present some small ideas I got in these days.
I have recently discovered I can even blog on Wordpress via Vim (and Emacs, of course). And these days I was thinking about a more flexible way of interacting with the web: namely, why do I need to "go" to the webpages when I need them? Why, for example, do I need to visit this forum in order to post this comment? Based on the RSS technology one could just get the needed information, and also send information. I was thinking of a web browser not in the classical sense of a standalone application, but as a set of tools that allow you to send and receive information where and when you like it. Let's say I find an interesting piece of text and I want to blog about it, I could just do:

blog send file.txt

Or even better:

blog send this is the actual text I am blogging

Where the CLI "understands" that everything that comes after "send" is the actual text and wraps and indents it.

When I subscribe to topics on boards like this, I could keep track of the threads via the web browser tools instead than by mail, like:

threads get

and get a list of the new posts of the threads I'm subscribed to, and it could even be more specific:

threads get archlinux

And what's so cool about it? The ability to manipulate input and output, and very quickly too, but well, we all know that at this point

But of course here a graphics terminal is much needed (there we go again!). It would be ultra cool if all that information could be displayed on a good UI, perhaps XHTML formatted. Also it would be cool to incorporate text editors' features in the CLI, so you could write lines of code without having to open a program to do that. Who knows, one could hack Vim...

Enough dreaming for today

wuischke · 2008-02-07 11:43:42

"The CLI understands" sounds like a nice AI. What you imagine is actually not that complicated, but that depends on some server side things.

HTTP is actually a very easy protocol, I bet you could implement your blog program with a simple bash script.

Just to give you an example of the communication via HTTP: telnet google.com on port 80.
Then type "GET /search?q=google HTTP/1.0" (better Copy&Paste unless you type fast) followed by two times Enter - you'll get the results page for the keyword "google" as answer (take a look at the HTTP answer, too).
Regarding your blog program, you just need to send a POST request to the server (granted, with authentification the whole thing gets a bit more complicated) and you're done.

The second idea depends on the server side, if there's no way to get these information, well - you can't process them. If there was a RSS feed or a way to search for new posts for subscribed topics, then it would be as difficult as parsing the RSS feed/HTML page for the necessary information - this can be done with a bash-script, too.

finferflu · 2008-02-07 12:01:06

Ah, I didn't know the telnet thing, that's very cool, and surely will come handy in the future, thanks a lot

I was thinking of maybe creating a client-side RSS feed that updates every time I run the "threads" command. Granted, it would take a bit longer to run, but surely it would be faster than going on the webpages, clicking here and there, and so on.

As for a CLI that understands, I think the fish shell gets pretty close to what I mean: it already provides syntax highlighting, autocompletion and text indentation at the prompt. Very cool.

peets · 2008-02-07 22:55:40

cowsay -f beavis.zen I am a talking cow. Wait, no, I am Beavis. Rather, I am a collection of ASCII characters. We are pixels.

cowsay understands.
Not sure about the commas though. Quotes always help. I guess Bash doesn't understand.

Last edited by peets (2008-02-07 22:56:53)

dunc · 2008-02-08 00:26:48

Some of the ideas in this article reminded me of this thread.

Arch Linux

#51 2008-01-30 13:49:51

Re: Ever thought of a graphics terminal?

#52 2008-01-30 14:53:49

Re: Ever thought of a graphics terminal?

#53 2008-01-30 23:36:47

Re: Ever thought of a graphics terminal?

#54 2008-01-31 11:01:31

Re: Ever thought of a graphics terminal?

#55 2008-01-31 11:04:14

Re: Ever thought of a graphics terminal?

#56 2008-01-31 11:05:23

Re: Ever thought of a graphics terminal?

#57 2008-01-31 11:49:04

Re: Ever thought of a graphics terminal?

#58 2008-01-31 13:57:56

Re: Ever thought of a graphics terminal?

#59 2008-02-01 14:16:46

Re: Ever thought of a graphics terminal?

#60 2008-02-01 15:45:09

Re: Ever thought of a graphics terminal?

#61 2008-02-01 18:02:41

Re: Ever thought of a graphics terminal?

#62 2008-02-01 18:10:06

Re: Ever thought of a graphics terminal?

#63 2008-02-01 18:25:18

Re: Ever thought of a graphics terminal?

#64 2008-02-01 18:56:13

Re: Ever thought of a graphics terminal?

#65 2008-02-01 20:23:46

Re: Ever thought of a graphics terminal?

#66 2008-02-01 21:08:49

Re: Ever thought of a graphics terminal?

#67 2008-02-01 21:55:11

Re: Ever thought of a graphics terminal?

#68 2008-02-02 14:32:31

Re: Ever thought of a graphics terminal?

#69 2008-02-07 04:01:07

Re: Ever thought of a graphics terminal?

#70 2008-02-07 05:23:12

Re: Ever thought of a graphics terminal?

#71 2008-02-07 09:47:09

Re: Ever thought of a graphics terminal?

#72 2008-02-07 11:43:42

Re: Ever thought of a graphics terminal?

#73 2008-02-07 12:01:06

Re: Ever thought of a graphics terminal?

#74 2008-02-07 22:55:40

Re: Ever thought of a graphics terminal?

#75 2008-02-08 00:26:48

Re: Ever thought of a graphics terminal?

Board footer