On Tue, Feb 5, 2013 at 10:42 PM, johannes hanika <[email protected]> wrote: > On Wed, Feb 6, 2013 at 9:53 AM, Jose Carlos Garcia Sogo > <[email protected]> wrote: >> On Fri, Feb 1, 2013 at 7:42 AM, johannes hanika <[email protected]> wrote: >>> hey, >>> >>> i think i like the direction where this is going. >>> >>> some random thoughts on it: >>> >>> single click feels a little faster, typing + enter still works, and >>> speed seems to be okay on my 10k image db. >> >> It seems also fast to me. Although I don't have such a image db, I >> think that my laptop is slower than your computer. >> >>> >>> now when you click something it somehow feels unexpected that you go >>> up to the top in the list again and the filter changes. maybe we need >>> to do this all the way then and keep the scroll and everything and >>> maintain the selection in the list as well as the filter string in the >>> entry box? >> >> I also had that strange feeling, and it was a bit more strange as I am >> used to double click in the list. About the problem of clicking and >> changing the filter, I did something for the treeview in it. The code >> is around the dt_lib_collect_rule_t typing var. Using it you can >> modify the behaviour depending if the user is typing in the gtkentry, >> where I would expect the matching entries on top, or not. > > did that ever work? i find the concept confusing. still not entirely > clear how you would define how long someone is typing after the last > keypress?
No, it is based on past actions, not current (should I have called it 'typed' instead?) While you type the first char, that var is set to 1. If you click on one entry, it gets back to 0. So at the end, you get the list filtered only when you need it to be, that is when you type to filter. >>> not sure how that would work with the collection serialization >>> required by the recent collect module for example. i guess in first >>> iteration it could just ignore the filter string. also unsure how to >>> handle switching back and forth between multiple collection rules in >>> that case. >>> >>> and how to handle wildcards in the query if all you can do is select >>> one from the list. >> >> Remember that wildcards are almost always used by default. That means >> that typing /home will select all the filmrolls there, without the >> need to type /home% > > no, that holds for the filter and not for the query. see how confusing > that is in one box? Oh, that is misleading, yes. But also having two entries packed together is not going to do any good. >>> so maybe a better idea than that would be actually introducing a >>> second entry box just for the filter and keep the current one as the >>> query box? i guess that has the potential to waste some screen space.. >> >> I don't think that would be clear at all. One entry for quering and >> other for filtering entries is not the best thing. Moreover, we have >> that second box if you click Ctrl-t. Gtk will show you the entry for >> filtering the list > > but that's different. it's an ugly popup, requires more interaction > and will not persist if you click around somewhere else? -- José Carlos García Sogo [email protected] ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ darktable-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-devel
