QS cringes

[Etienne Samson]

Hi again !

I'm still totally crying — literally, I'm drowing myself into a salted sea of desperation — when I see some parts of the codebase. I've started rewriting some of the easy parts, but #1363, #1373, #1455, #1492 and #1497 make me think we could use a framework-wide API refresh (that's what I started to do). Also note the use of the "rewrite" word that should ring to Patrick's ears ;-). As you know, I was planning to do a complete rewrite, but it's just *too* hard, because you can't really build a nice QSObject API without a QSLibrarian which does scans, and you can't have catalog scanning without QSObjects. So I plan on cleaning up things by "little" steps (little as in "rewrite a whole subsystem at once, keeping the rest happy, and inserting #warnings for dubious things that can't be changed because they're not part of the subsystem being rewritten"), and tackle the "subsequent" issues at the same time. 

But before I start coding days and night (okay, mostly nights ;-)), let's write the World's Most Advanced Quicksilver Architecture ;-).

- The QSInterface things.

I think we should take a deep, hard look at the things in there. They've been written a few years ago and the system Framework have evolved since. I know some system classes have their own subclasses in there (QSOutlineView, for example, which I've seen show up in some crashes here). There is also the use of bindings — while nice to use and development-easier — are actually dangerous because 1) they link models to views, which in a Model-View-Controller architecture is a big no-no, and 2) have a tendency to cause crashes with stack trace you have no idea what to do with.

Sadly, I'm still a mostly-complete noob at everything AppKit-related, so (for me at least) it doesn't fulfill my time-fun objective ;-).

- QSObject, its categories, and QSObjectHandler.

I don't like those ;-). It feels like an entangled mess of methods to me, all doing different things on different object types. The rewrites I had attempted had real subclasses for each different object type, but then it's harder to transtype objects (eg a local file: URL object to a string or a file object is the "worst" example I had). Maybe we can rely on the object handlers to do the transtyping on request, depending on what the action needs, but then if you add plugins to the mix it becomes hairier because you can't override the handler's transtype method.

Also messy is the fact that, even though an object can contain many different types, they can only have one "primary" type, which mean object consumers have to call `objectForType:` and pray the object source put the corresponding data in there (that's the point that got me on the "subclass" route in the rewrite).

There's also the Pasteboard handling, which IIRC hasn't been updated to the new UTI API, and the UTI rewrite itself.

I also had the hunch that we could maybe interact more closely with the Services system, but in fact that's more related to actions. What would you think of registering with it so that all actions are available anywhere ? That would allow our actions to be used system-wide, as well as in Automator workflows...

- QSLibrarian, QSCatalogEntries and QSObjectSources.

I've started work on that one already in #1601, but there's more I want to do, like the async loading we've discussed, and the UTI changes are likely to impact this one too. About the async loading, this will also require changes to Ranking, because at the moment it's one shot (you search for something and get back an array of objects). Objects that will be added asynchronously won't show up until you search again for the same thing (this can already be seen if you attempt a search at startup while the catalog hasn't finished loading). I'm also completely for either a protocol for QSObjectSource (or a real class if needed) because right now it feels a little free-for-all...

- QSCollection.

I have a branch with that one somewhere, I just need to dust it out and finish it. My main issue is that it touches QSInterface, and it creeps me out ;-).

Regards,

Etienne Samson

--

samson....@gmail.com