Re: [wxperl-users] porting a perl/tk application to perl/wx

[Bob H. <cat...@ya...>]

Hello John, thank you for your notes.

>As for coding the interface, no, it's nowhere near as
simple as Perl/Tk.

I was afraid of it.

>The payoff is that it doesn't look anywhere near as
bad, and you have a lot more control over the results
and the "inner workings" of your program.

I played with Apple's Interface Builder for about 30
minutes, knowing nothing about this tool I was able to
rebuild the interface of the application that I want
to port. This tool is great, but I do not know what to
do with the code it generates. If I find a perl/wx
extension to Xcode, I might solve that way, because
Xcode takes care of the coding interface between the
GUI and the routines. The hard work of designing the
GUI and dealing with it's API would be gone for good.
My core interest, however, is to keep the
cross-platform approach; Tk runs everywhere, Wx has
its known advantages, but Apple's Interface Builder
does not seem to generate perl/wx code, and I am not
into the business of porting perl into java...

I tried wxGlade, but it did not respond, and then it 
crashed. I tried wxDesigner, but I do not understand
it; by comparison with Apple's Interface Builder,
wxDesigner is a shoot on one's foot, with all due
respect to the effort of its developers.

So I am stuck. I am committed to use Wx, not Apple's
local library.

On the GUI itself, what results from Apple's Interface
Builder looks great. The only one thing I do not like
is the notebook, because it does not look like one.

> You can either create the interface by hand with
code, use an interface design tool to do it for you
(though only wxGlade emits perl), write definition
files in XML for the XRC subsystem (definitely not
recommended!), or use an interface design tool to do
*that* for you. I do the last; many folks do the
first.

I understand you use wxGlade, or some other tool?

> Once you have the visual interface created, you have
to write code to make it do things and to move data
between the interface and the working parts of your
program. This need not be interlaced with the display
code: Unlike Tk, wxWidgets is thoroughly object
oriented, so  it's pretty easy to use a design which
keeps everything nicely separated.

My greatest worry about GUIs has always been their
life cycle; an update to the old library comes out and
brakes something, or a new useful library that
requires porting. So this functional separation is
very welcome, provided one has the right tool to
change the GUI and interface it with the existing
routines. The harder problem is how to achieve it by
hand, lacking the tools. Despite my many years of
profession, I still find myself like a schoolboy. I do
not mind learning new things, but sometimes I just do
not have the time. I do not understand what refrains
people from making a unified (open source) Interface
Builder, that has all the possible graphical
libraries, generates code into all possible languages,
and runs on all platforms. It is not unrealistic, as
many parts of it are already available. 

Can you recommend a good reference on how to separate
the GUI from the routines?

Bob



 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php