wxperl-users — For wxPerl users

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

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

Mattia,

I do not know wxPerl, so I cannot code in it. In my
last mail I mentioned tk::ApplicationNest

http://search.cpan.org/dist/Tk-ApplicationNest/

I can do better myself with tk, but I think it would
be a good starting point to approach wxPerl. Someone
that knows wxPerl could write a similar module for us.
The task does not involve writing a whole API
interface, nor the API for wxPerl itself; it is only a
super-widget for the main window, with a menubar, a
taskbar, and a statusbar. Served with an example would
be even more useful, say, with a movable splitframe, a
listbox on the left and a notebook on the right. It
would be a very good framework to get started. With
one such framework, well coded by someone who knows
wxPerl, many tkPerl users would be able to get started
properly and quickly, playing with it, customizing it,
adding objects, etc. I understand that one can do
something more complex with a proprietary interface
builder running on windows, but everybody else
(osx,linux,bsd,...) who codes by hand would just be
happy with minimal GUI code a' la tkPerl, with a clear
and minimal interface where to attach one's data to
the GUI. There is a gap, but someone from the wxPerl
community has to go the extra mile to attract more
users. I think that a "tk::ApplicationNest" for wxPerl
would be enough of a bridge. Do you know of a good
fellow who would agree to do it? :-)

Regards,
Bob



 
____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

Re: [wxperl-users] Follow-up community

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

at least its default  in perl community :)
i am regularly on #perl #perl6 #perlde and sometimes #perlau

herbert
> I've not been to an irc channel for so long...is irc still the best 
> place to find likeminded ppl, especially in the wxperl context?
>
> Eriam Schaffter wrote:
>   
>> Hello
>>
>> Folowing the community discussion we had last week (or two weeks ago..) on
>> this list I just joined (and consequently opened) a #wxperl channel on
>> irc.perl.org.
>>
>> I suggest that we use it as an additionnal meeting point for wxperl fans
>> supporters and any other interested in wxperl who enjoys irc'ing.
>>
>> See you there.
>>
>> Eriam
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>   
>>     
>
>
> -------------------------------------------------------------------------
> 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] Follow-up community

[Foo JH <jhf...@ex...>]

I've not been to an irc channel for so long...is irc still the best 
place to find likeminded ppl, especially in the wxperl context?

Eriam Schaffter wrote:
> Hello
>
> Folowing the community discussion we had last week (or two weeks ago..) on
> this list I just joined (and consequently opened) a #wxperl channel on
> irc.perl.org.
>
> I suggest that we use it as an additionnal meeting point for wxperl fans
> supporters and any other interested in wxperl who enjoys irc'ing.
>
> See you there.
>
> Eriam
>
>
> -------------------------------------------------------------------------
> 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

[Mattia B. \<mattia\.barbon\@libero\.it\> <mat...@li...>]

> Dan Freed wrote:
> While I am not a detractor of new projects, I think a project such as  =

> this should be an different beast than wxPerl.  It should be a  
> compatibility layer of sorts for wxPerl and Perk/tk.

  I completely agree (that's why I proposed something like
Wx::Perl::Tk for this).

> On Mar 6, 2007, at 10:43 AM, Bob Hunter wrote:
> 
> > Mattia, your message is already an important step
> > forward. At least you acknowledge that wxPerl can be
> > improved from that point of view, and are open to
> > change/improvement. Given that time is limited for
> > everyone, the best approach to proceed is to post a
> > general "call for contributions", and leverage from
> > the open source community. Design ideas are valuable
> > as much as, if not more than, specific code, because
> > they can save a lot of coding.

  I believe you are a bit over-optimistic: I expect there
will be a loto of people wanting to _use_ this compatibility
layer, but not many (IOW, none...)  that want to actually
code it.  I don't know if I am being cynical or have just been
an OSS developer for too much time...

Best regards,
Mattia
=0A=0A=0A------------------------------------------------------=0ALeggi G=
RATIS le tue mail con il telefonino i-mode=99 di Wind=0Ahttp://i-mode.win=
d.it=0A

[wxperl-users] Follow-up community

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

Hello

Folowing the community discussion we had last week (or two weeks ago..) on
this list I just joined (and consequently opened) a #wxperl channel on
irc.perl.org.

