[Plugin] Plugins help script

TIG

Your method fails to find 'help' files within the Plugins directory itself - only does sub-folders ? Should be easy enough to fix... BUT it is very slow at start up building the list. I still think a dialog solution that builds the list as you want it is better...

azuby

Yes, it is slow. It is a try, not a well to use Plugin. And you are right with the Plugins and Tools menu

It is slow because of many checks for folder content and because I don't want to have empty submenus.

Figure that out:

Plugins : check for contained help files in its subdirectorys *
-- a : check for contained help files in it and its subdirectorys *
--- a1 : check for contained help files in it and its subdirectorys *
---- a11 : check for contained help files in it and its subdirectorys *
--- a2 : check for contained help files in it and its subdirectorys *
-- b : check for contained help files in it and its subdirectorys *

and if it containeds help files, build a submenu.

a11 gets checked 4 times if it contains help files. The more nested the folder structure the more time will be need.

OK, who's next with a solution? [b]Idea[b]: Scan the folders with Dir.glob and create a WebDialog containing links to the help documents in a frameset.

azuby

fredo6

TIG,

There is an error, due to a missing closing brace '}' on line 22.

Otherwise, it seems to work, though I may prefer to have the menu / submenu version (one suggestion would be to build the submenus at first call, rather that systematically at load time).

Thanks a lot

TIG

@unknownuser said:

TIG,

There is an error, due to a missing closing brace '}' on line 22.

Otherwise, it seems to work, though I may prefer to have the menu / submenu version (one suggestion would be to build the submenus at first call, rather that systematically at load time).

Thanks a lot

Fixed it !

TIG

Here's my reworking of Didier's script for a dialog version. It makes an alphanumeric list of any plugins' help files. in the resulting window it displays the path in the top bar etc. It appears in the 'Help' menu, but it is easily changeable to appear in 'Plugins'. It is fast...

Thanks Fredo6 - must've hit a key between testing it and uploading it !!! corrected script re-uploaded !

plugins_help_TIG.rb

azuby

@unknownuser said:

[...] though I may prefer to have the menu / submenu version (one suggestion would be to build the submenus at first call, rather that systematically at load time).
Please excuse, do you mean my version? A "build menu on demand" is possible. I'll do it soon, at this moment my Sketchup processes a really huge modell (250.000 points, 60.000 faces) and isn't usable

azuby

fredo6

Azuby,

In theory, we could imagine that a user would not call a PDF at each Skecthup session, and if he does, after all, he could wait a little bit.
But your macro is fast enough that this fine too. When we have hundreds of PDF and HTML documenting scripts, we could revisit the problem

All this proves that we have a damned good team of Ruby script programmers on this forum, as it took less than 24 hours to get 3 good versions after the idea just popped up.

azuby

For this, the folder structure is also important, because the deeper the structure the slower tht menu building. So we really could do it better (because for the WebDialog frames version we only need ONE folder scan).

azuby

watkins

Dear TIG,

Do you think you could modify your script to include simple text documents? I ask because when I install a plugin which isn't supplied with a help/readme document (more recently a .pdf file), I create my own help/readme document by making a simple text file and then cutting and pasting any explanation posted with the ruby script. I now have quite a few of these 'readme' files and it would be really useful if I could access them from the Help drop-down menu.

Many thanks,
Bob

Jim

I would go a step further and automatically parse out the header text from the script itself.

In fact would go even further and suggest authors adopt RDoc, or a similar embedded documentation scheme. RDoc is pure ruby, can be included in the Plugins folder, and creates nicely formatted documentation.

Edson

didier,

look what happened to your script on mac: there seems to be a problem as it does not see all i have and does not return anything. after this post i there is one on TIG version of the script, that appears to be working.

the script shows in the menu plugins
what it found the result: nothing?

Edson

TIG,

this is what happened to your script on mac: it seems to be working fine.

it shows on the help menu it found 3 rather than 2 items

it returns the path to the info for that plugin, as intended

TIG

@edson said:

TIG,
this is what happened to your script on mac: it seems to be working fine.

[attachment=2:2kcjb1a2]PluginsListB_01.png[/attachment:2kcjb1a2][attachment=1:2kcjb1a2]PluginsListB_02.png[/attachment:2kcjb1a2]

So Edson, you are saying that my version works OK ?

Note: the reason mine lists one more help-file than the other version is that it looks in all of the sub-folders in the Plugins folder and lists any it finds in there too...

TIG

@watkins said:

Dear TIG,

Do you think you could modify your script to include simple text documents? I ask because when I install a plugin which isn't supplied with a help/readme document (more recently a .pdf file), I create my own help/readme document by making a simple text file and then cutting and pasting any explanation posted with the ruby script. I now have quite a few of these 'readme' files and it would be really useful if I could access them from the Help drop-down menu.

Many thanks,
Bob

The problem is that many people add a .txt suffix to the end of the name of any scripts they don't want to have always loaded - they can 'load "script.txt"' through the Ruby Console later if needed. If the help script listed all .txt files these would come up in the list too. The formats that are found and listed are pdf htm html mht and doc - so you could make the txt files into doc ones ? OR you could make your help files end with a suffix .bob and set .bob files always to open with NotePad.exe; then edit the script and add ".bob" to the list of files it finds - easy to see how it works - and off you go...

watkins

Dear TIG,

Many thanks for your helpful suggestions. I will give it a go.

Kind regards,

.bob

watkins

Dear TIG,

I wrote before thinking (not unusual). I simply added "txt" to the list as I almost never load scripts using 'load "script.txt"' through the Ruby Console. This is a quick fix, although I should think about doing what you suggested in the future and loading little used scripts via the Ruby Console.

Kind regards.
.txt

Edson

@tig said:

So Edson, you are saying that my version works OK ?

yes, it seemed to work fine but i was unsure of it since i did not know whether the result i obtained was the one to be expected from the script or not. is it what you expected?

watkins

Dear TIG,

Its me again (bad penny and all that).

Okay, adding .txt works fine, except that for long text files I can only see what will fit on the screen (no vertical scroll bars). I note that .pdf files open with scroll bars and so viewing them is just fine. I also have a lot of .txt files in my plugin folder and so when I try to select a file I can only view/select those that are visible in the text window. It would be useful if your script could be made to work like the Plugin drop-down menu, viz. the window opens and stays open with a single click and then items on the list are accessed (if required) using up/down arrows. This might be a useful feature anyway as users are likely to accumulate lots of .pdf help files with time.

Kind regards,
Bob

TIG

@edson said:

@tig said:

So Edson, you are saying that my version works OK ?

yes, it seemed to work fine but i was unsure of it since i did not know whether the result i obtained was the one to be expected from the script or not. is it what you expected?

Yes - all is OK.

TIG

@watkins said:

Dear TIG,

Its me again (bad penny and all that).

Okay, adding .txt works fine, except that for long text files I can only see what will fit on the screen (no vertical scroll bars). I note that .pdf files open with scroll bars and so viewing them is just fine. I also have a lot of .txt files in my plugin folder and so when I try to select a file I can only view/select those that are visible in the text window. It would be useful if your script could be made to work like the Plugin drop-down menu, viz. the window opens and stays open with a single click and then items on the list are accessed (if required) using up/down arrows. This might be a useful feature anyway as users are likely to accumulate lots of .pdf help files with time.

Kind regards,
Bob

Making the top bar menu list is what takes the time and slows down any model opening - and it's what we are trying to avoid... It's a limitation of the current Ruby dialogs that long lists go off the screen. However if you type the first character of the likely file's name e.g. W for Windowizer_help then the list will jump to that (or at least near that) and scrolling down is then possible... This applies to lots of Ruby dialogs like ones listing layers or colours. It could be done better with a web-dialog... but others have that expertise (and time) - perhaps someone can clobber 'my' getting the list of files into 'their' web-dialog and make it run as a superior form of dialog... before the Ruby dialogs themselves get improved (if ever)...