wxperl-users

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

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

The following page needs an urgent and much needed
tutorial on how to use XRC with wxPerl:

http://wxperl.sourceforge.net/documentation.html




 
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121

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

[Eriam S. <er...@er...>]

>
> The following page needs an urgent and much needed
> tutorial on how to use XRC with wxPerl:
>
> http://wxperl.sourceforge.net/documentation.html


By the way, I've not done any testing of XRC performance, is it really as
slow as Eric Wilhelm described it ?

I mean is it worth using it or is the performance loss so huge that it
really makes it un-usable .. ?

Thanks for any pointers.

Eriam

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

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

Eriam, 

I think that my former quote to Larry Wall answers
your question deeply. The core problem is how to get
the job done quickly, that is, how to have
intellectually manageable code that we can write by
hand and maintain by hand when answering to the
clients needs, and avoid the language/modules to get
in the way. Writing the wx-gui directly in PERL
clutters the source to such a degree that I am no
longer sure it does what I want (will it crash becaue
of the gui?, etc.); it also gets in the way, as I have
to bother about the gui rather than the actual job. If
using XRC turns out to be slow,  I will live with it,
but I have gained a clear cut between the gui and the
application, apart from the interface. If using XRC
files is set as default policy (solving a load of
problems at once), then speed becomes part of the
procedures, and wxPerl would need to speed up its
internal routines so that XRC (or compiled versions of
it) have performance up to par. 

The additional benefit is, that a program like wxGlade
could do all the hard work for us, and the work itself
would be language independent, as wxGlade can generate
the XRC files by default and use your specified
language for the interface. It would be the ideal
solution to a hard problem.

I am interested in hearing what people think about
this, and also about the actual XRC performance...

Bob



 
____________________________________________________________________________________
Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front

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

[Mark D. <mar...@zn...>]

Bob Hunter wrote:

> I am interested in hearing what people think about
> this, and also about the actual XRC performance...

Hi Bob,

I have no interest in XRC or any form of XML templating scheme
regardless of the performance issue. I hope that default wxPerl
behaviour and development effort never goes in this direction. In my
opinion, it would be a mistake to point new users of wxPerl down this path.

Your enthusiasm for it is admirable. I hope you achieve what you want to.

Regards

Mark

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

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

Hi,

I am cross-posting from wxGlade. Perhaps you might
re-consider your position.

------------

I propose/d to adopt XRC as standard description for
the wx gui, write a fast XRC interpreter in c++, purge
the original wxGlade, wxPython, wxPerl, etc, of all
their code for running the gui, and bridge the
resulting gap at the interface by calling the fast XRC
interpreter. It is a hell of a project, it requires
careful consideration, but would solve many problems,
including the above one with wxPython.

>From the standpoint of wxGlade, if XRC is used as the
only wx gui description, then there is no need to
generate language specific code to build and run the
interface. The task of wxGlade would reduce to
generate the XML/XRC code and the language-specfic
interface between a programmer's own code and the
gui's XRC interpreter. wxGlade would still generate
two files: the XRC file and the main file, where the
main file is a template for the programmer, which now
includes a call to the XRC interpreter, via an
enhanced version of wxPython, etc, and the pointer to
a data structure storing all the event handles and
widget variables. The programmer's template will have
very little code in it.

This is an idea. I think it is a good idea, and I
would like to invite you to think about it over and
over again, as you might not see its worth at first
glance. Or, may be, you see that the idea is rubbish
and just want to leave things as they are, that is,
struggle and complaint with the programmers, and be
happy for sharing problems, rather than solutions.

-----



Bob


 
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love 
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265 

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

[Mark D. <mar...@zn...>]

Bob Hunter wrote:
> Hi,
> 
> I am cross-posting from wxGlade. Perhaps you might
> re-consider your position.

> This is an idea. I think it is a good idea, and I
> would like to invite you to think about it over and
> over again, as you might not see its worth at first
> glance. Or, may be, you see that the idea is rubbish
> and just want to leave things as they are, that is,
> struggle and complaint with the programmers, and be
> happy for sharing problems, rather than solutions.
> 

Hi Bob,

I just don't think the idea is well conceived, useful, or practical. I
don't see that you'll get anybody to write it for you, which you need as
you don't possess any of the requisite skills yourself.