I suggest that we use it as an additionnal meeting point for wxperl fans
supporters and any other interested in wxperl who enjoys irc'ing.

See you there.

Eriam

[wxperl-users] wx::ApplicationNest

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

A third idea in the former list, as I have just bumped
on it...

http://search.cpan.org/~xpix/Tk-ApplicationNest-1.1/ApplicationNest.pm


Bob



 
____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

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

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

"While I am not a detractor of new projects, I think a
project such as this should be an different beast than
wxPerl.  It should be a compatibility layer of sorts
for wxPerl and Perk/tk."

I like it. The API of wxPerl could stay as it is, and
then one could have a layer built on top of wxPerl
that has an API which is very similar or possibly
better than  that of tkPerl. In this way, wxPerl's
existent users would not have to rewrite their legacy
code, and wxPerl would gain popularity among the
tkPerl users (I am one of them).

Three cheers for Daniell! Bravo.

Bob


 
____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

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

[Daniell F. <win...@gm...>]

While I am not a detractor of new projects, I think a project such as  
this should be an different beast than wxPerl.  It should be a  
compatibility layer of sorts for wxPerl and Perk/tk.

I for one like the way wxPerl currently works (i.e. just like the C++  
version and python version).  I loath the thought of having to change  
all of my code to some new API because we wanted to dumb it down a  
bit (and I mean no disrespect by that).  I'm all for having a way to  
create quick and dirty GUI's using wxPerl, but that isn't always the  
appropriate way to do things.

wxPerl as it stands (and as others have already said) is a very  
complete GUI API that has a lot of power.  Yes there is some  
complexity to using it, but once you learn to code using it, it isn't  
any worse than any other API.

Just my 2 cents worth.

Thanks,
Dan Freed

On Mar 6, 2007, at 10:43 AM, Bob Hunter wrote:

> Mattia, your message is already an important step
> forward. At least you acknowledge that wxPerl can be
> improved from that point of view, and are open to
> change/improvement. Given that time is limited for
> everyone, the best approach to proceed is to post a
> general "call for contributions", and leverage from
> the open source community. Design ideas are valuable
> as much as, if not more than, specific code, because
> they can save a lot of coding.
>
> To make the first two contributions, these are two
> ideas.
>
> The first is to talk to the developers of tkPerl and
> ask them whether they want to merge with wxPerl. It
> might sound odd at first, to both the tkPerl and
> wxPerl communities, but read on. The first aim would
> be to *design* the same API for both projects. This
> API has to be consistent with PERL's philosophy,
> profit from the existent API of tkPerl and allow for
> wxPerl's enhanced features. When people have debated
> at length on design, and everybody is happy about the
> final resolution, then it is coding time for both
> communities. The tkPerl community would have (a) an
> improved API, (b) a means to port applications from tk
> to wx with minimal effort, and (b) stay with a tk
> interface if they like (wx can interface to gtk,
> cocoa, etc., and thus also with tk). The wxPerl
> community would finally have an API that is consistent
> with PERL's philosophy.
>
> The second idea is a tiny little one, and arises from
> a simple problem that I encountered today on
> tk/Perl.---I moved the mouse around the application,
> and noted that different parts of the GUI highlight
> differently and with different colors. I also noted
> that different text areas have different background
> colors. I spent two hours to fix a number of them, in
> detail, coding in. An idea that saved time was the
> following:
>
> 1. define a general color for the background and the
> highlight, at the beginning of the code, say:
>
> my $bg_text  = "#efefef";
> my $bg_texth = "#adbcd6";
>
> 2. state the following in the option area of relevant
> widgets:
>
> -background => $bg_text,
> -highlightcolor => $bg_texth,
> -highlightbackground => $bg_text,
>
> The result is that those widgets now have consistent
> look and feel. The problem is, that I still have to
> specify this detail for each relevant widget, coding
> by hand. And I am lucky I do not have to do that with
> an  Interface Builder, clicking around hundreds of
> time on various panels. Now, the idea is to specify
> this consistent behaviour only one time. The question
> is where? I propose to gather all such customizations
> in a separate "policy" file, so that, if you have k
> entries  you just write the policy once.
>
> Regards,
> Bob
>
>
>
>
> ______________________________________________________________________ 
> ______________
> TV dinner still cooling?
> Check out "Tonight's Picks" on Yahoo! TV.
> http://tv.yahoo.com/
>
> ---------------------------------------------------------------------- 
> ---
> 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

