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? >> 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? >> 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? j. ------------------------------------------------------------------------------ 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