Your initial question was you wanted to port a Tk application to Wx.

Your initial problem was that you couldn't get to grips with wxPerl at all.

Your initial solution was that wxPerl needed a shared interface with Tk.

I think it was pointed out that you needed to read the documentation.

Now, all of two weeks later, after complaining about the paucity and
content of the documentation  you feel your knowledge of wxPerl is
sufficient to propose 'purging' large chunks of wxPerl in favour of some
 XML based templating system.
Interesting.

My main area of paid work involves DBI.

In February you posted to the DBI board.
Your initial question was that you wanted to port some code written
using some legacy database connection tool to DBI.

Your initial problem was that you couldn't get to grips with DBI at all.

Your initial solution was that DBI needed to incorporate the interface
of your legacy db connection tool.

Several days later, after complaining about the inaccuracies and content
of the documentation, such was your knowledge of DBI that you felt able
to criticise its implementation as a whole, and its author for failing
to solve your problem to your satisfaction.
Interesting.

If you want to use wxPerl:

1) Install it
2) Install Wx::Demo
3) Download the wxWidgets documentation - you'll need to become familiar
with it.
4) Read the tutorial at http://wxperl.sourceforge.net/tutorial/tutorial.html
5) Install wxGlade -> the perl it produces will at the very least get
you over the initial hurdle of understanding absolutely nothing. Several
users with actual experience of writing something in wxPerl are very
happy with its output.
6) Post questions on any specifics to this list where I am quite certain
you will receive answers. I don't remember any unanswered questions in
the list archive.

It seems to me that you are confusing your requirement - which is a
easier interface to wxPerl - an entirely reasonable request - with some
misplaced feeling of competence to suggest the technical implementation
for a solution - which you clearly don't have not actually having
produced any useful wxPerl code at this point in time.

So, while I have sympathy for your position ( you are unable to use
wxPerl ) I hope your urgings for purging are ignored.

In any case, I don't possess the requisite skills (never mind the
incentive ) so in terms of getting someone to do the work for you, I'm
the wrong audience and can be safely ignored.

Regards

Mark

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

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

>I think it was pointed out that you needed to read
the documentation.

I'll stop you here. If you read all my comments, as
you seem to have, then you know that I have been
asking for documentation, but had none, because there
is none (proper). Today, I asked for how to bypass the
perl-gui programming at once via XRC. I do not care
about gui programming. I hate it. I do not know wxPerl
programming. I hate its API, it is not consistent with
PERL's philosophy, and I am not going to learn its
guts just because you love it. All I care about is to
get the real job done with no need to bother with gui
programming.

On the docs, I have a 700+ pages book on wxWidgets
(Cross-Platform GUI Programming with wxWidgets, P.Hall
2006) which is for c++ and python, not for perl.
wxPerl is different; it might mirror wxPython on the
API, but is not identical to wxPython, and I am not
going to learn python plus 700+pages just because the
wxPerl community cannot bother writing the PODs and a
single tutorial that does the job. Now, you might like
things as they are, because all you do is to program
gui 9-5, but I do not. All I want from wxPerl is to
cut through its own gui programming. I do not want to
see gui code in my own code in the first place. I want
a clear cut between form and function, and a minimal
interface between them.

I am not sure about how many people are actually using
wxPerl, but the fact that there is no proper
documentation, and all the efforts (from both
wxWidgets and wxGlade) are towards c++ and python,
speak aloud about how much wxPerl is lying behind,
both in terms of support and in terms of number of
users. I think I know why, at this point. If you want
to go forward in this direction, I am not going to
stop you. I just do not care. I care about having
wxPerl reading and using an XRC file directly. I know
that there are people who know how to do it. There is
no documentation around, so I am asking for what
little could be gathered in this mailing list. All the
rest is either old ideas, or new ones that I am giving
away. If the developers want to implement the ideas,
it is up to them. My resolution is that either I get
the docs on how to use an XRC, or I will stick with
Tk, which works wonders anyway (if you know how to use
it) and is cross-platform too.

The best idea is the XRC interpreter in c++, which
would cut out a large part of the problems and
development efforts with both wxPerl and wxPython, and
wxGlade. However, I understand that the developers
might be reluctant to let go, expecially after having
spent years to do implement an idea that is now
obsolete. It is hard to let go, but the old does clear
of the way, eventually.