Daniell Freed
win...@gm...
Bereshit bara Elohim et hashamayim ve'et ha'arets...

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

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

Mattia, your message is already an important step
forward. At least you acknowledge that wxPerl can be
improved from that point of view, and are open to
change/improvement. Given that time is limited for
everyone, the best approach to proceed is to post a
general "call for contributions", and leverage from
the open source community. Design ideas are valuable
as much as, if not more than, specific code, because
they can save a lot of coding.

To make the first two contributions, these are two
ideas.

The first is to talk to the developers of tkPerl and
ask them whether they want to merge with wxPerl. It
might sound odd at first, to both the tkPerl and
wxPerl communities, but read on. The first aim would
be to *design* the same API for both projects. This
API has to be consistent with PERL's philosophy,
profit from the existent API of tkPerl and allow for
wxPerl's enhanced features. When people have debated
at length on design, and everybody is happy about the
final resolution, then it is coding time for both
communities. The tkPerl community would have (a) an
improved API, (b) a means to port applications from tk
to wx with minimal effort, and (b) stay with a tk
interface if they like (wx can interface to gtk,
cocoa, etc., and thus also with tk). The wxPerl
community would finally have an API that is consistent
with PERL's philosophy.

The second idea is a tiny little one, and arises from
a simple problem that I encountered today on
tk/Perl.---I moved the mouse around the application,
and noted that different parts of the GUI highlight
differently and with different colors. I also noted
that different text areas have different background
colors. I spent two hours to fix a number of them, in
detail, coding in. An idea that saved time was the
following:

1. define a general color for the background and the
highlight, at the beginning of the code, say:

my $bg_text  = "#efefef";
my $bg_texth = "#adbcd6";

2. state the following in the option area of relevant
widgets:

-background => $bg_text,
-highlightcolor => $bg_texth,
-highlightbackground => $bg_text,

The result is that those widgets now have consistent
look and feel. The problem is, that I still have to
specify this detail for each relevant widget, coding
by hand. And I am lucky I do not have to do that with
an  Interface Builder, clicking around hundreds of
time on various panels. Now, the idea is to specify
this consistent behaviour only one time. The question
is where? I propose to gather all such customizations
in a separate "policy" file, so that, if you have k
entries  you just write the policy once.

Regards,
Bob



 
____________________________________________________________________________________
TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/

[wxperl-users] [ wxperl-Bugs-1674941 ] dead link in documentation

[SourceForge.net <no...@so...>]

Bugs item #1674941, was opened at 2007-03-06 06:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=115655&aid=1674941&group_id=15655

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: dead link in documentation

