Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin help. Fixes #999 #1364

Merged
merged 5 commits into from Feb 1, 2013
Merged

Plugin help. Fixes #999 #1364

merged 5 commits into from Feb 1, 2013

Conversation

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 1, 2013

Here she is in all her glory

If there's anything wrong - sorry, you're gonna have to fix this yourself.
I'm fed up with how stupidly HTML views were set up for plugins help:

why user a resource:file format instead of just SETTING A BASE URL for the HTML view which is what it's there for.
I refuse to have to set a resource loading delegate for the web and write about 10 lines of code just to load a .css file >:(

OK, rant over :)

@skurfer

This comment has been minimized.

Copy link
Member Author

@skurfer skurfer commented on 7273ce9 Feb 1, 2013

Here's an alternate proposal @pjrobertson. It has your first commit, but the second is different. It turns out there was already a help button defined in QSPreferencesController.m. So I've added an actual button to the view and hooked it to that. It's fixed in the bottom right, which is consistent with its position in the plug-in's info panel (for what that's worth). More importantly, it stays put.

I've set it to be visible only for plug-in prefs (not "main") and to be enabled only for plug-ins that provide extended description.

But that last bit is unreliable, and we won't be able to make the button actually do anything for the same reason. It seems there's no real relationship between a plug-in and it's prefs. That is, QSRegistry makes a note of all the prefs, but it has no idea where they came from. Some plug-ins define a nibBundle with their prefpane, which gives us a way to refer back to the actual plug-in, but not all of them do.

Possible solutions:

  1. Add some ugly hacks to QSRegistry so when it's going through prefpanes, it manually inserts the bundle ID for the plug-in.
  2. Just let the feature be broken for some plug-ins at first and make sure we add the nibBundle in the future.
  3. Maybe there's a cleaner hack for QSRegistry we could do? That is, store the originating bundle ID in all the tables it reads in, not just the one for pref panes.

And honestly, I'm not sure how we will get the button to work. What's sender refer to on the IBAction? The button? Can we add metadata to it or something, so it will know what to target?

This comment has been minimized.

Copy link
Member

@pjrobertson pjrobertson replied Feb 1, 2013

Just FYI:

What's sender refer to on the IBAction? The button?

Yep, it refers to whatever sent the action. Typically its not used, that's why in a lot of (the QS) code you'll see IBAction methods that just send nil like [something sendAction:nil]

pjrobertson and others added 3 commits Feb 1, 2013
…in help

Instead of using resource:file.css (scheme:file syntax) just use sensible base URLs then make all other files load from this relative.
skurfer added a commit that referenced this pull request Feb 1, 2013
@skurfer skurfer merged commit 8ea14c7 into master Feb 1, 2013
@skurfer skurfer deleted the pluginHelp2 branch Feb 1, 2013
@philostein
Copy link
Contributor

@philostein philostein commented Feb 10, 2013

Clicking the '?' works as expected. One thing: hitting ⌘⇧⌥? in Preferences>Preferences brings up the plugin documentation for the one selected in Preferences>Plugins instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.