Anders Carlsson

What about the proposed $BROWSER spec? gnome's init could have a $BROWSER="$BROWSER:epiphany" and kde's could have the same but konq.

http://www.catb.org/~esr/BROWSER/

To me it would be _great_ if this could become supported.

Because an api/abi-incompatible gnome 3.0 is not in sight, would it nonetheless be possible to deprecate whole libraries?
The lib would still be around but people would be encouraged to move off and older apps would still run.

Rob

The problem with $BROWSER is that you'd need to re-login for changes to take effect, which would be a step backward.

If you want instant apply for the browser setting, you'd need an additional protocol to tell all running applications to change their $BROWSER environment variable. At that point, using an environment variable looks like more trouble than it is worth -- why not just use the browser setting change protocol to pick the browser directly?

Given these flaws, it isn't surprising that desktops haven't started using esr's spec.

GTK and GLib really sucks! These have an ugly function naming. Some questions:What does eggRecent means?What if you like to execute an external program under your control?(glib_spawn or something like that is needed)There is no naming standard, the library is slower than Qt....The Qt library is well designed but the problem is the license.

Thanks for that keen insight, tuxor.

Now, to prove you aren't just trolling, how about pointing out 5 ways in which Qt sucks, too?

Look at me, I'm ignorant...

Regarding Qt, one issue I've met just recently and with no small amount of frustration is that GUI operations cannot be performed except from the main thread. For all I know this may also be true of Gtk+, but I'd be delighted to be told otherwise.

Qt also doesn't work very neatly with language bindings. For example, writing widgets in Python with PyQt works, but it's somewhat ugly. Its easy to leak memory if you're not careful because the Python widget instance and the underlying C++ widget instance aren't as tightly bound together as they could be.

Otherwise ... it's pretty hard for me to come up with ways to fault Qt. I've been really impressed by how much more bearable it makes C++ - especially the string and collection classes (QMap, etc).

I suppose one fault would be that it's impossible or nearly so to use from C - if you care about coding in C. To me, that's not a big problem, but I know it is for others.

Using gconf as a bonobo interface sounds great. Currently one of the main usability bottlenecks of gnome is definitely gconf. While i really like the idea of centralising all advanced/rarely used options into a single interface, the truth is that it's incredibly user-unfriendly. This is what makes gnome less attractive to power users. I believe that it's perfectly possible to provide both ease of use to less demanding users, and power features for power users at the same time. In order to do that, i think that 2 things need to be done.

Gconf needs:
1. a much better name which would accurately describe its purpose.
2. some kind of userfriendly UI abstration above the underlying registry _keys naming/value assigning - powerusers need usabililty, userfriendliness too :)
3. actually, the more i think about it, the more it seems to me that every setting/option should be provided via gconf not just in terms of the actual
passing of settings to a given application, but also in terms of the actual user interface for doing so. The consequence would be a centralised UI, no matter whether you edit your settings in gconf or a given application. And for that, providing a bonobo gconf interface to every application seems like a cool solution to me. The programmer of a given application would be then "forced" to classify all of the application settings/options in terms of importance(basic/essential...advanced/rarely set), design a gconf UI for all of them and provide them via bonobo in hi application. It also seems like a way for advanced features to get back into apps, which a lot of users were complaining about when using gnome 2.x. I really don't think that it would degrade the goal of userfriendliness and ease of use in gnome, quite the opposite.

As for bonobo, it doesn't seem like it's a praised technology, but let me list a few examples where bonobo can be a true usability enhancer:

1. view pdf/ps/doc/.. documents in epiphany

2. same for nautilus, evolution

3. view compressed archives in nautilus

