This report covers the first two weeks of coding time, May 21 – June 3.
Due to a bevy of personal commitments, any real work and preparation for this summer’s goals coincided with the official start of coding on May 21st.
The first week was spent getting jhbuild to work again for me and setting up this blog (functionally, visually it still needs a lot of work).
I originally intended to start off with something relatively simple: sliding the dash and workspace switcher out of view after a search is initiated and back into view if and only if an application launcher is dragged, as stated on the search design page. But as I got to looking at the current code and the work joost will be doing, I decided to wait until the new internal layout of the overview was a bit more solidified to save myself from repeat work.
So I’ve moved on to tweaking the application search results (not search results from applications, but the app search provider), trying to enforce some order/priority/preference. Referring to the search design page again, the application search provider should be preferring core/default and favorited apps first. Since there is already a system in place for retrieving a list of the favorited apps in JS, I decided start there.
It was fairly simple to get any favorited apps to the front of the displayed results in JS. The main problem is that the JS receives a single array of results from the C (where the search takes place) which is actually composed of prefix (name) matches and substring (description, keyword) matches. So without a way to differentiate them in JS, a substring matched result that happens to be a favorite is put above a prefix match that isn’t. I’m divided on whether or not that is a good thing, but I suppose it has been working reasonably well since I’ve been testing it.
Since the favorited app part was working (somewhat), I moved on to getting a basic list of default apps and sorting them to the front of the results. Currently, I’m just grabbing the default app for each mime type defined in System Settings (there are only 6). I’m unsure if these are the only mime types we should be grabbing defaults for, so that’s a chat with the designers.
At the moment I have what could be called a working proof-of-concept. Default apps are displayed first if they exist anywhere in the results and favorited apps follow. After that the apps are ordered as they are now. I don’t find the sorting to be particularly efficient, but right now it works just to see how the results look when sorted this way.
I need to grab a list of the ‘core’ apps as well and see what it looks like with them sorted to the front. I’m not confident it’s a good idea – I think it may clutter the results with irrelevancies – but I’ll give it a go. My current code is not great and probably doesn’t cover all the desired functionality. So these next couple of weeks will be spent on tightening my implementation once I get better direction from the designers. Then it’s on to dealing with search providers from applications.