Initial Comment:
just compiled the cpan modules and noticed that link in documentation ( http://wxperl.sourceforge.net/documentation.html ):
http://www.wxwidgets.org/manuals/2.6.1/wx_contents.html

should be changed to:
http://www.wxwidgets.org/manuals/2.6.3/wx_contents.html

B/r

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=115655&aid=1674941&group_id=15655

Re: [wxperl-users] why isn't Wx Tk?

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

# from Bob Hunter
# on Tuesday 06 March 2007 12:44 am:

>Can't we
>have an easier API for wxPerl? I think we can. 

I think so too.  I believe tkPerl has had a bit more time (8 years?) and 
maybe a few more developers.  If you're impatient, the standard 
procedure is to send large bundles of money or small bundles of code.  
Rants don't compile, sorry.

>One approach would be to retain the API of tkPerl, 

That seems very doubtful.  Besides being very different, Wx is quite a 
bit more flexible than Tk.

>possibly have a simpler one, and move additional
>detail to a separate file, if any are needed,

I've toyed with some DWIM stuff in the dotreader repository, but haven't 
been particularly happy with the loss of control that inevitably leads 
to.  DWIM not always being DWYM, etc.  However, I have identified a few 
areas where I think we could get some shorter code, such as in using 
the object as the constructor for its child widgets:

  my $thingy = $self->newThingy(...);
vs
  my $thingy = Wx::Thingy->new($self, -1, ...);

Though named (not positional) parameters and *reasonable* defaults would 
certainly help.

There are a few other things and observations, like that Wx->can should 
mirror the AUTOLOAD, a huge pile of shortcuts, yaml-driven menus, etc.  
Some of these ideas have been written and some haven't.  Nevertheless, 
the code is all completely visible at svn.dotreader.com.

>with no 
>need to struggle with unintuitive interface builders
>and our code, going mad in between. 

What interface builder are you using for Tk?

>Perhaps I will get 
>used to it, but I cannot believe I have to give up
>PERL's philosophy when programming in PERL.

Perl's philosophy is that you write Perl.  The trouble with wxPerl is 
that it is very nearly a straight-port of the C++ Wx, which is no small 
effort, but is bound to be far from a perlish API.  So, you can either 
wrap it and provide some mixins, traits, etc that make it more perlish, 
or you can try to redo the binding code to handle 20-odd cases of hash 
values in XS.  Keep in mind that you're talking about a redesign of the 
API.  That's no small task and it is not easily done well.

--Eric
-- 
Peer's Law: The solution to the problem changes the problem.
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

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

[Mattia B. \<mattia\.barbon\@libero\.it\> <mat...@li...>]

> I understand that wxWidgets is a very complex
> meta-library for local graphic libraries, but why
> would anyone be bothered with so many details? tkPerl

  OTOH, why would someone (me!) already knowing wxWidgets,
bother to write _and_ docuemnt a different interface.
For users? Good point, but I when?

> could be just as cumbersone as wxPerl, but is not. I
> still think that a perl interface to wxWidgets, wxPerl
> that is, could be more perlish, easier that is. The

  I agree. The answer is not necessarily a Tk-ish interface
(which would be nevertheless good for compatibility).

> cheaper, and human time is (we hope) getting more
> valuable. The  person has to come first." [Larry Wall]

  ...and mine is limited... if anybody feels like writing
Wx::Perl::Tk (or whatever), please feel free to do so.

Regards
Mattia
=0A=0A=0A------------------------------------------------------=0ACon Pro=
meteo prestiti senza spese fino a 31.000 Euro!=0Ahttp://click.libero.it/w=
ebnation06marz07=0A

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

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

I understand that wxWidgets is a very complex
meta-library for local graphic libraries, but why
would anyone be bothered with so many details? tkPerl
could be just as cumbersone as wxPerl, but is not. I
still think that a perl interface to wxWidgets, wxPerl
that is, could be more perlish, easier that is. The
complexity of the underlying library needs not to show
up in the API. No one could fly an airplane with two
arms if the interface would be closer to the hardware
than to the human. My programs are intellectually
manageable because I make an effor in that direction,
including using PERL instead of JAVA, for example. I
was perfectly happy with tkPerl's API, but had the
well known limitations of a tk interface. Can't we
have an easier API for wxPerl? I think we can. One
approach would be to retain the API of tkPerl, or
possibly have a simpler one, and move additional
detail to a separate file, if any are needed, with no
need to struggle with unintuitive interface builders
and our code, going mad in between. Perhaps I will get
used to it, but I cannot believe I have to give up
PERL's philosophy when programming in PERL.

"The  computer languages taught in schools and used in
industry, from Fortran and Pascal to C and C++, all
share in common the mis-feature of forcing programmers
to worry about all kinds of things that get in the way
of expressing what they're trying to do. [...] We need
to optimize both computer time and human time, but
when push comes to shove, computer time is getting
cheaper, and human time is (we hope) getting more
valuable. The  person has to come first." [Larry Wall,
The Origin of the Camel Lot in the Breakdown of the
Bilingual Unix, Communications of the ACM,
42(4):40-41, 1999.]



 
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

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

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

>
> Only you can decide which is the more appropriate tool for your use.
>

It is very clear and totally right.

Also I suggest that you take a look at visualWx (which is for windows I
know but you can eventually have a windows box and give it a try ..). That
one is IMHO the best one (despite not free etc).

You can for instance place controls without sizers (x and y) which is good
for fixed size frames like Wizards and so on. I've not found this feature
already in other gui ide but maybe I didnt looked in the correct
direction.

I would also say the price of the effort is worth it.

Thanks

Eriam

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

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

On Mar 5, 2007, at 2:48 PM, Bob Hunter wrote:

