LWN has an article regarding ideas for GNOME 3.0:

http://lwn.net/Articles/304982/

Thoughts? Opinions?

I think that there is some good ideas in there. My opinions:

The journal seems interesting, but couldn't the same functionality (more or less) be achieved today in Dolphin? If you enable "arrange in groups, sort by date", you get a journal-like view. What could be done is to make the sorting a bit more fuzzy as time goes on. Instead of grouped according to exact date, older documents could be grouped by month, and ancient documents could be grouped by year.

Combined with this, there could be a system where the user could "drill down" in dates. I mean, if the user has an older document that is grouped under "january 2008", he could click on the name of the group (in this case, "January 2008), and that would open that month with more fine-grained sorting. If he has a file in "Year 2006"-group, he could click on the title, and 2006 would be opened so that the contents is sorted by month. And so forth. This way the user would not have to remember the exact date of the file.

In addition, this data could be combined with the calendar. The calendar could display data that shows what files were worked on what dates. Even further, it could also display data on other activities as well ("Last wednesday you emailed these people:").

Workflow.... Of course it makes sense to make sure that the workflows is as smooth as possible. How good is KDE in this area? When you open and save files, do different apps know what you did in some other apps? I mean, so that we could have apps that work together, as opposed to having apps that stand alone, with no idea what the user did in some other app.

related to this, I find Karl Lattimers ideas (posted here) to be quite similar to my ideas from three years ago: Link 1, and Link 2 .

Any other thoughts?

To quote the queen Victoria: "We are not amused"

Well, the task-oriented idea is cool, but it existed for quite some time now, and what was done for that? Practically nothing. You'd have to have meta data for applications that would explain what the specific one is for etc. The current applications that are, in some sense, trying to make task-oriented approach more real (Gimmie and Lancelot included) are relying only on their own internal list of applications. So, nothing global, and it is possible to be done only for a few predefined categories (for example Documents, Music playing...).

Raptor has taken another approach (if I'm wrong, please do correct me) - they made Task Oriented Menu Editor which is essentially a menu editor in which the user makes categories, chooses applications etc. So, if you want to make a task oriented menu out of kickoff, fire the KMenuEdit up, and start shuffling.

So, from my POV, the main thing missing in implementing the task-oriented paradigm are not the interfaces, but the missing meta data. (and I, for one, have no intention to try again to push anything to FDO for /standardization/, but that's another story)

ivan wrote:To quote the queen Victoria: "We are not amused"

Well, the task-oriented idea is cool, but it existed for quite some time now, and what was done for that?

I don't think that it has.... Every system out there is still application-driven.

So, from my POV, the main thing missing in implementing the task-oriented paradigm are not the interfaces, but the missing meta data. (and I, for one, have no intention to try again to push anything to FDO for /standardization/, but that's another story)

Isn't that what Nepomuk is for?

@Janne
I said that the "idea" existed, not that an implementation exist. In fact, that /was/ the whole point - although the idea had existed for a long time, practically no one started really doing something about it. With the exception of the Sugar interface of OLPC, but that's another story.

In this sense, Nepomuk is /only/ a storage for meta-data. The problem I mentioned above is that the application developers do not provide needed meta-data for their applications. And no, they (we) are not to blame, there is no specification which would allow them to make the needed meta-data.

For example, if you take an application, say QtRecordMyDesktop, by looking at its .desktop file (the only standardized application-related mata-data provider) you can say that it is some kind of Multimedia application. You could also get the mime types it can open, but not whether it is meant for editing or only viewing those files. Then, look at K3B, it (again) is a Multimedia application. The same goes for Amarok... Three completely different applications.

So, can we tell from .desktop, for what the application could be used? The short answer is no, unless we already know what the application is for.

To achieve a real task-oriented work, we would firstly have to define the basic tasks that could be done. And then, all apps should tell what they could be used for. For example Firefox would get web-browser (or something similar) task, Kontact would have mail-client, calendar, ... and then the application launching interfaces, and the rest of the desktop for that matter, would implement the access to those tasks in their own way.

LOL, that crazy GNOME developer they cited actually thought about limiting GNOME to one static panel? This is a great idea - to get people to use KDE.

Seriously, this users-are-idiots-we-must-think-for-them-attitude is the main reason why GNOME is that bad.

From what I'm reading, this doesn't seem to have changed much since I stopped using GNOME - so I'll stick to KDE (which is better anyway:-D), especially as KDE 4 gets into a really good shape now.

Wow, I really hope they don't make gnome "spawn" "activities" as it sees fit. Computers are there to help us, not think for us.

My first is rewrite all the GNOME's code and GTK. GNOME needs so many innovations...