Meeting on irc.gnome.org:#gtk-devel
Meeting started September 20 2005 16:10 EDT 

In attendence:

Matthias Clasen (mclasen)
Emanuelle Bassi (ebassi)
Kristian Rietveld (kris)


<mclasen>  sorry for being late
<mclasen> hmm, doesn't look like anybody is here anyway...
<mclasen> ebassi: do you know a use case for the non-menu recent widgets, or are they "just because we can" ?
<ebassi> the gimp's document history
<ebassi> and i personally find useful the sidepane in msoffice from the xp release
<ebassi> which could be doable using a widget
<ebassi> anyway, i did them because i could. ;-)
<ebassi> also, gnome-panel could use them
<mclasen> do you agree to move the show-tooltips and the other show-... property to the interface ?
<ebassi> yep, makes sense... I kept them in the menu because we don't have tooltips for the treeview yet
<mclasen> we may have in 2.10. kris ?
<kris> yes, it's on my list
<mclasen> ebassi: the gimp dialog would probably have to be done with the embedded widget, since it uses the gimp dock stuff
<mclasen> did you look at how the recent manager api maps to native win32 api ?
<ebassi^ yes
<ebassi> on win32 they need only the file name/URI
<ebassi> and we could too, if I could bind a program with its launcher
<ebassi> fact is, we really offer something more than win32
<mclasen> I guess things like the app_exec string are problematic on windows. Do we need some more abstract "open" api ?
<ebassi> (they store the MRU in the registry, a key per application)
<ebassi> i thought about it
<ebassi> but the important thing is to store this meta-data for applications other than the application that registers a new recent item, not only using it
<ebassi> example: the panel should know that, if I opened 'text.xml' with gedit
<ebassi> I probably wish it to be opened again with gedit, and not with firefox (default XML handler)
<mclasen^ right. so the app_exec thing is mostly relevant for desktop-wide uses, like in the panel, which are not relevant on win32 anyway
<mclasen> is that the argument ?
<ebassi^ yes.
<mclasen> but there will be some way to associate recent files with the opening app, and e.g. gimp/win32 should be able to set that
<ebassi> in win32 we could store that in a per-application registry key, though. but I'm no registry expert
<ebassi> hypotetically, on win32, GtkRecentManager::add_item (uri) would use the shell functions
<ebassi> to register MRU items
<ebassi> on win32 there would be no need for the RecentData structure
<ebassi> but this would work only on good win32 applications
<mclasen> why is that ?
<ebassi> because I really don't know how a win32 application "knows" its registry key, for instance.
<ebassi> :-(
<ebassi> if it's automagically computed by windows
<ebassi> then it's easy
<mclasen> ah, I hope hans and tor can help us out there
<ebassi> that's what I was counting on. ;-) it's been a loooong time since I've been doing any application development on windows
<mclasen^ might be good to outline your thoughts on how the recent manager stuff would be implemented on win32 and send it to gtk-devel-list, asking for expert opinions
<ebassi^ will do
<mclasen> ah, so I just saved a file in the gimp
<mclasen> now its in the document index
<mclasen> and it has a thumpnail
<ebassi> the thumbnail thing is trickier than an icon
<mclasen> does the recentchooser support that ?
<ebassi> I use the same code of the FileChooser for the MIME icon
<ebassi> but James Cape has the thumbnailer code in libegg
<mclasen> would XBEL allow us to associate a thumbnail with an item, or would we have to add a private attribute for that ?
<ebassi^ the thumbnail should be bound to the URI, and it's another fd.o spec
<mclasen^ ah, that would make sense and would share the thumbnail with nautilus
<ebassi> http://jens.triq.net/thumbnail-spec/index.html
<ebassi> yes
<mclasen> jrb was talking about supporting thumbnails in the file chooser too
<ebassi> thumbnailing uses MD5 to compute an hash of the URI, so we would need the MD5 code too :-)
<ebassi> but, all in all, should be doable without many issues
<mclasen> there are enough copies floating around the stack, just pick one and stick it in glib...
<mclasen> but actually, since as you say, the thumbnail is bound to the URI, we could leave it out for now, and add it later without problems
<halfline> gdm has an md5 implementation in daemon/md5.c
<ebassi> halfline: http://cvs.gnome.org/viewcvs/libegg/libegg/md5/
<mclasen> http://cvs.gnome.org/viewcvs/libgnomeui/libgnomeui/gnome-thumbnail.c has another one
<mclasen> ebassi: will you put your GMarkup XBEL parser in libegg ?
<ebassi^ it's already there. :-)
<ebassi> http://cvs.gnome.org/viewcvs/libegg/libegg/bookmarkfile/
<ebassi> I've added some checks
<ebassi> and now should catch default namespaces
<ebassi> namespaced attribute are tricky, but we could live without them, for an XBEL parser
<ebassi> I double-checked with libxml2
<ebassi> mclasen: (and you were right: DV did rotate when I heard that I was implementing an XBEL parser with GMarkup ;-))
<ebassi> s/I/he/
<mclasen> I saw him rotate
<ebassi> eheheheh
<mclasen> you turned him into a xen hacker :-)
<ebassi> you can tell him I'm sorry... :-)
<ebassi> I'll buy DV a beer at the next GUADEC (or ${WHATEVER_WE_LL_CALL_GUADEC_NEXT_YEAR})
<mclasen> Quick reminder: I plan to work on 2.8.4 next Monday, so if you have fixes for 2.8.x, make them known...


Meeting ended September 20, 16:58 EDT