OSX Front End & Keeping the app long running

[jojojames]

1. Is there a way to decouple the frontend from the backend sorting/searching?

I'd like to (at least entertain) writing a native frontend client in obj-c for this instead of using the gtk+ dependency (as well as have to deal with the nonnative look).

A few pointers or a step in the right direction would be helpful!

2. Looks like gpicker closes right after its search and has to start back up on the next search. It'd be better if it stayed long running so that searching for files continues to be quick.

Right now, it looks like the increased speed from finding the file with no lag is offset by waiting for the program to start and stop.

[avsej]

There is simple CLI binary which doesn't depend on GTK

https://github.com/alk/gpicker/blob/master/simple_main.c

It should be a good start. Also you can modify that file ton run continuously instead of reading pattern from arguments

[alk]

You can start looking at simple_main.c. This is something that can be invoked directly.

But if you want your frontend to be responsive, you'll need filtration and loading to be done in separate thread independent from input loop, as happens in main gpicker. Start looking at how filtration is done in main gpicker:

• gtk calls on_entry_changed

• it fetches current filtration string and duplicates it

• calls filter_tree_view, which calls filter_files passing filter_tree_view_tail callback

• filter_files carefully passes work to filtration thread (including handling a case where filter_files is called again before filtration is complete)

• filtration thread picks up the work, does filtration, and then enqueues calling passed callback (filter_tree_view_tail) to mail loop.

• in trampoline function (filtration_idle) we take mutex around access to vector of filtered indexes and then filter_tree_view_tail just copies this data into tree view model.

I think it would be really awesome if you find some way to separate backend and frontend and have protocol that could be used by different frontends to talk to backend. One such area is native emacs lisp client that some people would be interested having.

As for startup costs, well, on GNU/Linux startup and loading list of files is really fast. And whole point was that startup is much faster than 100 ms so we can afford to have separate "picker" program. One exception that I saw is project with many tens of thousands of files. Where I ended up saving list of files into mlocate "database" for faster loading. If that doesn't hold on osex, well maybe implementing native GUI will help with that.

[jojojames]

simple_main.c looks like a really good starting point!

I'll give that a go as time allows.

My main goal is definitely to use it with emacs.

I wonder how fast the search could be if the 'client' part is implemented in elisp (we do have the emacs 25 modules now so that's a thought).