To view parent comment, click here.
To read all comments associated with this story, please click here.
Really? I wonder why it's called libegg.
Perhaps because these developers don't want to require another dependency for their applications. Perhaps because it may be a lot easier to copy one or two header files or source code into a directory than require users to download a library that has several testing API and functions that's not needed. I'm just guessing.
Really it's not like it's a cutting edge feature that may introduce bugs.
I only know of two applications that support editable toolbars, Epiphany and Evince. If you point me to five more. Then I'll accept the API is indeed widely tested and there's demand for it.
I saw __one__ app that plans to use editable toolbars in the roadmap. EOG.
Are you saying current GTK+/GNOME apps don't?
No, but apparently someone was __comparing__ GNOME to __other__ platforms.
So we agree. But OS X is no better. I use several applications on OS X that don't have editable toolbars and hell isn't freezing over. Besides, who edits toolbars but geeks and power users.
Evince - Thumbnails in file chooser
File Roller - Load and save remote archives
- Extract archive to a remote locations
So the Evince developers have finally convinced themselves to use a feature that has been in GTK+ for over 3 years. How's that GTK+/GNOME's fault.
So the File Roller developers finally convinced themselves to use GNOME-VFS.
Apologies, I don't see your point.
Edited 2007-05-27 05:09
Really? I wonder why it's called libegg.
Well, do you see it on your system? It doesn't exist in the Debian repositories at any rate, and they contain almost every Linux app/library out there.
Perhaps because these developers don't want to require another dependency for their applications.
That's a poor excuse. If this was integrated into GTK properly, it wouldn't be an extra dependency.
Perhaps because it may be a lot easier to copy one or two header files or source code into a directory than require users to download a library that has several testing API and functions that's not needed.
Easier in the short term yes. I've been tempted to do this as well, but it leads to an unmaintainable hell of an application eventually. Instead of delegating responsibility of core functions to separate libraries that can be updated for security and correctness fixes, you now have a snapshot of someone else's code, and need to keep up with developments on that code forever (or risk having vulnerabilities in your app that have been fixed already). The developer of libsexy makes this argument here:
http://www.chipx86.com/blog/?p=205
As for the user, modern package managers make dependencies a non-issue for the user.
Are you saying current GTK+/GNOME apps don't?
Well obviously they don't on the subject of editable toolbars. That's the whole point.
I only know of two applications that support editable toolbars, Epiphany and Evince. If you point me to five more. Then I'll accept the API is indeed widely tested and there's demand for it.
I'm not familiar with the Gnome apps, so I can't name any more from there, but every app on KDE, every app based on the Mozilla platform, most high quality apps on Windows. Obviously the feature is wanted by (a subset) of users. Whether the libegg API is stable I have no idea, but really there is no excuse for it not to be.
Besides, who edits toolbars but geeks and power users.
I agree that most people that want to edit toolbars are what you describe as geeks, but if that's your user base, then you should cater to them. In open source, geeks are the most important users, because they are the most likely to contribute back to the project at some point. While it is certainly beneficial to have the uninterested masses use OSS as well, they are very unlikely to actually contribute anything to improve the applications.
So the Evince developers have finally convinced themselves to use a feature that has been in GTK+ for over 3 years. How's that GTK+/GNOME's fault.
So the File Roller developers finally convinced themselves to use GNOME-VFS.
It is merely an indicator. If these features are in GTK and/or Gnome already, then why aren't people using them from the start? Of course this is merely speculation on my part, but I would guess that something about the GTK file selector and GnomeVFS was so hard to use or poorly done that developers didn't want to use it. Why else would someone have to be convinced to use a feature which on the surface should do nothing but help them? I guess that the feature was incomplete and they had to create their own instead.







Member since:
2005-09-21
Editable toolbar is in a library called libegg. Most developers do not need editable toolbars. And those who do can use libegg.
Except (and correct me if I'm wrong here) libegg doesn't seem to be a separate library at all. People just include the code from it into their projects instead of it being installed separately as a dependency like any other library. So in effect you have everyone copying and pasting the code instead of sharing it. That's a terrible idea for many reasons, which would be clear to you if you write software.
Untested and unpopular APIs should never be placed in a toolkit. APIs should added based popular request and need. And of course, after lots of testing.
Editable toolbars are untested? After 3 years?
Really it's not like it's a cutting edge feature that may introduce bugs. And obviously it is wanted, as shown by the apps in the roadmap intending to add support for it.
Consistency is overrated. I don't see how the absence of editable toolbars make applications "hymn" out of sync.
It's not the most important feature, but it is very nice when all apps on the system have similar interaction methods.
Have you used Windows? Do all Windows application share the same editable toolbars or even have one?
And Windows is the pinnacle of UI design? Windows is probably the last thing we want to look to for how to design GUIs. The Windows GUI toolkit is so poor that every second application feels the need to have their own custom widgets or widget toolkit.
You are making a mountain out of an ant hill.
That's true. Editable toolbars are not overly important, but there are other examples of features that really should be put into the libs, and not reimplemented in each app. From the roadmap:
Evince - Thumbnails in file chooser
File Roller - Load and save remote archives
- Extract archive to a remote locations
Other release notes I've seen for Gnome show similar examples.