Source Code for the Service Menu Module plugin
andreb
I am trying to get the source code for the Service Menu Module plugin
which I understand has not been made publicly available yet. I am
trying to fix the -[QSServiceProvider loadServices] method since it
appears from looking at the Debugger stack that it is there where the
nil Exception crash happens in the latest B5X branch (ß56a7 or
internal v3825 or svn r331 I believe) version.
So my question is if anyone knows who the author is for the Service
Menu Module plugin and where or how I can contact this person so that
I may politely ask for the source code.
Thanks for reading.
Cheers!
André
PS.: I also suspect that something in the calling environment has
changed so that this crash originated at all. I am currently running
v3820 (ß56a2 I beleive) and it runs with the Service Menu Module and
the File Tagging plugin.
So far I have been unable by looking at the diffs of svn r331 down to
r200 to find out what caused it. This is most likely because of my
failure to yet establish and understand the design model of all the QS
classes.
PPS. Apologies if this is the wrong forum/group.
Etienne Samson
Source code for most of the plugins is here :
http://code.google.com/p/blacktree-elements-public/source
Feel free to have look around ;-).
Le 25 août 09 à 22:20, andreb a écrit :
andreb
I should have searched for "blacktree" and not for "quicksilver
plugins"
Now I just have to figure out how to load external symbols into gdb so
that I may properly debug it and the methods executed by
QSServiceProvider won't be greyed out in the thread drop-down stack.
Thanks for everything Etienne!
Cheers,
André
Etienne Samson
Configuration/Developer.xcconfig file in QS working copy, then copy
this file under Configuration in your elements-public working copy.
Plugins (some might need a quick configuration check, I made a post
explaining what need to be done to update a plugin) that get built are
then automatically copied inside QS. You can then put some breakpoints
in the plugin files, and start debugging QS from its project, and it
should work.
Pay attention that building QS will update the copy under /Application
(using rsync) ;-).
Etienne.
Le 26 août 09 à 01:02, andreb a écrit :
andreb
the QS application the first time.
I am a bit skewed by the fact that it seems you have to specify the
real QS version all over the place (I am still new to this codebase.
Apologies if something I say is actually not true).
There were hints of a VERSION in the build script phases, there is
CFBundleVersion in Quicksilver-Info.plist and there is a header file
QSDebug.h where VERSION is set again.
(I mean the 38xx format number).
This might fall under the category of being superflous as it isnt used
much right now but wouldn't it be nice to just set the right number in
the plist file and have a shell script with reads CFBundleVersion for
all other instances. This could be easily done by a few lines like the
following:
#------------------- snip ----------------------
# Extract the number associated with the 'CFBundleVersion' key from a
plist file
get_bundle_version() {
if [[ "-h" == ${1} || -z ${1} ]]; then
echo -e "Usage: get_bundle_version <path_to_plist_file>\n
\nExtract the number associated with the 'CFBundleVersion' key from a
plist file."
return 0
elif [[ ! -e ${1} ]]; then
echo -e "Error: the supplied path (${1}) does not point to an
existing file!"
return 1
else
RUBYDOC="require \"rexml/document\"
include REXML
xml = %Q<`plutil -convert xml1 \"${1}\" -o -`>
doc = Document.new xml
cf_bundle_version = 0
doc.elements.each(\"*/*/key\") do |e|
if e.text == \"CFBundleVersion\"
cf_bundle_version = e.next_element.text
end
end
puts cf_bundle_version
"
echo "$RUBYDOC" | /usr/bin/ruby
fi
return 0
}
VERSION=$(get_bundle_version ${QS_SOURCE_ROOT}/PropertyLists/
Quicksilver-Info.plist)
#------------------- snip ----------------------
... or is that what the bltrversion binary is already doing?
Anyway back to the "debugging a plugin" thing:
I have the debugging working now. The trick in the plugin project was
to specify a custom executable as the host which should run the plugin
and set that custom executable to the /Applications/Quicksilver.app
(provided rsync does succeed copying the newly built Quicksilver into /
Applications). Then whenever you try to run or debug the qsplugin it
kickstarts Quicksilver and loads the bundle hopefully with your
breakpoints.
Oh yeah, and as you said, don't forget to copy the Configuration
directory form your Quicksilver project over to the Plugins
repository. When I opened the Xcode project file for the Service Menu
Module plugin the configuration folder was still in the project but
red indicating it physically missing on the disk. It was actually good
this way as I knew where I had to put the copied one.
At first I had troubly with all my breakpoints in the plugin project
turning yellow. The debugging session would ignore them and run right
into the crash. And this while I already had "lazy loading of symbols"
turned off in the Debugging preferences. The solution for this was to
set the deployment target back from 10.5 to 10.4. Fritz Anderson
writes in 'Xcode Unleashed 3':
"Remember the rule: The SDK specifies the maximum features your code
uses, and the deployment target specifies the minimum operating system
your code needs."
When I read this I set it back and that's when things started working.
Well let's see if I can find something out. I liked QS so much I spend
the better part of the last half year to learn Cocoa and Objective-C
just to be able to take a look and try to understand it and maybe even
help. Who knows.
And again, thanks for the help!
Cheers,
André
PS. I am writing this together for others who might want to dabble in
helping with the debugging.
I am sure, Etienne, you as a seasoned veteran already know all this.
Etienne Samson
Le 28 août 09 à 02:10, andreb a écrit :
>
> Yeah luckily I saw the Run Script build phase before I was building
> the QS application the first time.
>
> I am a bit skewed by the fact that it seems you have to specify the
> real QS version all over the place (I am still new to this codebase.
> Apologies if something I say is actually not true).
> There were hints of a VERSION in the build script phases, there is
> CFBundleVersion in Quicksilver-Info.plist and there is a header file
> QSDebug.h where VERSION is set again.
> (I mean the 38xx format number).
Yes, there are many leftovers from alcor's versioning system, which I
partially scrapped in favor of arbitrary version numbers (IIRC I'm
bumping them manually in Info.plist and in QSDebug.h). I tried using
agv (the Apple project versioning tool), but it's useless for projects
that contains more than one target, alas QS has plenty of those.
> This might fall under the category of being superflous as it isnt used
> much right now but wouldn't it be nice to just set the right number in
> the plist file and have a shell script with reads CFBundleVersion for
> all other instances. This could be easily done by a few lines like the
> following:
>
>
--snip--
>
>
> ... or is that what the bltrversion binary is already doing?
The bltrversion binary does something like this, yes.
>
> Anyway back to the "debugging a plugin" thing:
>
> I have the debugging working now. The trick in the plugin project was
> to specify a custom executable as the host which should run the plugin
> and set that custom executable to the /Applications/Quicksilver.app
> (provided rsync does succeed copying the newly built Quicksilver
> into /
> Applications). Then whenever you try to run or debug the qsplugin it
> kickstarts Quicksilver and loads the bundle hopefully with your
> breakpoints.
IIRC, Custom Executables are user-specific (this means that every
developer will have to setup it own, which is lame...). Personally I'm
not adding Custom Execs to plugins, since I usually have QS project
open alongside the plugin, I start debugging from there, since
breakpoints are globally shared, the debugger should stop on the
plugin breakpoints.
> Oh yeah, and as you said, don't forget to copy the Configuration
> directory form your Quicksilver project over to the Plugins
> repository. When I opened the Xcode project file for the Service Menu
> Module plugin the configuration folder was still in the project but
> red indicating it physically missing on the disk. It was actually good
> this way as I knew where I had to put the copied one.
Yes, readding the correct Configuration directory is the first thing
you'll have to do to "port" plugins. Then you should ensure that the
Project/Target Configurations are based on the correct .xcconfig files
(there's a small menu at the bottom-left corner that allows you to do
this. Then you should set the PRODUCT_NAME in the Target to something
valid, and the plugin should be built directly inside your QS copy
(then it'll be rsync-ed when you rebuild QS).
Note: Project-level config files are Debug.xcconfig/Release, and
Target-level are QSPlugIn_Debug.xcconfig/QSPlugIn_Release.xcconfig ;-).
> At first I had troubly with all my breakpoints in the plugin project
> turning yellow. The debugging session would ignore them and run right
> into the crash. And this while I already had "lazy loading of symbols"
> turned off in the Debugging preferences. The solution for this was to
> set the deployment target back from 10.5 to 10.4. Fritz Anderson
> writes in 'Xcode Unleashed 3':
> "Remember the rule: The SDK specifies the maximum features your code
> uses, and the deployment target specifies the minimum operating system
> your code needs."
I'm pretty sure you missed the "based on" step, which should have
taken care of all this stuff. You should do the thing I explained
above both at the project level and the target level.
> When I read this I set it back and that's when things started working.
> Well let's see if I can find something out. I liked QS so much I spend
> the better part of the last half year to learn Cocoa and Objective-C
> just to be able to take a look and try to understand it and maybe even
> help. Who knows.
>
> And again, thanks for the help!
No problem ;-).
(Quick note: I'm having a recurring problem when I start the debugger.
QS *almost* always crash the first time complaining about blah blah
0x4, and it will continue doing so if I restart debugging from Xcode.
I worked-around this by entering "run" (or "r" for short) in the gdb
console (this restart the gdb session).)
Etienne
andreb
> IIRC, Custom Executables are user-specific (this means that every
> developer will have to setup it own, which is lame...). Personally I'm
> not adding Custom Execs to plugins, since I usually have QS project
> open alongside the plugin, I start debugging from there, since
> breakpoints are globally shared, the debugger should stop on the
> plugin breakpoints.
> > Oh yeah, and as you said, don't forget to copy the Configuration
> > directory form your Quicksilver project over to the Plugins
> > repository. When I opened the Xcode project file for the Service Menu
> > Module plugin the configuration folder was still in the project but
> > red indicating it physically missing on the disk. It was actually good
> > this way as I knew where I had to put the copied one.
> Yes, readding the correct Configuration directory is the first thing
> you'll have to do to "port" plugins. Then you should ensure that the
> Project/Target Configurations are based on the correct .xcconfig files
> (there's a small menu at the bottom-left corner that allows you to do
> this. Then you should set the PRODUCT_NAME in the Target to something
> valid, and the plugin should be built directly inside your QS copy
> (then it'll be rsync-ed when you rebuild QS).
>
> Note: Project-level config files are Debug.xcconfig/Release, and
> Target-level are QSPlugIn_Debug.xcconfig/QSPlugIn_Release.xcconfig ;-).
> taken care of all this stuff. You should do the thing I explained
> above both at the project level and the target level.
target I also set the base config via the drop down in the bottom
right corner.
Nice, nice.
>
> (Quick note: I'm having a recurring problem when I start the debugger.
> QS *almost* always crash the first time complaining about blah blah
> 0x4, and it will continue doing so if I restart debugging from Xcode.
> I worked-around this by entering "run" (or "r" for short) in the gdb
> console (this restart the gdb session).)
>
> Etienne
I just found out that you can generate a model diagram of an entire
group (e.g. Code-QuickStepCore) by selecting all header files and
implementation files and doing "Design > Class Model > Quick Model".
This is helping me quite a bit with understanding the interconnections
between classes. In a project as complicated as this it is no small
feat to have a graphical representation of relationship and
inheritance.
Nevertheless, I hope you won't mind if I may ask a question or two if
I cannot come to grips about what a particular class does. I'll keep
it to a minimum I promise.
Right now, I am trying to find out where Icons get loaded/registered
for custom AppleScript Actions (which are loaded from
QSApplicationSupportSubPath(@"Actions/", NO)) since it appears that no
icons will show up for those script files even if you have assigned
custom icons from within the Finder.
Say, is QSIconLoader responsible for all icon loading or do QSActions
have their own icon determining code?
Cheers,
André
Etienne Samson
Le 28 août 09 à 13:06, andreb a écrit :
[snip]
> Nevertheless, I hope you won't mind if I may ask a question or two if
> I cannot come to grips about what a particular class does. I'll keep
> it to a minimum I promise.
No problem, I actually had a few questions to ask when I started
hacking around too ;-).
>
> Right now, I am trying to find out where Icons get loaded/registered
> for custom AppleScript Actions (which are loaded from
> QSApplicationSupportSubPath(@"Actions/", NO)) since it appears that no
> icons will show up for those script files even if you have assigned
> custom icons from within the Finder.
>
> Say, is QSIconLoader responsible for all icon loading or do QSActions
> have their own icon determining code?
I'm pretty sure QSIconLoader is useless on Leopard. Most generic icon
display stuff goes to QuickLook from now on. I guess the particular
thing you're looking for might be around QSObject (Icon) category in
QSObject.m (related to everything that's not a file-system object).
There's also NSImage+QuickLook.m, which is responsible for, hem,
QuickLook previews ;-).
Etienne
Rich Hong
seemed to be crashing at a different part of code. Here's my console
log:
8/29/09 12:18:39 AM Quicksilver[776] An uncaught exception was raised
8/29/09 12:18:39 AM Quicksilver[776] *** -[NSCFArray
insertObject:atIndex:]: attempt to insert nil
8/29/09 12:18:39 AM Quicksilver[776] *** Terminating app due to
uncaught exception 'NSInvalidArgumentException', reason: '*** -
[NSCFArray insertObject:atIndex:]: attempt to insert nil'
*** Call stack at first throw:
(
0 CoreFoundation 0x94ada58a __raiseError + 410
1 libobjc.A.dylib 0x926b0f49
objc_exception_throw + 56
2 CoreFoundation 0x94ada2b8 +[NSException
raise:format:arguments:] + 136
3 CoreFoundation 0x94ada22a +[NSException
raise:format:] + 58
4 Foundation 0x98f0a57a
_NSArrayRaiseInsertNilException + 75
5 Foundation 0x98e5e245 -[NSCFArray
insertObject:atIndex:] + 118
6 Foundation 0x98e5e1c7 -[NSCFArray
addObject:] + 68
7 Services Menu Module 0x1272a28c -[QSServiceActions
actions] + 830
8 Services Menu Module 0x12729b95 +[QSServiceActions
loadServiceActions] + 217
9 Foundation 0x98e70964 -[NSThread main] +
45
10 Foundation 0x98e70914 __NSThread__main__
+ 1499
11 libSystem.B.dylib 0x980dffe1 _pthread_start +
345
12 libSystem.B.dylib 0x980dfe66 thread_start + 34
)
8/29/09 12:18:41 AM com.apple.launchd.peruser.501[309]
([0x0-0xb80b8].com.blacktree.Quicksilver[776]) Job appears to have
crashed: Trace/BPT trap
8/29/09 12:18:44 AM ReportCrash[901] Saved crash report for Quicksilver
[776] version β56a7 (3825) to /Users/rich/Library/Logs/
DiagnosticReports/Quicksilver_2009-08-29-001844_Magic.crash
andreb
though. I am very much a Cocoa beginner and Quicksilver is a large and
complex project.
Besides, I am also only debugging on Leopard. Most likely I won't be
upgrading to Snow Leopard until 10.6.1.
So far I have curiously seen that when I single step through the
debugger when the "-[QSServiceActions actions]" routine does its magic
it seems to work just fine.
This could mean that it maybe a threading issue. If that's the case,
the hopes of me finding it out quickly descend to 0.
I do have one or two questions my self if you don't mind:
Looking at your service menu from any application do you by chance
have an entry somewhere that has "(null)" as its name?
Do you use software like Bellhop (http://www.xendai.com/) or
ThisService (http://wafflesoftware.net/thisservice/) ?
Cheers,
André
Rich Hong
changes depending on which application I am in and if I'm selecting
text or nothing. I don't have any entries that has "(null)" as its
name and I don't have neither of those software installed.
andreb
The way the plugin works is roughly this:
It asks a system component for all applications on your system then it
loops thru everyone of the apps and scans it has a .service bundle
contained in its .app folder structure.
From those findings it begins to build an internal list of service
names. Then it looks through predefined folders (namely ~/Library/
Services, /Library/Services and /System/Library/Services), finds
every .service bundle in those and adds them to the internal list of
service names.
Once it has all service names it needs to loop through all services
from its internal list and find the menu items the service wants to
install. This is because a service can have multiple actions that it
registers.
All this means that the plugin shouldn't be affected by context
switching. Unless the system sets currently hidden service actions to
disabled. But even then this should only matter when QS starts up and
it should simply not add services with disabled actions to its
internal list of service names.
Cheers
André
On 29 Aug., 22:07, Rich Hong <hong.r...@gmail.com> wrote:
> I think Service Menu works differently in Snow Leopard as in the menu
> changes depending on which application I am in and if I'm selecting
> text or nothing. I don't have any entries that has "(null)" as its
> name and I don't have neither of those software installed.
>
Rich Hong
same problem in leopard. It's likely that this is a bug in QS and not
something due to changes in snow leopard. Let me know if there's
anything I can do to help.
Thanks,
disconnected
just wanted to thank you for looking in to this, for us non-
developers. I'm on S.L. and was thrilled to see Quicksilver worked
(first thing i tested after CS3) but i'm having a crash due to
ServiceMenu module, which drives some instinct QS commands for me.
Will be following your progress! good luck
disconnected
of information, trouble shooting a different piece of software, that i
can share.
Snow Leopard includes 64-bit and 32-bit libraries, and by default the
system points everything to the 64-bit libraries. In a graphics
application, snow leopard compatibility was a matter of thinning
quartz vm and telling the application to use S.L.'s 32-bit libraries.
Could the module be suffering from he same trouble; trying to use 64-
bit libraries?
On Aug 29, 7:15 pm, andreb <andre.bergme...@googlemail.com> wrote:
> Thanks for your response.
>
> The way the plugin works is roughly this:
> It asks a system component for all applications on your system then it
> loops thru everyone of the apps and scans it has a .servicebundle
> contained in its .app folder structure.
> From those findings it begins to build an internal list ofservice
> names. Then it looks through predefined folders (namely ~/Library/
> Services, /Library/Services and /System/Library/Services), finds
>
> Once it has allservicenames it needs to loop through all services
> from its internal list and find themenuitems theservicewants to
> install. This is because aservicecan have multiple actions that it
>
> All this means that the plugin shouldn't be affected by context
> it should simply not add services with disabled actions to its
> internal list ofservicenames.
>
> Cheers
>
> André
>
> On 29 Aug., 22:07, Rich Hong <hong.r...@gmail.com> wrote:
>
>
>
> > text or nothing. I don't have any entries that has "(null)" as its
> > name and I don't have neither of those software installed.
>
> > On Sat, Aug 29, 2009 at 2:55 PM, andreb<andre.bergme...@googlemail.com> wrote:
>
> > > Yep, that's the one I am investigating. Don't get your hopes up
> > > though. I am very much a Cocoa beginner and Quicksilver is a large and
> > > complex project.
> > > Besides, I am also only debugging on Leopard. Most likely I won't be
> > > upgrading to Snow Leopard until 10.6.1.
>
> > > So far I have curiously seen that when I single step through the
> > > debugger when the "-[QSServiceActions actions]" routine does its magic
> > > it seems to work just fine.
> > > This could mean that it maybe a threading issue. If that's the case,
> > > the hopes of me finding it out quickly descend to 0.
>
> > > I do have one or two questions my self if you don't mind:
>
> > > Do you use software like Bellhop (http://www.xendai.com/) or
> > > ThisService (http://wafflesoftware.net/thisservice/) ?
>
> > > Cheers,
>
> > > André
>
> > > On 29 Aug., 06:37, Rich Hong <hong.r...@gmail.com> wrote:
> > >> log:
> > >> 8/29/09 12:18:39 AM Quicksilver[776] An uncaught exception was raised
> > >> 8/29/09 12:18:39 AM Quicksilver[776] *** -[NSCFArray
> > >> insertObject:atIndex:]: attempt to insert nil
> > >> 8/29/09 12:18:39 AM Quicksilver[776] *** Terminating app due to
> > >> uncaught exception 'NSInvalidArgumentException', reason: '*** -
> > >> [NSCFArray insertObject:atIndex:]: attempt to insert nil'
> > >> *** Call stack at first throw:
> > >> (
> > >> 0 CoreFoundation 0x94ada58a __raiseError + 410
> > >> 1 libobjc.A.dylib 0x926b0f49
> > >> objc_exception_throw + 56
> > >> 2 CoreFoundation 0x94ada2b8 +[NSException
> > >> raise:format:arguments:] + 136
> > >> 3 CoreFoundation 0x94ada22a +[NSException
> > >> raise:format:] + 58
> > >> 4 Foundation 0x98f0a57a
> > >> _NSArrayRaiseInsertNilException + 75
> > >> 5 Foundation 0x98e5e245 -[NSCFArray
> > >> insertObject:atIndex:] + 118
> > >> 6 Foundation 0x98e5e1c7 -[NSCFArray
> > >> addObject:] + 68
> > >> actions] + 830
> > >> 8 ServicesMenuModule 0x12729b95 +[QSServiceActions
andreb
I'd say no, not really.
It really has to do with some change in Quicksilver's model (as in the
Model-View-Controller paradigm) and I am trying to do my best to gain
understanding of how it all fits together but it's such a tough task
especially for a beginner like me which also only has some evenings
time to work on it.
NightStalker
continues to work on QS should be thanked profusely on behalf of all
non-coders such as myself :)
And furthermore, I think Alcor should be kidnapped, locked in a room
with a Mac, and made to bring everything up to date. ;)
His defection to the Google thingy is a real letdown for those of us
who love QS.
The Google thingy isn't anywhere even close to QS in functionality,
smarts, or that 'X' factor that we all love.
Etienne, Andre, and all the rest of you code-types - a sincere thank
you from me and I'm sure, on behalf of all the non-coders. :)
Keep up the great work :)
Rob McBroom
> Personally, I think that Etienne and Andre and anyone else that
> continues to work on QS should be thanked profusely on behalf of all
> non-coders such as myself :)
Absolutely!
> And furthermore, I think Alcor should be kidnapped, locked in a room
> with a Mac, and made to bring everything up to date. ;)
Not the worst idea. :)
> The Google thingy isn't anywhere even close to QS in functionality,
> smarts, or that 'X' factor that we all love.
I'm keeping an eye on QSB, but so far it doesn't even look like it
will *eventually* replace Quicksilver.
The day I can use QSB to "take the URL of the current page in my
browser and IM it to Joe" (using OmniWeb and Adium, not just Safari
and iChat) and things like that, I'll *consider* using it. But I'd
mush rather a cleaned up Quicksilver.
--
Rob McBroom
<http://www.skurfer.com/>