[Sugar-devel] more TA plugin changes...

[Walter Bender]

On Thu, Apr 7, 2011 at 3:43 PM, Guillermo Reisch (FING)
<greisch at fing.edu.uy> wrote:
> Hi Walter, hope this help:
>
> I think all the PALETTES need to be defined and all the BLOCKS in thats
> palettes also defined, and set the PALETTE visible/invisible (show/hide) if
> the related core hardware is detected or not. Using that a Turtle Art program
> (.ta) that use blocks in a hide pallet can be loaded without problems and
> children can see the logic of the program.
>
> One wonderful thing is add a button (or menu) to customize the
> visible/invisible pallets so childrens can set visible the pallets that they
> want to use, like in Firefox: View->Toolbars->Customize... , but sugarized
> style. (maybe too much programing work to do that...?)

If we were using pull-down menus (as in the case when launching from
GNOME) this would make sense. Not sure how best to do it within Sugar.
Any suggestions most welcome. But honestly, I think kids just ignore
the palettes they don't use. The issue is more that it can be
intimidating when you first start to see so many palettes.

>
> When a plug-in load it define the palette and all the blocks in that palette
> and set the palette to visible/invisible if core hardware is connected or not.
> After that if the children want to use the pallet then go to View->Toolbars-
>>Customize.. (or some thing like that) and set the pallet visible, and then
> program using this palette [only if implemented the above "customize palettes"
> ; if not then only see the logic of the program] .
>
> With regard to defining the function associated to the block in a hide pallet
> to a NOP function:
> I think is responsibility of the plug-in developer to handle that, and return
> the best thing or simulate the corresponding hardware or do nothing or show an
> error mensage or etc (imagination).

I agree. I just want the blocks defined in some fashion because
otherwise, it is almost impossible to properly preserve the project
structure.

>
> I hope my opinion help

Thanks.

-walter

>
> PD: Sorry for my poor English
>
>
>        Greetings Guillermo Reisch
>        Butia Proyect
>
>
> On Jueves 07 Abril 2011 12:15:33 Walter Bender escribió:
>> In the run up to v107, I am making some more changes (hopefully for
>> the better) to the plugin mechanism for Turtle Art.
>>
>> I just pushed a series of patches that require another reorganization
>> of the code, as follows:
>>
>> Required:
>> (1) each plugin lives in its own subdirectory in ./plugins
>> (2) in that subdirectory is a .py of the same name as the directory
>> (3) in that .py file is defined a class with the same name as the file
>> (but with the first letter capitalized, e.g.,
>> ./plugins/camera_sensor/camera_sensor.py defined a Camera_sensor
>> class, a subclass of plugins.plugin Plugin
>>
>> Optional:
>> (4) If you define your own palette, you may put icons in an icon
>> subdirectory; no need to put them in ./icons anymore. e.g.,
>> ./plugins/camera_sensor/icons/sensoron.svg and
>> ./plugins/camera_sensor/icons/sensoroff.svg
>>
>> Obscure:
>> (5) I am also working on a mechanism where by you can define custom
>> logo code associated with your custom blocks for use in the
>> export-to-logo method.
>>
>> Still to be debugged:
>> (6) I think I introduced a regression in the sensor code in my latest
>> incarnation. Investigating.
>> (7) In a manner similar to the icons, I need to sort out a mechanism
>> for adding skins to your custom blocks.
>>
>> Under discussion:
>> What should we do when a plugin is unavailable, e.g., the Arduino is
>> not present? I think we want to define the blocks regardless, but
>> associate a NOP. This will mean that children can explore their
>> program logic even if they don't have constant access to shared
>> hardware.
>> Thoughts?
>>
>>
>> My apologies for all of these changes, but I want to get it as close
>> to correct as I can before releasing this more broadly. Your feedback
>> to date has been very helpful.
>>
>> regards.
>>
>> -walter
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org