Animated Knobs - Where are the 'Steps' ?

[trogluddite]

Thanks for the kind words and encouragement.
The way I see it, FS will thrive only if it is easy for newcomers to get to grips with - so anyone sharing anything they learn or build has to be a good thing - the more users that find FS useful, the more it encourages the developers, and FS can go from strength to strength.

Plus, I really enjoy doing it - there's nothing quite like trying to explain something to someone else for really cementing ones own understanding of a new concept.

Re: Graphics paths.
There is one major advantage, though it is not obvious at first glance...

When you draw a shape using the regular 'View.draw...' methods, the whole string of commands to draw the shape has to be executed every single time the screen is redrawn. For a complex shape like an arc with lots of 'ticks', that gets to be quite a few commands for Ruby to deal with. The 'gauge' illustrates this quite well - there's a lot of 'rotation' maths etc. to work out where the 'ticks' have to go, done many times over in a loop.

Using a graphics path, it's possible to define the whole of that shape as a unified whole - and you could put that into a separate routine that only gets called at load-time, or when the shape needs to change.
Once the shape is defined, you then only have do 'view.drawPath(@my_shape)' within the 'draw' routine. That's just a single command to draw the whole shape - and none of the maths to work out the co-ordinates has to be calculated all over again. The drawing of the path is then mostly handled by the GDI graphics engine (fast 'C' code) rather than Ruby.

Having said that, in this case, the advantage would be quite slim - GraphicsPaths can't contain text, so the labels are going to need drawing a piece at a time anyway.

you may only want to have more options without changing the code ruby?
...some will not want to have so many moduls,
then you will implement functions in ruby​​, then use a few RubyEdit to create more complex routine

Just reading back, and spotted this post from Tronic that I hadn't noticed before - and I think it makes a good point that is worth a bit of discussion.

The only way really that we can deal with very complex code is to avoid writing it as one huge chunk of programming, and to be careful to comment/document the code that we put on the forums. Ruby is a good language for this, as it is easy to divide the code into quite short methods, each of which only does a very specific job. (I have seen in some "style guides" the recommendation that a method should not be more than five line of code! - though that is taking things a bit too far, I think!).

A good example of this is in the "gauge" module - rotating a point/line around an axis is a tricksy little bit of maths - so there is a separate "rotation" method for it, as it would be confusing to see that code inside the main 'draw' routine. All that matters when the 'draw' routine is written is that we CAN rotate the graphics, at that point we don't have to worry HOW it is done. It has the advantage too, that you could use the 'rotate' method somewhere else in the code very easily, or even cut/paste it into as a whole into another Ruby block where you needed that function.

Even more importantly, each method should have a good description of what its inputs are (the method parameters), what it does, and what (if any) return values it gives back. It should also be commented if a piece of code requires, for example, an input or output with a particular label and data type. For something complex, a quick example of the usage could be included too. The method then becomes much more like an FS/SM module - you can paste it into a Ruby code box, and without even trying to understand the inner code, you still know how to use it.
In fact, much of the official Ruby language documentation is done exactly like this - the lists of method names and descriptions are auto-generated from comments that the developers put into the source code.

For folks who do want to understand the code, nice compact, well 'targeted' methods will also help - when trying to decipher, for example, a complex maths routine, you don't want to get distracted by chunks of code that are doing something completely unrelated like drawing to the screen.

This is just like assembly - only quite a small number of users know how to program it, but if the module is well labelled and has a good tooltip, you don't need to understand the ASM at all, you can just get on with using it.

It's a shame that the stock examples are not always so good in this respect. Very few have comments, and I have noticed in some cases that they contain code that does absolutely nothing (cut/pasted from other modules, I guess). The programming style is also not consistent with the way that most Ruby programmers lay out their code, making examples from elsewhere confusing to understand just because the formatting and use of brackets doesn't look the same (Ruby is a little bit too flexible with its syntax sometimes!).