Graphics, canvases and GUIs in Lua... [Was: Thoughts wanted on automatically "wrapping" existing functions.]

[sur-behoffski <sur_behoffski@...>]

G'day Matthew:

> I often use Lua-GD because in many cases,  I find it easier to create an image by writing code than to try and draw it.
>
> Recently I came up with an idea to make the process a little more interactive, and to type less. I've tried it out with just a small handful of the functions and I like how it's shaping up.
>
> Here's the essence of the idea:
>
> gd = require 'gd'
>
> [...]
>
> function create(sx, sy)
>    _img = gd.create(sx, sy)
>    --
>    -- some code to create a set of colors...
>    ---
> end
>
> function setpixel(x, y, c)
>    local result = _img:setPixel(x, y, c)
>    show()
>    return result
> end
>
> function rectangle(x1, y1, x2, y2, c)
>    local result = _img:rectangle(x1, y1, x2, y2, c)
>    show()
>    return result
> end
>
> -- etc, etc
> [...]


Within PUC-Rio, a graphics group, Tecgraf, have been working on tools
for:

        - Image read/write/store/convert/analysis/modification (IM):
                https://sourceforge.net/projects/imtoolkit/

        - Canvas creation and manipulation, including primitives for
          lines, boxes, images, and many other items (Canvas Draw: CD).
          CD depends on IM to build successfully:

                https://sourceforge.net/projects/canvasdraw/

(CD [with IM as a dependency, but perhaps providing value in its own
right] may well be sufficient for your project.)

        and:

        - Full-blown Graphical User Interface primitives, including
          buttons (radio etc), checkboxes, lists, text editor
          (Scintilla), web browsing (Webkit), and more: IUP.  IUP
          depends on both CD and IM to build directly.

                https://sourceforge.net/projects/iup/

All three packages are released under the MIT (Permissive) license,
in the same spirit as Lua itself and many other components of the
Lua ecosystem (e.g. LuaRocks).

There are pre-built (the "Files" tab) versions of releases, and
bleeding-edge sets of sources (Subversion head) under the "Code" tab.

Each of the three projects is intended to be highly portable, with
support across multiple OSes including Windows(R), Ubuntu GNU/Linux(R),
and a number of others that I can't recall quickly.

--

(A fair bit of this section is based on my own opinions as an observer
and part-time user of the Tecgraf tools.  My opinions may be inaccurate;
I apologise in advance for any material misrepresentations of others;
and would be grateful to accept corrections and apologise where such
cases occur.)

Although each of the IM/CD/IUP projects has its own mailing list, most
of the activity tends to be gathered into the iup-l mailing list
(partially because that is where the majority of client-level heavy
usage of the overall set of packages lies:  IM and CD are relatively
stable, whereas IUP has a more aggressive development profile).

I find that getting the raw Subversion head sources, and compiling the
code myself, works best, as bugfixes appear quickly in the SVN tree,
whereas the official release versions tend to get stale fairly quickly.

While the Subversion repository may sometimes have a suite of changes
that break the build, in my experience there are additional updates
applied quite quickly to apply fixes.

This seems to be because of limited resources given to the project
managers, esp. Antonio Scuri, who is the overall manager and
front-facing person for dialogue about the packages on the "iup-l"
mailing list.

It appears that the result is that the Tecgraf team are fairly reticent
about adopting a more aggressive release schedule (very tedious and
time-consuming, with relatively little gain in value).  Apparently, this
stance is based on past experience:  It may be possible to review this
policy in the future, but the entire owner of the situation is the
Tecgraf crew, who serve multiple competing clients and requirements.

--

Hope that this helps,

s-b etc etc etc
programmer, Grouse Software