Bob



 
____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

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

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

Besides, Mark, your address happens to be blacklisted.
Yahoo is very good at filtering spam, and your
messages
keep falling into it. (You might not deserve it, or
not.)

Bob



 
____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 

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

[Mark D. <mar...@zn...>]

Bob Hunter wrote:
> Besides, Mark, your address happens to be blacklisted.
> Yahoo is very good at filtering spam, and your
> messages
> keep falling into it. (You might not deserve it, or
> not.)
> 

Hi Bob,

I would be most grateful if you could post details of where my address
is blacklisted. I appreciate that posting from an address at a domain
registered in my own name is a bit of a giveaway. Perhaps I should sign
up with Yahoo and undergo the stringent identification procedures.

If you simply mean that Yahoo filters my mails for whatever reason, and
you don't understand the technical difference between that and a
blacklisting, then I forgive your ridiculous intimation being borne, as
it is, out of ignorance.

Kind regards

Mark

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

[Eriam S. <er...@er...>]

>
> I would be most grateful if you could post details of where my address
> is blacklisted. I appreciate that posting from an address at a domain
> registered in my own name is a bit of a giveaway. Perhaps I should sign
> up with Yahoo and undergo the stringent identification procedures.
>

No problems here with any blacklisting of any sort.

Then for those who hates things.

About the documentation: if you don't like it then improve it, about
wxPerl API, if you don't like it improve it, about free software, if you
don't like them don't use them. And if you don't like your job, get
another job, that should be possible.

Then if you hate all those things, I understand that you'd like to hurt
the people who actually do like these things. But you have to think about
the fact that most people, as human being, try to behave consciently. It's
not always easy but it's worth the effort.

So please, stop hating and start respecting the work of others.

Thank you

Eriam

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

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

There are other open-source projects who do not demand
the users to get involved with their internal
development. Take Tk, for example. It is open-source,
and has no less than two books devoted to introduce
and master tkPerl. The books are specific for tkPerl,
not for Tk, and guide the novel user step-by-step, all
the way to mastering this gui. By comparison, wxPerl
has no documentation, and when you ask for it, you are
told to make it yourself. I think wxPerl will die
sooner than later. I think it is dead already.

Good luck with you love.



 
____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097

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

[herbert b. <dei...@we...>]

in german we say totgesagte leben länger. in english things you call 
dead, tend to live longer.
i dont think wxperl is dead. i see it more and more accepting. shure 
there could be more docs.
im willing to fix that too (curently im writing some dics for perl6).

you seem to be frustrated, sorry for that, but call id thatswhy dead 
seems a bit immature to me
(not because you flamed my vi äh wx) . wxperl is far younger but has an 
better coverage on perl.com
(and will have when my article come out) there are also docs on 
perlmonks. the wx book come finaly
out and i think its a matter of time when the wxperl book will come out. 
i dont really feel that im enough
qualified to write that one but i thought about it since i know some guy 
who work for oreilly

we will see
all best to you
> There are other open-source projects who do not demand
> the users to get involved with their internal
> development. Take Tk, for example. It is open-source,
> and has no less than two books devoted to introduce
> and master tkPerl. The books are specific for tkPerl,
> not for Tk, and guide the novel user step-by-step, all
> the way to mastering this gui. By comparison, wxPerl
> has no documentation, and when you ask for it, you are
> told to make it yourself. I think wxPerl will die
> sooner than later. I think it is dead already.
>
> Good luck with you love.
>
>
>
>  
> ____________________________________________________________________________________
> Now that's room service!  Choose from over 150,000 hotels
> in 45,000 destinations on Yahoo! Travel to find your fit.
> http://farechase.yahoo.com/promo-generic-14795097
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxperl-users mailing list
> wxp...@li...
> https://lists.sourceforge.net/lists/listinfo/wxperl-users
>
>   

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

[Eriam S. <er...@er...>]

> told to make it yourself. I think wxPerl will die
> sooner than later. I think it is dead already.
>

Free software never dies, just think about it and document yourself.

Eriam

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

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

Being "dead", for a software, means that no one uses
it.
Or rather, it is used only by a few lovers. But love
is 
a form of folly; you do not see it for what it truly
is.

I like Tk because 

