[Eliot-dev] Re: [Eliot-general] some technical and UI questions

[Olivier Teuliere]

Hello,

On Tue, Dec 14, 2010 at 1:06 AM, Bruce vanNorman
<address@hidden> wrote:
> Have used PyQt4 package before. Also available is PyQt {for Qt3}. Why
> Python? Just faster development and tweaking - no memory leaks, especially
> for ill-timed object destructors.
> ---
> I have been programming for 50+ years. I am very poor at UI design, but very
> good at I/O subsystems, compilers, and interpreters. I approach UI design
> with all the forethought a small child brings to finger painting :-) and
> have similar results.

No problem with Python, PyQt4 seems to be a mature project.
Apparently, there is also PySide, developed by Nokia.

> My definition of UI is much narrower than yours. Mine is restricted to
> presentation & rendering and excludes user operation & user functionality.

Depending on your definition of "user operation &user functionality",
we still have the same definition of UI :-)
For me, everything involving business logic should not be part of the
UI, but the UI can (and should) provide visual cues (like disabling
buttons corresponding to unavailable functions) and some
ergonomy-related functionality (for example, auto-completion of a
value from a known list of values).

> The kind of interface I have in mind is one where the "engine" owns all of
> the game mechanisms - save/restore, the bag, racks, command line options,
> and the board. This, extremely narrow definition of UI, theoretically
> disables any alteration to the logical (non-physical) appearance of engine's
> behavior. Eliot remains Eliot. It does not "extend" the engine or it's
> logical image. A usage similar to the physics engine inside a game.
> ---
> It would seem, then, for minimal alteration to the eliot C++ engine, I would
> need to proxy, and perhaps consolidate, QT method use. Hence, the initial
> desire to imbed Python into eliot {as a QT wrapper?}, rather than wrap
> Python around eliot.

You can see the engine as a library, providing methods to do all the
game mechanisms (as you said: save/restore, bag, racks, board,
players, etc...). The interface is "simply" there to present these
features to the user in an intuitive way (if possible :-)).

Of course, the interface could be programmed in such a way that the
features in a wrong way. In this way it is different from your example
of a physics engine: there is nothing forcing you to use it correctly
(except some assertions).
But using the features of the library in the intended way should not
be difficult at all. And in particular, there should be no need for
modyfying the engine at all, unless you plan to add new features. If
you think this is not the case (i.e. if the API is limiting you for
your needs), we can discuss it, I'm open to suggestions.

> As a practical matter, it is probably wiser to wrap Python around Eliot and
> provide eliot with a "C" call-back list to be used by a QT stub class. The
> initial phase would be to use the original QT class methods as the proxy.
> Without much thought, two requirements stand out:
> - Do not contaminate the engine with Python particulars.
> - Determine if QT should be proxy'd with it's current method set, or should
> a consolidated class be "inserted" between eliot and QT. It's the UI that I
> seek to saw in half.
>
> Another approach is to create a Python eliot module, that mirrors the
> functionality that you define as the UI and then proxy that. The performance
> hit should be minimal. I'm not to proud to recycle your logic and widgets
> :-) with credit given.

I would say the decision will be based on the way Python and C/C++ can interact.
I know very little of Python, so I'm not able to advise on the best
method to use in this case...

> The other reason I seriously favor wxPython is wxGlade. Useful for every
> widget except the board. wxGlade does emit C++ as well as Python. I've
> gotten rather good at animating wxGlade generated Python classes from
> external code. Not that I recommend it, but one can add class methods and
> properties to classes defined in another module, on the fly, at run-time -
> without modifying the source code. The "this/self" pointer actually works.
> How is that for a maintenance nightmare?

I think that the nightmare would be to use the wxWidgets framework
along with the Qt one :-)
The Qt Designer is very well done (PyQt4 even has specific support for
it), and I don't think you will find much benefit in wxGlade (but I
must admit I never tried it). I suppose you would still be able to add
dynamically your methods and properties with Qt, should you need so,
because if I understand correctly this is provided by Python itself.

> I have authored an extensive wxGlade / Python development & programming
> primer-practice that extends from drag & drop GUI development (no
> programming experience required) to multi-threading long running background
> tasks that run asynchronously with the GUI. The goal of the practice is to
> completely separate GUI evolution from program evolution. Sound familiar?
> ---
> I am going to follow your lead and rummage around a bit in your code -
> focusing on the areas you identified. I will pay particular attention to QT
> use. I hope to come up with a better partitioning (factoring) of the problem
> set, than my initial, seat of the pants, preconceived notions.
> ---
> I am very interested in your opinion. This is your code, you don't need me
> mucking it up :-) If there are some particular approaches that are of more
> general use, my ears are open.

In any case, I advise you to stick with the Qt framework instead of
using wxWidgets. In addition to the aforementioned advantages (use of
Qt Designer and re-usability of the existing UI widgets), the main
argument for using Qt, for me, would be the quality of the framework
itself, and in particular the power of its signal/slot mechanism. This
is very practical to have loosely-coupled components, and now that I
have tried it I find it painful to use other UI frameworks, based on
simple callbacks/listeners.

I am actually planning to use QtCore and QtNetwork (both are non UI
parts of the Qt framework) in future versions of the engine, to use
the signal/slot mechanism internally and benefit from the very good
API of Qt classes.

I'm not sure I have answered all your concerns, so feel free to ask
further questions :-)

Regards,
-- 
Olivier