Discussion over a new desktop environment.

simongmzlj · 2009-08-21 23:07:32

I've been sitting on several ideas of what an "ideal" desktop environment should behave like. I've finally started coding a pseudo mock-up of this system, but I'd like to share my ideas her because I'd love to hear the opinions of others. I enjoy KISS minded attitude of Arch.

Now, there are several problems with the traditional desktop when it comes to usability which prevent its full potential to be realized. The command line interface is considerably more powerful for the majority of tasks due to its modularity and flexibility. For example, transcoding video is as simple as piping a decoder's output into an encoders and piping the output to a file. This allows for users to write their own "programs" to do what they need to do.

The idea is to start from scratch, and make "data" and data discovery the focus of the desktop environment instead of application management. I discard the traditional idea of what an application is. Instead of applications, the desktop environment is built on modules and the iteration and discovery of modules to construct an end product, much alike to the function of UNIX pipes, with the added ability to discover what to chain to to get a desired functionality. Each module does only one thing and hopefully, one thing well. The GUI is handled with a separate module and is generated at runtime. Controller modules aid the GUI generating module to provide a ways defining interaction with components. This kind of system is also, as a bonus, immune from bloating because all that matters are the individual components, which can be installed or removed one by one.

The separation of the GUI leads to many interesting applications. It guarantees conformance to a standard, adapting to the target system such as one based on a touch screen, provides a way to generate web GUIs (such as for a torrent program) for free, and provides a way to applications remotely, and this barely scratches the surface of potential.

Some examples:

A web browser could be implemented as a set of separate commands chained together.

Source ---> HTML Parser ---> Canvas ----> GUI Generator
|---> Controller --|

Adding the following components to the system can add the following behaviour
Canvas ---> PDF web browser can export to PDF
Canvas ---> CUPS web browser can print.

An image viewer doesn't need to know about the various libraries to support different file types, it simply "opens" a file with a request for image data. The system discovers the proper component that can handle the file type. The controller can be changed on the fly, so the image viewer can transform into an image editor. The image viewer could also possibly detect lossy conversions, say, the rasterization of svg files and then automatically provide a mechanism to "import" instead of to "open" the file.

A torrent program really can benefit from decoupling the GUI from the application. A torrent application can be automatically started in the background, and a notification component can automatically notify you on completion of torrents.

In a file browser, when viewing filed being currently downloaded, the file browser can automatically get extra information for those files and display progress information in place. When viewing a folder holding mp3s, it can display album info/art and show a track listing.

For my implementation, I've build a gobject like system that supports duck typing, reflection, and discovery. This allows for, and I have basic code that does, automatically loading components in ruby and across shared objects. I have a basic GUI builder which builds either a GTK interface or web page from an XML description from an application. It's a long way off still, but its a start.

As a side, I'd also build by own widget library. This is only because I think both GTK and QT are starting to show cracks in widgets. Sure widgets can be inherited from and customized, but these lack standardization across applications and many controls are, in my opinion, misused. For example, progress bars/sliders aren't the most appropriate for streaming video. Neither can overlay position over download progress download progress and I feel like its a misuse of the widget to seek with a progress bar, especially so when animated. It looks and feels like a hack.

Mardoct · 2009-08-21 23:20:34

If you could find a way to let me use CLI programs without remembering so many program names and options, I'd probably switch to it.

Peasantoid · 2009-08-21 23:22:43

I've often thought about this sort of thing, but not actually known where to start building one. While this may sound is somewhat premature, I'd gladly join in development if/when this gets off the ground.

Xyne · 2009-08-21 23:33:15

This is interesting. I've had similar ideas for creating basic functional tools that could then be chained together as nodes in a graph to create new applications. Such an approach could also lead to a very nice GUI frontend in which the user can graphically create these connections and thus generate new tools from basic building blocks.

For usability the connections would need to be easily accessible for modification on the fly, e.g. to easily send the webpage output to a PDF converter instead of the GUI Generator when the use wants to export the page.