1. it is well documented (new users can learn it, with
no need to write the documentation, given that they
cannot write what they are supposed to learn in the
first place)

2. it is intellectually manageable (Tk was designer by
Prof. John Ousterhout, who conceived it as such. You
first draw by hand your interface, with paper and
pencil, then convert the design into code, leveraging
on intuition and using code that actually means
something with respect to the design.)

By comparison, wxPerl is not documented at all (new
users have to read wxPerl's source code to understand
what and how they can do with it), and it is not
intellectually manageable (the API is
counterintuitive, as it does not follow the standard
philosophy of PERL,  and the code includes all sorts
of objects that have no reference to the design, that
is, objects that you can only see with the mind, not
with your eyes when looking at the drawings). The only
way to use wxPerl is via an interface builder, which
does all the coding for you, and you have to trust it,
and like it, for whatever code it generates, even when
this code clutters your own and keeps clashing with
your real tasks.

Life does not need to be that hard. I understand that
you like it that way, but hey! There are people who
like suffering. I am not one of them.

Bob



 
____________________________________________________________________________________
Don't get soaked.  Take a quick peek at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather

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

[Johan V. <jvr...@sq...>]

Bob Hunter <cat...@ya...> writes:

> [...] it does not follow the standard philosophy of PERL,

... which is spelled Perl, not PERL.

-- Johan

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

[Sergei S. <ser...@ya...>]

--- Johan Vromans <jvr...@sq...> wrote:

> Bob Hunter <cat...@ya...> writes:
> 
> > [...] it does not follow the standard philosophy of PERL,
> 
> ... which is spelled Perl, not PERL.
> 
> -- Johan
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxperl-users mailing list
> wxp...@li...
> https://lists.sourceforge.net/lists/listinfo/wxperl-users
> 

Even in case-insensitive *DOS ?


Applications From Scratch: http://appsfromscratch.berlios.de/


 
____________________________________________________________________________________
Don't get soaked.  Take a quick peek at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather

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

[herbert b. <dei...@we...>]

Hello Bob
> Being "dead", for a software, means that no one uses
> it.
> Or rather, it is used only by a few lovers. 
I use it, a friend use it for commercial thing and many other do also.
> But love is a form of folly; 
thats the most possible untrue sentence. love is most important thing of 
all.

The official wx documented containes all you need for wxperl, all 
exception for wxperl are noted on place.
it was always all i needed but i wrote also an good tutorial (in german).

What you also miss is the fact is that Wx is designed for heavy app 
devlopement, with more complex GUI
and more control over it than Tk. Therefore you have to pay some more 
typing taxes so choose wisely for
your purpose. A gui designer can you still leave you most of control 
over GUI if you know the ID or use
XRC.  Wx  is mostly easy because it alswas resambles the same order of 
parameter, most things are easy
that way its only different.

If Tk serves you well, fine keep using it and be happy but bashing wx 
with an uninformed opinion doesnt
makes you look good. the things you wrote are beginner level information 
which almost all people know here,
as far as they were correct. and please keep in mind that tk has in the 
perl arena much more userbase while
wx is still small. and yes wxperl has shortcomming as Perl/Tk has but 
please inform yourself a bit more,
than  it makes sense to talk about. try to make clear for yourself what 
you want to accomplish, than
you can get benefical results for you. just whining about how bad wx is, 
will you give nothing nor helpes us.


god bless
herbert

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

[Johan V. <jvr...@sq...>]

Bob Hunter <cat...@ya...> writes:

> Take Tk, for example. [... all good ...]
> By comparison, wxPerl [... all bad ...]

We (speaking on behalf of the wxPerl users) do not force you to use
wxPerl. 

> I think wxPerl will die sooner than later. I think it is dead
> already.

I'm sorry to feel your deep disappointment in wxPerl. 

Now, if you would be willing to set aside your grieve and try to
communicate with us you may get the help you want. Calling wxPerl dead
will definitely not.

-- Johan

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

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

Hi Mark,

Your messages keep falling into the SPAM bin, and do
it without any intervention from me. Your address is
blacklisted, and it does not matter whether it comes
from the private website of a bore, as this type of
filtering does not need to know who you are.

Best regards
Bob



 
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

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

[Peter G. <pe...@pg...>]

