wxperl-users — For wxPerl users

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

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

I spent the whole day reading and experimenting with
wxPerl. I think I have a grasp of the most elementary
parts, but got stuck when adding the menu bar and its
items. I went back to wxGlade, only to find that the
code it generates is both old and bugged. Further, a
tutorial makes it clear that wxGlade overwrites the
code, so we cannot change it by hand. Thus, if we must
use a GUI builder (because writing by hand from
scratch is just insane), and cannot change the code by
hand (because the builder overwrites it), why
bothering at all about having perl code for the main
GUI inside our scripts? Why bothering with
wxPerl/wxPython etc in the first pace, if we could do
otherwise? The idea is this: wxGlade generates the XML
description of the GUI, then we "use" an interface to
this description, that is, we use a module that reads
the XML file and generates a list of all the variables
we can use to fill the GUI with data and events. The
script, as a result, would be smaller than using tk.
Do I make sense?




 
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

Re: [wxperl-users] your wxGlade wishlist

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

# from Mark Dootson
# on Saturday 17 March 2007 11:22 am:

>Eric Wilhelm wrote:
>> IS NOT SMALLTALK!  No matter what wxglade or other tool does, it
>> still has to generate a text file, which is an all-or-nothing
>> operation. Even with the "start" and "end" markers, you're left with
>> a blob of code that can't be changed in your editor.  It's a one-way
>> street, which means the workflow is perverted into something like
>> "make, then edit."  Until a gui tool can deal with *incoming*
>> changes to the code, we're not even close to solving this.
>
>Nah.
>
>Have the GUI tool generate a separate template class from which you
>inherit. Never edit the template class 'cause it just has your window
>construction stuff in it.
>Edit your derived class in whatever you like.
>
>So that's it solved.

