LabVIEW from a modern toolkit GUI builder's point of view

[Wolfgang Draxinger]

Well, I think LabVIEW is damn cool... as long as, well, as it
comes to modern GUI design.

However now I'm stuck at a point, which I'd have done with a good
toolkit like GTK, wxWidgets or Qt in no time (as this is
integral part of these toolkits): That is automatical placement
of widgets and i18n.

I started using LabVIEW 2 weeks ago and the very first you do is
placing Wigets on the frontpanel. The Problem is just, that
positioning those widgets is done absolutely. The lack of
structuring containers (in GTK called boxes, grids, panels,
viewports, etc.) makes it extremely difficult to build
applications that can scale to any screen resolution. Also the
colors and the appearance of the widgets is fixed, practically
hardcoded into the VI. Moreover the whole GUI of an VI is fixed
and cannot be changed in the final application.

This is my wish for the next version of LabVIEW: Decoupling of
the GUI and the Code in the way it is possible with e.g. GTK and
it's XML GUI loader. Using this you attach the outputed data to
some generic widget reference compatible to the data and give it
an Id. Then you load the GUI stored in an XML and the backend
couples the data with the GUI. In case you need a custom control
you make this the child of an generic panel widget, carrying the
Id for the XML representation et voila.

Appearance is controled by an application independent theming
engine on which ever application can request it's own theme.

Moreover i18n is what I miss at LabVIEW. The program I'm
currently doing will be used by a lot of students from all over
europe, thus the program should at least have a german, english,
and french UI. However in LabVIEW every language requires to put
it into an own VI (or fiddling with Property Nodes). In e.g. GTK
(again) i18n is an integral part. For most stock objects
(standard buttons and menu entries) there are ready made
translations. For all the application specific stuff strings get
automatically translated by putting i18n files for the different
locates into the app's directory and setting the LC_LANG
envrionment variable to that locales name: Voila the whole app
got a fully translated interface. Best thing is, that GTK
features the Pango component which takes care of proper text
direction rendering, automatically adjusting the GUI if
neccesary. (e.g. in RTL languages like hebrew labels are at the
opposite side as in LTR languages like english)

In one sentence: It's the methods of modern GUI design that I
miss from LabVIEW. GUIs in LabVIEW are still build in the way as
it was 10 years ago. Nobody elso does it this way anymore, only
LabVIEW AFAIK. So this is my wishlist for one of the next
versions:

- decoupling of GUI and code
- GUI design using hierarical structuring elements (have a look
at GTK, that Tk is just great)
- i18n

Wolfgang Draxinger
--

[angdis]

I think that NI has done a great job at evolving labview while
maintaining its strongest feature: simplicity. Simplicity increases the
speed of development.

Java and windows developers are flabbergasted at how fast labview
developers can put together a GUI that does the job. It may be the case
the labview is not as deeply general as other tools, but it solves the
problems it is intended to solve very well.

Things like layout managers and totally de-coupled GUI are very nice
for people developing apps to run on many different machines, and of
course, you get generality. The problem is that it complicates
development. Although there are some features of labview that address
your concerns, I agree that it would be nice to see things like a
gridbag layout manager for labview front panels. I only hope that such
a change would be an additional feature that is optional to the
developer rather than a change in the simple way of doing things.

[Wolfgang Draxinger]

Post by angdis
I think that NI has done a great job at evolving labview while
maintaining its strongest feature: simplicity. Simplicity
increases the speed of development.

When I was building the GUI for my current project the most time
was spent on clearly aligning the single widget. The only tools
that there are as an aid are align to edges, center, same
size/gap and vertical/horizontal compress.

Actually prior to start putting together the GUI of my current
(and first) LabVIEW project I used GTK's GUI builder "glade" to
design the gui. Then I set the size of the main frame to 990x750
and dumped the dimensions of the resulting layout into a text
file. Then I used LabVIEW's "set size and position" tool to
enter for each corresponding widget the values I got with glade.

Any other approach seemed to annoying to me.

Post by angdis
Things like layout managers and totally de-coupled GUI are very
nice for people developing apps to run on many different
machines,

Isn't that the idea behind LabVIEW? I was forced to use LabVIEW
by my employee, as they said it, due to it's high portability of
measurement applications. I must admit, that e.g. using the
RS232 requires no changes to the LabVIEW "code", while a native
compiled app for Linux needs other API calls than for Win32 - of
course there are wrapper libraries.

Post by angdis
and of course, you get generality. The problem is
that it complicates development.

I don't think so. Did you ever use a GUI builder like glade or
qtdesigner? They require you to think about the aimed GUI
purpose in the first place, but that is a _good_ thing. Also
guidelines for good GUI design exists, and most GUI builders
come with ready to use template for all sorts of GUIs.
qtdesigner eg. comes with templates for:

- Application Window (complete with free user configurable menu-
and toolbar)
- Wizards (used for setting up things step by step)
- Dialogs
- Preferences setup windows
- Custom Widgets
etc.

Post by angdis
Although there are some
features of labview that address your concerns,

I know. File->VI Properties->Window->Resize Contents...
But this will scale everything, even if it doesn't make sense.
Users enlarge windows to get more workspace, not for a larger
view. Also chaning font sizes to larger than normal will make a
LabVIEW app unreadable, thus unusable. Modern GUIs toolkits
automatically adapt.

Wolfgang Draxinger
--