Ever thought of a graphics terminal?

finferflu · 2008-01-25 13:38:59

@ smoon
I wonder which packages I'm missing...

@ peets
What you say is very interesting, and it's even helpful for my brainstorming. As you say, I think the keyboard so far is the most usable device for operating with a computer. It simply offers more flexibility. I would confine the use of a mouse to graphics applications, together with pen tablets, touch screen, multitouch, and such.

@ bionnaki
I have come up with a quick and dirty mock-up. Here we go:

As you can see, there is the ability to tile the apps into frames (perhaps one could have a number associated with them and keep it visible all the time).
On the bottom there is a visible prompt all the time, and it could be expanded with a keystroke, just in case it is needed.
On the very bottom there is a tag bar, where you can organise your "workspaces". I think the idea of task-oriented workspaces gives you a rational way of reaching many different apps all open at the same time. Next to the calendar and clock, there is a debug tag, it could also be called "messages" tag, where all the eventual errors/warning/messages that the apps output are gathered (of course in an orderly way, every message would have its own frame according to the application it belongs to).
Obviously one of the most challenging task would be to organise the shortcuts in a way they don't get overcomplicated and utterly unusable.

This is just the appearence of the whole thing, but what would be more interesting is to explore what's under the hood. I think it would be cool to have a semantic environment, where you type a topic, and all the related apps are shown. All the "terminal-enabled" apps would need to conform to a kind of standard, in order to respond well to the input they receive (having a .desktop-like file associated with them, using the same set of keystrokes, on which workspace(s) it will be shown, and so on).
Ah, and something very important is that the apps *don't* generate pop up windows, I think that's one of the most annoying and distracting things ever created

Last edited by finferflu (2008-01-25 13:43:06)

peets · 2008-01-25 14:25:04

finferflu wrote:

I think it would be cool to have a semantic environment, where you type a topic, and all the related apps are shown.

That's something I've been pondering about lately. I guess there's two ways it can be done: "static" and "dynamic".
The first way is to specify manually which apps go with which task (and while we're at it how they are laid out on the screen ,etc.). I'd like this, it would make sense, and be pretty simple to implement. I think my WM (pekWM) has what it takes to achieve this effect; I'll try it.
The second, "dynamic" way is to have the computer guess what I want to do and find the apps that are relevant. It could search the web and bring up web pages I would never have thought about visiting. It could encourage me to stay focus and stop reading so many webcomics. It could choose my wallpaper based on the weather and time of day, or play my music based on my mood and what have you. This would require that it maintain a complex and dynamic collection of symbols related to me and my work; achieving that would mean taking many significant steps into the realm of AI. I don't even know if stuff like this is possible yet.

finferflu wrote:

Ah, and something very important is that the apps *don't* generate pop up windows, I think that's one of the most annoying and distracting things ever created

That's mainly what keeps me from using a true tiling WM.

What do you think of a "modal" interface? e.g. vim. I think all apps use disguised modal interfaces: the mode switches when the user holds a certain key (e.g. alt+tab, shift+arrow, etc.) or is in a certain menu or is "communicating" with an annoying popup "dialog". I think we would benefit from making these modes more explicit and easier to enter in and out of. Vim does this well, with the <Esc> and i,I,a,A,o,O,etc. keys.

wuischke · 2008-01-25 14:26:18

Mh...we are talking about different things, I guess. Seeing your mockup, I get the impression of an advanced window manager or a second emacs.

Coincidentially, the term "LaTex" sprung into my mind when I was thinking about expanding the unix priniciple as well, peets. It would be great, if you just could pipe some images to another application, which would then show them. Or in the case of my application, I would use the conjugation of the verbs, add some little contextual grouping information (e.g. all forms for present belong together and should have the caption "presente") and let another app output these information to the user.

If you ignore any integration in the terminal, it's already possible, you only have to write the right apps to do what you want. Take e.g. the following bogus code:

find [all images from today] | thumbnails

The app thumbnails would output me all images from today in a nice orderly fashion, fitting perfectly on my screen or allowing me to less-like scroll through the image thumbnails.
Or imagine something like this:

ls | group *.png Images | group *.ogg Music | group *.cpp Code | group * Other | output

This would create groups of all these filetypes and give you a nice overview by filetype with every group in a box. I think you get what I mean.

Mh...I have to wait what the requirements for my C++ project next semestre are, but this is something I would love to work on.

finferflu · 2008-01-25 15:11:50

@ peets

I don't know why, but I have the impression that when people talk about CLI it's like they're talking about the last resort, like something that is less poweful or less usable than a GUI. When I first tried out Linux what really hooked me was the terminal, and the ability to communicate effectively with the machine. A verbose way is much more intelligible and straight forward than pointing and clicking, it's like talking vs miming. I'm gonna also paste a quote I got from the blog of the much unloved Ion creator:

"[i]t's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible."
-- Gentner and Nielsen: The Anti-Mac Interface

This is to say that what you propose, not only is very powerful, but it can be implemented at its best only in a terminal-like environment. That's why I would like to see an enhanced terminal: we are disposing of the real power and focusing our energies in something that isn't really worth.

Let me add another quote from the same people:

"[i]nstead of an executive who gives high-level instructions, the user is reduced to an assembly line worker who must carry out the same task over and over."

As for the Vim modal interface, I was thinking about it. That's what makes me love Vim, I find it very clever. I am also trying out Emacs, since I have used Vim only for the last 2 years, just to see what's the difference. I think it's nice to have the ability to type text as soon as you press a key, but then the keybinding become ridiculously extendend. Perhaps one could have some quick keybindings for the "insert" mode, and some extendend keybindings for the "visual" mode. Well, that's what Vim does already So, I think that's the best way.

@ wuischke

First of all, I'm very pleased you are getting interested in this project (which doesn't exist yet ). Especially when I'm not a programmer (I'm in the Biblical Studies world). I just bought my "Programming in C" book, so it will take a while before I can actually create something useful...