Right, and that's what I was doing until I ran into problems.  It's not 
solved because it's still a one-way street, wxglade still generates 
code that doesn't do what I want in some cases, drops menu-items on the 
floor (requiring me to maintain a mirror of numeric ID's), etc.  If it 
were solved, I would be a happy clam, but I'm not.

--Eric
-- 
Those who cannot remember the past are condemned to repeat it.
--George Santayana
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Re: [wxperl-users] Questing on interacting with Tar

[Mattia B. <mat...@li...>]

On Fri, 16 Mar 2007 13:50:49 +0900
Evan Read <er...@ii...> wrote:

  Hi,

> I am currently writing my first wxperl program.  What I am doing is
> taking a user selection of a source dir and a destination dir and am
> taring up the source dir to the destination dir.

  I haven't looked at the code yet, but I suggest you take a look
at Wx::Execute and Wx::Process ("::wxExecute" and "wxProcess" in the
wxWidgets documentation).  They allow to (a)synchronously execute
subprocesses with input/output redirection, to portably send signals
and terminate processes and offer termination notification callbacks.

Regards
Mattia

# execute asyncronously
my $proc = MyProcess->new;
my $pid = Wx::ExecuteArgs( [$progname, @args], 0, $proc );
# use $proc to control the program
# OnTerminate will be called when the process finishes

package MyProcess;

use strict;
use base qw(Wx::Process);

sub new {
  my $class = shift;
  my $this = $class->SUPER::new();

  return $this;
}

sub OnTerminate {
  my( $this, $pid, $status ) = @_;

  Wx::LogMessage( "Process '$pid' terminated with status $status" );
}

1;

Re: [wxperl-users] your wxGlade wishlist

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

Eric Wilhelm wrote:
> IS NOT SMALLTALK!  No matter what wxglade or other tool does, it still 
> has to generate a text file, which is an all-or-nothing operation.  
> Even with the "start" and "end" markers, you're left with a blob of 
> code that can't be changed in your editor.  It's a one-way street, 
> which means the workflow is perverted into something like "make, then 
> edit."  Until a gui tool can deal with *incoming* changes to the code, 
> we're not even close to solving this. 

Nah.

Have the GUI tool generate a separate template class from which you
inherit. Never edit the template class 'cause it just has your window
construction stuff in it.
Edit your derived class in whatever you like.

So that's it solved.

Mark

Re: [wxperl-users] your wxGlade wishlist

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

# from Johan Vromans
# on Saturday 17 March 2007 04:59 am:

>> Next, I've heard "I want a good, free GUI rad tool" before, and to
>> be honest, I have no interest in that sort of thing or that line of
>> discussion and thus no intention to do anything about it.
>
>I think this is an very unfortunate attitude.

What!?  I'm trying to be pragmatic here.  Code generation doesn't work, 
so I don't think it is worth discussing.

I only intended that to set the topic as "not wxglade."  If you want to 
use it, fine.  I prefer to write clean, concise code rather than wade 
through piles of generated muck.

>As many people here know, I'm a fan of wxGlade. wxGlade provides a
>great help in setting up user interfaces and generates good Perl code.
>Many of the things that bother you when using wxPerl do not bother me,
>since they're part of automatically generated code that I don't have
>to maintain. I even don't care to look at this code except for
>educational purposes.

Thanks.  Now to untrim the important bit of that paragraph:

>>Sorry, wrong thread.  If someone has an adequately smalltalkish
>>inspiration for wedding the tool to the code, it might be applicable.
>>Otherwise, no. 

I'm not saying "it can't be done" or "I won't allow it."  Rather, THIS 
IS NOT SMALLTALK!  No matter what wxglade or other tool does, it still 
has to generate a text file, which is an all-or-nothing operation.  
Even with the "start" and "end" markers, you're left with a blob of 
code that can't be changed in your editor.  It's a one-way street, 
which means the workflow is perverted into something like "make, then 
edit."  Until a gui tool can deal with *incoming* changes to the code, 
we're not even close to solving this.  Now, make the tool and the 
editor communicate via a mechanism that doesn't involve conflicting 
overwrites on one file.  Ok?  See why we're in the wrong environment to 
enable this sort of thing?  You might be fine with the way it works, 
but it is so far from optimal that I see it as having started from a 
*completely* wrong set of assumptions.

It doesn't count as wheel-reinvention if the current wheel won't roll.

--Eric
-- 
Those who cannot remember the past are condemned to repeat it.
--George Santayana
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

[wxperl-users] firewood walker

[narrowness <nv...@be...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<img alt="comprise" src="cid:par...@be..."
 height="456" width="248"><br>
The demo provides a script that adds a mortgage calculation to the F1
key.<br>
This method places key-value pairs into a javax. Not yet an SDN
member?<br>
If you are using a proxy server to server your web requests, you need to
specify the proxyHost and proxyPort context parameters in the web. Press
the F1 key to execute the script and to invoke the calculate method.<br>
Press the F1 key to execute the script and to invoke the calculate
method. Therefore, I manually entered the column data into the page.
This fact doesn't detract from the power and richness of the Java
platform but simply acknowledges that scripting languages have an
important place in the developer's toolbox. Something strange was
observed by the Hubble Space Telescope.<br>
One of the JavaScript functions that Dynamic Faces provides is the
fireAjaxTransaction function. For more details see the Java EE 5. Code
Example 7: You can use the Invocable interface to call specific methods
in a script. How to Access Script ObjectsThe eval, invokeMethod, and
invokeFunction methods always return an Object instance.<br>
That's all there is to it. To get my new listener to be called when a
new value is selected, I needed to add code to dojo combobox widget's
component. That's what you will use with the sample portlet.<br>
You can copy and paste the URL right into your browser or use curl to
readily see the results.<br>
See the tutorial for more information on building Phobos applications.
The Phobos project is focussed on building a web application framework
that allows you to develop your web applications with a scripting
language.<br>
I realized there was a simpler way to do this by using the built in
functionalities of the servlet API using the  HttpSession API. Jai Suri,
a member of the Sun Java Portal Server engineering team, is currently
involved in developing next-generation portlet containers based on AJAX
and DHTML. I realized there was a simpler way to do this by using the
built in functionalities of the servlet API using the  HttpSession API.
The Back buttons on browsers can present a problem with AJAX-based Web
applications.<br>
The ScriptCalc DemoThe ScriptCalc demo application implements parts of a
postfix calculator. Now that you've seen it please go out and use the
XmlHttpProxy and let us know what you think. User-defined
functionality.<br>
A  follow-on to Java API for XML-based RPC 1. I'll get to the importance
of this later on.<br>
js script as an argument.<br>
The Java source for the XmlHttpProxy client is part of Project jMaki and
may be accessed on java.<br>
</body>
</html>

Re: [wxperl-users] your wxPerl wishlist?

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

Eriam Schaffter wrote:

Hello,

Wx::WidgetMaker is interesting because it does some of the things
suggested previously. I must admit, I'd never read past the word 'CGI'
before. For me, 'CGI.pm like' would be the wrong starting point.

As the author of the module says, its 'a CGI.pm-like library for wxPerl'.

For me, I feel that starting out to emulate CGI.pm would be a very
limiting approach that might not lend itself well to as rich an
environment as wxPerl. But that's really really not a criticism of
Wx::WidgetMaker which does exactly what it says on the tin.

Perhaps I have a minority viewpoint on this. I came to Perl first via
data munging and DBI. If my entry point had been CGI then perhaps my
view would be different.

Regards

Mark



> Hello
> 
> I just came across Wx::WidgetMaker
> 
> http://search.cpan.org/~slanning/Wx-WidgetMaker-0.11/lib/Wx/WidgetMaker.pm
> 
> Which is an attempt to ease the creation of wx based applications.
> 
> I havent tested that though but I'm interested to see what you think
> about this.
> 
> Eriam

Re: [wxperl-users] your wxPerl wishlist?

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

Hello

I just came across Wx::WidgetMaker

http://search.cpan.org/~slanning/Wx-WidgetMaker-0.11/lib/Wx/WidgetMaker.pm

Which is an attempt to ease the creation of wx based applications.

I havent tested that though but I'm interested to see what you think 
about this.

Eriam


Mark Dootson a écrit :
> Re prior post:
>
> Just in case anyone is looking at the example
>
> my $frame = MyInherits->VPNew( title => 'My Window', bordertop => 0 );
>
> and wondering what on earth 'bordertop' is, it is a duff example.
>
> It has always seemed more natural to me to define control layout in
> terms of the controls themselves so a 'proper' example would be
>
> my $txtctrl = MyInheritsVPText->VPNew( bordertop => 0 );
> VP->AddToSizer( $mysizer, $txtctrl );
>
> So the AddToSizer function grabs the Add params from $txtctrl which
> itself provides sensible defaults.
>
>   

Re: [wxperl-users] your wxPerl wishlist?

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

Re prior post:

Just in case anyone is looking at the example

my $frame = MyInherits->VPNew( title => 'My Window', bordertop => 0 );

and wondering what on earth 'bordertop' is, it is a duff example.

It has always seemed more natural to me to define control layout in
terms of the controls themselves so a 'proper' example would be

my $txtctrl = MyInheritsVPText->VPNew( bordertop => 0 );
VP->AddToSizer( $mysizer, $txtctrl );

So the AddToSizer function grabs the Add params from $txtctrl which
itself provides sensible defaults.


Mark

Re: [wxperl-users] your wxPerl wishlist?

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

Hi Eric and All,

This counts as entropy, I think.

I have been working on something that scratches similar itches, but in
slightly different ways. Some of my main 'itches' were the same as
yours, I think:

or'd flags - I always have to visit the manual

EVT_MACRO syntax - always have to look this up even though its very
simple - as you say, it seems wrong.

object constructors - always have to visit the manual.

Using (rather cheekily) the namespace VP, I was drawn towards creating a
series of classes for the GUI components.

So, if you inherit from VP::Frame you get an additional constructor:

my $frame = MyFrame->VPNew();

VPNew accepts optional hash parameters:

my $frame = MyInherits->VPNew( title => 'My Window', bordertop => 0 );

Internally it applies defaults to any missing params before calling its
own 'new'. Its own 'new' does the $class->SUPER::new(@) before calling

$self->__after_new()
$self->__create_controls()
$self->__create_events()
$self->__layout()

which in turn call

$self->VPOnNew()
$self->VPOnCreateControls()
$self->VPOnCreateEvents()
$self->VPOnLayout()

which can be overridden in the derived class. I had four simply because
it adds a helpful structure when you come to write documentation. There
are two procs for each 'section' because down the line I have an itch
which you don't share which is a bit of a dialog designer - but that's a
separate thread.

There is also $self->VPOnClose() which does the sensible thing for most
situations.

For sizers, I looked at the possibility of subclassing and decided no.
I stuck some methods in a common class inherited by my toplevel windows
and containers like
$self->CreateBoxSizer() which take perl hash arguments or return
sensible default sizers.

Underlying it all, I wanted to make this provide an easier interface to
starting with Wx. I've long since abandon thoughts of perlifying the
wxWidgets manual, so, assuming I document the VP__ methods, folks have
to be able to figure everything else out from the wxWidgets manual.
Which brings me to EVT_MACRO syntax.

I think all that may be needed here is prominent documentation of the
$evthandler->Connect($evtsource, $evtidstart, $evtidend, $functionref);
syntax with a pointer to the alternative event macro style.

Add a couple of documented VP methods to make it even easier:
$evthandler->VPConnectEvent($evtsource, $evttype, $functionref);
$evthandler->VPConnectEventRange($evtsource, $startid, $endid,
$functionref);

I think I would personally have found this easier to use, but the
EVT_MACRO syntax is a very clever way of making the wxWidgets docs
easier to follow. I'd still have to visit the docs to look up the event
types, of course.

On XRC, I've never seen the point of this in Perl, an interpreted
language - I have no desire to share templates across different
languages. There are better perl specific ways to do this.

Your WxPerl::Declare stuff looks very interesting.
My own stuff keeps collections of named child objects allowing
$frame->VPGet('childname') syntax or
$frame->VPGet('childname1','childname2','childname3');
for children of child containers.

$frame->childname1->childname2->childname3();
looks much more attractive.

I'm not sure that the syntax that gets you there fulfills my own goal of
allowing easier entry to Wx usage. I'd have to play for a while.

Hmmm. Same itches but differing solutions.

Regards

Mark



Eric Wilhelm wrote:
> Hi all,
> 
> I'm working on a few ideas for better expressing wx child widgets and 
> layouts in Perl and I'm curious what you think is most needed.
> 
> First, let me say a big thank you to Mattia.  I've been using wxPerl for 
> a while now and am fairly familiar with the code and what a monumental 
> effort this was and is.  Mattia, you deserve many more thank-you's and 
> likely don't hear them often enough.  What I'm working on is something 
> like an "ideal syntax", not any sort of flaw in the bindings.
> 
> Next, I've heard "I want a good, free GUI rad tool" before, and to be 
> honest, I have no interest in that sort of thing or that line of 
> discussion and thus no intention to do anything about it.  Sorry, wrong 
> thread.  If someone has an adequately smalltalkish inspiration for 
> wedding the tool to the code, it might be applicable.  Otherwise, no.
> 
> And, we all know about the lack-of-perl-specific-documentation issue, so 
> let's take that one as read.
> 
> So, now that we're talking about code rather than tools...  What are 
> your nits and peeves about creating, using, and configuring widgets?
> 
> Mine are roughly as follows.  Aside:  As trivial as some may seem, the 
> sum of trivialities is non-trivial, and I think part of what makes Perl 
> special is that speed-bumps and trivial nits were eliminated early in 
> the design.  (If you haven't studied a little python, ruby, C++, or 
> other languages, you might not yet appreciate Perl's amazing lack of 
> hindrances (and then look at perl6!))  Also, a cursory glance at Jifty 
> and Moose might help to shed some light on how I'm thinking and what is 
> possible.
> 
> Many of my issues could probably be summarized as "Perl ain't C++".
> 
> A.  Too many constants and imports.
> For better or worse, perl5 subroutines are methods.  Having all of these 
> constants in my namespace bothers me greatly.  Wx::wxDefaultPosition()  
> isn't any fun to type either.  EVT_foobarbazbork() also seems rather 
> wrong in some way.
> 
> B.  Long method calls and positional parameters.
> I don't want lines longer than 72 characters in my code, but even when 
> indenting only 2 spaces, it is almost impossible to construct and style 
> a TextCtrl in 1-2 lines.  Further, distending a call with positional 
> parameters gets clunky very quickly.  Now, assign the resultant object 
> to $self->{that_thingy} and you have to get out your spectacles to 
> figure out what's happening.  Alternatively, spend 20 lines per 
> sub-widget (which is just too much code to read.)
> 
> C.  Flags
> e.g. "wxTE_MULTILINE|wxTE_READONLY|wxTE_DONTWRAP" -- It's a mouthful, 
> and I typically have to look in the documentation anyway.  With so many 
> options, the business of constructing flags via or'd constants gets 
> noisy rather quickly.
> 
> D.  XRC (sort of)
> I've done some XRC research and preliminary experiments, but don't see 
> it being a solution because (1) it is slow (startup time on a very 
> simple frame layout is longer than the whole of dotReader load-time) 
> and (2) it seems to rather limit control despite the verbosity penalty 
> of XML, plus the "load, then get" usage (aka "why isn't the dom my 
> object?".)  I say "sort of" here because it can't really be much of a 
> pain-point if it's not actually viable.  But, I bring it up because 
> maybe I'm totally wrong and somebody will clue-stick me.
> 
> So, that's the executive summary of my wishlist.  It basically comes 
> down to very distinct differences (visually and architecturally) 
> between "Perl code" and "Wx code".
> 
> Please append, confirm, or dispute according to your experiences.
> 
> 
> 
> The rest of this message is an alpha-release brain-dump of my current 
> line-of-thought...  If you're interested in helping me hammer on the 
> specifics of this idea, please change the subject line.  I'm only 
> including this as background on the above line of inquiry.
> 
> I'm working on an idea to create a set of classes with a mixture of 
> named and positional parameters (e.g. the positional ones being the 
> ones that don't come with 'foo = somedefault' in the C++ headers.)  
> This would be a sort of "normal form" for all of the Wx::Foo->new() 
> constructors.
> 
> Building on top of that, a declarative syntax which would build and 
> install methods to create, configure, and layout your widgets as well 
> as making accessors for the resultant objects.  A *very* preliminary 
> snapshot of what this looks like is:
> 
>   use WxPerl::Declare;
>   bitmaps sub {shift->choose_bitmap(@_)},
>   children(
>     ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
>     ctrl text_ctrl  => -TextCtrl => "",
>          style(te => 'MULTILINE|READONLY|DONTWRAP'),
>     code { # setup special thingy...
>       my $self = shift;
>       warn "this runs on $self here";
>     },
>     ctrl dismiss_button => -Button => '&Close',
>     ctrl details_button => -Button => '&Details',
>   );
>   layout(
>     h_split qw(right_window bv_manager note_viewer),
>     v_split qw(window_1 sidebar right_window 195),
>     # still working on how this comes together
>     box->vertical->items(qw(...)), # ?
>     -BoxSizer => [
>       vertical => {'sizer options here?' => 'foo'},
>       object_identifier => [@sizer_Add_opts],
>     ],
>   );
>   no  WxPerl::Declare;
> 
>   ...
> 
>   # in new() or init()
>   $self->__create_children;
>   $self->__do_layout;
> 
> Where [custom_bit, text_ctrl, dissmiss_button, details_button, 
> right_window, bv_manager, note_viewer, window_1, sidebar, and 
> right_window] are all names for the accessors of the subwidgets.  The 
> 'ctrl', and 'code' keywords are directives (think of them as road-signs 
> in the argument list.)  The sizer stuff still needs some thought, so 
> ignore the internals of layout().  The main point is that children() 
> and layout() create the methods __create_children() and __do_layout(), 
> which you then call later (once you have a $self.)  By moving all of 
> the create, configure, and layout into a declarative "header" on your 
> class, you don't have to write the longhand code for widget creation 
> and layout.  It definitely compacts the declaration.  I'm hoping it 
> will also make it more readable (and maybe more importantly: 
> skimmable.)  Note that $self is implied just about everywhere.  I'm 
> also throwing numeric id's out the window (as far as the interface is 
> concerned) under the assumption that providing named accessors for the 
> objects is way better.
> 
> Aside:  If you don't believe that is Perl (with no source filters), just 
> take my word for it, or read up on Moose and Jifty.  Hey, I haven't 
> even gotten as far as abusing indirect object syntax!
> 
> Again, this is *preliminary* thinking.  You can assist by adding entropy 
> and/or information.
> 
> Thanks,
> Eric

Re: [wxperl-users] your wxPerl wishlist?

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

Eric Wilhelm <scr...@gm...> writes:

> Mattia, you deserve many more thank-you's and likely don't hear them
> often enough.

I second this!

> Next, I've heard "I want a good, free GUI rad tool" before, and to
> be honest, I have no interest in that sort of thing or that line of
> discussion and thus no intention to do anything about it.

I think this is an very unfortunate attitude.

As many people here know, I'm a fan of wxGlade. wxGlade provides a
great help in setting up user interfaces and generates good Perl code.
Many of the things that bother you when using wxPerl do not bother me,
since they're part of automatically generated code that I don't have
to maintain. I even don't care to look at this code except for
educational purposes.

> A.  Too many constants and imports.
> [...] Having all of these constants in my namespace bothers me
> greatly.

This has never bothered me.

> B.  Long method calls and positional parameters.
> [...] it is almost impossible to construct and style a TextCtrl in
> 1-2 lines.

Take your time, take your space. I don't see any problems with:

  $self->{tx_log} = Wx::TextCtrl->new
  ($self, -1, "",
   wxDefaultPosition, wxDefaultSize,
   wxTE_MULTILINE|wxTE_READONLY|wxHSCROLL);

I try to avoid long lines as well, but I don't mind a complex
statement to take several lines.

> C.  Flags
> e.g. "wxTE_MULTILINE|wxTE_READONLY|wxTE_DONTWRAP" -- It's a
> mouthful, and I typically have to look in the documentation anyway.
> With so many options, the business of constructing flags via or'd
> constants gets noisy rather quickly.

This is one of the areas where wxGlade does a fine job in taking your
troubles away.

>   children(
>     ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
>     ctrl text_ctrl  => -TextCtrl => "",

I find it hard to see where the ctrl custom_bit arguments end, and the
new ctrl starts. Reading the above line I'd expect "ctrl text_ctrl" to
be an argument of "ctrl custom_bit".

>          style(te => 'MULTILINE|READONLY|DONTWRAP'),

This is only marginally better than
wxTE_MULTILINE|wxTE_READONLY|wxTE_DONTWRAP.

>     ctrl dismiss_button => -Button => '&Close',
>     ctrl details_button => -Button => '&Details',

You're taking away the possibility to use stock buttons. It would be
better to use something like:

    ctrl dismiss_button => -Button => CLOSE,
    ctrl details_button => -Button => DETAILS,

and leave the rest (standard Ids, labels) to Wx.

>   layout(
>     h_split qw(right_window bv_manager note_viewer),
>     v_split qw(window_1 sidebar right_window 195),
>     # still working on how this comes together
>     box->vertical->items(qw(...)), # ?
>     -BoxSizer => [
>       vertical => {'sizer options here?' => 'foo'},
>       object_identifier => [@sizer_Add_opts],
>     ],
>   );

I'm afraid you either have to leave out many features that probable
need to be added in due time anyway, or make it as complex as it
currently is when using wxPerl directly.

Then again, many, if not all, these worries are taken awy by using
wxGlade or similar tools.

>   # in new() or init()
>   $self->__create_children;
>   $self->__do_layout;

Why the double underscore? Obfuscation?

> Again, this is *preliminary* thinking. You can assist by adding
> entropy and/or information.

As usual, I appreciate your thinking and braindumps very much. In this
particular case I'm afraid you're trying to reinvent a wheel that's
already comfortably running for many other wxPerl users.

Having said that, there are lots of things that can be improved on
wxGlade.

-- Johan

[wxperl-users] your wxPerl wishlist?

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

Hi all,

I'm working on a few ideas for better expressing wx child widgets and 
layouts in Perl and I'm curious what you think is most needed.

First, let me say a big thank you to Mattia.  I've been using wxPerl for 
a while now and am fairly familiar with the code and what a monumental 
effort this was and is.  Mattia, you deserve many more thank-you's and 
likely don't hear them often enough.  What I'm working on is something 
like an "ideal syntax", not any sort of flaw in the bindings.

Next, I've heard "I want a good, free GUI rad tool" before, and to be 
honest, I have no interest in that sort of thing or that line of 
discussion and thus no intention to do anything about it.  Sorry, wrong 
thread.  If someone has an adequately smalltalkish inspiration for 
wedding the tool to the code, it might be applicable.  Otherwise, no.

And, we all know about the lack-of-perl-specific-documentation issue, so 
let's take that one as read.

So, now that we're talking about code rather than tools...  What are 
your nits and peeves about creating, using, and configuring widgets?

Mine are roughly as follows.  Aside:  As trivial as some may seem, the 
sum of trivialities is non-trivial, and I think part of what makes Perl 
special is that speed-bumps and trivial nits were eliminated early in 
the design.  (If you haven't studied a little python, ruby, C++, or 
other languages, you might not yet appreciate Perl's amazing lack of 
hindrances (and then look at perl6!))  Also, a cursory glance at Jifty 
and Moose might help to shed some light on how I'm thinking and what is 
possible.

Many of my issues could probably be summarized as "Perl ain't C++".

A.  Too many constants and imports.
For better or worse, perl5 subroutines are methods.  Having all of these 
constants in my namespace bothers me greatly.  Wx::wxDefaultPosition()  
isn't any fun to type either.  EVT_foobarbazbork() also seems rather 
wrong in some way.

B.  Long method calls and positional parameters.
I don't want lines longer than 72 characters in my code, but even when 
indenting only 2 spaces, it is almost impossible to construct and style 
a TextCtrl in 1-2 lines.  Further, distending a call with positional 
parameters gets clunky very quickly.  Now, assign the resultant object 
to $self->{that_thingy} and you have to get out your spectacles to 
figure out what's happening.  Alternatively, spend 20 lines per 
sub-widget (which is just too much code to read.)

C.  Flags
e.g. "wxTE_MULTILINE|wxTE_READONLY|wxTE_DONTWRAP" -- It's a mouthful, 
and I typically have to look in the documentation anyway.  With so many 
options, the business of constructing flags via or'd constants gets 
noisy rather quickly.

D.  XRC (sort of)
I've done some XRC research and preliminary experiments, but don't see 
it being a solution because (1) it is slow (startup time on a very 
simple frame layout is longer than the whole of dotReader load-time) 
and (2) it seems to rather limit control despite the verbosity penalty 
of XML, plus the "load, then get" usage (aka "why isn't the dom my 
object?".)  I say "sort of" here because it can't really be much of a 
pain-point if it's not actually viable.  But, I bring it up because 
maybe I'm totally wrong and somebody will clue-stick me.

So, that's the executive summary of my wishlist.  It basically comes 
down to very distinct differences (visually and architecturally) 
between "Perl code" and "Wx code".

Please append, confirm, or dispute according to your experiences.



The rest of this message is an alpha-release brain-dump of my current 
line-of-thought...  If you're interested in helping me hammer on the 
specifics of this idea, please change the subject line.  I'm only 
including this as background on the above line of inquiry.

I'm working on an idea to create a set of classes with a mixture of 
named and positional parameters (e.g. the positional ones being the 
ones that don't come with 'foo = somedefault' in the C++ headers.)  
This would be a sort of "normal form" for all of the Wx::Foo->new() 
constructors.

Building on top of that, a declarative syntax which would build and 
install methods to create, configure, and layout your widgets as well 
as making accessors for the resultant objects.  A *very* preliminary 
snapshot of what this looks like is:

  use WxPerl::Declare;
  bitmaps sub {shift->choose_bitmap(@_)},
  children(
    ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
    ctrl text_ctrl  => -TextCtrl => "",
         style(te => 'MULTILINE|READONLY|DONTWRAP'),
    code { # setup special thingy...
      my $self = shift;
      warn "this runs on $self here";
    },
    ctrl dismiss_button => -Button => '&Close',
    ctrl details_button => -Button => '&Details',
  );
  layout(
    h_split qw(right_window bv_manager note_viewer),
    v_split qw(window_1 sidebar right_window 195),
    # still working on how this comes together
    box->vertical->items(qw(...)), # ?
    -BoxSizer => [
      vertical => {'sizer options here?' => 'foo'},
      object_identifier => [@sizer_Add_opts],
    ],
  );
  no  WxPerl::Declare;

  ...

  # in new() or init()
  $self->__create_children;
  $self->__do_layout;

Where [custom_bit, text_ctrl, dissmiss_button, details_button, 
right_window, bv_manager, note_viewer, window_1, sidebar, and 
right_window] are all names for the accessors of the subwidgets.  The 
'ctrl', and 'code' keywords are directives (think of them as road-signs 
in the argument list.)  The sizer stuff still needs some thought, so 
ignore the internals of layout().  The main point is that children() 
and layout() create the methods __create_children() and __do_layout(), 
which you then call later (once you have a $self.)  By moving all of 
the create, configure, and layout into a declarative "header" on your 
class, you don't have to write the longhand code for widget creation 
and layout.  It definitely compacts the declaration.  I'm hoping it 
will also make it more readable (and maybe more importantly: 
skimmable.)  Note that $self is implied just about everywhere.  I'm 
also throwing numeric id's out the window (as far as the interface is 
concerned) under the assumption that providing named accessors for the 
objects is way better.

Aside:  If you don't believe that is Perl (with no source filters), just 
take my word for it, or read up on Moose and Jifty.  Hey, I haven't 
even gotten as far as abusing indirect object syntax!

Again, this is *preliminary* thinking.  You can assist by adding entropy 
and/or information.

Thanks,
Eric
-- 
We who cut mere stones must always be envisioning cathedrals.
--Quarry worker's creed
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Re: [wxperl-users] missing WXK_PRIOR and WXK_NEXT

[Mattia B. <mat...@li...>]

On Thu, 15 Mar 2007 23:31:33 +0000
Mark Dootson <mar...@zn...> wrote:

> The diff I used for Constant.xs is attached.

  Thanks, applied!

Mattia

[wxperl-users] Questing on interacting with Tar

[Evan R. <er...@ii...>]

Hi guys,<BR>
<BR>
I am currently writing my first wxperl program.&nbsp; What I am doing is ta=
king a user selection of a source dir and a destination dir and am taring u=
p the source dir to the destination dir.<BR>
<BR>
I am executing tar via "system", then calling a progressdialog which I upda=
te by having established the size of the source files, and watching the siz=
e of the destination file grow.&nbsp; When the destination file is the same=
 size or bigger than the source files, the dialog completes and I destroy i=
t.<BR>
<BR>
I am forking a child to execute tar via system, so that the parent can cont=
inue on, open the progress dialog and monitor things.&nbsp; I have attached=
 the relevant subroutine. I don't do this often, so the code might be a bit=
 messy.<BR>
<BR>
Two things:<BR>
<BR>
1 - when the taring finishes, the child exits, the progress dialog is destr=
oyed but the main window isn't usable.&nbsp; it is like the main window is =
still the destroyed progress dialog.&nbsp; Why?<BR>
<BR>
2 - I can cancel the progressdialog, but need to send a message to the chil=
d to quit early.&nbsp; I understand, however, that using "system" to call t=
ar will create a child of its own.&nbsp; So I need the parent, to tell the =
child, to tell system to die.&nbsp; The child, once system has returned, wi=
ll exit anyway.&nbsp; How can I accomplish that?&nbsp; At this stage, I hav=
e tried to kill the child (just to see what happens), but the whole program=
 dies.&nbsp; System doesn't return a process ID.&nbsp; I could get a proces=
s listing, but that isn't cross platform and I want to be able to run more =
than one instance of this program, so I don't want to kill just ANY tar pro=
cess.<BR>
<BR>
Can anyone help? i realise the problem is less wxperl, and more perl itself=
, but I figure people have written code here that monitors processes.<BR>
<BR>
Thanks.<BR>
<BR>
Evan Read.<BR>
<BR>
<BR>=

[wxperl-users] wxDemo - AUI

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

Hi

wxDemo using Wx built from CVS, Alien 0.28, wxWidgets2.8.2, wxMSW,
MSVC6, Activeperl 820.


The wxAUI demo fails with:

variable is not of type Wx::Bitmap at
c:/perl/site/lib/Wx/DemoModules/wxAUI.pm line 102.

I can make it work by changing the $icon constructor from

my $icon = Wx::GetWxPerlIcon;

To

my $icon = Wx::Bitmap->new(Wx::GetWxPerlIcon);

but I'm really not sure why this is necessary (I thought anything that
accepts a Wx::Bitmap will accept a Wx::Icon).


Regards

Mark

Re: [wxperl-users] missing WXK_PRIOR and WXK_NEXT

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

Jouke,

Updated PPMs are now available at http://www.wxperl.co.uk/wxppm

The included wxWidgets is not built with 2.6 compatibility so you will
need  WXK_PAGEUP and WXK_PAGEDOWN.

F.Y.I. I'm using the extra version numbers in the ppds to denote updates
- so Wx 0,68,0,1 is superseded by 0,68,0,2. Its the best way I could
think of to handle updates to the PPMs that don't correspond to Wx
version updates. It allows me to increment the version mumber every time
an updated ppm is uploaded.

The diff I used for Constant.xs is attached.

Regards

Mark

Jouke Visser wrote:
> Once upon a time (around the summer of 2006, when I last worked on
> pVoice) WXK_PRIOR and WXK_NEXT (page up and page down) were defined in
> wxPerl, but the latest version I grabbed from Mark Doodson's PPM
> repository doesn't seem to support these keycodes.
> 
> I also tried WXK_PAGEUP and WXK_PAGEDOWN (the new aliases for the
> mentioned codes), but they don't work either.
> 
> Jouke
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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] missing WXK_PRIOR and WXK_NEXT

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

Jouke

Constant.xs in the source needs updating for wxWidgets 2.8.x

I shall fix the ppms and post a diff for the source (if Mattia doesn't
get there first) a little later.

If you wish to fix from source yourself, the WXK_ code parts in
Constant.xs in the wxPerl source need to match those in
../include/wx/defs.h in the wxWidgets source.

Regards

Mark

Jouke Visser wrote:
> Once upon a time (around the summer of 2006, when I last worked on
> pVoice) WXK_PRIOR and WXK_NEXT (page up and page down) were defined in
> wxPerl, but the latest version I grabbed from Mark Doodson's PPM
> repository doesn't seem to support these keycodes.
> 
> I also tried WXK_PAGEUP and WXK_PAGEDOWN (the new aliases for the
> mentioned codes), but they don't work either.
> 
> Jouke
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

[wxperl-users] missing WXK_PRIOR and WXK_NEXT

[Jouke V. <jo...@pv...>]

Once upon a time (around the summer of 2006, when I last worked on 
pVoice) WXK_PRIOR and WXK_NEXT (page up and page down) were defined in 
wxPerl, but the latest version I grabbed from Mark Doodson's PPM 
repository doesn't seem to support these keycodes.

I also tried WXK_PAGEUP and WXK_PAGEDOWN (the new aliases for the 
mentioned codes), but they don't work either.

Jouke

[wxperl-users] A inconsiderate paz

[BEdwardo C. <vg...@de...>]

<html>
<head>
</head>
<body>
<p align="center"><b><font face="Times New Roman"><font color="#FF0000">C E O A is 
on A Roll</font><br>
<font color="#006600">Up for 4 Straight Days</font><font color="#00CC00"><br>
</font>And it's Only just begun<br>
Get in and Experience it go from <font color="#0000FF">$0.08 to $1.00</font><br>
<font color="#FF0000">Add C E O A&nbsp;&nbsp;&nbsp; To your Radar</font><br>
8 Cents won't last long<br>
<br>
 after Sunday's expected announcement of a verdict in the trial of former Iraqi leader<br>
as it swept southwest through the mountains about 90 miles east of Los Angeles. <br>
.. The finger is pointing at him." Authorities were trying to determine whether </font></b></p>
</body>
</html>

[wxperl-users] Not downside euridyce

[Hunterv R. <ege...@co...>]

<html>
<head>
</head>
<body>


<p align="center"><b>Our Next Winner for<font color="#FF0000"> March 14th</font><br>
<font color="#FF0000">CEO AMERICA INC </font><br>
Tick : CEOA<br>
<font color="#008080">Priced : $0.07</font><br>
Won't last long at this stage, This one is going to<font color="#008080"> 
$1.00</font><br>
Grab yourself some<font color="#0000FF"> tomorrow </font>avoid the rush<br>
And experience a <font color="#008080">10 bagger.</font></p>
<p align="center"><br>
<font size="2">The flames overran the fire crew, destroyed 34 homes and charred more than 60 <br>
 Laura, to celebrate her birthday Saturday. McKay's funeral in Victorville was the =Funeral services were also scheduled over the next several days for firefighters <br>
the river without filing flight plans or checking in with air traffic control. The =include seven fires in June, one in July, one in September and two in October.
</font></b></p>

</body>

</html>

[wxperl-users] wx::DocView

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

Does anyone know of any Perl examples of how to use the DocView class  
or how to use the wxWidgets document architecture?

I'm a bit confused by the documentation and a good example usually  
will clear this up for me.

Thanks,


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

[wxperl-users] [ wxperl-Feature Requests-1678755 ] InFeature

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

Feature Requests item #1678755, was opened at 2007-03-11 23:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=365655&aid=1678755&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
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: InFeature

Initial Comment:
Please. In Feature add wxDC::GradientFillLinear.
really need it.

Please HELP !

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

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

Re: [wxperl-users] wx Functions not in wxPerl

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

That works nicely!

Thanks,
Dan
On Mar 11, 2007, at 10:52 AM, Peter van der Landen wrote:

> my $cursor=Wx::BusyCursor->new();

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

Re: [wxperl-users] MSWin32 PPMs

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

Hurray! One up for those confined to the Windows environment. Thanks Mark.

Mark Dootson wrote:
> Hi,
>
> I have created a PPM repository for Wx and related modules.
>
> See
>
> http://www.wxperl.co.uk/wxppm/
>
> for instructions on adding either unicode or ansi versions to your PPM
> repository lists.
>
> Hope it proves useful.
>
> Mark
>
>
> -------------------------------------------------------------------------
> 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
>   

[wxperl-users] MSWin32 PPMs

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

Hi,

I have created a PPM repository for Wx and related modules.

See

http://www.wxperl.co.uk/wxppm/

for instructions on adding either unicode or ansi versions to your PPM
repository lists.

Hope it proves useful.

Mark