On Thu, Dec 09, 2010 at 01:45:18PM -0600, Thomas Powderly wrote:
> 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
GladeVCP is just 'extension' to Gtk. It's legal to use _any_ Gtk widgets in your
GladeVcp panels. And it's possible to use all properties of base Gtk widgets of
HAL counterparts - like assigning image to HAL Button or to HAL Label. That's
why i think gladevcp is superior to pyvcp - we just provide extension to Gtk
with our domain specific properties and not interfering with base ones. PyVCP
creates it's own interface description language, it's own rules of creating
widgets.
> 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.
It's possible with last Michaels improvement to Combobox. Gtk Combobox consists
of combobox widget and data model bound to it. Data model is not just set of
strings -- it's table of arbitrary number of columns. For HAL Combobox there is
property which tells it from what column to take value for HAL pin. So if you
want to implement 'fast' 'medium' 'slow' combobox with 1.0 0.3. 0.1 values -
create model with string and float columns and fill it with ('fast', 1.0),
('medium', 0.3) and ('slow', 0.1) values. Then set 'column' property to 1 (as
usual columns are counted from 0).
Live adjustment is a bit harder. But still possible. You have to create another
spinbutton/scale and. Then on spinbutton change event adjust value in combobox
model and emit changed signal. On combobox change reload value in that
spinbutton. I understand that it's not straightforward but
provides nice interface to user.
> 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 )
For radiobuttons there is one output pin per radio entry. So for here you'll get
two pins 'gladevcp.Chocolate' and 'gladevcp.Strawberry' pins. Only one of them
is '1'.
> and the email lists mention that labels can be mixed data (%s%0.3f to
> resolve to "coreTemp = 0.123k")...
Label text format receives only one value - taken from HAL pin. So it's illegal
to use format strings with more then one argument. For your example you have to
use something like 'coreTemp = %0.3f' as format string.
> 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.
I think that's not too accurate but very user friendly :) Only concern i see
with live view is where to place camera? Tool will certainly close field of
view. Also i think it's not too hard to implement such interface with EMC now.
But it would be very specific...
Pavel
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