>
> I'm so close to scream like an awk to this python...
>
> ...and stick to Tk. Why is that Perl/Wx must be so
> cumbersome? Perl/Tk is so easy to manage by hand, by
> comparison. After all, we are talking about Perl/Wx,
> which everyone assumed it to have the same coding ease
> of Perl/Tk. Why is that Perl/Wx is so cumbersome? Who
> cares about all those details? Why can't Perl/Wx be as
> easy as Perl/Tk? Can't you make an effort to hide the
> complexity, and deliver an API that is similar,
> whether not identical to Perl/Tk?
>
> Bob

I think that you misunderstand both wxWidgets and wxPerl.

wxPerl is a wrapper around (most of) wxWidgets. It is not  
particularly perlish, and it is most definitely not like Perl/Tk,  
because wxWidgets isn't like Tk.

wxWidgets in turn wraps various platform GUI frameworks -- Carbon or  
Cocoa for OSX, GTK (and not as well developed, Motif) for X11, Win32,  
Wince, PalmOS, and others. It also provides a common API to some of  
the underlying OS services, like sockets, and fills in holes in some  
areas like regular expressions. It's a C++ library, for which  
wrappers in other languages are available, including wxPerl and  
wxPython.

wxWidgets is emphatically *not* intended to do what Tk does: Provide  
a quick-and-dirty graphical front end to quick-and-dirty "scripts".  
It *is* a full-featured framework for developing full-featured  
applications.

Only you can decide which is the more appropriate tool for your use.

Regards,
John Ralls

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

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

I'm so close to scream like an awk to this python...

...and stick to Tk. Why is that Perl/Wx must be so
cumbersome? Perl/Tk is so easy to manage by hand, by
comparison. After all, we are talking about Perl/Wx,
which everyone assumed it to have the same coding ease
of Perl/Tk. Why is that Perl/Wx is so cumbersome? Who
cares about all those details? Why can't Perl/Wx be as
easy as Perl/Tk? Can't you make an effort to hide the
complexity, and deliver an API that is similar,
whether not identical to Perl/Tk?

Bob



 
____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

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

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

# from Bob Hunter
# on Monday 05 March 2007 01:53 pm:

>Which means that wxGlade still depends on wxPython
>after all.

I think the warning was trying to tell you that wxGlade is using the 
wxPython code, which apparently is now a compatibility wrapper around 
what is now called "wx".  FWIW, wxGlade's Perl output and various other 
issues are so bad that I've gone to hand-written layout code and have 
been sleeping much better ever since.

--Eric
-- 
"Left to themselves, things tend to go from bad to worse."
--Murphy's Corollary
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

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

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

I forgot, one thing. If I uninstall wxPython, then
call wxGlade, I get the following:

--> python2.5
/Applications/se/wxGlade-0.4.1/wxglade.py
Traceback (most recent call last):
  File
"/Users/sb/Applications/se/wxGlade-0.4.1/wxglade.py",
line 148, in <module>
    run_main()
  File
"/Users/sb/Applications/se/wxGlade-0.4.1/wxglade.py",
line 135, in run_main
    import main
  File
"/Users/sb/Applications/se/wxGlade-0.4.1/main.py",
line 9, in <module>
    from wxPython.wx import *
ImportError: No module named wxPython.wx


Which means that wxGlade still depends on wxPython
after all.


 
____________________________________________________________________________________
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

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

I'v just had a hell of a roundtrip. I thought that the
reason for wxGlade crashing so much (to a point that
it just keeps crashing with no opportunity to save any
work in between) is that it needs updates. So I read
from the home page that wxGlade requires wxPython,
which in turn requires an updated version of python.
So on my OS 10.4.8 with python 2.3.5 I had to install
python 2.5 (100MB+) and wxPython 2.8 on top of it
(100MB+). Then I fire wxGlade with 

pythonw2.5 ~/Applications/se/wxGlade-0.4.1/wxglade.py
& 

only to have the following warning:

--> /Applications/se/wxGlade-0.4.1/main.py:9:
DeprecationWarning: The wxPython compatibility package
is no longer automatically generated or activly
maintained.  Please switch to the wx package as soon
as possible.
  from wxPython.wx import *
...


ARGH!

Did I miss something?

wxGlade's home page at
http://wxglade.sourceforge.net/