marek: WRT GConf - I think it's pretty clear what GConf is, even for the illiterate; point 2. and 3. are interesting, though. Basically, you're proposing an equivalent of libgnomeprintui for GConf, or a "libgconfui", with a GConf-bound GtkEntry and a GtkCheckButton subclass, for instance. I was thinking in implementing thos in Perl for the Gnome2::Ex namespace, but a C version could be interesting too. The problem is, though, that such widget should fall in a separate library, and that would mean a new dependency. Since GTK+ is not aware of GConf, and libgnome(ui) is going to be stripped out of widgets, where should these GConf-aware widget should go?

Regarding Bonobo and GConf, are there any plans to switch the implementation from CORBA to D-BUS? Since the latter is appointed to become a mainstay of the Linux desktop, and since it does not, reportedly, have the activation/lifecycle complications that ORBit has (or, rather, it has its own), will ORBit be phased out too?

A bit of a related comment to the URI issue WRT to konqueror vs galeon/epiphany... What about a universal mime database (including uri handlers?) that is communicated with via dbus (or some other IPC that is used by both platforms)? Each desktop could have an abstraction layer where programs that can handle certain kinds of files/operations are registered with their own desktop, which in turn register them with the central DB as perferred or secondary handlers with certain configurations (say, gnome can query the central DB for the primary and secondary mp3 playback programs with a hint that it's being run inside the gnome environment). With the abstraction layer in each environment, we could support other architectures that might not have the centralized backend (and just include our own). Using dbus it should allow for realtime changes, and even notifications if something has changed.

What do you guys think?

I think the idea of a preferred browser could be extended to all sorts of other types of applications. Its basically an association of functionality to a command to run. It would be nice if there was a, pardon the term, "registry" where different functionality classes could be registered and applications associated with these. This would be like the existing mime database but more abstract (not associated with a specific file type). Gnome already has the "Preferred Applications" settings, why not extend this to a more generic system. One issue would be in standardizing a set of these functional classes.

Examples of application classes:

"browser" - Web browser
"file-manager" - File manager
"image-editor" - Graphics editor
"image-viewer" - Graphics viewer
"midi-router" - ALSA MIDI sequencer routing manager
"audio-router" - JACK audio routing manager
"audio-mixer" - Sound card mixer control
"text-editor" - Text editor
"audio-editor" - Audio sample editor

This would make it possible to spawn ones favorite sound card mixer application from within another audio related program. Another nice thing would be the option of flagging an application as open once, so if it was already running it would just bring it to the front of the window stack. This feature could also easily be desktop independent.

A thing to remember about MIME media types is that you don't always want to do the same thing with a given type of document. Sometimes you want to view it, sometimes save it, sometimes edit it, sometimes taste it. Er, well. maybe not taste.

This is wandering from "popt" though (improvements here would be very welcome, especially if they can be tied in automatically to filename/argument completion, documentation, configuration of defaults).

As to the ~esr/BROWSER thing, I'm pretty sure I don't want a file called BROWSER on my desktop :-) A traditional Unix way might be a symbolic link in ~/bin/ to the browser of choice I suppose, but that's not so good on other platforms.

The big problem with GNOME is that it is no longer GNOME, i.e., GNU Network Object Model Environment.

We don't have objects, just a collection of pseudo-objects that are barely re-usable. For the sake of a dumb competition (some years ago), the GNOME concept were corrupted. For the hurry to have a working desktop, the development of the components were abandoned, the same for the future of GNOME.

Dont't tell me about Bonobo, gnorba and the others... Nobody use it anymore... So, they are not so re-usable as they claim. And as state before, useless weight.

Take a look, Nautilus uses its own scheme of components, Epiphany and any other "component/object oriented" application have to build its own component set, and they are poorly designed, poorly re-usable.

I don't use KDE, in fact I use GNOME, but the development curve and directions of KDE seems to me a bit more clever and planned.

It sounds to me horrible to plan a binary brake at each major version. It shows that, since the begining, the ideal of component design and reuse were abandoned for a long time.

If the binary brake is already planned for GNOME 3, so why don't start it from scrath? From TRUE component design and reuse? But start it now and use some REAL object orientation, choose one side of the wall and run for it.