Re: The future of Gnome?

["Adam C. Powell" <hazelsct mit edu>]

s335328@student.uq.edu.au wrote:

> Hi everyone
>
> From what I can tell, both Linux and Gnome seem to approach things
> very much from a fat-client perspective. Install heaps and heaps of
> software in order to do the simplest of things. Now if I'm some guy on
> a warehouse floor who only uses an inventory application or a personal
> assistant who only uses a word processor, email and a personal
> organiser, what do I need with httpd, etc within linux and then this
> tremendously advanced desktop with ORBs and the like in order to do my
> work?

Okay, this sounds like an installation issue.  Debian, for example, lets
you select the package you wish to install, and then presents a list of
requirements for that package, and splits the GNOME libs into their
separate parts.  So when you select an app to install which only uses
libgnomeui (and the libs it requires), dselect presents a list of
required libs which includes libgnomeui, gtk+1.2, etc. but does *not*
include ORBit or libgnorbagtk or libgtkxmhtml, and one keystroke selects
all of the required libs for download/installation.  If the app uses
ORBit, e.g. the panel, then you must get that too.  But AFAIK you don't
need httpd for anything in GNOME.

> Would it make sense to approach "the desktop" from a new perspective?
> One where the structure of applications is not tied to their
> presentation within a Gnome client running on Linux. I'll try to
> explain what I mean by this. What if I have a PDA, or a Palm V or
> Windows CE or whatever, where the desktop is inherently different to
> the one presented on my PC? Would it make sense for a "Gnome Server"
> to present content to me based on the computing device which I use to
> see it?
>
> Again, would it make sense for a HTML-ised version of the desktop to
> be presented to someone who connects to this "Gnome Server" with
> something like Netscape or the like? Straight away we have solved
> these two people's problems. Rather than the world's largest program
> sitting on their computer so that they can use the world's simplest
> applications, they can use whatever client they see fit, and all they
> need is a browser. They connect to Gnome and it figures out how to
> interpret the applications display requests in a way which fits with
> the way that application is being viewed.

There are two ways to do this currently: have thin clients running an X
server and connecting, so the GNOME apps and libs need only live on one
fat server.  (This is confusing: a "server" in X is the display to which
"client" programs attach, so the client would run the X server and the
fat server would run programs which are X clients.)  The other method
depends on the application design: you have a CORBA-based server app,
and various CORBA clients, such as a command line, CGI for a web server,
Palm GUI, GNOME GUI, etc., and the CORBA interface can be designed to
use vastly lower bandwidth than is necessary for X.  This still requires
an ORB on the client, but ORBit is very light.

> A recent example of this type of thing is displayed in an article
> currently on technet.oracle.com. A company called Indus represents its
> GUIs with XML documents, and then they write interpreters for each
> client so that the GUI can be represented in a way which befits the
> particular client.

If you design your GNOME GUI using Glade, the UI is represented as an
XML document, and the library libglade interprets it to build the full
GNOME GUI for the app.

Question/feature suggestion: are there alternate backends to libglade in
the works, e.g. to build a CGI/HTML GUI?  Or some type of CLI, or
curses-based GUI?  That would be quite cool, though it might require
some kind of dynamic HTML, Javascript or even Java to make the CGI/HTML
work, and some features/widgets might not translate well...

The advantage: you can run a program from any machine with a browser
using relatively bandwidth-light http/html (well, light relative to X
anyway).  The disadvantage: you still need a browser smart enough to
interact with the server, which requires a pretty fat client, though
browsers are pretty ubiquitous these days.

> Such an ideal leads to all sorts of interesting possibilities.
> Immediately within a framework such as this would come the ability to
> "share desktops", something which you need third-party software to do
> now. The complexity of the clients would be decreased by orders of
> magnitude as we install everything on the server and let whatever
> clients access it in whichever way they want. Fridges could display
> Gnome desktops as they begin to plug into the network. And the list
> could go on and on.

Sure, all you need is a framebuffer for the fridge, then add the
framebuffer X server and you're all set to run remotely as described
above.:-)

> Why does the desktop have to be so inherently tied to the way
> Microsoft has done things for so long?

I think the principle is to copy what MS has done right, chuck what
they've done wrong, add stuff they've never thought of, and make it all
lighter, faster, more powerful and more stable. :-)  Are you suggesting
MS has never done anything right, or saying that the degree of copying
has gone too far- that we should have a complete paradigm shift?  If the
first, then you've been blinded by ideology.

But if the second, there are a couple of important things to consider:

   * GNOME is already superior to Windoze because it's built on a
     rock-solid OS family (Unix) and windowing system which allows
     remote graphical applications (X)- something of a paradign shift
     for Windoze users even though it's all 15+ years old!!
   * GNU-Linux-XFree86-GNOME is *vastly* lighter than NT4 or W2K, though
     I can't vouch for speed, or for weight relative Win95/98.  (Anyone
     have relevant info or benchmarks?  Seems benchmarks would be kinda
     hard- unless you just race Excel vs. Gnumeric or some such.)
   * Making things look sorta recognizable to a Windoze user eases the
     transition from the dark side.

Thanks for your input.  I hope my libglade idea bears some fruit so some
of your ideas can be made to work, but I think some of them are already
there.

Zeen,

-Adam      "...the firmament sheweth His handywork" (Ps 19:1)    ///
............................................................__  ///|
Adam "Cold Fusion" Powell IV Firmament Science & Engineering\\\///_|
http://lyre.mit.edu/~powell/ Standing on the Solid State Rock\XX/  |MIGA