On Tue, 2003-02-04 at 01:49, Havoc Pennington wrote: > Woot, let's stick ourselves with supporting a huge hunk of bloat in > libgnomeui for the next 5 years, duplicating a feature that will be in > a GTK release 3 months later. Even better, apps can randomly select > which API to use, so the UI can be all inconsistent. That will rule. Havoc, your sarcam was totally uncalled for. :-) I am not advocating "bloat" or "duplication". All I can see is that the file selector issue has been never resolved, at least partially because people thought it would have to go into GTK, and the requirements list for having it in GTK was too long for anyone to come up with finished implementation. At this point, either we have to solve the issue in GTK or I'd rather stick it into libgnomeui (thus also taking advantage of all the GNOME features and simplifying the implementation). GTK-only applications are always going to be inconsistent with the rest of the desktop anyways, in a way or another, simply because they don't have access to the full set of features of the other libraries. For example, I am still curious how the icon / MIME type handling and Nautilus integration are going to work in a GTK-only file selector. Anyways, I have just read that Owen is looking into the file selector issue now; which is great. I am looking forward to see what he comes up with; if that works out, all the better. > libgnomeui die die die. One unified API means half the bloat, half the > developer learning curve, no choices for app developers to get wrong, > and your choice of double the features or double the quality. Or 1.5x > of each. Or something. Yes, except when you have to complicate the API in GTK because you can't rely on features that are available in GNOME. > Cut and paste or static link is far preferable; it's some temporary > pain for maintainers, there's no impact there at all after 6 months. Shortening the GTK release cycle and syncing it up with the GNOME release is even better than that. -- Ettore Perazzoli <ettore ximian com>
Attachment:
signature.asc
Description: This is a digitally signed message part