ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Ecaradec's Software

Qatapult

<< < (33/67) > >>

ewemoa:
I hope that whatever choice is made, the app can remain portable

--- End quote ---
That's the issue with relying on activex objects to bind behaviors. Windows has a lot of theses objects preinstalled, but some will need a separate installation. Implementing JSctypes would be best; it's also quite a bit of work because nobody seem to have done and published it on a JScript basis.
-ecaradec (February 23, 2012, 07:08 AM)
--- End quote ---

Sorry to hear it may be a lot of work...I hadn't heard of JSctypes until you mentioned it.  I doubt I'll find anything helpful, but I'm interested in finding out more :)

I don't suppose V8 / node.js is a practical option -- I was surprised to learn that MS provided some aid in the Windows port...

ecaradec:
At least I have a new version ;)

It has been a bit long, there is now a simple skin system. I've designed a simple inline skin as a demo :

So you can try making a few skins with that ;). The position of text and icons inside fields is probably not pixel perfect which means it might change slightly, so you should avoid making tightly ajusted things. Qatapult automatically detect if the ratio W/H is more than 2 then it will do a inline things instead of the big icon thing.

I've also added some variables : rpath, rdirectory and rfilename that resolve links . This is useful for making cmdhere or explore commands on links, as you'd usually do not want to explore the startmenu but the linked location instead.

ecaradec:
I found an interesting guide on how to develop plugins for QS : http://projects.skurfer.com/QuicksilverPlug-inReference.mdown . It goes deeper that the user manual. I found that QS maintains a list of types for objects, it might be nice to have something like that : Currently a catalog in Qatapult can only return one type of data. QS catalogs can return various types : as a example a contact might return a 'phone number','an address', etc.. all of them correctly typed. I could be very nice for declarating actions. That will also maintain types more homogeneous.

@pigeonlips : Very creative use of the sqlite commands within Qatapult. I was on the go for work and didn't really tried your command.

ecaradec:
I had a look at node.js and spotted that it now has a Windows installer. The previous time I had a look it was only available on linux. Node.js would be very nice to include, as it has a lot of librairies. However its purpose is to be a server and it doesn't seems to be easily embeddable : http://stackoverflow.com/questions/5525162/how-to-embed-node-js-interpreter-into-c-c

v8 seems embedable however, I'll have a quick look if I can integrate that.

ewemoa:
I found that QS maintains a list of types for objects, it might be nice to have something like that : Currently a catalog in Qatapult can only return one type of data. QS catalogs can return various types : as a example a contact might return a 'phone number','an address', etc.. all of them correctly typed. I could be very nice for declarating actions. That will also maintain types more homogeneous.
-ecaradec (February 24, 2012, 12:41 PM)
--- End quote ---

I used to think of QS' object/type idea as something like -- each type for a given object representing a different "view" or "perspective".  As an example, some object might have a view as a file on one's disk but another view of it might be the text of the full path to the file.  Is that close to your understanding?


On a related note about examining existing systems...

It used to be that QS' source code was not available and writing plugins involved trying to understand the few examples available, asking on the forums, and trying to catch the main developer on IRC.  I think the main developer felt his source code was very messy and was reluctant to release it for a while -- though he eventually did.  Following a link from the guide you posted about, I learned that QS' source code went through a fair bit of cleaning up in recent years and IIUC it is generally available.

It's probably very obvious, but FWIW, being able to interact with QS and work with its source has some hurdles -- it's written in Objective C and only builds and runs on Mac OS X.

In contrast, the Kupfer launcher seems to me a pretty close emulation of QS and though AFAIK it doesn't run on Windows, its source (Python) is available and can run on *nix -- so can be tested pretty easily via something like Virtualbox.

I've only written one plugin for Kupfer, but I found it much easier than writing plugins for QS.  I believe this has to do with Python being easier to work with for this type of thing compared to Objective C, but I think that's not the only reason.  My impression so far is that historically, Kupfer had the advantage of being able to examine how QS worked and the developer was able to avoid a lot of messiness that crept into QS' evolution.

Well...anyway :)

some kupfer plugin documentationBTW, some plugin documentation for kupfer:

  http://kaizer.se/wiki/kupfer/PluginAPI.html

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version