XRC is not particularly fast, but it is just about tolerable.

That assumes that that you compile with --disable-mimetype. For some
reason, using --enable-mimetype forces a read of all the mime files at
startup and that takes a really long time. 

Peter

On Mon, 2007-03-19 at 02:31 -0700, Bob Hunter wrote:
> Eriam, 
> 
> I think that my former quote to Larry Wall answers
> your question deeply. The core problem is how to get
> the job done quickly, that is, how to have
> intellectually manageable code that we can write by
> hand and maintain by hand when answering to the
> clients needs, and avoid the language/modules to get
> in the way. Writing the wx-gui directly in PERL
> clutters the source to such a degree that I am no
> longer sure it does what I want (will it crash becaue
> of the gui?, etc.); it also gets in the way, as I have
> to bother about the gui rather than the actual job. If
> using XRC turns out to be slow,  I will live with it,
> but I have gained a clear cut between the gui and the
> application, apart from the interface. If using XRC
> files is set as default policy (solving a load of
> problems at once), then speed becomes part of the
> procedures, and wxPerl would need to speed up its
> internal routines so that XRC (or compiled versions of
> it) have performance up to par. 
> 
> The additional benefit is, that a program like wxGlade
> could do all the hard work for us, and the work itself
> would be language independent, as wxGlade can generate
> the XRC files by default and use your specified
> language for the interface. It would be the ideal
> solution to a hard problem.
> 
> I am interested in hearing what people think about
> this, and also about the actual XRC performance...
> 
> Bob
> 
> 
> 
>  
> ____________________________________________________________________________________
> Bored stiff? Loosen up... 
> Download and play hundreds of games for free on Yahoo! Games.
> http://games.yahoo.com/games/front
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxperl-users mailing list
> wxp...@li...
> https://lists.sourceforge.net/lists/listinfo/wxperl-users

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

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

I am forwarding a message that I sent to the wxGlade
community this morning.

Bob



-----

Date:	 Mon, 19 Mar 2007 02:15:54 -0700 (PDT)
From:	"Bob Hunter" <cat...@ya...>  Add to
Address BookAdd to Address Book  Add Mobile Alert
Subject:	wxGlade->XRC+PERL
To:	wxg...@li...

Hello,

When compiling for PERL (but also for PYTHON, or any
other language) wxGlade could adopt a different
approach than it currently does. At this time, wxGlade
generates the wx code in the language; if you specify
c++, it generates the wx code in c++; if you specify
perl, it generates  the wx code in perl; and so forth.
This requires a lot of work to the developers of
wxGlade, and support for specific languages might fall
behind, as it is the case for perl. 

I propose a different approach, to solve the above
problems, and free developers time, who could devote
efforts to improve wxGlade in other ways. The proposal
is this: when compiling, wxGlade generates XRC code by
default. Compiling for a specific language then
reduces to printing a standard template in the
specific language (phthon, perl, etc), call the XRC
files with specific modules (wxPython, wxPerl, etc.),
and finish by loading the widgets from the XRC files
(an automatically generated list of all the handles).

This would allow wxGlade developers to simplify
wxGlade's own code (cut out most of it), improve the
overall stability of wxGlade, and generate code that
is  intellectually manageable (the programmer will not
have to go mad with gui code, but just "use" the
widgets).

What do you think? I think it is a great idea!

Bob Hunter



 
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121

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

[Eric W. <scr...@gm...>]

# from Bob Hunter
# on Monday 19 March 2007 02:37 am:

>call the XRC
>files with specific modules (wxPython, wxPerl, etc.),
>and finish by loading the widgets from the XRC files
>(an automatically generated list of all the handles).

See "XRC cannot express events and etc.".  Now, an offline process to 
generate code from the glade file might help.  Then you could wrap that 
in scripts which allow it to run under strict...  Oh, wait... wxglade 
has a command-line mode.  Oh, wait...  I ALREADY TRIED THAT.

The build code turns into:  while($cruft) {s/$cruft/$cruft/};

Possibly the wxglade data-structure has enough in it to express 
everything, but I'll stay on the "not even going to consider XML as a 
part of the solution" side of the fence.

--Eric
-- 
"Everything should be made as simple as possible, but no simpler."
--Albert Einstein
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

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

[Eric W. <scr...@gm...>]