As for the interface, I have already mentioned of a hybrid between a terminal and a GUI, like Emacs
I think it's a concept that is really worth exploring and expanding. And as I said, it would be more or less like a Desktop Environment, which I have re-labeled "Working Environment" (good bye, desktop).
What you mention is exactly what I meant when I talked about the "all-in-one" principle that makes Unix so poweful. I think it's important that all the apps conform to a shared base, like all the tools work within a shell: all of them end when you press C-c, all of them stop when you press C-z, the all respond to keyboard input, and such. So, why not enhancing these CLI "tools" and make them graphical, and also make the GUI behave in a CLI fashion. And if it's all in one, you no longer talk about those alien entities that are the windows, where every window behaves its own way, you have a coherent set of tools that don't get in the way, and behave the way you expect, and most of all, can communicate between each other in an efficient way.

Last edited by finferflu (2008-01-25 15:18:33)

wuischke · 2008-01-25 15:36:18

Mh...actually, my current way of using a computer is not so much different.

I use OpenBox and no panel. I start applications either via hotkey (I have 4: start terminal, start gmrun, start opera, control xmms2) or via gmrun or a terminal (depends on whether I need the output or not).
Almost all applications are full screen already, except for terminals of which I often have multiple opened.

Anyway, keep up posting ideas, maybe more people are interested in this and we can do some concept programming.

peets · 2008-01-26 03:15:03

finferflu, I think that first quote you posted has humorous value, but cannot be taken seriously. Placing commands entered into a terminal on the same level as human language is a gross error. Bash and CLIs in general are much closer to grunts than language. Except instead of pointing, one has to write. For me, writing is more efficient and enjoyable and powerful most of the time -- but it's not like I'm talking to my computer, no matter how complicated the pipelines and the loops. Besides, point-and-click can be pretty expressive too with things like drag-and-drop and contextual menus.

When I double-tap <tab> at an empty bash prompt, I get asked: "Display all 1688 possibilities?" 1688 buttons on my screen would be too much, even if they were placed in menus. The command line is clearly more expressive, and it's always my first approach, but it doesn't come close to rivaling with human language!

What's good about it is that it's easily "scriptable" (c.f. point-and-click!) So I absolutely agree with your second quote. To me, "scriptability" is one of the most important aspects of a user interface; when I find such and such a task are repetitive, I want to put them in a script, and when I find that this program would go very well hand in hand with this other program, I like to be able to make them communicate easily.

I think my other UI philosophy is something I read while learning perl: "easy things should be easy, hard things should be possible" or something like that. I'd like a "Working Environment" where I can easily and naturally switch between windows (alt-tab is confusing and requires too much concentration, using the mouse takes forever). I'd like one that places windows in a smart yet predictable (ideally user-defined) fashion. I'd like one that's "scriptable".

Also, beauty is a rare quality.

I'm really rambling on. I'll try to summarize now.

