I have written an article for my O’Reilly Weblog called Remixing how we use the Open Source desktop discussion a design to better integrate software together within the umbrella of a project. With a particular focus on GNOME, the article seeks to present a means of making the desktop more useful when applied within the common ‘project’ setting.
Remixing how we use the Open source desktop
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
James opens a business. He opens up “Business Manager Magic” on his “Magic” desktop and boom it knows what his business does!
I think some the levels of integration he talks about are a great goal; but they sound low on the importance totem pole (lower than things like making all of these applications usable for everyone, making these applications run for years without a crash, and that sort of thing that’s not even that high on the importance totem pole).
I can’t wait for the next segment on the latest IDE ideas. This new IDE will write your simple algorithms for you!
Ok, enough sarcasm
.
I guess my biggest problem with it is the vagueness he’s engendered in the word “project.” What if a project is more complicated than creating communications networks and logging time put into it? What if the computer plays an active role in the project?
Also, the OO.o part sounds like a bit of a dream, seeing as how OO.o can barely get enough hackers to finish 2.0.
Thoughts?
I thought this was pretty much exactly what Nat Friedman’s Dashboard project does. Perhaps Jono missed the memo? Proves the article has a point though.
I think maybe “John” just needs better CRM software. Alot of this stuff can be done out of the box with current CRM software for certain non-OSS platforms. What isn’t can be customized (and it will need to be anyways, businesses are not all alike) to do so.
Or maybe if he had a common database in which to store and link all the information from these disparate programs.
I think if OSS desktops want this kind of high level functionality they ought to do a shared object relational (repeat RELATIONAL, important part) database (that can also be used to store and index legacy files and be searched, navigated, and organized like a file system) that multiple task specific applications can use. This database would also be able to synchronize with external databases and devices such as legacy databases and PDAs.
This database would have a standard schema for objects such as “OO.o text document”, “email”, “appointment”, “phone conversation”, “IM conversation” as well as the ability for developers to extend existing objects and add their own. Then someone can write a “project” object that knows how to bring the relevant data together (might be simple as a virtual folder/live query, might be more advanced with custom shell commands that can act upon project objects).
Build this infrastructure and let the app writers have at it.
MS is calling their’s WinFS. It’s taking them longer than expected to ship it. Do you think you can get one out before they do?
Can’t wait for the Dashboard…greatest idea ever (well, ok, one of few :> )
If you limit yorself to coding, this sounds a bit like Eclipse (and probably other IDE’s out there).
I was thinking that mabey we should rethink the whole development model. Instead of a bunch of project providing applications, which provide a service and a UI, this should be split. UI should be developed as extensions to the desktop and services as plugins.
VCS is good example, the UI of vcs belongs in filemanagers of every kind, so some extendable and integrated way of providing VCS controlls everywhere needed must be invented. The service however could be a subversion plugin, cvs plugin or whatever system you choose to use.
Currently UI projects are developed as front-end applications to a specific service providing back-end. Subversion and TortoiseSVN for example.
With this new model Tortoise would be developed as an UI extension to GNOME and be somewhat service agnostic.
The service plugin would just wrap subversion to provide the correct API.
With regard to the VCS Gui that is very simmilar to the nautilus-vcs project, which was originally a demo for the new (at the time) extension possibilities for nautilus and now supports cvs and (I believe) subversion. If I recall correctly, it implements each VCS in a ‘plugish’ way (as part of the source code), so all you need to do is to make it load the stuff from out of process and your done!