Meeting on irc.gnome.org:#gtk-devel
Meeting started February 14 2005 16:04 EST (21:04 UTC)

In attendence: 

Manish Singh (yosh),
Matthias Clasen (mclasen),
Federico Mena Quintero (federico),
Sven Neumann (neo)
Anders Carlsson (andersca),
Billy Biggs (vektor)


<mclasen>	so...
<mclasen>	I don't have anything particularly urgent to talk about
<mclasen>	are there things we should discuss ?
<mclasen>	whoever has topics, bring them up...
<neo>	I have a GtkComboBox wish, if you think that
<neo>	's appropriate
<mclasen>	sure
<neo>	there's also a GtkFileChooser performance problem that I would like to discuss with federico
<neo>	if there are no other topics...
<mclasen>	just go ahead
<neo>	let's start on GtkComboBox then
<neo>	I saw that GtkEntryCompletion now has an API to add "actions" to the bottom of the completion popup
<neo>	I'd like to see such a thing being added to GtkComboBox
<andersca>	hasn't it been like that for some time?
<neo>	I think it's new in 2.6 
<mclasen>	neo: the actions have been in GtkEntryCompletion since it entered gtk in 2.4
<neo>	I'd like to easily add "Other..." to a GtkComboBox
<neo>	sure, this can be done using the current API but it is non-trivial to not let the "Other..." item become the selected item
<mclasen>	neo: so you need some way to hook up a custom action for that item, rather than the default "select this" ?
<neo>	so, I'd like to see a somewhat similar API that allows to do this w/o having to remember the last selected item and doing nasty stuff in GtkComboBox::changed
<neo>	something similar to GtkEntryCompletion for API symmetry?
<neo>	I've implemented this in GIMP
<neo>	http://cvs.gimp.org/viewcvs/gimp/app/display/gimpscalecombobox.c?rev=1.7&view=markup
<neo>	but this API is perhaps not suited for GTK+ since it actually uses GtkAction
<mclasen>	are there any other use cases beyond "Other..." ?
<neo>	a set of standard choices, then a separator and "Custom..."
<neo>	owen said that this would have been part of the original design but never got implemented
<mclasen>	oh, I wasn't aware of that
<neo>	a combobox must not have to many items, so it's probably not uncommon to select a set of common ones and to provide access to a larger set of choices
<neo>	it's just an idea, I found it useful and difficult to implement
<neo>	especially since GtkComboBox::changed is RUN_LAST :(
<mclasen>	neo: sounds like a reasonable idea to me. Can you file a bug for that, so that we don't forget it ?
<neo>	sure
<neo>	federico: are you around?
<neo>	does anyone else know about the ugly details inside the file-chooser ?
<federico>	neo: sorry, was distracted
<neo>	np
<neo>	do you or anyone else have other topics that we should discuss first ?
<federico>	neo: is your bug http://bugzilla.gnome.org/show_bug.cgi?id=166601 ?
<neo>	yes, probably
<neo>	you did a workaround that went into 2.4.14
<neo>	which involves waiting 0.5 seconds, then show the dialog and populate it asynchronously
<neo>	right?
<neo>	that works rather well when changing directories from within the file-chooser
Feb 14 16:48:59 -->	jpe (~jpe@pool-141-154-126-130.bos.east.verizon.net) has joined #gtk-devel
<neo>	the problem is that calling gtk_file_chooser_set_uri() seems to block until the tree is populated
<neo>	it would be nice if the file-chooser could just switch to the given folder, test if the file exists() and return, queuing population of the folder
<neo>	at the moment opening a file-chooser is reasonably fast, unless the app calls gtk_file_chooser_set_uri()
<neo>	in the latter case, it can take very long for the dialog to show up
<federico>	it blocks!?
<federico>	the file chooser does this:
<federico>	when you change folders, it:
<federico>	1. starts a 0.5 second timer
<federico>	2. slurps as much of the folder as it can
<federico>	3. if the timer triggers, the model is set on the treeview; subsequent files are added as they come in
<neo>	yes, it does that when you change folders
<federico>	4. if it finishes loading before the timer triggers, the model is set on the treeview
<neo>	change folders from within the file-chooser
<federico>	if the current path is not the same as the path for set_uri(), then it remembers the uri you want, changes folders, and selects the uri when it finishes loading the folder
<neo>	but it does it also do that if the app selects a file using set_uri()
<neo>	oh, it actually does that?
<federico>	yes
<federico>	see gtk_file_chooser_default_select_path()
<mclasen>	I'm gone now, see you later
<neo>	perhaps we need to investigate further
<neo>	this was an idea we had to explain the behaviour that has been reported
<federico>	neo: where does it block?
<neo>	set_uri() needs to check if the file exists
<federico>	I agree; that's a bug --- but is there a situation in which you actually care?
<neo>	so it doesn't wait for the file to show in the list of read files ?
<neo>	sure, the GIMP file-chooser
<federico>	aren't you just doing "select the last file the user used, just for convenience"?
<neo>	if you open the file-chooser from a file that has a filename set, we select that file
<federico>	... and if the file is gone, well, too bad and you'll appear on its parent folder anyway?
<neo>	well, we got bug-reports when we didn't do that
<federico>	neo: what is the exact problmem you are having?
<neo>	jimmac complained that it takes a long time for the gimp file-chooser to open
<neo>	and we are trying to figure out the cause
<federico>	ok, so it *is* the bug I mentioned :)
<federico>	do you know if that futex() shit actually happens due to set_uri()?
<federico>	(jimmac gave me the strace log that is in the bug)
<federico>	neo: I suggested that he use the unix backend for now, and it worked for him
<neo>	OK
<federico>	there's some funkiness going on with gnome-vfs and threads
<neo>	so my guess was wrong
<neo>	I see you are on it
<federico>	the bug he saw was that the file chooser takes much longer to come up if you instantiate it and set_folder than if you set_folder on an existing one
<federico>	(the latter is "it takes a short time to change folders with the gui")
<federico>	I have no idea of why that happens
<federico>	neo: I have a deadline at work that's keeping me busy; would you have time to track this down?
<federico>	it's ugly :(
<neo>	unlikely that I would find time to work myself into this code
<federico>	I can guide you through it :)
<neo>	I just had this idea at what could be causing it. but if you say the problem is in gnome-vfs ...
<federico>	oh?  tell me
<neo>	well, I did, see above
<federico>	ah, ok
<federico>	(I thought you had thought of something else)
<federico>	neo: I'd love to have two things
<federico>	1. a good strace log with timings and threads, both of opening a new file chooser and of setting the path in an existing one
<federico>	(also, possibly, of remapping an existing one like in the gimp)
<federico>	2. a good ltrace to see what calls to gnome-vfs we are doing
<neo>	you don't mind if I add that request to the bug-report, do you?
<federico>	sure, go ahead
<neo>	no need to hurry with this
<neo>	just want to be able to respond to some of the complaints that we got about the new file-chooser
<neo>	we are getting quite a few of them, btw.
<neo>	these people haven't tried gtk+-2.6 yet though
<federico>	jimmac's report is about 2.6
<neo>	yes, but most of the people with usability complaints base these on 2.4
<neo>	sometimes even older 2.4 releases
<neo>	of course a few people won't stop complaining until the entry is back
<federico>	what are your mostfreqs about usablility?
<neo>	lack of entry and long delay before the dialog is displayed
<federico>	what specifically about lack of entry?  "it's not exactly like in 2.2" or other?
<neo>	people say that they don't want to be forced to use the mouse
<federico>	type "*.jpg" and have it filter is already in bugzilla
<neo>	and Ctrl-L they say is undiscoverable
<neo>	being able to filter like that would be cool
<federico>	bullshit; everything is already accessible through the keyboard, and you can get to that dialog from the context menu
<federico>	you can even get to the context menu from the keyboard
<neo>	I don't follow the argumentation that the entry is needed
<neo>	don't tell me
<neo>	yes, it got a lot better in 2.6
<neo>	there's one scenario that is valid
<neo>	if you have a directory with lots of files starting with the same prefix
<federico>	what do you do then?
<neo>	if you use Ctrl-L, you type the first few chars, it shows completion but it doesn't complete in the entry so that one could continue typing
<neo>	Tab used to do that in the old file-selector
<federico>	I'm having trouble visualizing it
<number>.jpg"
<neo>	well, imaging a directory with 1000 rendered images
<federico>	the entry starts empty
<federico>	what then?
<number>.jpg
<vektor>	Type in 'd' and hit tab is faster than typing 'dscn_'.
<neo>	you type "ve" and get a popup that shows you the completion
<vektor>	I have a directory of eclipse builds that all (generally) start with 'eclipse-I200502...'.
<neo>	the entry stays "ve" though
<neo>	it could fill in very-long-and-descriptive-name-
<federico>	huh? that works for me
<neo>	I could imagine that it would work nicely if it did that on Tab
<neo>	did that change in 2.6 also?
<neo>	I didn't try it for a while, just told you about the complaints we get
<yosh>	federico: it fills it in the entry? (*not* the dropdown)
<federico>	type the start of the prefix, and the entry is filled with the longest common prefix.  The LCP minus what you typed is selected.  If you then hit Tab, you get the LCP in the entry, nothing selected, and the cursor at the end of the string
<federico>	like
<federico>	the entry starts empty
<federico>	I type "i"
<neo>	yes, it does, but it doesn't move the cursor after the filled-in chars so that one could type the missing bits
<neo>	just tried it again
<federico>	it displays "i[mg_2]"
<federico>	I then hit tab
<federico>	it displays "img_2|"
<federico>	the | is the blinking cursor
<neo>	ah
<federico>	this is img_2000.jpg, etc.
<neo>	yes, that works
<neo>	it's somewhat annoying that the completion popup is taken down and redisplayed
<tab>
<federico>	yosh: http://bugzilla.gnome.org/show_bug.cgi?id=141153
<federico>	neo: should be simple to fix.  file a bug
<yosh>	federico: the bug doesn't specifically mention spanning multiple directories when doing wildcards
<federico>	yosh: ENOTSUPPORTED
<yosh>	yeah, and I miss it :P
<federico>	that's what gsearchtool is for
<neo>	having those extensions you proposed in the file-chooser would be cool
<yosh>	gsearchtool doesn't help a whole lot when nagivating large image collections in gimp to open
<federico>	yosh: nautilus works pretty well for that
<federico>	or f-spot
<federico>	I'm in love with f-spot
<federico>	like
<federico>	the gimp is a terrible image browser
<federico>	it's a pretty decent image editor, though :)
<yosh>	not browsing images. browsing *filenames* to edit
<federico>	yosh: how do you pick among img_XXXX.jpg?
<federico>	realistically, stuff from digital cameras is the only case where end users will get many similar filenames
<federico>	... for which they should use a photo cataloguing tool, and drag and drop to the gimp to edit them
<yosh>	drag and drop is slower than this, when you actually have a reasonable map in your head where things are
<yosh>	also, say you have a project dir: with "originals", "web", "print" and you want to open different versions of the image. it's faster to have a single view to pick from
<federico>	I'd love to see an actual user test of that case
<federico>	I bet you they will create three shortcuts in their desktop and work from there
<yosh>	shortcuts don't scale to 100s of projects
<federico>	hax0r-gone-graphic-designer doesn't count
<yosh>	having a directory per client, with subdirs of different image uses isn't a hax0r thing
<neo>	I'd like to have "Copy Location" in Nautilus, it would copy the URL of the selected file to the primary selection
<yosh>	middle click paste in the file chooser would be nice, but that's more of a hax0r thing ;)
<neo>	yeah, like middle-click paste in the gimp toolbox ;)
<federico>	yosh: http://bugzilla.gnome.org/show_bug.cgi?id=153212
<yosh>	heh, I figured that be easily to implement
<neo>	I like the solution suggested in the bug report
<neo>	it's less hackish, the user has a chance to understand what's happening
<neo>	should probably change the gimp implementation to use Open Location as well
<federico>	and http://bugzilla.gnome.org/show_bug.cgi?id=145121
<federico>	oooh, it also has a patch now
<neo>	I added PATCH keywords for you to these two reports
<neo>	in case you haven't seen that yet: http://jimmac.musichall.cz/demos/misc/pathetic-performance-in-2.6.avi
<federico>	can't view that
<federico>	I don't have a codec
<neo>	it shows the problem we talked about already 


Meeting ended February 14, 17:25 EST (22:25 UTC)