Sign In/My Account | View Cart  

advertisement

AddThis Social Bookmark Button

Weblog:   The path to unified interaction
Subject:   The lack of abstraction and cooperation
Date:   2004-07-20 16:17:00
From:   mondalaci
I think there are primarily two barriers two overcome:


The lack of abstraction: Every desktop has its own more or less well defined standards on how things should work. Yes, I'm talking about policy. As I see this issue, most developers think in terms of policy, instead of mechanisms.


Another significant problem seems to be the lack of cooperation between desktops to define standard interfaces to doing thigs. It's like every projects wants to create their own universe, while excluding or ignoring others.


I'm irritated by UI inconsistency also. This is an issue we'll need to address in the future.

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • Jono Bacon photo The lack of abstraction and cooperation
    2004-07-22 01:46:01  Jono Bacon | O'Reilly AuthorO'Reilly Blogger [View]

    (I blogged about this at http://www.jonobacon.org/viewcomments.php?id=368)

    Some good feedback on The path to unified interaction has come through, and I was interested to read the comments when it was linked at OSNews. Although I was pretty much expecting this to turn into a KDE vs GNOME flamewar, some people did get the spirit of my article and discussed it where they could.

    One of the comments posted was by modalaci and cited two core barriers that we need to overcome in creating a system such as this:

    • The lack of abstraction: Every desktop has its own more or less well defined standards on how things should work. Yes, I'm talking about policy. As I see this issue, most developers think in terms of policy, instead of mechanisms.

    • Another significant problem seems to be the lack of cooperation between desktops to define standard interfaces to doing thigs. It's like every projects wants to create their own universe, while excluding or ignoring others.

    I agree here. Policy and co-operation are key problems that need to be focused on, but I am confident that there are real and technically viable methods in which these issues can be overcome.

    If we are looking at a technical solution to this problem, we have two core options to allow this kind of integration between the toolkits:

    • Standardise of middleware. To do this you will need to manage the drawing engine, configuration management, resource management (such as dialog boxes and icons) and other common entities. Graphical environments will need to rely on this middleware to be compliant.

    • Build software bridges. Another option is to build a middleware bridge that maps from one system to another. An example of this would be mapping the configuration from the GNOME configuration store to the KDE configuration store. This method strikes me as error prone and would still rely on API stability on both sides of the bridge

    This is an area where freedesktop.org have the chance to play a critical role. If some form of middleware technology is developed to manage these abstracted layers, there is no excuse why the different desktops should not use them. With all honesty though, I can certainly foresee that they will not use them. If there is one thing that annoys me about the free software world, it is that people preach endlessly about not re-inventing the wheel, and then they go and develop yet another framework. Why do we have so much duplication? KParts and Bonobo, DCOP and dbus, GNOME panel and Kicker, aRts and ESD - framework after framework after framework. The only people that care about this are developers, not users. I am all for choice and competition, but we do need at least a modicum of co-operation, and I don't just mean drag and drop.

    I think these problems are critical to the adoption of Linux. I would be interested to hear more thoughts on the subject and less KDE vs GNOME bitching.

Showing messages 1 through 1 of 1.