Thursday, June 12, 2008

Gnome in the age of decadence?

See this.

This is when you know that a project will improve and that good things will start happening, it is when people start realizing that things aren't going in a correct direction.

Some Gnome developers find this a chance to express what they think is best for the project, some others disagree that the project should change where it is heading and others simply don't care.

I will not offer an ultimate solution here because I am not deeply involved with the Gnome community. It is up to more aware and responsible people to do so. I am only a user of the desktop and it's developer framework. Here, I lay out ideas, it is up for those who are interested to take them or leave them, or just take some of them and leave the rest.

A Document-Centric Environment

Abstraction:

Some people have been discussing if this will make Gnome (or Gtk+ applications) more document-centric. If I was to make a decision, I would ignore the menubar and look at the bigger picture, the entire environment. A Document here may be a Person, some Text, a Picture or a Photo, a Song by an artist (Person or group of Persons) or an Audio Clip or Audio Joke or whatever, a Website address or a Blog or a Feed or a News page or Website content (a group of Texts and Pictures), even a Book by a certain Author (Person) etc...

Documents need to relate to each other. A photoshoot (set of Photos) and songs (set of Songs) off an artist's album need to know about each other, including the lyrics (Text) and the artist himself (Person).

Another example, my contact list is a list of People and not a list of email addresses or ICQ numbers. I want to be able to drag (or copy, move, etc...) another document (a music Album or even an artist - Person) into a Person and this person receives the Document however it is possible (if they are not online on their IM, then just send it by email, whether it will be in a form of a compressed archive or individual files, I don't care, neither does the Person whom I am sending this to) and so on...

I receive a Document, I don't care if it is by email or IM or whatever, I just am notified that I received one and it stays as an unread until I check it out. No, I do not download a file, look for an appropriate application to open it with, etc... I just open the Document and that's it.

All this may sound too complicated at first, but if you think about it, it's as logical as our real world.

All this would need intensive semantics, tagging concepts, new standards, etc... which I am sure will lead to a brave new world of desktop and workstation computing.

Speed:

My computer needs to understand that it is supposed to be waiting for me and not the other way around.

If the environment doesn't need bluetooth right now, then the bluetooth stack shouldn't be running. Wait, here's an idea, I can drag a Document into a Person and it gets sent to them over bluetooth if they are around with their mobile phone, pda, laptop, whatever, I don't care, it just should get to them.

Something that is fairly complete right now - probably the only thing - is when I want to move something to a USB Stick or an External Hard Drive. What I think is still missing is the automatic organization of the files (think backend here) on this drive. I don't want to move a Photo to /media/disk/personal/photos/birthday/photo1.jpg, but I just want to throw that Photo where me and John were eating cake at Lilly's 20th birthday onto the disk, I don't care where it is copied or moved, all I care about is that it's there now and that I'll be able to get it back by looking at the Photos > Birthday > Lilly > 2007 (or 20) > John > Eating or someway simpler than that...

UI:

It's called an Interface for a reason, to abstract the complications and make things easier. The user interface needs to present informative visual data. People don't read the text on error messages (or the alike) anymore. We can learn something from movies here, if there's a green blinking box - whatever it's trying to say - then it's something positive, if it's red, then something's wrong - or whatever. Of course, in a more appealing way.

A side note, something like Wobbly Windows is completely useless, it indicates that the window is being moved (or being maximized, minized, etc...). But I am the one who is moving it! I already know it is moving!

Coming to windows, this concept should go away (okay, not like that, but I'm just thinking). A Document Centric Environment would need to treat the current document as first priority - like a king - and this includes it's share of screen space. Tiling window managers are a good and helpful concept here when combined with fullscreen window managers, it is Gnome's turn to make these easy, integrated and as familiar as possible.

Gnome as a developer framework:

I am going to spit out nasty things here...

A developer framework needs to attract developers, and these days, developers are not necessarily elite software hackers with infinite amounts of time to learn and learn and learn. No, developers dream of a framework where they can just tell it to do X and it will do it for them. Code less, create more.

So, first, Autotools needs to go away and be replaced by something simple that can be auto-generated. Second, the use of a native Object Oriented programming language that is not interpreted or compiled into bytecode. Objective-C is a viable solution and GObject needs to go away, it's too much of an overhead to developers. Third, the API needs to be changed:

void gnome_keyring_item_ac_set_display_name (
GnomeKeyringAccessControl *ac, const char *value);
isn't very attractive, isn't it?

About GObject, I can understand it's there for a reason, but why the philosophy of having to interface with every possible programming language and paradigm, while the Gnome people claim they can't target every possible desktop usage paradigm. Doesn't fit, and personally, things like Haskell, Ruby, PHP, etc... are not there for desktop and workstation applications, so don't put them into account.

Documentation - including guides, tutorials and references - is also extremely important, something that is being overlooked right now. To 3rd party developers, a library never existed if they can't find documentation for it. Trust me on that one.

Components, Centralization, Integration, etc...:

The entire desktop and developer framework needs to be broken down into clear components that interact with each other to produce the desktop and it's applications. A huge pile of small connected and high-performance plugs would be a good example (high-performance if Gnome will want to run handhelds, mobile phones, laptops, sub-notebooks, etc...). If one of these is too broken or simply doesn't cut it for a certain user, or developer, or OpenMoko, they can just replace it with a more appropriate rewriting of theirs instead of having to re-engineer the entire environment.

Online Desktop, but also Offline:

It is nice how integration between the desktop and the web is happening, but it is not nice when a website tries to become my desktop. The web is not an operating system. I would like to receive a Document on my desktop (here, message) when someone sends me a message on Facebook. I would like to have the option to add that person I have on my friends list on Facebook to my contact list rather than copy and paste each detail. I would like to receive suggestions from other people about other songs when I'm currently playing a certain one. It would be nice to have my contacts information, my workspace, etc... accessible from anywhere on the planet but I don't want my desktop to be some script inside a web browser, because I still want to use it normally, I still want to work with my system and my files directly - not through "Documents".

Gnome Mobile:

This is more of a consequence to the previous parts. One thing I did not mention is that Python, Java and Mono will have to go away. Not way away. Just out of the core components and core applications. These are not system languages, in my opinion, they are there to easily extend current applications, nothing more, nothing less. But they're easy languages and their libraries are amazing?! Why throw them out?! The answer to that is, create steady and competent framework libraries - here, for Objective-C - and it will be as easy as any other language. Then, select only one of these as an extension scripting language (for plugins and the like). I would choose Python. As a person who really cares about what is running on their not-very-high-end laptop, I don't want a plugin to run the entire Python interpreter and another plugin to run the entire Java Virtual Machine and another one to run Mono and etc... No.

Another thing I didn't mention earlier is screen space, the sacred screen space. Currently, UIs tend to be stupid when consuming screen space, this should be fixed and a lot of mockups out there target this problem.

I would gladly join the movement towards new concepts and ideas better interaction with my laptop here. If this is ever going to happen within Gnome and you're a Gnome developer reading this and in need of man power, ideas, design or whatever, don't hesitate to invite me! :P

Just my two cents.

Cheers.

3 comments:

Florian said...

YEAH!

That's how a modern desktop environment should be!
But I doubt that this can be accomplished by modifying Gnome.
I think starting a new project from scratch, based on the above mentioned design criterias, will be more promising.

Kind regards,
Florian

Fred Morcos said...

interested in such a project?

Florian said...

interested yes, but i'm no software developer/programmer... sorry.

but you might have some influence to the etoile (etoileos.com) project, which i think is very promising.