The problem that I see with this is that there would be such tight integration of the DE applications due to the nature of the modular backend that third-party apps will feel completely out of place. You would also need to reduplicate the functionality of many apps in a way that fits into this scheme (that's not a reason not to do it, just an acknowledgement of the work that it will require, which may well be worth it).

Peasantoid · 2009-08-21 23:49:46

Xyne: With regard to the 3rd paragraph, I would argue that a properly-designed modular system wouldn't need other applications.

We would also need to figure out a way of passing data between modules.

And a non-stupid name for the whole thing. Anything in the style of GNOME or meaningless like KDE should not even be considered. I suggest 'Hubris'.

Last edited by Peasantoid (2009-08-21 23:56:56)

Xyne · 2009-08-22 00:01:28

Peasantoid wrote:

With regard to the 3rd paragraph, I would argue that a properly-designed modular system wouldn't need other applications.

My main point was that you would need to write modules for many things which would involve rewriting a lot of code that already exists in an amenable form.

Peasantoid wrote:

We would also need to figure out a way of passing data between modules.

It should probably be capable of non-sequential routing of data too, to enable parallelism etc.

Peasantoid wrote:

And a non-stupid name for the whole thing. Anything in the style of GNOME or meaningless like KDE should not even be considered.

So the following would be a bad idea then, huh?

NODE = Node-Oriented Desktop Environment, as each module would essentially be a node and each application would be a directed graph.

Peasantoid · 2009-08-22 00:04:01

Xyne: When I said 'style of GNOME', I should have said 'stupid pronunciation'. NODE is actually pretty cool. (And it's a recursive acronym! We totally need one of those!)

Ranguvar · 2009-08-22 00:08:41

To me, the very _idea_ of a DE is wrong -- DEs are necessary evils. They simplify development of a unified environment by allowing all components to depend on one another rather than doing things the real, proper way -- careful development of open standards that allow each piece of the environment to interact, and then building software that is needed while welcoming alternatives.

As for the web browser... well, I believe that even browsers like (the awesome) uzbl aren't truly Unix-like in philosophy. The entire concept of a web browser is wrong. It's an OS inside an OS. Rather, I argue, net functionality should be worked into desktop apps much more. I fear however that it may be impossible to do this without actually changing the web as we know it though.

That all said, this seems a very anti-DE DE, and is certainly interesting.

simongmzlj · 2009-08-22 00:22:04

I've used the code name "rawr", which I like because it has nothing to do with anything, yet isn't unpronounceable. Node is interesting name.

Remember, this is a highly modular system. HTML to PDF exporter could be invoked with this system from a command line because its just chaining modules. The GUI module is optional as its a module.

Calling it a DE i guess is a bit misleading.

As for the web browser... well, I believe that even browsers like (the awesome) uzbl aren't truly Unix-like in philosophy. The entire concept of a web browser is wrong. It's an OS inside an OS. Rather, I argue, net functionality should be worked into desktop apps much more. I fear however that it may be impossible to do this without actually changing the web as we know it though.

I completely agree with this. Considering I currently implement the communication between modules as an XML stream, its much akin to how a web browser works in the first place. As well, the components I've shown above can be further broken down: css parsing, javascript, dom, etc.

Peasantoid · 2009-08-22 00:23:25

Ranguvar: To me, it seems less like a DE and more like a module chaining system that can be used to build a DE.

If it's designed well, you can make anything — for example, an image viewer consisting of 'load file' -> 'convert image' -> 'display image'. Although this seemingly simple chain entails a number of extra concerns, like a common image format the 2nd link outputs and the 3rd interprets.

simongmzlj: I don't particularly agree with the 'XML' part — it's hard to parse and painful to edit by hand. I'd suggest a less evil markup language (although I don't know of any).

Last edited by Peasantoid (2009-08-22 00:29:33)

TomWitko · 2009-08-22 00:27:32

Intersting sounds like something I would like to give a try. I really like the idea of java ajax like interfaces and good search functionality based on shaman functionity tofind what you need whan you have a lot of programs. Intersting idea.

Peasantoid · 2009-08-22 00:30:03

TomWitko wrote:

Intersting sounds like something I would like to give a try. I really like the idea of java ajax like interfaces and good search functionality based on shaman functionity tofind what you need whan you have a lot of programs. Intersting idea.

Correct me if I'm wrong, but... I don't think that's what we were talking about?

Trent · 2009-08-22 01:24:55

Peasantoid wrote:

Xyne: When I said 'style of GNOME', I should have said 'stupid pronunciation'. NODE is actually pretty cool. (And it's a recursive acronym! We totally need one of those!)

Actually, it isn't a recursive acronym, because the "Node" for which the N stands is used in the dictionary meaning of "node", not in the invented meaning of the acronym NODE. If it were a recursive acronym, it wouldn't make much sense.

Personally, I hate recursive acronyms. Unfortunately I have to live with them, or go back to Windows. But I like the idea, and I would use it even with a name like "gavjoungle", if I liked the implementation.

thisoldman · 2009-08-22 02:32:37

The architecture sounds like the JACK Audio Connection Kit writ large. Having had some audio background, that's how I visualize the flow: a signal through mixers and patchbays to devices that do something with that signal. Take a look at the sequence of images for qtjackctl, particularly the "Connections" and "Patchbay" windows.

Am I on the right track (no recording pun maliciously intended)?

Peasantoid · 2009-08-22 02:32:57

Trent wrote:

Actually, it isn't a recursive acronym, because the "Node" for which the N stands is used in the dictionary meaning of "node", not in the invented meaning of the acronym NODE. If it were a recursive acronym, it wouldn't make much sense.

Note to self: It's very difficult to convey a humorous tone through the medium of text (read: I tried to make a joke and it failed miserably).

Your post raises something I hadn't though of, though — a recursive acronym with two meanings. See, there's the non-stupid 'node-as-dictionary-definition', then there's 'NODE-as-bloody-stupid-recursive-acronym'. Makes more sense than most recursive acronyms, I guess.

With regard to markup languages: JSON, bitches!

Last edited by Peasantoid (2009-08-22 02:39:41)

ArchArael · 2009-08-22 16:05:04

Very interesting discussion.

I would like to try that. This reminds me of an older discussion: http://bbs.archlinux.org/viewtopic.php?id=42773

Maybe you could collect some idea from.

Last edited by ArchArael (2009-08-22 16:07:45)

Crows · 2009-08-22 19:42:07

Intriguing idea. So a web browser (fairly complex example) would presumable be implemented by stringing together a collection of nodes, such as a parser, image renderer, javascript etc?

An interesting side-effect of a system like this - if implemented in a certain way components would be able to swap-out very easily. Say you have a GUI node. You then create the specific interface of the node (which every app will expect it to implement) to handle each GUI-based request by other nodes. Providing the interface was maintained you could, for example, use GTK/QT/wxWidgets/anything for the actual toolkit and the apps themselves would never need to worry about it (probably a bad example, but I believe it gets the idea across).

Not to mention the ease in which systems could be updated. New super-fast javascript engine? No problem, maintain the interface and use it in place of the old one. None of the other functions would ever need to know.

EDIT: As for a name, may I suggest something like "Concert" or "Harmony".

Last edited by Crows (2009-08-22 19:47:29)

Zerathidune · 2009-08-23 00:40:23

I very much like this idea. Do you have anything in the way of mailinglists, project page, etc set up? you said you'd started on some kind of an implementation, I'd be curious to have a look/get involved.

Peasantoid · 2009-08-23 02:42:55

Implementation question — what would be the best way to string modules together? Would they just be executables/scripts, each one piped into the next? Or something more exotic?

ArchArael · 2009-08-23 09:46:27

This article is very interesting and maybe could be useful to read for developing further your ideas.

http://www.freesoftwaremagazine.com/col … d_limiting

The end of the article presents a modular stream/flow interface as concept.

Last edited by ArchArael (2009-08-23 09:47:41)

t4k1t · 2009-08-23 10:20:48

Crows wrote:

EDIT: As for a name, may I suggest something like "Concert" or "Harmony".

I think smth. like "Accord" would fit better to the concept of chaining together these nodes, but NODE is really a great idea for the name.

However I really like the idea of this "DE" and too would like to get involved. I suppose you use C as programming language?

arkay · 2009-08-23 11:51:37

I love the idea of this. I've often thought that GUI's were done the wrong way and that just like CLI commands it should be possible to take the output of one and pipe it to the input of another to essentially create new applications without having to be a low level programmer. Given that so many complain about having to learn the complexity of the shell and actually use cli commands I've wondered why someone yet hasn't built a modular gui replacement for every command line executable and then developed a communication library that allows you to stream io between modules in order to create programs. It would then be trivial to assemble gui tools for anything we currently need the shell for. For new users people wouldn't see the code, they get a gui, it's the code that frightens people. Instead of posting a series of shell commands to a user to help them you could post a "graph" that assembles the components they need to update their rc.conf or modify their networking parameters etc. A 1 click run fix to a given issue that presents a GUI... Anyhow. That's a little OT.

I do believe though that a modular system where every component does one and one task only and is optimised to the hilt, has incredible power and that as time progresses you are taking the best of code developed and building on it to make better and more complex applications quickly, without losing the effort expended previously. The is the way it should always have been done. They way so many people re-write and/or re-invent the wheel in order to create new gui programs has always been a huge waste of resource. You could say that class libraries are exactly that but the difference with this approach is that you differentiate coding, "actually cutting language syntax", from application design. Anyone can design applications with a gui library such as this and more often than not application coders are not good gui designers. The possibilities of this concept are endless. Designing a method that caters to any possible form of input/output is the tricky part. You'd have to document a standard that remains as static as possible. But just imagine how cool it would be, rather than having to go learn C, C++, ruby, Python etc, you could just grab a video decoder, a file opener, a remote control module, an audio decoder, a tv tuner, throw it all together in a module "graph" designer and instantly have yourself a PVR application. It has to be done!! Then the "coders" can write the components in anything from highly optimised assembly to perl or <insert language of choice>, add them to the module library and let the application designers have at creating killer apps. The specification would have to be spot on and 100% policed with no room for interpretation. Fantastic idea though. I'll be watching this one with interest.
The only thing I wonder is if it's really possibly to break everything down to it's base level components. There's always going to be instances where data manipulation and or logic needs to be inserted between on output and another input. That also would need to be graphically represented, otherwise you'll end up with another programming language that glues all the UI components together and have not fully satisfied the end goal.

Cheers,

Arkay.

joaca_rj · 2009-08-24 21:24:07

Hey, I've stumped in some desktop project that did sounds interesting and similar with the idea...

[...]While you can run regular applications in Étoilé, the majority of the actions you'll be performing in Étoilé will be via Services. Services are like micro programs which can be strung together to create just the application you need to fit just the workflow you want. Services come in two forms: Command and Palette. Simply put, a Command Service runs as soon as it's called, while a Palette Service creates a small window, or palette, for a more interactive process. Additionally, you can create Contexts, which are a series of Services that become activated when working with a specific type of file. For example, if you wanted to create a drawing application, you might make a Context that launches your Color Selector service, your Brushes service and your Shapes service whenever you make a new document that contains an Image Component[...]

the url http://etoileos.com/

EDIT: There's stable and svn packages in AUR

Last edited by joaca_rj (2009-08-24 21:32:54)

ArchArael · 2009-08-25 09:28:23

The problem, well not actually a problem, I see with all these projects is that the assembling of the application is performed mainly by using mouse. It's hard for me to understand how someone could use such interface by using keyboard.

Can someone please provide valid points on how could we manage this new interface by keyboard?

The unix tools invoked through shell are easy to assemble by using pipes, redirection ecc because it's all text. We combine simple commands and use simple syntax, although sometimes very cryptic, and we perform a lot of tasks. This is done easily by just typing on keyboard. But when it turns out to apply same concepts to gui I have difficulties to see and comprehend how this can be done from keyboard easily and simply as with unix tools.

Last edited by ArchArael (2009-08-25 09:28:57)

alterecco · 2009-08-25 11:32:55

An interresting approach is taken by Quicksilver like interfaces. It could be expanded to provide a richer gui, and pipes that extend over more than 3 `actions`. It is completely keyboard controllable, yet lives and integrates in a gui envoronment.

Last edited by alterecco (2009-08-25 11:33:15)

Arch Linux

#1 2009-08-21 23:07:32

Discussion over a new desktop environment.

#2 2009-08-21 23:20:34

Re: Discussion over a new desktop environment.

#3 2009-08-21 23:22:43

Re: Discussion over a new desktop environment.

#4 2009-08-21 23:33:15

Re: Discussion over a new desktop environment.

#5 2009-08-21 23:49:46

Re: Discussion over a new desktop environment.

#6 2009-08-22 00:01:28

Re: Discussion over a new desktop environment.

#7 2009-08-22 00:04:01

Re: Discussion over a new desktop environment.

#8 2009-08-22 00:08:41

Re: Discussion over a new desktop environment.

#9 2009-08-22 00:22:04

Re: Discussion over a new desktop environment.

#10 2009-08-22 00:23:25

Re: Discussion over a new desktop environment.

#11 2009-08-22 00:27:32

Re: Discussion over a new desktop environment.

#12 2009-08-22 00:30:03

Re: Discussion over a new desktop environment.

#13 2009-08-22 01:24:55

Re: Discussion over a new desktop environment.

#14 2009-08-22 02:32:37

Re: Discussion over a new desktop environment.

#15 2009-08-22 02:32:57

Re: Discussion over a new desktop environment.

#16 2009-08-22 16:05:04

Re: Discussion over a new desktop environment.

#17 2009-08-22 19:42:07

Re: Discussion over a new desktop environment.

#18 2009-08-23 00:40:23

Re: Discussion over a new desktop environment.

#19 2009-08-23 02:42:55

Re: Discussion over a new desktop environment.

#20 2009-08-23 09:46:27

Re: Discussion over a new desktop environment.

#21 2009-08-23 10:20:48

Re: Discussion over a new desktop environment.

#22 2009-08-23 11:51:37

Re: Discussion over a new desktop environment.

#23 2009-08-24 21:24:07

Re: Discussion over a new desktop environment.

#24 2009-08-25 09:28:23

Re: Discussion over a new desktop environment.

#25 2009-08-25 11:32:55

Re: Discussion over a new desktop environment.

Board footer