From what I gather, we're on a quest to make GUI apps more CLI-like, or more UNIX-like. This can mean many things. It would be good to figure out what exactly we're talking about. I've been talking mostly about WMs and UI in general, wuischke is imagining some cool apps that take text-commands as input and output pretty graphics (I like this idea very much), finferflu is designing his ideal "working environment". I have no clear idea where this is going!

To jumble things up even more, here's another thought on UI: I think it's useful to have a "plural interface". Modern GUIs seem to be made for casual users who don't want to read any documentation before jumping right in and "using" software. Sometimes I am such a user: yesterday I downloaded k3b to burn a dvd because I didn't want to figure out how to setup and use a more expert CLI tool. And it was O.K., I burned the dvd, then pacman -Rs k3b until the next dvd (in a few months maybe?) But if I wanted to become a backup-freak and burn dvds regularly, I'd like a scriptable interface. I haven't checked if k3b has this, but it would be cool if it did, it would exemplify my point: we should have easy one time interfaces, but we should also have powerful everyday interfaces. The powerful interfaces should be prioritized and the natural way to use the software. A good example of this is MATLAB. It's a programming language, but it has menus and GUIs for a lot of its functionality. It helps to get started or to do some quick-and-dirty one-time jobs.

dunc · 2008-01-26 13:49:13

finferflu, you'd have liked AmigaOS. While it had a (very advanced, for its time) GUI desktop, hardcore hackers tended not to load it, and work entirely from a CLI just as many do on Linux. But the Amiga hardware didn't have a text mode, so even a bare CLI environment was fully graphical, with the mouse, pointer, and even the window manager fully operational. However, because so many people were using only the CLI, a lot of graphical apps were developed with extensive keyboard shortcuts, and the Amiga's system of "screens" (something like workspaces crossed with virtual terminals) meant that many of them opened fullscreen, with users cycling between them using the keyboard. And many of them were scriptable, using ARexx (which was often used where shell scripts would be under Linux, because of the Amiga's rather basic shell).

It's not exactly what you're talking about, but it's in the same area I think.

Last edited by dunc (2008-01-26 13:52:38)

harlekin · 2008-01-26 16:46:41

I like the concept you are suggesting, finferflu.

Especially I like the imagination of chaining commands like this (as already suggested):

ls *.png | display | thumbnail | tile

Where display displays a given picture, thumbnail creates a thumbnail from it and tile takes for example three thumbnails and displays them in a row.

But how can this be realized?
I think the best way would be if a program could request a drawing context from the terminal it is running in and then use the drawing context to draw. But is this possible? Can you just create a drawing context and pass the handle to another program and share it without starting to hack on the X code? Unfortunately I am not experienced enough to answer this question.

I think that would be pretty neat. You could also add a new standard output to the terminal which just redirects the drawing context.

Another method could be that the program creates a drawing context itself just over the terminal (which is possible) and the terminal tells the program whenever it is resized or moved so that the drawing context could be moved as well. This would be the same as creating invisible windows overlaying the terminal which don't respond to any interactions and are detached from the influence of the window manager.

The latter suggestion is a bit more hacky but could may be implemented without hacking on the X code?

Last edited by harlekin (2008-01-26 17:29:41)

peets · 2008-01-26 18:14:56

ls *.png | display | thumbnail | tile

That's cool, and can be done already, sort of. "feh" is an image-displaying program that has this particular functionality.

I think what you mean would be cool is if I was in any app and could choose some data and pipe it over to another app to be processed. e.g. I'm editing an image in gimp, then I enter a command to pipe the current image to program xyz that applies some filter, and I write the output to some file, or use it to replace the very image I was working on. Unix makes this possible, but it turns out that a lot of applications don't make use of this.

There's the JACK Audio Connection Kit for audio, there's the GNU coreutils for plain text... I don't know of others. It would be nice to have something like this for images, video, and whatever other data format we'll think of (odf, pdf, etc.)

Last edited by peets (2008-01-26 18:15:30)

finferflu · 2008-01-26 22:22:42

@ wuischke

Well, I was thinking more about a "compound" environment. As I said, I like the "all-in-one" approach. I detest having an environment with sparse applications that "ignore" each other. While it might graphically look like a window manager is techinically something else. Especially when there are no windows any longer (finally!).

@ colinwalters

Thanks for the tip, it worked
I suppose (from the number of your posts) you are Hotwire's developer. If so, thanks for your work.
My only critique, and I hope you find it constructive, is that there are buttons for functions, and I think it's annoying having to reach the mouse every time: I admit I haven't explored it enough, but I hope there are keyboard shortcuts.