clearly says that it is written in Python and
wxPython, and there is no mention to the above news.
So, now I have to uninstall wxPython, in replacement
of what, exactly? Oh...

The positive side is, that wxGlade is more stable. It
does not crash as it used to. However, it became
chatty, and fills the console with error messages
about wxGlade's own bugs.

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

[Daniell F. <win...@gm...>]

I here you Bob.  I have had the very same dilemma.  I've used  
wxDesigner and while it can get the job done, it doesn't function  
like any other GUI designer I've used, and I have the same crashing  
problems with wxGlade.  Despite the unstable nature of wxGlade, it  
still does a better job, by far, than wxDesigner (and I've even paid  
for wxDesigner).  I just make it a habit to save after every major  
change I make.

I don't think there is any alternative for OSX beyond those two, at  
lease not for Wx.

Thanks,
Dan Freed

On Mar 5, 2007, at 2:12 PM, Bob Hunter wrote:

> I think I've been here before, however...
>
> wxGlade would be a very nice tool, if only it would
> stop crashing. wxDesigner, on the other hand, is a
> tool for sado-maso; it does not show the complete GUI,
> like wxGlade or Apple's Interface Builder, and this is
> a major limitation on usability, which is not what one
> expects from a GUI builder... Apple's Interface
> Builder seems locked on its perfect world, and I could
> not find any way extension or converter (so far).
> Other tools are either worse on usability, or
> available for platforms other than OSX. Can I pick
> your brains again? I need something like wxGlade, but
> stable!
>
>
> Bob
>
>
>
>
> ______________________________________________________________________ 
> ______________
> Expecting? Get great news right away with email Auto-Check.
> Try the Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
>
> ---------------------------------------------------------------------- 
> ---
> 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

Daniell Freed
win...@gm...
Bereshit bara Elohim et hashamayim ve'et ha'arets...

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

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

I think I've been here before, however...

wxGlade would be a very nice tool, if only it would
stop crashing. wxDesigner, on the other hand, is a
tool for sado-maso; it does not show the complete GUI,
like wxGlade or Apple's Interface Builder, and this is
a major limitation on usability, which is not what one
expects from a GUI builder... Apple's Interface
Builder seems locked on its perfect world, and I could
not find any way extension or converter (so far).
Other tools are either worse on usability, or
available for platforms other than OSX. Can I pick
your brains again? I need something like wxGlade, but
stable!


Bob



 
____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html 

[wxperl-users] Perlwrapper updated for tiger

[Daniell F. <win...@gm...>]

I've posted an updated version of PerlWrapper for OS X Tiger.  It  
will now compile unlike the previous version.

I can't take credit for the changes in the package since I  
shamelessly just made the changes that were suggested by another  
wxperl user on this list (the archives are your friend).

If you are interested in the package it can be found here: http:// 
wintermte.googlepages.com/wxwidgetsdownloads

Thanks,
Daniell Freed
win...@gm...
Bereshit bara Elohim et hashamayim ve'et ha'arets...

[wxperl-users] As venerate do miff

[Randy B. <xm...@dg...>]

Alert for you.



Sym8oL: ARSSCurr Price: $0.15 5 Day Target price: $0.75Action: Aggresive =
Buy/Hold!!!

500% profit potential short term..



See the hottest news of the ARSS, wxperl-users!

[wxperl-users] Search path for images

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

Hi,

Is it possible to have Wx::Bitmap and friends search for image files
using a search path instead of having to specify a fixed file name?

For example,

        ... Wx::Bitmap->new("foo.png") ...

and then foo.png will be tried in several preset locations (@INC, maybe)?
   
-- Johan

[wxperl-users] wx Functions not in wxPerl

[Daniell F. <win...@gm...>]

Can anyone tell me, are there plans to implement (or are they  
implemented and I'm just not doing something correct) the functions:

wxBeginBusyCursor
wxEndBusyCursor
wxGenericAboutBox

These seem to be very useful functions, but they don't seem to work  
in wxPerl.  They return:

	Error while autoloading 'Wx::BeginBusyCursor' at - line 2

or something similar when called.  Is there a different library file  
I am missing, or a compile option?  I've tried this on both Win32 and  
OSX.

Thanks,

Daniell Freed
win...@gm...
Bereshit bara Elohim et hashamayim ve'et ha'arets...