[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] wxGlade and edit areas

From: Syan Tan
Subject: Re: [Gnumed-devel] wxGlade and edit areas
Date: Sun, 27 Nov 2005 19:01:04 +0800

when I was learning computer programming ( this time formally) back in Year 11 , I said to my maths teacher,

"why don't  you write a language to interpret this problem ? " and he sort of looked at me incredulously and said,

"but that's why you are learning XXXX" XXXX being the programming language.  I get that kind of feeling when someone

talks about trying to impose another layer of formalism on the one that wxglade gives you already. It isn't going to make it

easier to read and would achieve the same thing if you just let programmers access your business layer any which way

they see fit , from within the skeleton code generated by wxglade.  awaiting rebuff or all round ostracism on this...

On Sun Nov 27 8:41 , Karsten Hilbert sent:

On Sun, Nov 27, 2005 at 07:20:55PM +1100, Ian Haywood wrote:

> I notice you guys have started using wxGlade. This is good.
Yes, we've been experimenting around with setting up a good,
logical infrastructure on how to carry over wxGlade
generated code into useful classes non-desctructively and
without too much impact on existing code. The concept is
pretty much along the lines that Horst mapped out:

- client/wxg/ holds *.wxg XML files as used by Glade to store GUI layout

- client/wxGladeWidgets holds *.py files generated from client/wxg/*.wxg by wxGlade

- wxGlade generated base classes are prefixed with "wxg", eg wxgFoo

- application GUI classes in client/wxpython/ inherit base
classes from client/wxGladeWidgets thereby acquiring
transparent GUI re-layouting

- for that to work, attribute and method names must be
defined at the wxGlade level (client/wxg/*.wxg) and
overriden by application classes (client/wxpython/*.py)

That seems to work out and display a comprehensible,
maintainable structuring of things. We have added the
necessary directories and I also added some READMEs to them.

> I have been playing with gmEditArea and come to the same conclusion,
> what do you think moving the common gnumed functionality to a base class
> which is used in multiple inheritance with the wxGlade class to make
> popups?

> class VaccEditArea (gmEditArea.cEditAreaBase, wxGladeWidgets.wxgVaccEditArea):


Looks good to me. If you want to go ahead with one of the
not yet in use edit areas (say, vaccinations) feel free to
do so. I'd just ask you keep the existing vaccination edit
area code around for the time being (until your solution
has displayed the superiority we expect of it).

I notice you've stalked around vaccination functionality
lately. Is that a concern in your area of real-life work ?

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

Gnumed-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]