@ peets

The first quote made me think a lot. I think it has some value, a value that goes beyond a plain sense like "CLI language = human language". I think what they're trying to say is a bit different and deeper. It is about the abstraction ability we lose when using the WIMP interface. It is like the difference between meaning and acting. While using the terminal we mean what we wish to accomplish, while using the GUI, we just do it. And that's related to the second quote obviously. But I think that's what they mean when they differentiate between human language and primordial grunts. To be balanced: sometimes it's just quicker to act, other times it's quicker to speak, and I think it's a good question/dilemma to deal with.

As for the ideas that are popping up, I'm loving this
What I actually am talking about is, yes, a "working environment", but by that I mean a base upon which adapting applications. A base to which applications have to conform, and a base that facilitates the interaction between them. And of course, it has to be CLI oriented. So if one starts designing the base, then it would be a lot easier to create applications that communicate between each other. Base first, application-specific features later. What do you think?

I also think this environment has to be easily approachable (i.e. good usable defaults) but also open to more advanced tweaking. The best application that provides this for me is Alpine. I just wanted to start with reading my mail, before getting acquainted with all the possible configurations (like it happens with Mutt, for example). I would call this approach "learn as you go".

@ dunc

Interestingly, I was an AmigaOS user, I used to have an Amiga 600
But I was too young to know enough about computing, I mainly used it for playing videogames (I was about 7-12). Up to now I didn't know all that was possible.

@ harlekin

You are talking about the technical side already, and for now I can't say anything, since I have no expertise.
All I want to say, though, is that I wouldn't like a solution like w3m. I would like to have a fully capable terminal, which so far as we have discussed, is not even a terminal any longer, it's like an hybrid between a terminal and a GUI application.

The other question that comes to my mind is: do we automate piping or do we use the traditional shell commands? But that is a question that will come much later I think.

peets · 2008-01-27 19:21:20

We can split applications into two categories: those that know all their parameters as soon as they are called (e.g. through command-line arguments) and those that require additional user input throughout their execution.

Obviously we spend most of our online time using this second type of program. These are the programs that need "User Interfaces". We can split the UI into two categories: input and output.

I think what we've been talking about is: take text as input, produce a graphical output.

But here's what I think would be cool: programmers should not have to worry about designing input UIs. All input from any source should be accepted (through some well-written freely available libraries?). A program with a UI should present a list of functions to the user, and the user should be able to say which input triggers what function. There should be sane defaults profiles.

I find it annoying when I have to make choices in between two pieces of software based on their interface: "This one is more powerful, but the other one lets me control it through the network... I need the second one then".

Here's an example of what I'm imagining. Consider the task of writing a URL into a web browser's address-bar. I think the only events the author of the web browser should worry about are something like "received input: <character>" or maybe even "received input: <string>". The character/string could come from any source: keyboard, speech, mouse gesture, touchpad, network event, timer event, some button clicked, a pipe, etc. etc. The output should be processed character by character if it's the programmer's job to manage the output (echoing the characters on screen / speakers / whatever output interface) or string by string if there exists some good standard libraries for dealing with output.

I could, to continue the example, be reading a website when I find an image containing a URL. Then, from within the web browser I could send that image to an OCR program which outputs the URL in text format; that output is redirected to the web browser, and the browser loads the page described by the URL.

I think that would be cool.

I think we already have the base: the Unix-like system that we love using. Maybe some standards need to be written and some libraries, but for the most part it's the applications that need to change. To quote the Django philosophy, we need "loose coupling, tight integration": components that can work independently of each other, but that, once combined (in a myriad possible ways) create a coherent and very enjoyable system.

veek · 2008-01-28 08:03:33

Interesting stuff here, must come back and finish reading

finferflu · 2008-01-28 09:41:58

What you say, peets, makes a lot of sense. What I want to push, however, is the need of a single interface. All apps should be embedded into this "graphical terminal". In this way I think the base is much more powerful. It provides keybindings and functions per se, and most of the UI. So what the apps would need is just the ability to interact with the base. Think of the base of something like a graphical toolkit: it provides windows, buttons, menus, and all you might need. The developers only need to give each element its own use. Of course, our base would be much more than a toolkit, since it would provide standard functions. The developer would only need to get those functions operate within their applications.

