[Code] YARC – yet another ruby console
-
OK:
Thoughts:
It seems to work OK for me on XP.
It works independent of the native Sketchup Ruby Console (and let us keep it that way. I still need it running with my personal modified toolbar.) Neither one one affects the other, each has it's own input and output.
Issues:
The left-side of the "code highlight" button is clipped by about 1 pixel.
The default dialog background color is not working for me, inside the "init" callback.
I cut & pasted it outside, just before the callback definition, and now it works.The text size is quite small, I prefer larger.
I believe that the block form of the methods
show
,show_modal
andset_on_close
, are all still bugged on Safari Mac. The blocks never run.
Forset_on_close
, you will need to attach a onunload="window.location=skp:do_on_close@" to the body or html element.
And change:@console_dlg.set_on_close{ save_defaults @@open = false }
to:
@console_dlg.add_action_callback("do_on_close") { |dlg, param| save_defaults @@open = false }
Nit-Pickin':
And, in all the block parameter lists, you are using the instance reference
@console_dlg
, which is weird. Those parameter (var) names are local to each block, and passed in by Sketchup'sskp:
protocol handler.
The instance reference@console_dlg
, is not local to each block, it's shared by the instance context.
I am concerned that the callback will be actually making re-assignments each time a callback is called. Basically when the block gets called, the first parameter makes the assignment@console_dlg = @console_dlg
.
Maybe it does not matter, as long as things go well, and the reference never changes.
The reason for the parameter, is so you can use a local nickname reference,..d
if you wanted ( I usually usedlg
, myself.) -
Still an issue: I do not see the line numbers, when I turn that feature on.
-
Wow, wow, wow, yahooooooooooooooooo1!!!!!!
Jst awesome, that ruby console could save a lot of time
-
Screenshot for the OP please?
-
@dan rathbun said:
And, in all the block parameter lists, you are using the instance reference @console_dlg, which is weird.
Thanks! I haven't yet thought about why it references the dialog but shouldn't be the same instance variable. And thanks for all the other improvements!
@dan rathbun said:
The default dialog background color is not working for me, inside the "init" callback.
I had done that with javascript (and thus in the callback) but then I found the API method that only works before the dialog is displayed.@dan rathbun said:
The left-side of the "code highlight" button is clipped by about 1 pixel.
It didn't occur to me, I will test this later with Windows and with classic/themed.@dan rathbun said:
Still an issue: I do not see the line numbers, when I turn that feature on.
The numbering starts again for each item that you write on the console so I thought it makes only sense for multi-line items (otherwise there is always a 1). I could enable it for single-line items if it causes less confusion.
I was thinking about an autocomplete function. Instead of maintaining a dictionary of keywords, I could do this:
If the user types a module name + something into the console, I send the module name (or nothing) to Ruby, get an array of methods and filter the best matching method name. -
@dan rathbun said:
Updated again, to ver 0.6.2, fixed the location and sizing of the WebDialog. (It now remembers where it the user puts it and it's size.)
Actually it seems.. there are still a few issues with positioning:
The width is remembered OK, both during a session, and on restart.
But there is still a problem with new height being remembered, both during the session and on restart. (It's like the height is hard-coded.)
A new position, is not remembered during the session, but only on the next restart.
(I do know how to solve this on Windows using WinAPI calls, but was hoping to keep this all cross-platform.)
Maybe ThomThom could have a look see?
ADD: Usually for WebDialogs, I just let Sketchup handle remembering the position and size. I am not sure why You (Andreas,) why you were sending the height and width, and calculating bordersize and titlebar size in Ruby, and saving them in instance variables. If you keep all this on the Javascript side, and we can do away with that, then the built-in save and restore in the WebDialog class can solve this issue.
-
I added a screenshot.
@dan rathbun said:
I am not sure why you were sending the height and width, and calculating bordersize and titlebar size in Ruby, and saving them in instance variables.
That was some code that I used for determining the webdialog size from the content (so that I don't have to hardcode it and it can't conflict with different rendering/fonts/zoom settings). It makes sense for static dialogs that a user shouldn't be able to resize, but I see it doesn't make sense here (other than makeing things complicated). I'll see how it works without.
-
@dan rathbun said:
But there is still a problem with new height being remembered, both during the session and on restart. (It's like the height is hard-coded.)
A new position, is not remembered during the session, but only on the next restart.
Yes, it's an annoying WebDialog thing. If you close and reopen the webdialog within a session it doesn't remember the new position or size until the next session.
-
@dan rathbun said:
@dan rathbun said:
Updated again, to ver 0.6.2, fixed the location and sizing of the WebDialog. (It now remembers where it the user puts it and it's size.)
Actually it seems.. there are still a few issues with positioning:
...
Well, because of the state of the API Dictionary.. I can no longer remember what is bugged and what is not!
@unknownuser said:
(http://forums.sketchucation.com/viewtopic.php?f)":2mfzj5er]Haven't checked it out, but on PC the position is stored between sessions, but not within sessions. If you make a webdialog, close it, then open it again it doesn't remember the last position - only the last position from last session.
I haven't noticed because I am using Win32API calls to control where my Console is (.. I guess I gave up on Sketchup doing it. We can only wait so long for the vendor to fix bugs.)
-
There is a way around this issue.. but I hate it. It's not best practice.
You create a NEW instance each time the WD is opened, and abandon the old instance when it's closed.
You'll lose any info and snippet links I think. -
So instances remember it... I see. They read the last position when the WebDialog initializes.
Good point about the Win32API, for my WebDialog wrapper in TT_Lib I can add that. ..though OSX only... creating new instance isn't ideal in many of my cases because I want to preserve the content throughout the session. -
@thomthom said:
... creating new instance isn't ideal in many of my cases because I want to preserve the content throughout the session.
Yepper... you (and Aerilius,) would have to write to a log, and restore it on open.
Actually, Aerilius is already saving the commands... he could just iterate them, and re-eval them to restore the output.
And perhaps the snippets are already saved in a "snippet" directory ?? -
Here's ver 0.6.1 with all the mods below added in for the "ae_Console/Console.rb" and "ae_Console/Console.htm" files.
Updated again, to ver 0.6.2, fixed the location and sizing of the WebDialog.
Updated again to ver 0.6.3 (It REALLY now remembers where it the user puts it and it's size. We let Sketchup do the work here.)
!! Closing the dialog will clear it contents, and wipe out command snippets !!ae_Console_0_6_3.rbz
ae_Console_0_6_3.zip
Add class variables to hold the various singleton instance objects:
@@console_dlg = nil @@command = nil @@topmenu = nil @@menuitem = nil
(see bottom of post...)
The
open
instance method should be namedcreate
and return a reference to the newly createdUI::WebDialog
instance:(OSX)? @console_dlg.show_modal ; @console_dlg.show return @console_dlg end
Then the instance
open
method should be:def open dlg = @console_dlg if OSX dlg.visible? ? dlg.bring_to_front() ; dlg.show_modal() else # WIN dlg.visible? ? dlg.bring_to_front() ; dlg.show() end end
And the class method
AE::Console.open()
def self.open(instance) if @@console_dlg.nil? # nil if not yet instanced. @@console_dlg = instance.method(;create).call # also opens it. else # The WebDialog instance exists, just open it. instance.open() end end
Lastly, I always suggest putting the "Run Once" block inside your namespace.
(at the bottom of the file...) and thefile_loaded()
inside that block to prevent multiple entries in the$loaded_files
array.
(Actually,file_loaded()
will not insert duplicates, but .. why call a method if you don't have to?)unless file_loaded?(File.basename(__FILE__)) $old_stdout = $stdout if !$old_stdout # in case you want to turn off traces $stdout = AE;;Console.new $stderr = $stdout # trap error displays as well @@command = UI;;Command.new("Ruby Console (WebDialog)"){ self.open($stdout) } # Menu @@topmenu = UI.menu("Window") @@menuitem = @@topmenu.add_item(@@command) file_loaded(File.basename(__FILE__)) end end # class Console end # module AE
Then you can (your choice,) provide class getter methods for singleton objects, that make sense. Ie, references that some other organizer script, might need a handle to:
# Provide a handle to the command, in case # some other script wants to add it to a toolbar. # def self.command @@command end
-
Updated again to ver 0.6.3
(It REALLY now remembers where it the user puts it and it's size. We let Sketchup do the work here.)
!! Closing the dialog will clear it contents, and wipe out command snippets !!
So use minimize, instead of close, if you wish to keep these things.See second post for d/l
-
@dan rathbun said:
> unless file_loaded?(File.basename(__FILE__)) > ... > file_loaded(File.basename(__FILE__)) >
I recommend putting the whole
__FILE__
instead of aFile.basename(__FILE__)
. That way you would eliminate same filenames that are in different folders.EX:
Plugins/Anton_Lib/core.rbthat statement would be true
` unless file_loaded?(File.basename(FILE))...
file_loaded(File.basename(FILE))end`
Plugins/TT_Lib/core.rbthat statement would be false, preventing vital parts to be called
` unless file_loaded?(File.basename(FILE))...
file_loaded(File.basename(FILE))end` -
@anton_s said:
I recommend putting the whole FILE instead of a File.basename(FILE). That way you would eliminate same filenames that are in different folders.
+1
I have adopted the same pattern myself. Just using the filename is not a unique ID - full path is. It doesn't even have to be a filename you feed file_loaded - just any unique string.
-
Yup we've talked a bit about this before. (I didn't change what he had in his code. I thot it might be too far off topic.)
I've posted a new topic on this subject:
[ Code ] custom file_loaded() and file_loaded?()@Anton_S: I sent you a personal edition via PM, check your inbox.
-
yep, sure
-
@anton_s said:
I recommend putting the whole
__FILE__
That's very reasonable. I'll fix it.
I just wanted to let you all know that I'm working on improvements (esp. the snippets should have been saved over sessions) but I'm a bit busy at the moment. I'll publish a next version when I'm ready.
Advertisement