re: GladeVCP flexibility
HAL widgets respect the hal data types ( the data is numeric )
GladeVCP has a large number of non Hal widgets,
and these can have strings and lists
because general toolkits know user dialogs are not always numeric
you cant use strings in Hal, thats ok, (cant have strings on pins)
but you cant communicate with users only in numbers,
so the widget tk's have pictures, and text and lists of texts
its tricky moving from pictures to numbers ( from fuzzy to crisp )
i hope the toolkits stay flexible so we're not bound in the future
My first GladeVCP attempt was a widget to choose one of several data
sets by index,
like a row of data in a DB of technology.
I wanted to display a set and let the user "live" adjust them
("live adjustment" doesnt change the stored technology, just allows
experienced operators to tweak some parms in a run )
Reading and writing data files is new territory for an EMC user
interface right now.
Selecting data from a list ("fast","medium","Slow" or
"Spade,Cbore,Cdrill,ReamDry") requires lotsafoo to resolve into a
number.
I dont mind that the result needs to be numeric ( the pin that
communicates to HAL),
but I hope the tools needed to implement such stay available, that we
dont build in limits at this early stage.
I realize GladeVCP is just evolving right now,
new docs are being written
(http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?HalWidgets)
That page shows a radiobutton with text labels like 'Chocolate', or
'Strawberry'...
tho the output pin will be numeric (1 or 2 I'd suppose )
and the email lists mention that labels can be mixed data (%s%0.3f to
resolve to "coreTemp = 0.123k")...
nice stuff :) thanks,
At Timtos 2005 I showed a user interface that overlaid a reticle over
a photo of a Bembo brake,
( a hack of a web page, javascript, svg, and remote running a
heidenhain TNC416 via a serial channel )
the user moved a gui reticle over the picture, to where he wanted to
drill a hole, and clicked near where he wanted the detail.
The coords popped up in a javascript window.
The user could edit the numbers and the JS would write the Gcode
(well, Heidenhain's code ) for the machine.
Conversely, the transparency of the brake photo could overlay a live
camera view,
and the reticles could snap over the programmed positions, so the user
could 'inspect' the work done.
The user had a whole pallete of marks, each made a different hole or
canned detail.
Using this hid all the gcode from the user, he worked visually, just
drag and drop.
thanks for the great work
tom3p
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