As you say, a set of libraries might do that. I wish we could have tight standards, so that we don't end up with chaos, as it happens with GUIs. I think order is something very important for usability. One needs not to be distracted by "how the hell does this work now?"s (nice sentence huh?). If all the apps behave the same way, then using them becomes natural, and one can focus on the content, more than on the technical/mechanical part of operating the apps.

I think that, yes, the applications need to change, and a solid and flexible base is the starting point to achieve this.

Last edited by finferflu (2008-01-28 09:42:32)

harlekin · 2008-01-28 11:48:30

I think I am not convinced of going that far.

What you are suggestion reminds me of a window manager inside the window manager. I mean, you should not force new programs to run in the new idea of a graphical terminal and create not just a duplication of GUI programs but also a lack of programs for the graphical terminal at the start. Handling and arranging windows belongs to the window manager and one should not forget about that X should be used instead of being replaced. Further more what's the point of integrating the ability to split windows into the terminal? I think this should still be problems external programs should face, not the terminal itself. E.g. screen shows how that is possible and with sane libraries and standards it will be possible with a graphical terminal as well.

Again the problems with recent, mostly GUI programs belong to the developers that are heading the wrong way or at least a way I don't want to follow. I won't say the way is wrong in general. I can't stop thinking of Firefox here. But for instance vimperator shows approaches which makes Firefox almost fully usable in a effective way, imho.

Therefore I don't see the point of forcing a certain type of application.
What peets suggested would be very nice indeed. But I can't estimate how complicated the process would be of implementing this.

Or am I just not seeing the advantages?

Last edited by harlekin (2008-01-28 12:18:54)

finferflu · 2008-01-28 14:38:31

The point is that we have to get rid of windows, even the concept of windows. If everything is embedded into a terminal, we talk about applications, not about windows. Applications become part of the terminal, they are more interactive with the base than what windows do into a windows manager. Let me take an extreme example: when you run the command "ls", you get an output. But neither "ls" nor the output occupies a window of its own. There are no windows in a terminal. In the same way one could run multiple apps into a terminal at the same time and produce a single output. Then one can have splits and frames if s/he wanted to run multiple instances at the same time. But that's only a secondary thought. What matters is that all the applications can interact effectively with the base, and therefore with each other. This project is not about creating a new way of managing windows or a new Desktop Environment, it's about how applications should behave, rather than how applications occupy space on the screen.
Does this make sense?

P.S. Conkeror is even better than Vimperator, since it doesn't need Firefox to run any longer

Last edited by finferflu (2008-01-28 14:39:23)

harlekin · 2008-01-28 15:01:00

I see the point and I agree that there's a certain need for graphical applications which don't create a window by themselves but instead just use the window provided by the terminal. I still think of a display and thumbnail function, or something like a preview function of ls for pictures.

But why can't interactive applications run in their own window or why they shouldn't do so? We can difference between interactive and non-interactive applications and I agree that non-interactive applications, such applications that perform a certain task and then quit, need to run in a terminal and need to communicate with the base making piping and combining the commands possible. That'd be great for graphical applications as well, but they have to be non-interactive. Otherwise I don't see any advantages over different windows.

Let me explain that using an example. I use vim and irssi regularly as interactive terminal applications and I usually use them in their own windows (terminals) as it isn't useful to use them together with other commands. For instance it would be highly ineffective if I've got one terminal, run irssi from it and want to edit a text file. I have to detach irssi for a while and can't follow the chat messages, edit the file and then reattach irssi. As I see no point in this, irssi has it's own terminal and vim gets its own terminal either. And I see no reason we shouldn't keep it this way that certain applications have their own windows. Although it would be better if they all run inside a terminal. But there are applications, interactive applications, that don't need to be integrated into command chain of piping and combining because it's useless.

What would be nice though was if you could detach whatever program you want and reattach it in a different terminal. Well, you could use screen for that, but it's a mess, because every terminal would launch another screen session, reattaching other screen sessions, etc. But still I think using some sort of terminal splitting is the wrong approach as window, or name it application, management (arrangement) belongs to the window manager.

peets suggestion still should be taken into consideration, but there should be a possible solution that avoids to cage the applications in a certain terminal, e.g. every application reads from their terminal's stdin but you can pipe through different terminals (or directly to applications as interactive applications will occupy the terminal and non-interactive applications don't need to be run into different terminals).

