RE: Filechooser and Bookmarks spec
Excessive number of libraries also slows down symbol resolution so APP start up time can be affected. It looks in each library in turn until it finds the symbol it is looking for. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Larsson Sent: Tuesday, February 12, 2008 1:47 AM To: nf2 Cc: gtk-devel-list@gnome.org Subject: Re: Filechooser and Bookmarks spec On Mon, 2008-02-11 at 18:01 +0100, nf2 wrote: > Or perhaps GIO could be split into two *.so libraries . One for > file-management and one for the file chooser shortcuts API, GAppInfo, ... Extra libraries make applications more bloated (at least 4kb nonsharable memory per process using the library), whereas adding unused code to a library hardly affects a process using that library at all. So, its more likely that things will be added to libgio.so rather than in separate libraries. This has been discussed a lot recently, and the likely approach we'll have for future additions of gobject based glib APIs is to put them in libgio.so, but have them be a separate .pc file. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Filechooser and Bookmarks spec
On Mon, 2008-02-11 at 18:01 +0100, nf2 wrote: > Or perhaps GIO could be split into two *.so libraries . One for > file-management and one for the file chooser shortcuts API, GAppInfo, ... Extra libraries make applications more bloated (at least 4kb nonsharable memory per process using the library), whereas adding unused code to a library hardly affects a process using that library at all. So, its more likely that things will be added to libgio.so rather than in separate libraries. This has been discussed a lot recently, and the likely approach we'll have for future additions of gobject based glib APIs is to put them in libgio.so, but have them be a separate .pc file. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Filechooser and Bookmarks spec
On Mon, 2008-02-11 at 18:01 +0100, nf2 wrote: > > there is a patch already for the standard gtk+ filesystem backend at: > > > > http://bugzilla.gnome.org/show_bug.cgi?id=147434 > > > > it will use GBookmarkFile to store the file chooser shortcuts and move > > the shortcuts across from the old internal format. > > Cool! I think it would be good to switch soon, as KDE4 is pretty fresh. last time I checked, the KDE guys said that they had no intention on using/working with the desktop bookmark spec, and they didn't even bothered about giving me a rationale about why or how the spec could have been changed to go in their general direction[1]. oh, well. > >> I think KDE is already using XBEL for this, and GLib also has an XBEL > >> parser. Are there any other obstacles than agreeing on the location and > >> name of such a shared bookmarks file? > >> > > > > when I proposed the desktop bookmarks spec[1], I used > > $HOME/.shortcuts.xbel as the proposed storage file for the file selector > > shortcuts; this should probably be changed to > > $XDG_DATA_DIR/shortcuts.xbel or similar - I have no strong feelings > > towards either solutions. > > > > > > > > I would opt for $XDG_DATA_DIR/shortcuts.xbel. the recent files storage could be moved there as well. > May i forward your mail to the xdg-list? sure. ciao, Emmanuele. +++ [1] http://lists.freedesktop.org/archives/xdg/2006-August/006862.html -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Filechooser and Bookmarks spec
Emmanuele Bassi wrote: > On Mon, 2008-02-11 at 17:01 +0100, nf2 wrote: > > >> I just wanted to ask about your plans regarding using a standardized >> format for file-management bookmarks. >> > > there is a patch already for the standard gtk+ filesystem backend at: > > http://bugzilla.gnome.org/show_bug.cgi?id=147434 > > it will use GBookmarkFile to store the file chooser shortcuts and move > the shortcuts across from the old internal format. Cool! I think it would be good to switch soon, as KDE4 is pretty fresh. > Nautilus and the > gnome-vfs backend would still need to be ported. since the file chooser > in the next gtk+ stable release will probably use the new GIO/GVFS API, > the gnome-vfs port it's probably useless. it might also make sense to > move the file chooser shortcuts API straight into GIO. > Personally i wouldn't make GIO too feature rich. Particularly cause i'm trying to get it into KDE4 as an optional KIO plugin (and they have their own kbookmarks library). Or perhaps GIO could be split into two *.so libraries . One for file-management and one for the file chooser shortcuts API, GAppInfo, ... > >> I think KDE is already using XBEL for this, and GLib also has an XBEL >> parser. Are there any other obstacles than agreeing on the location and >> name of such a shared bookmarks file? >> > > when I proposed the desktop bookmarks spec[1], I used > $HOME/.shortcuts.xbel as the proposed storage file for the file selector > shortcuts; this should probably be changed to > $XDG_DATA_DIR/shortcuts.xbel or similar - I have no strong feelings > towards either solutions. > > > I would opt for $XDG_DATA_DIR/shortcuts.xbel. May i forward your mail to the xdg-list? Thanks, Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Filechooser and Bookmarks spec
On Mon, 2008-02-11 at 17:01 +0100, nf2 wrote: > I just wanted to ask about your plans regarding using a standardized > format for file-management bookmarks. there is a patch already for the standard gtk+ filesystem backend at: http://bugzilla.gnome.org/show_bug.cgi?id=147434 it will use GBookmarkFile to store the file chooser shortcuts and move the shortcuts across from the old internal format. Nautilus and the gnome-vfs backend would still need to be ported. since the file chooser in the next gtk+ stable release will probably use the new GIO/GVFS API, the gnome-vfs port it's probably useless. it might also make sense to move the file chooser shortcuts API straight into GIO. > I think KDE is already using XBEL for this, and GLib also has an XBEL > parser. Are there any other obstacles than agreeing on the location and > name of such a shared bookmarks file? when I proposed the desktop bookmarks spec[1], I used $HOME/.shortcuts.xbel as the proposed storage file for the file selector shortcuts; this should probably be changed to $XDG_DATA_DIR/shortcuts.xbel or similar - I have no strong feelings towards either solutions. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Filechooser and Bookmarks spec
Hi GTK+ developers, I just wanted to ask about your plans regarding using a standardized format for file-management bookmarks. I think KDE is already using XBEL for this, and GLib also has an XBEL parser. Are there any other obstacles than agreeing on the location and name of such a shared bookmarks file? Thanks, Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
