Status update
Etienne Samson
As you might have noticed, I've pulled some changes I had done to the
trunk. I'm currently trying to port as much of the changes I made to
the branch as I can, and things are likely to break a little. I'm
currently cleaning up the low-level model stuff (the QSBasicObject
class hierarchy), then as soon as I have a working bug-free
implementation of QSCommand, I'll move on to reworking
QSCommandInterfaceController.
I can provide you with a quick list of what needs to be done, in case
some of you with free time and a need for a coding frenzy can help ;-)
(You can also give your thoughts about those things, I'm all ears open
to any suggestions) :
- Cleanup the low-level model. This is the thing I'm currently
tackling. This is mostly taken from stuff I changed to the branch, so
it's pretty straight-forward. Still left to handle: localization.
- Use Sparkle for updates. This requires extensive changes to
QSUpdateController, which actually does all the heavy lifting by hand.
You'll need some knowledge of how Sparkle works, because it's likely
the default Sparkle behavior will not be what's needed for QS (the
update pop-up window).
It should allow individual plugins to be updated, and some changes to
the Blocks framework is likely (maybe just a link to this specific
plugin appcast, added in the Info.plist file of the plugin), as well
as the main application.
- Make stuff KVO-compliant. I'm pretty sure I'll tackle this while
reworking the low-level model, because it's likely to be necessary for
stuff like ranking (so that the ranker know its object ranked
properties have been changed), but if someone wants to take a look at
it while I fix QSAction & QSCommand, please do.
- The big view detanglement project (™ ;-)). This is complicated
stuff, and I'm kinda more of a model/controller developer than a view
one ;-).
Right now, the view part of QS looks a little complicated.
QSCommandController is the oldest one, but it has been superseded in
trunk by QSCommandInterfaceController. My goal right now is to replace
its 3 QSObject ivars with one mighty QSCommand ivar, which will
contain. That means that to be MVC compliant, we need a QSCommandView
(actually QSCommandInterfaceController), a QSCommandController (which
will update the view when the object changes, or the user types
stuff), a QSCommandInterface (which will wrap all those, and be
subclassable, to allow for different interfaces). Also in need of
cleanup is QSObjectView hierarchy (subclasses are QSSearchObjectView
(the one which displays a result list when you type things), and
QSCollectingSearchObjectView (the one that's used for comma-trick)).
This really makes for a lot of cleanup, especially since most of the
code there predates cool Cocoa stuff like KVC/KVO.
- I'm really wondering about the multi-typing abilities of QSObject/
QSBasicObject. Right now, nothing prevents you from creating a
QSObject representing a file, and merging (except I killed object
merging recently) it with an object representing *anything* else (I'm
having difficulties finding an example ;-), say a screen proxy). I
don't like that. What I'm planning for this is to add some transmuting
capabilities (maybe reusing -objectForType:), which could be used to
know if an object can be converted to a specific type.
Example: the file I was talking about can be converted to :
- an URL
- a process (if it points to an application, and this application is
running)
- a string (the file path)
...
Most objects would be convertible to a string type, but I'm
considering with a lot of interest the Detector stuff new in Leopard,
for converting the other way around ;-). The small issue I see with
that, is that it's likely I'll need to create a subclass for each
"atomic" type (File, URL, Number, Contact, Email, ...), and I don't
know how well it will turn.
- Not really code-related, but I switched to git, and I'm loving it !
(cause: svk killed my repositories more than a few times). If it
interests enough people, I can make a mirror of Alchemy on github, to
facilitate code sharing.
- Nicholas, I want to know if I can freely replicate the Apache
Licence on the files that are missing licence info. I've added it to
the few files I created in my last commits, but I would like to make
all those changes in one sweet blow, and never go back.
Etienne
Andrew Eberbach
Thanks for the update. What are your thoughts on the plugin architecture and existing defects? I see there is a huge refactoring going on, but that could theoretically break things. Are these changesgoing to affect existing components?
Thanks,
andrew
Etienne Samson
Sorry for the extended silence. I'm hard at work at the moment, so I
don't really have time to devote to QS.
About the refactoring, I do agree some things are likely to end up
broken, but as the plugin system changed, we're already running an
(almost) incompatible QS (almost in the sense that porting a plugin
from v1 to v2 requires rewriting the QSRegistration key in Info.plist
as an element.xml file for Blocks, the plugin framework).
About existing components, QS code really need a little shake-up,
since IIRC it dates back from around 10.1, it doesn't use stuff like
CoreData (which would be IMHO a big win for stuff like the Catalog (=
startup time, ranking time), and most of the cool stuff that was added
since then.
The problem I'm having with the API right now is that there is no
obvious way of creating some stuff (or, stated differently, there are
multiple ways of achieving the same thing. The most obvious example I
have is QSAction, which can be created from a dictionary
(QSRegistration > QSAction, from a plain -alloc/-init (QSRegistration
> QSActionProvider, then it uses the mechanisms there to populate its
action list), or by setting it's various needed stuff (then there's no
easy list of "needed stuff").
Then again from QSAction, it can actually be running a script file
under AppSupport/QS/Scripts, or direct ObjC-messaging to whatever it
was told, or ask it's provider to do something. I'm a little baffled
at this complexity of one of QS most "basic" classes. So, rework
underway ;-). I think I'll turn QSAction into a vanilla class that
does nothing, then provide subclasses like QSFileAction (for scripts),
and some others.
Le 13 juin 09 à 20:49, Andrew Eberbach a écrit :