Well, I somehow get the feeling, we're talking about the same thing but expressing it differently. Correct me if I'm wrong. (-:

PS: Can I use vim-like key bindings with conkeror? I really don't like emacs.

Last edited by harlekin (2008-01-28 15:06:00)

finferflu · 2008-01-28 15:40:09

The way I see it, is that the applications become less and less monolithic, in a way that they lose those boundaries that imprison them inside a "window". Applications would be composed of many different "tools", put together creatively. I bring an example, which doesn't fit very well with the applications I'm talking about, but it's nevertheless a good one: there is a blog engine called nanoblogger, which is entirely managed by sed, grep, cat and such, and still it does its own job. Can you see where I'm heading to?
Of course, the example of Vim vs Irssi is a sharp one, because a chat client needs its own space. But not all applications work that way. And that's why one would also need to provide some frames and tiling capabilities.

Anyway, if everything happens inside this "terminal", then you can even run it within a Window Manager, and go back to the old fashioned GUIs for apps that haven't been ported/created for the terminal yet. It would provide a seamless and unintrusive way to gradually shift from the GUI world to the non-GUI world, or to combine both worlds for those who like it.

Ah! as for Conkeror, it is supposed to use Vim keybindings also, but I don't think it's working. It's just at an early stage, so features will come along with time. I also don't particularly like the Emacs keybindings, but I had to adapt. I prefer speed over bloat (i.e. Conkeror over Firefox+Vimperator).

Last edited by finferflu (2008-01-28 15:47:51)

peets · 2008-01-28 22:55:45

harlekin, I like your protests. finferflu, do you find there is a difference between things like ncurses applications inside screen vs. gtk applications inside an X11 WM?

Maybe I don't understand what you mean by "a common base". To me, a base is a means for managing processes and allowing them to communicate with each other and with the user. Linux does an adequate job of managing processes and inter-process communication. What's left to figure out is user-to-process communication.

But first, here's a potential clarification about inter-process communication: pipes are a way to send data from one program to another, but there are a lot of other ways to achieve this too. There are signals, sockets, named pipes, etc. I'm not a Unix expert, but it's good to know that these exist and have the potential of being used. A terminal, using the '|' operator, makes it easy and convenient to transfer data from one process to another, but it's not the only way, and it's one of the least powerful. Consider sockets (ports): these allow my computer to exchange data through the internet with bbs.archlinux.org, which in turn your computer can connect to and fetch this very web page for you to (hopefully) enjoy. I think that's cooler than pipes. What I'm saying is this: why limit ourselves to line-by-line terminals? There are myriads of other possibilities!

The hard part is figuring out how the user jumps in and commands all the processes. But I think it's a bad idea to limit ourselves from the outset to line-by-line text input. It's a good medium, but not the only one.

P.S. I like this thread, I'll be back soon with more rambling!

Last edited by peets (2008-01-28 22:59:24)

finferflu · 2008-01-28 23:29:59

Ok, as far as I can see, I am being misunderstood
I guess it's for the most part my fault, since I can't find a precise way to express what I mean.

So, to answer your question: ncurses applications are more interactive via keyboard, usually, and Gtk ones need a mouse, usually. But that's not the point. There are some ncurses applications wich I utterly dislike, first and foremost Finch. I hate the GUI-like approach, whether it's inside a terminal or inside a window.

What I call "terminal" here is not strictly bound to text-only, or line by line. Perhaps I should have called it "console". Not sure what's the best term. What makes me call it terminal is the level of interaction a user can have with it, which is far higher than a GUI with buttons and menus. So, that's why I called it "Working Environment", it's not limited to line-by-line commands. It can have applications with a user interface. Perhaps the mock-up I came up with was not so clear, too. As you can see there are applications with a user interface on top and a command line at the bottom: this means that one uses what's more convenient. The point is having both of them available at the same time, that's why I said that it would have been cool to have an expandable command line: you press a key, and the prompt raises up half of the screen (or something of that sort). You might say that you can achieve this with things like Yakuake or Tilda, but it's not the same thing when the command line can have a set of built-in functions that interact with the applications. Every application could have its own command-line counterpart (if it happens to be graphical), so while using it you can pop up the CLI and give some commands (it's a bit like to colon in Vim).
And as I said, I feel the need of abolishing windows. I think we had enough, this game is getting old. Now they also wobble
I think the concept of windows also imposes a mindset or a philosophy upon the functionality of the application. I don't think an application should be limited to a portion of the screen. It might be convenient at times, but not always. We need more flexibility.

A common base for me is something like a Desktop Environment, which facilitates the interaction between its own applications. But in our case it handles the job in a much different fashion. It should go as far as creating a standard UI and defining standard commands for all its applications. And as far as my opinion goes, it should focus on content as the most urgent priority, and on the form/aspect only to let the content flow better, i.e. a "Keep It Simple Stupid" and minimalistic interface.

peets · 2008-01-29 04:18:56

finferflu wrote:

the command line can have a set of built-in functions that interact with the applications. Every application could have its own command-line counterpart (if it happens to be graphical), so while using it you can pop up the CLI and give some commands (it's a bit like to colon in Vim).

Yes. That's what I've been arguing for, but in a more general sense. The commands given by the user should be processed by the "working environment" and then be sent to the application. The most convenient way I can see is through a vim-style command bar that can be popped up at will. But this input could come from elsewhere. My point is, the working environment should process input from any source, but send it in a uniform way to applications (maybe by translating everything into a text command?)

finferflu wrote:

I don't think an application should be limited to a portion of the screen. It might be convenient at times, but not always. We need more flexibility.

Yes. I like "headless" applications. Everything should be a daemon or a server, and present output only at the user's will.

it should focus on content as the most urgent priority, and on the form/aspect only to let the content flow better, i.e. a "Keep It Simple Stupid" and minimalistic interface.

Amen.

varl · 2008-01-29 09:27:12

http://en.wikipedia.org/wiki/W3m

The article says that XTerm has support for inline images in the terminal. Just to throw it out there.
I think you have some pretty cool ideas, finferflu, but I think that you are venturing onto dangerous waters when you say things like terminal apps having to adherring to a standard -- I don't know if you are trying to rework how we interact with computers completely, but that seems to be beyond a realistic scope. What you are building is more along the lines of an operating system if you set up design rules for applications (they have to work like so and like so, this is what MacOS and Windows does).

My question to you is:
What are you trying to portray? Not a window manager, because you hate windows. Not a terminal, because of the limitations.

A common base for me is something like a Desktop Environment, which facilitates the interaction between its own applications. But in our case it handles the job in a much different fashion. It should go as far as creating a standard UI and defining standard commands for all its applications.

Yes, this seems to describe what you want, but the desktop environment handles applications, and the applications handle how they are interacted with -- if that is text-based or mouse-based is up to the application. Your DE (from what I understand) seems to demand applications being developed for it, which breaks compatability with all of todays X apps -- and probably the text-based ones too since you wanted them to conform to standards as well.
So really, my interpretation is that you are trying to set up a new operating system -- maybe based on the linux kernel, maybe not.

Am I way off?

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

@ varl

That article is about w3m, and as far as I know, it's the only CLI application that makes use of inline images. But they are displayed on top of the terminal screen, on an invisible windows, on a different layer.
It looks a bit too hackish to me

Anyway, I think you're going a bit too far When you talk about Operating Systems, do you also include Desktop Environments? Because the DEs we use on Linux are available on other platforms as well. If "Linux" is GNU + Linux, I don't think I'm planning to create a new one, we can have this "terminal" running on Linux. We are simply planning to enhance the current system of giving commands to a prompt and to communicate with applications (more or less).

As I said in one of my other posts, I would like to have this environment running inside a "terminal", that is, inside its own (!!!) window, in order to facilitate the interaction with the old fashioned GUI-based environment. So one could have both worlds, especially when this environment would break the compatibility with the current X applications, as you well said. I think we really need to break with the current state of things. We have gone very far, and it would be difficult to make the current X apps work in this new environment. I don't think we should reinvent the wheel, but we could just port what is already there. It surely would take a lot of time and effort, but if everything will be inside this "terminal" we can temporarily survive with the current apps. The same could be true for the text-based ones (run them in a standard terminal for the time being).

So, in conclusion, I really would like to break with the current direction, and head towards different aims. It really annoys me when I read/hear people (critics, devs, and so on) discussing about usability and innovation, and only considering the de facto interfaces. So what's the point of trying to improve things if you only look at them from a single perspective?

Last edited by finferflu (2008-01-29 11:37:10)

varl · 2008-01-29 11:52:55

@finferflu
If you break compatability with all applications "we" use in our day-to-day schedule I don't think it will take off or be widely accepted, and you need to at least convince developers to make their programs work in your environment, and the only way I can see to avoid major annoyances with it is casing it in the term "operating system". This means you can set up your own rules for how an application is to be designed so it guarantees compatability with your environment. Running it as a "window manager" inside a window manager seems round-a-bout and I can see no benefits (other than playing around with a new innovative way of working, which I would definately do), and even running it as a desktop environment doesn't seem to "fit".

It would need it's own repos with "finferflu capable apps" to avoid that people install some weird app thinking it would work with it, which is how I came into the "OS" line of thinking, of course, you could see it as it's own distro instead .. but the effect would be the same.

And I agree with you about interfaces, the way they work is based on concepts from the 80's and 90's with what is basically only minor alterations. As you said, it's a new way of working. And thus it needs to be it's own platform. I am getting ahead of myself however, I just don't see it "working" nested.
My understanding of what you are trying to portray is lacking, and it will be until you have a prototype working as you envision it.

Last edited by varl (2008-01-29 11:53:28)

peets · 2008-01-30 05:36:33

I just read a bit about X11. It's hard to find any relevant doc for it, by the way. Anyway, here's an introduction mentioned by the wikipedia article: http://www.visi.com/~grante/Xtut/. It's pretty discouraging to see where the author takes the article; he ends up with the opposite of what we've been talking about.

The X server is an ugly monster. It does too many things at once. It handles keyboard and mouse input; it has the abstract notion of window/client hierarchies; it draws primitive shapes; it draws fonts. It's an ugly in-between between modularity and turnkey packaging.

I'm always awe-struck when I play the occasional videogame: the people who wrote those had to "re-invent the wheel" by writing their own input processing, font-drawing, window managing programs! And some of them come up with pretty functional stuff too. The last game I've played is The Sims 2. I'm amazed at how much can be done, and very efficiently, with one three-button mouse and a scrollwheel. But that's OT. What I'm hinting at is that maybe it's time to ditch X11! :-O

Since I don't care about windows that can overlap, finferflu's idea of frames is welcome, and a major function of X11 can be ditched. What else is there that it does? Input processing? There must be much better libs (GNU readline?). Font drawing? I'll have to read about freetype and how it's usable outside of xft. Graphics primitives and bitmaps? OpenGL!

I'm dreaming in colour. x.org has been in development for decades, there's no way we can write a quick drop-in replacement for it. But we can do like Linus and start a revolution.

Note: this post is purely speculative.

Even though it would be cool.

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

Last edited by peets (2008-01-30 05:39:26)

wuischke · 2008-01-30 07:39:50

peets: Have a look at the directfb-project, you might like it.

Arch Linux

#26 2008-01-25 13:38:59

Re: Ever thought of a graphics terminal?

#27 2008-01-25 14:25:04

Re: Ever thought of a graphics terminal?

#28 2008-01-25 14:26:18

Re: Ever thought of a graphics terminal?

#29 2008-01-25 15:11:50

Re: Ever thought of a graphics terminal?

#30 2008-01-25 15:36:18

Re: Ever thought of a graphics terminal?

#31 2008-01-26 03:15:03

Re: Ever thought of a graphics terminal?

#32 2008-01-26 13:49:13

Re: Ever thought of a graphics terminal?

#33 2008-01-26 16:46:41

Re: Ever thought of a graphics terminal?

#34 2008-01-26 18:14:56

Re: Ever thought of a graphics terminal?

#35 2008-01-26 22:22:42

Re: Ever thought of a graphics terminal?

#36 2008-01-27 19:21:20

Re: Ever thought of a graphics terminal?

#37 2008-01-28 08:03:33

Re: Ever thought of a graphics terminal?

#38 2008-01-28 09:41:58

Re: Ever thought of a graphics terminal?

#39 2008-01-28 11:48:30

Re: Ever thought of a graphics terminal?

#40 2008-01-28 14:38:31

Re: Ever thought of a graphics terminal?

#41 2008-01-28 15:01:00

Re: Ever thought of a graphics terminal?

#42 2008-01-28 15:40:09

Re: Ever thought of a graphics terminal?

#43 2008-01-28 22:55:45

Re: Ever thought of a graphics terminal?

#44 2008-01-28 23:29:59

Re: Ever thought of a graphics terminal?

#45 2008-01-29 04:18:56

Re: Ever thought of a graphics terminal?

#46 2008-01-29 09:27:12

Re: Ever thought of a graphics terminal?

#47 2008-01-29 11:31:31

Re: Ever thought of a graphics terminal?

#48 2008-01-29 11:52:55

Re: Ever thought of a graphics terminal?

#49 2008-01-30 05:36:33

Re: Ever thought of a graphics terminal?

#50 2008-01-30 07:39:50

Re: Ever thought of a graphics terminal?

Board footer