Ruby - Classy Area!

[trogluddite]

Hi All,
Really having fun checking out Ruby, and I though I'd post some WIP - a first attempt at a little library to add some new tools.
The new graphics features look pretty amazing, loads of wonderful scalable vector goodies - but 50% of the trouble with GUI programming is just doing the maths to get the co-ordinates right - there's always something moving back-to-front the first time I fire up a new panel.
So here is my first proper Ruby class - ViewArea

A View Area object can be used in place of an array - because is is a special sub-class of array.
But I have added a smattering of methods that normal arrays don't have - there are methods for splitting an area in two, scaling it, combining and intersecting them, and generating arrays of area cells in grids or radially.

To do it, the new class is in it's own module that doesn't need connecting to anything. The module must be placed in a schematic before any other modules refer to the class. Any other Ruby primitive can see the class because it's in the global namespace - but if it isn't first bit of Ruby code that the interpreter sees at boot up, it'll throw errors. And I'm pretty new to Ruby too, so don't write too many GUI based on these routines just yet - I'm just dipping my toes in the water.

Area Class release 001_1.fsm

(11.96 KiB) Downloaded 1554 times

I hope DSPr can come up with a way around the start-up order thing - adding extra 'libraries' this way would be great as there are no external files to worry about - just plonk a module in from the toolbox like with anything else. Maybe a special 'designated' module that always runs first (like stage(0) in code).
Comments, criticism always welcome.

[TheAudiophileDutchman]

Wow, great stuff!
Just one minor remark: the '0' in the given examples does not flip-flop...

[unkargherth]

WOW !

Very interesting the idea of having a library of basic "classes" ready to use

Very interesting too the rotary areas example... Just one step ahead is the "Dial Menu", alla xbox/psx..

Only if i know more ruby .....

[trogluddite]

Just one minor remark: the '0' in the given examples does not flip-flop...

Ooops, yes, well spotted.
I'll repost some fixes in a day or two for this, and a load of little code speed-ups that I've found while tinkering.

Very interesting the idea of having a library of basic "classes" ready to use

Yes, if the code parsing order thing can be sorted (or we can find a reliable and easy workaround), this would make it insanely easy to develop some easily shared libraries - it will only work for pure Ruby of course (not .dlls etc.), but for those, it totally gets around the problem of needing to package libraries as separate files.

[trogluddite]

Yes, if the code parsing order thing can be sorted (or we can find a reliable and easy workaround)

After getting stuck into the FS3 manual, I've now sussed out that this is actually quite simple.
The scan order is dictated by module order, but in a nested way.
So the first item placed in the schematic when editing is scanned first - then, if it is a module container, the first of its sub-modules - until all the nested components are done. Then onto the next item added of the top level - then object 2's sub-components if there are any - etc. etc.

So the simple way to get class definition to always get interpreted pronto at start up is like this...
As soon as you start a new schematic, place an empty module in there, and call it something obvious, like "ME FIRST".
Then all you need to do at any time is to paste any Ruby 'library primitives' into the "ME FIRST" module, even long after starting the schematic, and the contents of that module will be first in the interpretation queue whenever the schematic is started.
Rubies inside the "ME FIRST" module might need to be re-arranged if they have dependencies on each other - but that's easily solved by simple cutting and pasting the Ruby code all into one long listing in a single primitive.
If you discover that you need some libraries part way through a project, and forgot to put a "ME FIRST" module - no problem - create a new empty schematic, add your "ME FIRST" module, then Select All->Copy->Paste the whole of the old project file into the new one.

Now that I know this, I will definitely press on with making some more add-on classes - Ruby wasn't made with graphics areas, manipulating MIDI data built in, but we can soon customise it with some classes and methods to make these things more user-friendly to deal with.

[MyCo]

I've read this part, too and thought: No!

I don't want to rely on component placement. You'll run into problems just by copy and paste and you can't put the stuff into toolbox unless you group them somehow logically.

I would prefer a more stable method. And I guess the developers of FS could implement this. How about a ruby primitve that is always initialized before the other ruby primitives?
Or something more cooler: an include statement... so you give a Ruby Editor a title "myclass" and in other primitves you call <include "myclass"> at the top?

[trogluddite]

It is certainly not ideal - but at least this way, we can make a start on building some libraries - it's still much more manageable than copy/pasting the actual code itself into every Ruby block, and it should speed loading of schematics if the same definitions aren't being declared in every module.
I was wondering if something akin to the code stage() idea would be a way to do it - no special primitives etc., just a simple Stage(x) statement at the top of code.
That way you could have several levels to make the order even more explicit - and then assume that any primitive without such a statement falls to the regular ordering at the end of the queue.

[rlr]

AFAIK the ruby way to do that would be to define a module and place it in ruby's library folder. Then use require, extend, or include keywords to add the module to your code. I tested that by placing files in Flowstone's ruby/library folder but that didn't work. Pity.

[support]

Placing a file in the FlowStone/ruby/libraries folder should work rlr. Certainly seems to work here.

You have to be careful with require calls if you are changing the file that you're loading. Once you require a file the interpreter will not load it again. It may be that you ran into this when checking (it happened to us too). A way round it is to use 'load' instead of 'require' if you plan to edit the external file whilst using it in a FlowStone session.

[trogluddite]

Require is working OK here on the Rubies that I've tried it with.
Are you getting an error message at the require call? If not, then like support says, it means that the file already loaded on a previous pass through the code - so you will need to re-boot FS if you have edited the Ruby file before any changes take.
I'm using this now in conjunction with the "ME FIRST" idea I posted above, and it is working flawlessly.
Note, you can also use a different folder for your Rubies by adding new folders to the default search path, like so...
$LOAD_PATH << 'folder path'