Discussion over a new desktop environment.

Peasantoid · 2009-08-25 19:09:04

I'm working on a Python implementation of this idea. It reads in a file that describes how everything is connected, then creates a series of FIFOs and lets the nodes communicate from there.

(It's extremely ugly code — experimentation purposes only.)

Last edited by Peasantoid (2009-08-25 19:09:29)

simongmzlj · 2009-08-25 19:51:28

The idea is to remove the notion of an application as the unit of interactions. Instead of the "Need to get to the web? Open firefox, and navigate", the model is "Open this file, its an html page. do we have anything to parse it? yes. do we have anything to display it? yes" and so forth until a GUI is made.

I'll have a basic system of this released sometime early/mid september depending on when my new laptop comes in.

I have the backing type system built, a very simple GUI parser, a very hacky gtk and webserver frontend. I just have to build a couple demonstation applications, probably hacked up in ruby.

funkyou · 2009-08-25 20:49:42

simongmzlj wrote:

The idea is to remove the notion of an application as the unit of interactions. Instead of the "Need to get to the web? Open firefox, and navigate", the model is "Open this file, its an html page. do we have anything to parse it? yes. do we have anything to display it? yes" and so forth until a GUI is made.

Isnt this what MAC OS X does/has?

"document centric UI" or something... (dont know the correct eng. term, in german its "dokumentenorientiert").

brisbin33 · 2009-08-25 21:16:29

alterecco wrote:

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.

win.

as a mac2linux convert i loved quicksilver (gnome-do just didn't compare, last i tried it). being an xmonad-keyboard-centric-terminal user, i was taking a very wait-and-see approach to this (albeit _very_ interesting) idea. once you mentioned quicksilver it clicked. and entire OS operated in that manner would be very sweet.

*hits quicksilver keybinding*

open<tab> ~/Music/Some Album/*<tab> convert<tab> wav<tab> burn<tab> /dev/sr0<enter>*

and just like quicksilver, the list of available actions for any current link in the chain would be filtered dependent on the links in the chain so far, so memorizing commands becomes much less of an issue. and once you've created this one-tool-one-job world, portions of these chains could be completely automated and created on the fly, dynamically... ok, /me gets excited...

*note: smart tab-completion would be a requirement of course, but would've totally confused my example.

roignac · 2009-08-26 09:20:08

I really liked the idea. To my mind, this might be implemented using signal-slot system. When some event happens (slot), some actions are bound to the event (signals). Like "button pushed - start an application" or "laptop lid closed - start screensaver, change status in IM client". I guess, this should be better implemented using DBus. However, this might not be lightweight, but much more userfriendly than pipes.

Last edited by roignac (2009-08-26 09:20:52)

ArchArael · 2009-08-26 09:39:45

brisbin33 wrote:

*hits quicksilver keybinding*
open<tab> ~/Music/Some Album/*<tab> convert<tab> wav<tab> burn<tab> /dev/sr0<enter>*

Hm...interesting. I can see now how such new GUI paradigm could be managed by using keyboard. Thank you.

The problem I see is learning the syntax. But, actually, that wouldn't be a problem for power users. The ordinary users could use mouse and both world would be satisfied.

I like it.

alterecco · 2009-08-26 12:41:37

It think an important to realize that what we have in a console, is actually in some ways a gui, just using text as it's representation. In todays world however, we have many new media types that do not translate well to this representation. The feeling i have when working with applications that live in the terminal, is that I am always inline, and I loose that when I open up an image in some gui app. All context is lost, and am removed from my most powefull environment, relagated to some crippled middleware (in that it sits between my data/enviroment and me). Horrible...

What i think we want to achieve when we talk about creating this paradigm of a new DE ( NO DE ?? ), is that we want our typical X applications, or gui applications, to be interconnected. We want to break down this barrier of isolation, and allow the interface and data to be worked on consistently, no matter what the state and task (not a very humble ambition).

Moving on with the Quicksilver example, i think what is important is clever use of context. Not only for tab completion and filtering, but application (or window) context.

As example, viewing images:

*Trigger shortcut* (no previous context, default to file selection perhaps, or bare command entry)
*Navigate to arbitrary image dir* (could be a series of individual steps, or one whole path, a la `cd`) *enter (change state) or pipe (tab?)*
*Select file(s)* (with regex/globbing of course) *pipe (tab?)*
*Select View Action* (this is a top level action, mimetype aware, has a reasonable default and several sub-actions) *sub-select (tab?)*
*Choose to execute a sub-action* (I have a selection of images selected, so typical sub-actions will be shown in that context) *see previous*
*Select sub-actions, say scale-down, random* (Think option passing, feh --scale-down --randomize) *select (space?)*
*Enter* (Some gnome, qt, chromeless window shows an image according to the specified options)

At this point, we are imagining a powerfull viewer application, with very configurable interface (keybinds, gui). In itself it should be a nice application, capable of viewing images (or documents in general perhaps). The relevant bit comes next...

*Trigger app/window context shortcut* (we get the same "Quicksilverish" interface, but this time in application context mode, we are basically working with the apps "stdout". As we were viewing an image, we can now operate on that image.)

-- Some simple actions i can imagine at this point

*Copy...*, *Move...*, *Rotate... (in place)*, *Open with...* ....
The list could go on, and can contain several Top-Level Actions, as ImageManip (imagemagic), FileSys (rsync, scp, ftp, regular), Comm (email, fileshare, socialnetwork) ...

Basically the point is to use context as much as possible. In the shell, tasks are made easier by having a fixed (but flexible) location in the filesystem, and the ability to quickly re-call and re-edit previous commands (that is what I can think of atm). Having the same concepts carry over to a modern gui environment would be interresting.

.]

Last edited by alterecco (2009-08-26 12:44:43)

XFire · 2009-08-26 13:27:32

Instead of calling it a Desktop Environment, what about Contextual Environment instead.

hak5fan · 2009-08-26 13:46:56

This is a really interesting projcet/thoughts, and I've been thinking a lot about such a system myself, but I don't have much programming experience (yet)

dunc · 2009-08-26 20:18:47

Very interesting idea.

Although the scope of what you're proposing is wider, this part:

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.

reminds me very much of AmigaOS's "datatypes" system, which is something I still miss about that OS. It was limited and quite slow, so most programs just used their own code, but the idea was very similar to what you describe. There was a small program included with the OS called "Multiview" that could handle any type of file you had a datatype for: jpeg, wav, mp3, html...

Interestingly, the last owners of the Amiga trademark, in their - sadly unrealized - plans to update the OS for the 21st Century took this idea and ran with it. And this sort of thing:

The idea is to remove the notion of an application as the unit of interactions. Instead of the "Need to get to the web? Open firefox, and navigate", the model is "Open this file, its an html page. do we have anything to parse it? yes. do we have anything to display it? yes" and so forth until a GUI is made.

sounds very familiar to me. It's like reading an Amiga.com press release from 2000. (I don't know whether that's a good thing or not; the last ten years of Amiga history has been nothing but lawsuits, backbiting, recrimination and ultimately, failure. Here's hoping these ideas will somehow still see the light of day...)

As joaca_rj points out, there are also similarities with Etoilé, which is a fascinating project.

[Edit] I might as well say this here rather than start a pointless new thread: I think it's brilliant how much discussion is going on in this forum about what an OS should actually be (this thread. the one about sandboxing, etc.). This is how technology moves forward. Great stuff.

Last edited by dunc (2009-08-26 20:24:17)

ZankerH · 2009-09-10 11:38:09

This is certainly an interesting concept that deserves to be realised.

zowki · 2009-09-10 12:10:32

I would be very happy to help out once we have a code base on this.

Last edited by zowki (2009-09-10 13:14:36)

lolilolicon · 2009-09-10 13:38:49

This reminds me of transformers and building blocks. It's like a toy for both developers and users.

If you are gonna make it (looking forward to it!), I really like to see a "GUI building center" where users can place/design/combine/add GUI elements with ease and fun. I imagine it to be like drawing, painting or playing with plasticine. Since you make the GUI a separate module, this should definitely be possible. It's fun and it's charming!

Edit: No, I didn't mean a "building center", I meant drawing directly onto the freshly automatically generated GUI interface, and drag and place elements freely. And optionally tell the controller to remember this artwork I've done. I know you may think this isn't the core part of your whole idea, but this is definitely the very important part determining how users feel.

Last edited by lolilolicon (2009-09-11 03:03:02)

XFire · 2009-09-11 06:43:32

lolilolicon wrote:

This reminds me of transformers and building blocks. It's like a toy for both developers and users.
If you are gonna make it (looking forward to it!), I really like to see a "GUI building center" where users can place/design/combine/add GUI elements with ease and fun. I imagine it to be like drawing, painting or playing with plasticine. Since you make the GUI a separate module, this should definitely be possible. It's fun and it's charming!
Edit: No, I didn't mean a "building center", I meant drawing directly onto the freshly automatically generated GUI interface, and drag and place elements freely. And optionally tell the controller to remember this artwork I've done. I know you may think this isn't the core part of your whole idea, but this is definitely the very important part determining how users feel.

It would be quite cool if you could customise the interface which the previous module specifies.

pauldonnelly · 2009-09-11 08:20:40

I'm not sure if anyone (possibly me) has posted this yet, but the ideas in this thread are similar to some expressed in The Human Interface.

FeatherMonkey · 2009-09-11 14:56:51

Unless I'm missing something(Quite possible) this looks like what squeak is doing...
http://www.squeak.org/

The example here seems similar to the concepts approached in this thread...
http://www.cosc.canterbury.ac.nz/wolfga … talk1.html

andre.ramaciotti · 2009-09-11 15:39:39

@FeatherMonkey
I didn't know squeak before, but I think there's a problem with their approach: it's very centered on a specific language. I think if a DE (or whatever this new concept will be called later) is going to be highly modular, it shouldn't depend on a single language.

FeatherMonkey · 2009-09-11 15:47:49

Yeah I suppose so, but then there is already talk of using some language for construct, ok not quite as abstracted but still is abstracted.

I suppose in my limited thinking xml vs a specific language = the same. Albeit you have a lot more abstraction with the squeak model. I've not looked too much into it but I guess there will be a way to bind to some other language(Not to mention of limited skill set).

Last edited by FeatherMonkey (2009-09-11 16:02:15)

Xenophobe · 2009-09-12 15:09:56

Just to throw in my two cents...

Reading the OP, my impression is that basically this system will be a graph with each edge being some state change of data (a "module"). Using this would be as simple as knowing what state the data begins as, and what state the data must finish as, and then letting the underlying base system do its graph search to fill in the blanks in between. It also allows a pure form of MVC.
For example, given the web browser example, I picture the process to go something like

"To view this web page at www.example.com, I need to convert the HTTP stream into viewable rich media" -> (Source: HTTP -> Destination: rich media) -> (Path is found in the graph which fills in the blanks: HTTP -> page source -> canvas -> rich media) -> Displayed on screen

The two main problems I can see are 1) designing an API which will allow each "module" to talk to its neighbours and 2) redundancy of code. The former isn't so much a problem as an inevitable task, but the latter will require some thought. Having redundant code to in each edge allows the basic concept to remain pure and simple, but means that there will be a lot of necessarily repeated code in each edge and defeats the purpose of having a modular system anyway. Using libraries muddies the basic idea of a simple graph into something which may or may not be over complex. It'll require some thinking which I'm not up for at this hour.

It's a great idea, but it'll take some work to fully flesh out the details.

Peasantoid · 2009-09-12 19:40:09

Xenophobe: With regard to problem 1, my sample implementation sets up a series of FIFOs for the nodes/modules to communicate. I can post the code if you like, though I'd rather not because it's hideous.

As for #2, can you explain?

It might be better to have some sort of API, so it's easier to [de]serialize data for passing around. Unfortunately that rules out shell scripts and any language for which bindings can't be provided.

Last edited by Peasantoid (2009-09-12 19:42:35)

andre.ramaciotti · 2009-09-12 19:44:50

I guess the idea is exactly the opposite: less redundant code. By making the modules reusable, we shouldn't need to implement the same code twice. Think of how many lines in common GIMP and Inkscape probably have, or think of the media players.

XFire · 2009-09-12 20:44:48

There may actually be a serious use for Object Orientated programming

arkay · 2009-09-14 01:04:33

Implemented correctly there won't be any programming at the application design level. Just assembling. The core units of work will need programming but application design is separate to the code. It's back to basic input->process->output. By far and away the hardest part of this project would have be designing a representative data type capable of handling any type of data. Generic enough to allow anything to pass but specific enough to enable each "receptor" to get a valid data type for it's work type.

In many ways this is similar to MS's directshow concept of graph building using codecs. The difference here though is that:

1. It will actually work and
2. Will be for any type of data.

The possibilities are endless. I'd really really love to see this take off, be done and done well. It could revolutionalize modern computing.

Cheers,

Arkay.

skottish · 2009-09-14 01:27:05

arkay wrote:

By far and away the hardest part of this project would have be designing a representative data type capable of handling any type of data. Generic enough to allow anything to pass but specific enough to enable each "receptor" to get a valid data type for it's work type.

That's what Haskell's Algebraic data types and type classes are for.

Bionic Apple · 2009-09-14 23:04:21

I have thought about this type of idea before, specifically creating pipes between applications, but never to this level. And I have to say, this is a very brilliant idea. If you guys need any help at all, I will be glad (and in fact very excited) to give a helping hand.

Also, this got my brain working, so I am going to put some thoughts below for everyone to see.

- By having "modules" (how I will call them), there is one important feature that is pure awesome: sharing of data. I know that it is implied, but the power of such an open system really shows when one considers data managing programs such as contact managers. Instead of every application possessing its own closed contact system, a single contact manager module would have the only contacts list on the system. That way, every program which utilizes the same modules shares the data.

- Ease of programming. Instead of programming whole parts of applications, only modules which did not exist before would have to be produced.

- There would be little memory usage, as a single module would offer its service to the desktop manager and all of its applications. There would be no reproduction of similiar features in seperate programs.

- A "mold" system would be needed. Let me explain: after different modules are put together, there should be a way to save this makeshift application for later. And if a friend wanted to use it? Just download the "mold" file, which would be a remarkably small text file, and let the desktop environment reproduce the the program with modules.

- There would be an extremely high quality potential. If everyone who wants to develop a calendar database worked on a single calendar database module, in theory the quality of code produced would be quite high.

- The KDE project has already touched on this concept (although barely) with Plasmoids. I am not talking about how they act as desktop widgets, but how they can be integrated into applications.

Arch Linux

#26 2009-08-25 19:09:04

Re: Discussion over a new desktop environment.

#27 2009-08-25 19:51:28

Re: Discussion over a new desktop environment.

#28 2009-08-25 20:49:42

Re: Discussion over a new desktop environment.

#29 2009-08-25 21:16:29

Re: Discussion over a new desktop environment.

#30 2009-08-26 09:20:08

Re: Discussion over a new desktop environment.

#31 2009-08-26 09:39:45

Re: Discussion over a new desktop environment.

#32 2009-08-26 12:41:37

Re: Discussion over a new desktop environment.

#33 2009-08-26 13:27:32

Re: Discussion over a new desktop environment.

#34 2009-08-26 13:46:56

Re: Discussion over a new desktop environment.

#35 2009-08-26 20:18:47

Re: Discussion over a new desktop environment.

#36 2009-09-10 11:38:09

Re: Discussion over a new desktop environment.

#37 2009-09-10 12:10:32

Re: Discussion over a new desktop environment.

#38 2009-09-10 13:38:49

Re: Discussion over a new desktop environment.

#39 2009-09-11 06:43:32

Re: Discussion over a new desktop environment.

#40 2009-09-11 08:20:40

Re: Discussion over a new desktop environment.

#41 2009-09-11 14:56:51

Re: Discussion over a new desktop environment.

#42 2009-09-11 15:39:39

Re: Discussion over a new desktop environment.

#43 2009-09-11 15:47:49

Re: Discussion over a new desktop environment.

#44 2009-09-12 15:09:56

Re: Discussion over a new desktop environment.

#45 2009-09-12 19:40:09

Re: Discussion over a new desktop environment.

#46 2009-09-12 19:44:50

Re: Discussion over a new desktop environment.

#47 2009-09-12 20:44:48

Re: Discussion over a new desktop environment.

#48 2009-09-14 01:04:33

Re: Discussion over a new desktop environment.

#49 2009-09-14 01:27:05

Re: Discussion over a new desktop environment.

#50 2009-09-14 23:04:21

Re: Discussion over a new desktop environment.

Board footer