[ale] Re: Cross platform GUI

[David Hilvert]

On Wed, 20 Feb 2008 22:45:14 -0600
Andrew Buck <andrew.buck at ndsu.edu> wrote:

> Would it be possible to create a new "project" or whatever darcs calls
> them for the GUI and give me write access to that portion or should I
> just keep putting them on my server and have you upload them into darcs.
> I would like to have some version tracking done both for backup and for
> backtracking if I screw up the code base, but whether I commit it in
> myself or not isn't that important.

Git and darcs allow local repositories to be kept, and don't require any
central repository.  These tools also allow sending of patches by e-mail, which
could be used for backup purposes (e.g., by sending to some convenient Gmail
account) if no other backup facility is available.  Hence, it should be
possible, and probably would be most convenient, to maintain your own local
repository for any GUI code.  It would probably also be nice if a repository
were somewhere generally accessible on the web.  (Unfortunately, the current
server configuration at auricle.dyndns.org doesn't support putting to the
repository via HTTP; this could probably be remedied at some point, probably
after a transition from darcs to git.)

> > I'm sufficiently focused on the engine that I would probably not be very useful
> > for interface design, but sending XML UI descriptions, such as those produced
> > by Qt Designer, or diffs of these, as in-line message text to the list should
> > work, in case this would be useful for a more concrete discussion of UI design
> > ideas.
> 
> Thats an interesting idea.  I was planning on just making an SVG, or
> maybe a DIA diagram, of the UI elements and passing that around, but the
> editor might be a more elegant solution.  It's easy enough to rearrange
> the UI layout so I was just going to focus on adding everything first
> and then arrange it at the end.

A UI editor might be more convenient for those of us who aren't practiced at
graphical arts, as it draws a lot of things for us.

> > One element that might be interesting to see would be a preview and/or
> > graphical canvas of some sort, which could then be used to manually specify
> > crop or exclusion regions by rectangle selection, to manually specify
> > alignments, or to view the results of the incremental rendering process.  Basic
> > functionality of this sort shouldn't require changes to the engine interface;
> > eventually, it might be useful to have a way to stop and restart rendering,
> > however, perhaps with parameter changes (e.g., to alignment, crop areas, etc.),
> > which might require some engine interface changes.
> 
> These are exactly the ideas that inspired me to write the GUI; the
> alignment specifically.  I tried making a panorama of my room as a test
> and had a heck of a time trying to get the alignment files properly set
> up.  These will however be the last to get done, I want to do the
> "standard" options first before I start adding new functionality.  Plus
> as I said I am still learning and radio buttons, etc, are currently the
> extent of my Qt knowledge.

Cropping is probably more widely used than --fl or --wm.  Since we don't have
other data yet, I can only cite my own:

   1114 --perturb-upper
    ...
    121 --crop
    ...
     29 --wm
    ...
      4 --fl
    ...

If the details of handling image alignment are complex to code, would it be
possible to spawn an external tool to do this?  There are programs designed for
panorama stitching, and for image editing and transformation, and one (or more)
of these might have something that could be usable for generating alignment
data, interactively or otherwise, for at least early versions of the GUI.

> The main thing I was thinking about was the program Inkscape, which is
> an SVG illustrator, has a whiteboard utility that I think multiple
> people can edit a file together.  I though we could just pull up a
> "dummy" interface in that and then use the mics to discuss different
> arrangements, etc.  The end result could certainly be put into the
> mailing list but I don't know that every detail of the entire discussion
> needs to be recorded for everyone.  I have nothing against other people
> participating in the discussion or even reviewing how the layout got to
> its present state but I doubt most people would care too much about
> every little twist and turn this takes over the course of the project.
> Your suggestion from above was good too though.  The mic has two obvious
> advantages though, one being the time saved to type out these long
> discussions, the other being every question and answer has a 24 hour lag
> as I don't think either of us wants to be checking our E-mail every 15
> minutes.

I'd rather not spend a lot of time discussing GUI ideas in a small group,
because my ideas on GUI design are very likely to be bad; I'd rather have a lot
of others look at my ideas, to increase the chances that someone will complain.