Submitted by “This presents a high-level overview of the different pieces of the GNOME Platform: libraries to write user interfaces, to integrate with the desktop, to do inter-process communication, the virtual file system, accessibility, multimedia. You should read this to know what tools you can use to perform different things in your GNOME applications.”
I’m right with them up to the point of dbus but then I see what:
Bonobo and CORBA
Service Discovery
XML and Web Services
SOAP
XML Processing
Transforming XML with XSLT
For a desktop? No minimalism there. Could this be the root of dreaded, “bloat”, in Linux desktop I have heard about lately? Is it a sin to force developers to use a common interface as opposed trying to support every protocol/binding out there?
Did not mean to include zeroconf.
For a desktop? No minimalism there. Could this be the root of dreaded, “bloat”, in Linux desktop I have heard about lately? Is it a sin to force developers to use a common interface as opposed trying to support every protocol/binding out there?
That’s just because you are wrong.
libxml/xslt are the best implementation out there, and used by everyone. XML is used everywhere in Gnome.
In Gnome, docs use Docbook for example, which needs XML processing. XML is used by GConf too, or by Glade to make user interfaces.
Is this bloat ? XML is your common interface here, the one you strive for.
It’s the minimalism too.
Service discovery is not mandatory, but Gnome supports it. SOAP is just what is associated with Corba, which is associated to Bonobo.
Well, Bonobo and CORBA in Gnome are not new.
With all the added services, Gnome 2.14 is still faster, so I don’t see the point.
Hardly! These are the most primitive necessities of a network capable and aware environment. It’s a shame many developers do not take advantage of the GNOME libraries in the name of their misguided bloat.
First off, 2, 3 and 4 are all part of the same thing. There are a huge number of applications making use of web-services today, for example: everytime the Amarok music player fetches a piece of album art for you it’s using XML/SOAP etc.
Likewise, 5 and 6 are necessary for 2-4, and are also necessary for half a million other things, as XML is now the standard format for data everywhere! There is a real need for this stuff, you should consider educating yourself some more before evaluating the “bloat” (oh, how I hate that word) of the various desktop environments.
Edited 2006-04-07 17:31
like a lot of folk who’ve shot down your comment, for any desktop there’s going to be alot of additional components necessary to making the whole thing work.
that said, there’s a world of difference between what it takes to make gnome/kde run, and what it takes to make something like icewm chug. I guess it all comes down to what you want out of you destkop/window manager. ie, do you want something that’s going to try to do everything under the desktop sun, or do you want something that’ll manage windows, and provide a basic environment for you to launch X-based (and console via xterms) programs?
personally, I’m tending nowadays to the latter idea. I think it’s more in line with the classic UNIX philosophy (which for thirty years has proven itself a correct one many times) of one program doing one task and doing it right, instead of one program trying to do all tasks, perpetually revolving between mediocrity and failure.
that said, that’s just me, I actually think the heavy *nix desktops have come quite a ways, I’m just not sure it’s what I want anymore.
good stuff to see and something I’d like to see more of. proper documentation is one area I find the kde folk have their stuff in better order. what would be helpful for gnome is to have the equivalent of something like this to map out dependencies :
http://www.kde.org/info/requirements/3.5.php
it also helps in building kde that they split their stuff cleanly into fat tarballs with a clear build order and purpose (though still giving you the ability to exclude components you want with an export DO_NOT_COMPILE=foo). right now if I want to build gnome from source, the only good documentation on how to do it that I know of is the blfs stuff. and no, garnome et al don’t count as I’m looking at it from the perspective of someone who packages for a distro to be distributed to several workstations, not single system in my home.
what would be helpful for gnome is to have the equivalent of something like this to map out dependencies :
http://www.gnome.org/start/2.14/notes/en/rninstallation.html , I don’t know what more you need.
To discover that I needed akode for KDE, I used exactly the same technique as with Gnome, I read the configure output.
Gnome configure is very good, as it stops with an error when an important dependancy is lacking.
it also helps in building kde that they split their stuff cleanly into fat tarballs with a clear build order and purpose (though still giving you the ability to exclude components you want with an export DO_NOT_COMPILE=foo)
Well, double-edged sword. When you need to add a feature (because you added some dependancies, for example), you have to recompile the whole big package.
right now if I want to build gnome from source, the only good documentation on how to do it that I know of is the blfs stuff
This is not true. Especially since BLFS is out of date about Gnome, and if you follow their actual doc to install 2.14, you will miss out lots of things.
I’m looking at it from the perspective of someone who packages for a distro to be distributed to several workstations, not single system in my home
You haven’t been looking hard enough then, as it’s in the release notes of Gnome 2.14.
Try better next time.
that’s a handy list to have, and thanks for pointing to it, that said, come on… with kde you have to compile in this order-> qt, arts. kdelibs, kdebase, anything else out of the 16 tarballs that you want, all of which are clearly marked out as to what they are (kdeaccessibility, kdegraphics, kdenetwork, etc.). kdeaddons should go last. that’s it.
that list however lays out close to 130 packages, no explanation as to what they are with names like libbonobo, gail, ekiga, pessulus, evince, sabyon… (yes somebody like you and me could figure that out by searching around, but kdemultimedia, kdeadmin etc is a heck of lot more intuitive).
I like gnome as an end user, but as a packager I really came to understanding my patrick volkerding dumped it on slackware…
“I like gnome as an end user, but as a packager I really came to understanding my patrick volkerding dumped it on slackware…”
Pat is only one person, besides Slackware has very good GNOME support from Dropline and freerock which offer much more than any other distros do.
I like gnome as an end user, but as a packager I really came to understanding my patrick volkerding dumped it on slackware…
Pat’s decision is very understandable considering the one-person nature of slackware and the existence of superior alternatives to the official gnome package.
Edited 2006-04-08 03:48
For a desktop?
For the associated application development framework.
Bonobo and CORBA
While CORBA might not have been the best choice, a component system is a requirement for an application framework, because it reduces bloat by enabling sharing of large parts of functionality.
XML and Web Services
A lot of services applications or users will want to interact with are now using XML and are implemented as webservices. Google Maps, Wikipedia integration, etc
Definitely something a good application framework should offer instead of forcing every application to decide on their own and end up with multiple libraries in memory that do the same thing
SOAP
Only point from your list that might not be necessary
XML Processing and Transforming XML with XSLT
See XML and Webservices. Availability of XML processing functionality is a must for up-to-date application frameworks, think OpenDocument support, SyncML, etc
While CORBA might not have been the best choice, a component system is a requirement for an application framework, because it reduces bloat by enabling sharing of large parts of functionality.
True, but then again, what are the alternatives? There is SOAP, but like what a GNOME coder said to me, it would be the equivilant of killing a flea with an atom bomb.
There is KDE’s KParts idea, but I’m not too sure whether that would fit into the whole GNOME paradigm.
Then there is always the avenue of ‘develop something new’ which brings a whole new ball of worries along with it – its the equivilant of a person saying, ‘lets re-write the application from scratch!’ after a security bug is found.
From what I understand DBus is losely based on KDE’s system, but abstracted and more flexible; its sad, however, that they haven’t started designing things on GNOME 3.0 yet – outlining radical changes now so that proof of concept models and the like can be developed to show the fesibility of a particular idea.
To cut down on so called bloat, once is the gtk icon cache, it’s been here since 2.6 but distros just dont use it. It seems only now are Ubuntu are going to use it, blame anyone blame your distro.
What I don’t understand is: Why must the icon of the toolbar be so huge? They waste so much space! Its a pitty, that these icons aren’t scalable like in Firefox or Thunderbird. Well, I know, it depends on the Screen and the resolution. I have 15″ with only XGA (1024×768). But I think, there are a lot of user with this or similar configurations.
What do you think about?
Unfortunately there is no GUI for this yet but you can configure this.
I use this line in my ~/.gtkrc-2.0:
gtk-icon-sizes=”panel-menu=18,18:gtk-menu=14,14:gtk-large-toolbar=14,1 4:gtk-small-toolbar=14,14:gtk-button=14,14:gtk-dialog=18,18:gtk-dnd=18 ,18″
~
~
~
~
Thanks a lot! That did it! I guess there are a lot more such hidden features, where users could costomize their desktop. Well, maby I have to root up the GNOME Doku to find all such tricks!