# from Eriam Schaffter
# on Monday 19 March 2007 02:42 am:

>By the way, I've not done any testing of XRC performance, is it really
> as slow as Eric Wilhelm described it ?
>
>I mean is it worth using it or is the performance loss so huge that it
>really makes it un-usable .. ?
>
>Thanks for any pointers.

My observations are based on the following

  http://scratchcomputing.com/tmp/calc.pl
  http://scratchcomputing.com/tmp/calc.xrc

Comment-out the IDLE event at the bottom to have it not immediately 
exit.

  $ time ./calc.pl
  bye at ./calc.pl line 150.

  real    0m2.140s
  user    0m0.929s
  sys     0m1.167s

Then, using the dotReader testing hook, which also happens in the first 
IDLE event:

  $ time DOTREADER_TEST='print "ok\n";' ./run
  ok

  real    0m1.939s
  user    0m1.628s
  sys     0m0.182s

dotReader loads *at least* 222 .pm files in that amount of time and 
creates a gui window.  While calc.pl (stolen from a python xrc example) 
only creates a primitive calculator with 3 TextCtrls.  Using 
Devel::DProf shows that 70% of the time is spent in the (supposedly C++ 
and expat-based) Wx::XmlResource::Load method.


That      just       scares        me.


That is, however Wx 0.27 (yeah, I know, feel free to come upgrade sarge 
to etch for me and ruin my week^Wmonth while I discover everything else 
that KDE has managed to break in the last few months, deal with mozilla 
(which we *were* embedding) rolling over, etc..)  Maybe it has gotten 
better, but those numbers just scream "something is wrong" to me.

Add to that the fact that you can't even declare events in XRC, plus the 
difficulties with storing your object data in your sizer datha, plus 
the very awkward process of turning strings into integers in order to 
do anything with the objects (hey, this is Perl!  Turning my strings 
into method calls or accessors is much more useful!) and I just have to 
think chucking the whole ball of XML out the window and forgetting I 
ever heard about it is probably going to allow me to sleep better at 
night.

I'm not saying data-driven layout and configuration can't be done, but 
I'll bet XRC ain't it.  Particularly in Perl.  I can just imagine the 
if/else code that must be happening in C++ (though maybe they managed 
something involving hashes and function pointers... is "call a method 
given by a runtime string" even possible?)  In any case, the 
GetXRCID("string") stuff is rather silly.  Just watch me try to make 
any of that concise in InitMenu() of calc.pl.  Feel free to laugh at my 
pain too.  Please do show me some sympathy since I was trying to make 
this as much of a "straight and academic port" of the python code as I 
could bear.  Trust me, there a lot of "oh, man... how could anyone bear 
to write in such a verbose language as python!" and various other 
lamentations (expressed in less palatable words) involved ;-)  Heh.  
Could be worse.  We could be trying to work from wxPHP documentation!

--Eric
-- 
But you can never get 3n from n, ever, and if you think you can, please
email me the stock ticker of your company so I can short it.
--Joel Spolsky
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

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

[herbert b. <dei...@we...>]

i currently preparing an XRC tutorial for perl.com which can shurely be 
linked from there

blessings
herbert
> The following page needs an urgent and much needed
> tutorial on how to use XRC with wxPerl:
>
> http://wxperl.sourceforge.net/documentation.html
>
>
>
>
>  
> ____________________________________________________________________________________
> Be a PS3 game guru.
> Get your game face on with the latest PS3 news and previews at Yahoo! Games.
> http://videogames.yahoo.com/platform?platform=120121
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxperl-users mailing list
> wxp...@li...
> https://lists.sourceforge.net/lists/listinfo/wxperl-users
>
>   

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

[John R. <jr...@ce...>]

On Mar 1, 2007, at 10:15 AM, Bob Hunter wrote:

> ... an alternative to hand coding would be one that I
> have long wanted to have, but were afraid to ask, that
> is, to make a clear cut between the GUI and the actual
> routines, and use an Interface Builder to design the
> GUI with ease, provided the I.B. generates perl/wx
> code.
>
> If you have references on how to do this, it would be
> wonderful to have them.
>
> Bob

As for coding the interface, no, it's nowhere near as simple as Perl/ 
Tk. 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.

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.

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.

Regards,
John Ralls