wxperl-users — For wxPerl users

Re: [wxperl-users] (?:W|w)xPerl::Constructors

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

On Sun, 18 Mar 2007 18:38:55 -0700
Eric Wilhelm <scr...@gm...> wrote:

  Hi,

> Now that it is roughly done, I think all I need is a name before putting 
> it on CPAN.  Any objections to wxPerl::Constructors?

  Not from me :-) you might want to ask for advice on module-authors
before starting a new top-level namespace, though.

> In the end, I went with the longhand under the assumption that you 
> almost never need to specify a value for position.  Is that about 
> right?  I'm thinking it *might* get used in dialogs and frames if the 
> window manager can't do its job for some reason.

  This is the only use I can think of, and I find 'position' better
than the other alternatives you mentioned.

Regards
Mattia

Re: [wxperl-users] declarative syntax (please, "longer" ne "better"!)

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

--- Eric Wilhelm <scr...@gm...> wrote:

> # from Sergei Steshenko
> # on Sunday 18 March 2007 04:08 pm:
> 
> >>   ...
> >>   funky_array => do {my @p = (1,2);
> >>     [1,2,map({push(@p, my $v = shift(@p)+$p[0]); $v} 3..100)]},
> >>   ...
> >
> >Why should I load my brain trying to understand what $p means ?
> >And what is $v if I may ?
> 
> Well, one-letter variables that only appear within a closed block on two 
> lines of code never bothered me.  I prefer to think about the algorithm 
> and not whether the code *appears* to be readable.  It's encapsulated 
> by virtue of its seeming opacity.
> 
> >I prefer readable code, not a short one.
> 
> I prefer correct code.  If my subtlety eludes you, go run yours and see 
> what answer you get.  It is just a long-winded [map({2**$_} 0..99)] 
> (i.e. a doubling sequence) which is at-a-glance very readably wrong.
> 
> I really don't understand why so many people seem to think that longer 
> code is somehow better and more readable.  Have they had a readability 
> study?  Would you call a 5000-page novel "readable"?  Is a 20-hour 
> movie "watchable"?  If you're writing 10 times as much Perl as you 
> should, why not just use C?  You'll have the same number of bugs, but 
> they'll run faster :-D
> 
> A local news station once had (maybe still does have) the slogan "Clear, 
> accurate, and to-the-point."  I always thought it ironic that they 
> would use so many words to claim that they are "concise".
> 
> I'm not claiming that code should be all one-character variable names in 
> a single chain of compile-time map() statements with no carriage 
> returns (for that, you need lisp.)  Rather, code should not be any 
> longer than it needs to be.  A large part of Perl's expressiveness 
> comes from context, implied information, and concision.  There's more 
> than one way to do it, but there's a whole lot of ways to do it wrong.
> 
> Concise and correct code beats long-winded incorrect code.  Further, 
> short and incorrect code is easier to fix.  In fact, the longer code is 
> obfuscated by its shear size.  Ever heard the phrase "needle in a 
> haystack"?  For code to be readable, you have to understand what it is 
> doing.  I could use utf8 with greek characters for variable names and 
> it would make as much sense and still be correct.  We have two things 
> @p which get rotated as the new one $v arrives.  How is that more 
> complicated than your longhand variable names?  (If you haven't found 
> the bug, I think you need yet another variable to hold the new value.  
> Then it will give 1,1,1,1,1 instead of 1,2,4,8,16.  But to get 
> 1,2,3,5,8,13 you have to deal with the seeding.)
> 
> So you want better variable names and comments?  Fine.  The algorithm is 
> still more clearly (and correctly) expressed in less code.
> 
>   funky_array => do {
>     my @pair = (1,2); # previous pair
>     [1,2, # seed first
>       map({ # roll-over the pair while calculating the next val
>         push(@pair, my $new_value = shift(@pair)+$pair[0]);
>       $new_value
>     } 3..100)]
>   },
> 
> Or,
> 
>   funky_array => do {
> 	my @out = my @pair = (1,2); # seed/previous pair
> 	for(3..100) {
>       # roll-over the pair while calculating the next value
>       # I call it '$new_value' because it is new, and a value.
> 	  push(@pair, my $new_value = shift(@pair)+$pair[0]);
>       push(@out, $new_value);
>     }
> 	\@out
>   },
> 
> Well, that's getting long-winded.  But, to make sure the dead horse is 
> thoroughly beaten, let me just say that you (hopefully) won't be 
> searching your codebase for bugs and skimming this e-mail in 
> Foo::Bar.pm.  Code is going to be read/skimmed over and over and over 
> and over and over again.  You pay for the extra lines of code *all the 
> time*.  You only pay for the extra density when you're working on that 
> particular chunk.
> 
> --Eric
> -- 
> "Because understanding simplicity is complicated."
> --Eric Raymond
> ---------------------------------------------------
>     http://scratchcomputing.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
> 

I just reject outright the code with $p, $v, $i, $j - I admit I am too dumb
to understand it.

Sorry, I was educated that names have to be meaningful and self-explanatory,
which allows one to have self-documented coded, i.e. code needing practically
no comments, because the comments are not needed.

Everything should be obvious; comments should be needed only in places where
the code is not obvious.

Regards,
  Sergei.


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


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

[wxperl-users] (?:W|w)xPerl::Constructors

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

Hi all,

Now that it is roughly done, I think all I need is a name before putting 
it on CPAN.  Any objections to wxPerl::Constructors?

Documentation:

  http://scratchcomputing.com/tmp/WxPerl-Constructors.html
  http://scratchcomputing.com/tmp/WxPerl-Constructors-doc.html
  http://scratchcomputing.com/tmp/WxPerl-Constructors-argmap.html

The main change in WP::C::doc.pod being to change 'pos' to 
'position' (which avoids the aesthetic issue of using a perl builtin 
which often highlights as a function despite the fact that perl allows 
it to be unquoted via => hash-quoting rules.)  I thought about 'posi', 
which is good in that it has the same number of characters as 'size'.  
Also, 'poz' might work since it is pronounced the same.  Alternatively 
'place' keeps us in the same neighborhood as 'style' in terms of key 
length.

In the end, I went with the longhand under the assumption that you 
almost never need to specify a value for position.  Is that about 
right?  I'm thinking it *might* get used in dialogs and frames if the 
window manager can't do its job for some reason.  For me, it has always 
been a piece of padding that I have to mention before I can specify a 
style.  If someone has a frequent use case, I can shorten it.

Anyway... running code:

  svn co http://scratchcomputing.com/svn/WxPerl-Constructors/trunk

Thanks,
Eric
-- 
Consumers want choice, consumers want openness.
--Rob Glaser
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Re: [wxperl-users] declarative syntax (please, "longer" ne "better"!)

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

# from Sergei Steshenko
# on Sunday 18 March 2007 04:08 pm:

>> =A0 ...
>> =A0 funky_array =3D> do {my @p =3D (1,2);
>> =A0 =A0 [1,2,map({push(@p, my $v =3D shift(@p)+$p[0]); $v} 3..100)]},
>> =A0 ...
>
>Why should I load my brain trying to understand what $p means ?
>And what is $v if I may ?

Well, one-letter variables that only appear within a closed block on two=20
lines of code never bothered me.  I prefer to think about the algorithm=20
and not whether the code *appears* to be readable.  It's encapsulated=20
by virtue of its seeming opacity.

>I prefer readable code, not a short one.

I prefer correct code.  If my subtlety eludes you, go run yours and see=20
what answer you get.  It is just a long-winded [map({2**$_} 0..99)]=20
(i.e. a doubling sequence) which is at-a-glance very readably wrong.

I really don't understand why so many people seem to think that longer=20
code is somehow better and more readable.  Have they had a readability=20
study?  Would you call a 5000-page novel "readable"?  Is a 20-hour=20
movie "watchable"?  If you're writing 10 times as much Perl as you=20
should, why not just use C?  You'll have the same number of bugs, but=20
they'll run faster :-D

A local news station once had (maybe still does have) the slogan "Clear,=20
accurate, and to-the-point."  I always thought it ironic that they=20
would use so many words to claim that they are "concise".

I'm not claiming that code should be all one-character variable names in=20
a single chain of compile-time map() statements with no carriage=20
returns (for that, you need lisp.)  Rather, code should not be any=20
longer than it needs to be.  A large part of Perl's expressiveness=20
comes from context, implied information, and concision.  There's more=20
than one way to do it, but there's a whole lot of ways to do it wrong.

Concise and correct code beats long-winded incorrect code.  Further,=20
short and incorrect code is easier to fix.  In fact, the longer code is=20
obfuscated by its shear size.  Ever heard the phrase "needle in a=20
haystack"?  For code to be readable, you have to understand what it is=20
doing.  I could use utf8 with greek characters for variable names and=20
it would make as much sense and still be correct.  We have two things=20
@p which get rotated as the new one $v arrives.  How is that more=20
complicated than your longhand variable names?  (If you haven't found=20
the bug, I think you need yet another variable to hold the new value. =20
Then it will give 1,1,1,1,1 instead of 1,2,4,8,16.  But to get=20
1,2,3,5,8,13 you have to deal with the seeding.)

So you want better variable names and comments?  Fine.  The algorithm is=20
still more clearly (and correctly) expressed in less code.

  funky_array =3D> do {
    my @pair =3D (1,2); # previous pair
    [1,2, # seed first
      map({ # roll-over the pair while calculating the next val
        push(@pair, my $new_value =3D shift(@pair)+$pair[0]);
      $new_value
    } 3..100)]
  },

Or,

  funky_array =3D> do {
	my @out =3D my @pair =3D (1,2); # seed/previous pair
	for(3..100) {
      # roll-over the pair while calculating the next value
      # I call it '$new_value' because it is new, and a value.
	  push(@pair, my $new_value =3D shift(@pair)+$pair[0]);
      push(@out, $new_value);
    }
	\@out
  },

Well, that's getting long-winded.  But, to make sure the dead horse is=20
thoroughly beaten, let me just say that you (hopefully) won't be=20
searching your codebase for bugs and skimming this e-mail in=20
=46oo::Bar.pm.  Code is going to be read/skimmed over and over and over=20
and over and over again.  You pay for the extra lines of code *all the=20
time*.  You only pay for the extra density when you're working on that=20
particular chunk.

=2D-Eric
=2D-=20
"Because understanding simplicity is complicated."
=2D-Eric Raymond
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

Re: [wxperl-users] declarative syntax

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

--- Eric Wilhelm <scr...@gm...> wrote:

> # from Sergei Steshenko
> # on Sunday 18 March 2007 02:15 pm:
> 
> >funky_array => [1, 2, 3, 5, 8 ...],
> ># element is the some of previous two,
> ># and this way 100 times; 
> 
> >So, this is Perl, and there is more than one to do it, and I would do
> > it this way:
> >
> >{
> >...
> >funky_array => do{
> >                 my @tmp_array;  # no name clash danger, the scope
> >                                 #  protects from name contention
> >
> >                 my $number_of_times = 100; # I said 100 times, dodn't
> > I ?
> >
> >                 my $previous_element = 0;
> >                 my $element = 1;
> >
> >                 while($number_of_times-- > 0)
> >                   {
> >                   $element += $previous_element;
> >                   push @tmp_array, $element;
> >                   $previous_element = $element;
> >                   }
> >
> >                 \@tmp_array; # the array reference to be returned
> >                 }
> >};
> >
> >So, the point of this example is that there should be
> > canonical/normalized data structure and there can be infinite number
> > of ways to produce it.
> 
> Fine.  But, you should be able to skim over the code in much less space.  
> When you want to build something based on a rolling pair of values, why 
> not use a rolling pair of values?
> 
>   ...
>   funky_array => do {my @p = (1,2);
>     [1,2,map({push(@p, my $v = shift(@p)+$p[0]); $v} 3..100)]},
>   ...

Why should I load my brain trying to understand what $p means ?

And why should help those claiming Perl is unreadable ?

And what is $v if I may ?

I prefer readable code, not a short one.

I remember a few days ago a colleague of mine was saying "'i' is current and 'j' is
previous". And the colleague had a real difficulty debugging her own code.
And I wanted to ask her "Why did you give your variables meaningless names in the
first place ?".

I wouldn't have written such a code in the first place - in my code previous is
previous and current is current.

Sorry.

--Sergei.

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



 
____________________________________________________________________________________
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] declarative syntax

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

# from Sergei Steshenko
# on Sunday 18 March 2007 02:15 pm:

>funky_array =3D> [1, 2, 3, 5, 8 ...],
># element is the some of previous two,
># and this way 100 times;=20

>So, this is Perl, and there is more than one to do it, and I would do
> it this way:
>
>{
>...
>funky_array =3D> do{
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my @tmp_array; =A0# no name clash dange=
r, the scope
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# =A0pr=
otects from name contention
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my $number_of_times =3D 100; # I said 1=
00 times, dodn't
> I ?
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my $previous_element =3D 0;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my $element =3D 1;
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while($number_of_times-- > 0)
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$element +=3D $previous_element;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0push @tmp_array, $element;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$previous_element =3D $element;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\@tmp_array; # the array reference to b=
e returned
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>};
>
>So, the point of this example is that there should be
> canonical/normalized data structure and there can be infinite number
> of ways to produce it.

=46ine.  But, you should be able to skim over the code in much less space. =
=20
When you want to build something based on a rolling pair of values, why=20
not use a rolling pair of values?

  ...
  funky_array =3D> do {my @p =3D (1,2);
    [1,2,map({push(@p, my $v =3D shift(@p)+$p[0]); $v} 3..100)]},
  ...

And once you know it is correct, you don't have to read it.  Of course,=20
I would put that in a method call and maybe even test that it gave the=20
correct answer.

And as far as understanding what it does.  With a little examination, it=20
is fairly clear that it doesn't do:

  ...
  funky_array =3D> [map({2**$_} 0..99)],
  ...

Thanks for helping to illustrate my point.  More code means more bugs. =20
Individual line complexity really doesn't mean much.  Bug density has=20
been shown to be roughly a constant proportion of SLOC across multiple=20
languages.

=2D-Eric
=2D-=20
perl -e 'srand; print join(" ",sort({rand() < 0.5}
  qw(sometimes it is important to be consistent)));'
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

Re: [wxperl-users] declarative syntax

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

--- Eric Wilhelm <scr...@gm...> wrote:

> # from Sergei Steshenko
> # on Saturday 17 March 2007 07:16 pm:
> 
> >I am not sure I clearly understand what it's about, but why new
> > syntax/language to describe hierarchical relationship if Perl already
> > supports hierarchical data structures ?
> 
> One word:  concisification
> 
> >my $children_array_ref = # or should it be hash ref ?
> 
> No, order matters.
> 
> >  [
> >    { # first child
> 
> oops, we lost the order now
> 
> >    custom_bit =>
> >      {
> ...
> >    text_ctrl =>
> >      {
> >      type => 'ctrl',
> >      label => "", # I'm not sure about this
> >      style =>
> >        {
> >        te => MULTILINE|READONLY|DONTWRAP 
> >        # these are meant to be bitwise OR'ed constants 
> >        } 
> 
> Yeah, but the te => 'string|string|string' means the style() function 
> can append wxTE_ to the front, so-as to Wx->"wxTE_$thing" it.
> 
> >      }
> >    },
> >
> >    { # second child
> >    ...
> >    }
> >  ];
> 
> >Whenever I see another language inside Perl, I'm getting really
> > nervous - another (possibly incomplete) definition, another (possibly
> > buggy) parser ...
> 
> Nope, no parser.
> 
> >Well, the original example is likely still Perl, but why a subroutine
> > where plain hierarchical data structure should suffice ?
> 
> The data structure would basically have to be array refs all the way 
> down.  Also, the style() function does some mapping.  The idea was 
> basically to make a mini-language that would add some unverbosity and 
> other conveniencification.
> 
> (The Bushism-ated words are jokes.  You should laugh now.  I'm not 
> really going to extendify the language like that.)
> 
> A sufficiently expressive data-structure would be good, but it wouldn't 
> be declarative.  The benefit of the declarative bits of code is that 
> their procedural guts can remove the need for ']]]]]]]]]]'(did I get 
> enough brackets in there?)-ish stuff.  I'm still on the fence about 
> many details of implementing either or both.
> 
> --Eric
> -- 
> software:  a hypothetical exercise which happens to compile.

I don't quite understand the ']]]]]]]]]]' part - do you think that nested
function calls are any better ?

The point of Perl data structures is that is is also (and primarily) code.

I.e. suppose you need to write something like this:

{
...
funky_array => [1, 2, 3, 5, 8 ...], # element is the some of previous two, and this way
                                    # 100 times; 
...
}
.

So, this is Perl, and there is more than one to do it, and I would do it
this way:

{
...
funky_array => do{
                 my @tmp_array;  # no name clash danger, the scope
                                 #  protects from name contention

                 my $number_of_times = 100; # I said 100 times, dodn't I ?

                 my $previous_element = 0;
                 my $element = 1;

                 while($number_of_times-- > 0)
                   {
                   $element += $previous_element;
                   push @tmp_array, $element;
                   $previous_element = $element;
                   }

                 \@tmp_array; # the array reference to be returned
                 }
};

So, the point of this example is that there should be canonical/normalized data
structure and there can be infinite number of ways to produce it.

IMO the power of Perl is anonymity - this ensures no name clashes, and the 'do'
statement is an anonymous executable/executed code block returning a value
(array reference in this case).

Define the canonical form and give user freedom to produce it - this is how
I'm writing my stuff.

...

FWIW, have a look at

http://exit1.org/Gtk2-Ex-FormFactory/

- though this is for gtk2-perl, the idea is still OK IMO.

Regards,
  Sergei.



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


 
____________________________________________________________________________________
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] mixing positional and named parameters

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

# from Mattia Barbon
# on Sunday 18 March 2007 04:19 am:

>=A0 The first is "WxPerl"; right name, wrong capitalization. =A0But this
>might be my flawed sense of aesthetics...

Well, it could be wxPerl::*.  I've been using 'WxPerl::*' in the few=20
extensions and convenience modules that I've done thus far for=20
dotReader, but haven't broken any of those into separate dists.

What would be the ideal namespace for extensions?  I guess my sense of=20
aesthetics doesn't like the de-facto Wx::Perl::*.

>=A0 The second is: I suppose I will need to derive all my classes from
>WxPerl::*. =A0

Yep.  The benefit here is maybe that you get to add more methods to=20
those classes from elsewhere.  If we can decide on an "enhancements"=20
namespace, we could conceivably have a whole pile of cooperating mixins=20
available as we figure out how to grow the API.  I'm not certain if=20
much is needed beyond the constructors though, so ponder that=20
accordingly.

  use wxPerl::Constructors;
  use wxPerl::TreeCtrl::FlyingSquirrel;

>Wouldn't it be better if Wx::Perl::Constructors added a=20
>'create' or 'make' (or whatever) method to all wxPerl classes? For
>example:

Hmm, I prefer Something->new(), but I've considered a complete=20
switcharoo on the Wx:: constructors via an import() option.  This=20
would, of course, need to be aware of caller() in order to not disturb=20
the rest of the system (though it would add a level to the call-stack=20
by the time we got to Wx::Button->new(), etc.  I'm thinking the whole=20
scheme will be installed via globs anyway, so where I install them=20
isn't that big of a deal.

=2D-Eric
=2D-=20
Cult: A small, unpopular religion.
Religion: A large, popular cult.
=2D- Unknown
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

Re: [wxperl-users] wxDemo - AUI

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

On Fri, 16 Mar 2007 01:41:22 +0000
Mark Dootson <mar...@zn...> wrote:

  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);

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

  Mostly.  Under GTK/Mac/Motif wxIcon derives from wxBitmap, and most
of the time there is a function overload to accept both icons and
bitmaps.  But not always.

Regards
Mattia

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

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

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

> I went back to wxGlade, only to find that the code it generates is
> both old and bugged.

FUD. I'm looking forward to your bug reports.

> Further, a tutorial makes it clear that wxGlade overwrites the code,
> so we cannot change it by hand.

More FUD.

As with many tools it takes a couple of minuted to get the hang of it. 

I use wxGlade on a daily basis. It works, generates good code, code
that works, and never overwrites my code. And saves me hours of boring
programming. 

> [...] 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.

Sounds like XRC all over again.

-- Johan

Re: [wxperl-users] mixing positional and named parameters

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

Hi,

I'd been working on the basis below. Its just a snippet but gives the idea.

Mark

#############################################################################
#
# Package VP::Frame
#
#############################################################################

package VP::Frame;
use base qw( Wx::Frame  VP::TopLevelWindow );

sub newVP {
    my $class = shift;
    my %parms = @_;
    my @allowedparms = qw(parent id title position size style name
vpname sizertype saveposition topwindow );
    if(VP::__vp_param_check(\%parms, \@allowedparms) ) {
VP::croak("$class allowed params = '" . join(',',@allowedparms) ); }

    $parms{parent} ||= VP->GetTopWindow();
    $parms{id} ||= -1;
    $parms{title} ||= VP->App->GetAppName();
    $parms{postition} ||= Wx::wxDefaultPosition;
    $parms{size} ||= Wx::wxDefaultSize;
    $parms{style} ||= Wx::wxDEFAULT_FRAME_STYLE;
    $parms{name} ||= '';
    $parms{vpname} ||= $parms{name};
    $parms{sizertype} ||= 'v';
    $parms{saveposition} ||= 'v';
    $parms{topwindow} ||= '0';

    $parms{id} = $VP::MAINWINDOW_ID if($parms{topwindow});

    my @args = ($parms{parent}, $parms{id}, $parms{title},
$parms{postition}, $parms{size}, $parms{style}, $parms{vpname},
$parms{sizertype}, $parms{saveposition}, $parms{topwindow} );
    my $self = $class->new(@args);
    return $self;
}



sub new {
    my $vpname = '';

    if( exists($_->[10]) && $_->[10] eq 'vptopwindow' ) {
        $_->[1] = $VP::MAINWINDOW_ID;
        if( exists($_->[7]) ) {
            if( $_->[7] !~ /[A-Za-z]/ ) { $_->[7] = 'TopWindow'; }
        } else {
            $vpname = 'TopWindow';
        }
    }

    $_->[1] = VP->GetTopWindow() if not exists $_->[1];
    $_->[2] = -1 if not exists $_->[2];
    $_->[3] = VP->App->GetAppName() if not exists $_->[3];
    $_->[4] = Wx::wxDefaultPosition if not exists $_->[4];
    $_->[5] = Wx::wxDefaultSize if not exists $_->[5];
    $_->[6] = Wx::wxDEFAULT_FRAME_STYLE if not exists $_->[6];

    $vpname = $_->[7] if exists $_->[7];
    my $sizertype = $_->[8] if exists $_->[8];
    $sizertype ||= 'v';
    my $saveposition = $_->[9] if exists $_->[9];
    $saveposition ||= 0;

    while(@_ > 7) {  pop(@_); }

    my $self = shift->SUPER::new(@_);

    #-----------------------------------
    #-- Set The Main Sizer
    #-----------------------------------

    $self->SetSizer( VP->CreateBoxSizer( style => $sizertype ) );

    #-----------------------------------
    #-- Initialize
    #-----------------------------------

    $self->__vp_init_class( $vpname, 'VP_Frame' );

    #-----------------------------------
    #-- Restore a saved screen position
    #-----------------------------------

    $self->{__vp_saveposition} = $saveposition;
    if( $self->{__vp_saveposition} && $self->IsVPNamedInstance() ) {
        # load the previous screen position
        my $left = VP->ReadConfig('winpositions/' . $self->{__vp_vpname}
. '/left', '0');
        my $top = VP->ReadConfig('winpositions/' . $self->{__vp_vpname}
. '/top', '0');
        my $width = VP->ReadConfig('winpositions/' .
$self->{__vp_vpname} . '/width', '0');
        my $height = VP->ReadConfig('winpositions/' .
$self->{__vp_vpname} . '/height', '0');
        my $saved = VP->ReadConfig('winpositions/' .
$self->{__vp_vpname} . '/saved', '0');
        if($saved) {
            $self->SetSize($left, $top, $width, $height);
        } else {
            $self->Centre();
        }
    } else {
        $self->Centre();
    }

    #-----------------------------------
    #-- Return Frame
    #-----------------------------------

    return $self;
}



Mattia Barbon wrote:
> On Sun, 18 Mar 2007 02:24:07 -0700
> Eric Wilhelm <scr...@gm...> wrote:
> 
>   Hi,
> 
>> I'm still not sure what I'm doing with the declarative syntax, but I'm 
>> currently working on a module that will create constructors with 1-2 
>> required parameters, followed by key => value pairs.  This is just a 
>> dump of the autogenerated pod chunk which will accompany it.
>>
>>   http://scratchcomputing.com/tmp/WxPerl-foo.html
> 
>   Looks fine to me, and I believe this is a very useful feature (I
> wanted to do it myself).
> 
>> Let me know if there's anything glaringly wrong about that chunk of pod.
>>
>> At the moment, the only classes that I'm mapping are the ones that match 
>> newFull() in the XS source.  The code for this is at:
>>
>> http://scratchcomputing.com/svn/WxPerl-Constructors/trunk/build/xs_proto_map
> 
>   WxPerl::TreeCtrl->new(
>     $parent,
>     id        => -1,
>     pos       => Wx::wxDefaultPosition(),
>     size      => Wx::wxDefaultSize(),
>     style     => Wx::wxTR_HAS_BUTTONS(),
>     validator => Wx::wxDefaultValidator(),
>     name      => treeCtrl,
>   );
> 
>   There are two things I do not like about this.
> 
>   The first is "WxPerl"; right name, wrong capitalization.  But this
> might be my flawed sense of aesthetics...
> 
>   The second is: I suppose I will need to derive all my classes from
> WxPerl::*.  Wouldn't it be better if Wx::Perl::Constructors added a
> 'create' or 'make' (or whatever) method to all wxPerl classes? For
> example:
> 
>   use Wx::Perl::Constructors;
> 
>   Wx::TreeCtrl->create(
>     $parent,
>     id        => -1,
>     pos       => Wx::wxDefaultPosition(),
>     size      => Wx::wxDefaultSize(),
>     style     => Wx::wxTR_HAS_BUTTONS(),
>     validator => Wx::wxDefaultValidator(),
>     name      => treeCtrl,
>   );
> 
>   What do you think?
> 
> Regards
> Mattia
> 
> -------------------------------------------------------------------------
> 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] your wxGlade wishlist

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

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

> # from Johan Vromans
> # on Saturday 17 March 2007 04:59 am:
>
>>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.

That, again, is a very unfortunate attitude. And surprising, since
your Wx::Declare is just a code generator disguised as method calls.

For me, code generation works and many of my programs contain
generated code. Writing a generator is often more fun than writing the
generated code ;-).

-- Johan

Re: [wxperl-users] mixing positional and named parameters

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

On Sun, 18 Mar 2007 02:24:07 -0700
Eric Wilhelm <scr...@gm...> wrote:

  Hi,

> I'm still not sure what I'm doing with the declarative syntax, but I'm 
> currently working on a module that will create constructors with 1-2 
> required parameters, followed by key => value pairs.  This is just a 
> dump of the autogenerated pod chunk which will accompany it.
> 
>   http://scratchcomputing.com/tmp/WxPerl-foo.html

  Looks fine to me, and I believe this is a very useful feature (I
wanted to do it myself).

> Let me know if there's anything glaringly wrong about that chunk of pod.
> 
> At the moment, the only classes that I'm mapping are the ones that match 
> newFull() in the XS source.  The code for this is at:
> 
> http://scratchcomputing.com/svn/WxPerl-Constructors/trunk/build/xs_proto_map

  WxPerl::TreeCtrl->new(
    $parent,
    id        => -1,
    pos       => Wx::wxDefaultPosition(),
    size      => Wx::wxDefaultSize(),
    style     => Wx::wxTR_HAS_BUTTONS(),
    validator => Wx::wxDefaultValidator(),
    name      => treeCtrl,
  );

  There are two things I do not like about this.

  The first is "WxPerl"; right name, wrong capitalization.  But this
might be my flawed sense of aesthetics...

  The second is: I suppose I will need to derive all my classes from
WxPerl::*.  Wouldn't it be better if Wx::Perl::Constructors added a
'create' or 'make' (or whatever) method to all wxPerl classes? For
example:

  use Wx::Perl::Constructors;

  Wx::TreeCtrl->create(
    $parent,
    id        => -1,
    pos       => Wx::wxDefaultPosition(),
    size      => Wx::wxDefaultSize(),
    style     => Wx::wxTR_HAS_BUTTONS(),
    validator => Wx::wxDefaultValidator(),
    name      => treeCtrl,
  );

  What do you think?

Regards
Mattia

Re: [wxperl-users] your xrc wishlist

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

# from Mark Dootson
# on Saturday 17 March 2007 02:13 pm:

>So ... (and sorry for getting all gui designer specific) what's needed
>is a dialog designer written in perl that gets 80% of things right so
>you can fix the other 20% to meet your own needs. The thing is, once
> one has attained the level of basic competence that allows one to
> make a reasonable job of writing such a thing - one has probably lost
> a lot of the incentive to do so. I'm just going to attempt to get the
> ball rolling by shoving something out that does stuff the way I want
> it to.

Oh, I do want a dialog designer.  I just said I didn't want to talk 
about it.  But, here we go.

I don't want it to get in my way.  I also don't want XRC, and I'm not 
sure that anything XML would be a good idea when we have YAML.

What about a compile-time class generator that feeds off of a perl data 
structure?  That would get around most of the troubles with generated 
(printed) code, and possibly lead the way to something that allows 
run-time redefinition (think menu-items, but I wouldn't rule-out 
buttons, sizer layouts, etc.)  Add the ability to break individual 
class designs into separate files and you open the option to use 
something like SGI::FAM to automatically redefine the class when the 
source changes on disk (e.g. the designer could modify the running 
code.)  Now make the designer also understand this data-structure (and 
possibly use the file-alternation-monitor), and you get the two-way 
street that wxglade is so badly lacking.  This, of course assumes a 
unix-like development system (and shouldn't be enabled in typical 
deployment builds.)

Besides being slower than a dead snail on vacation in the arctic, XRC 
seems to have no way to create objects other than in sizer-order.  IMO, 
the object creation and sizer declaration should be totally separate.  
Further, the manual process of loading the individual bits and 
constantly calling GetXRCID($name) to get access to things that already 
have names is just plain painful.  Think `$class->new()` and 
`$self->$name`.  Now, doesn't that sound better?  Perl's unifying 
concept of "everything is a string" really gets lost in the Wx paradigm 
of "everything is a number".

I think it would also do well to include support for events.  AFAICT, 
XRC has nothing for this.

How about code snippets as part of the designer?  (Again, broken into 
individual files.)  I'm not sure about this yet, but it does seem to 
have some yummy smalltalk flavor.

Just think "strings are methods" and you're well on your way to being 
free of the C++ mindset which is likely at the core of most of what I 
find lacking in XRC.

--Eric
-- 
Like a lot of people, I was mathematically abused as a child.
--Paul Graham
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Re: [wxperl-users] child accessors

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

# from Mark Dootson
# on Saturday 17 March 2007 09:03 pm:

>I'm presently stuck with
>
>->MyGetControlMethod('controlname');
>->MyGetMenuMethod('menuname');
>
>which, of course, works and is I think at least better than
>$self->{controlname} or $self->{menuitemisaved}.

Well, I just put a WxPerl::MenuMaker in $self->mm and 
$self->{control_name} is simply $self->control_name.  If you then have 
clashing methods because of widget names, that's going to make trouble 
anyway, so I tend to see the "pass a string to a method" scheme as 
unjustified (and you have to error-check it.)

>I'm undecided on the named accessor thing. On the one hand I think
> that any accessors in your classes should behave in a standard way vs
> inheritance whether hard coded or added at runtime and if you can't
> achieve that you should leave it alone.

Well, Class::Accessor doesn't allow you to override the accessors.  It 
does allow you to override the get()/set() methods, but 
Class::Accessor::Fast loses that.  Class::Accessor::Classy lets you 
have it both ways (at least, as soon as I push the next version) by 
declaring a setter(sub {...});  Anyway, that's all overkill for simply 
preventing typo's when accessing child widgets, but inheriting a new() 
really rains on the parade if you're subclassing something besides the 
accessor generator.  If you're not making a specialized accessor 
generator, why subclass an accessor generator?

Nearly all of dotReader is done in Class::Accessor::Classy now, and I'm 
thoroughly enjoying the clean, declarative syntax since it basically 
serves as documentation where __PACKAGE__->mk_accessors("foo") won't.  
Also, the recent meta-data capturing means ./util/accessor_report can 
show me all of the attributes for a given class.

> On the other hand, accessors 
> for controls would be sooooo nice and you could always take the view
> that in practical terms, approach X does the job so lets go for it.

Yeah, '$self->that_button' does the job.

> Then again, would it be wise to implement your own scheme rather than
> the commonly used Class::Accessor with its known limitations /
> workarounds? I'm firmly on the fence today.

Uh, it's already implemented and requires no workarounds?  I might not 
be wise, I might be crazy, but I'm pretty sure I'm not delusional 
(yet :-D)

--Eric
-- 
"I've often gotten the feeling that the only people who have learned
from computer assisted instruction are the authors."
--Ben Schneiderman
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Re: [wxperl-users] declarative syntax

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

# from Sergei Steshenko
# on Saturday 17 March 2007 07:16 pm:

>I am not sure I clearly understand what it's about, but why new
> syntax/language to describe hierarchical relationship if Perl already
> supports hierarchical data structures ?

One word:  concisification

>my $children_array_ref =3D # or should it be hash ref ?

No, order matters.

>=A0 [
>=A0 =A0 { # first child

oops, we lost the order now

>=A0 =A0 custom_bit =3D>
>=A0 =A0 =A0 {
=2E..
>=A0 =A0 text_ctrl =3D>
>=A0 =A0 =A0 {
>=A0 =A0 =A0 type =3D> 'ctrl',
>=A0 =A0 =A0 label =3D> "", # I'm not sure about this
>=A0 =A0 =A0 style =3D>
>=A0 =A0 =A0 =A0 {
>=A0 =A0 =A0 =A0 te =3D> MULTILINE|READONLY|DONTWRAP=20
>=A0 =A0 =A0 =A0 # these are meant to be bitwise OR'ed constants=20
>    =A0 =A0 }=20

Yeah, but the te =3D> 'string|string|string' means the style() function=20
can append wxTE_ to the front, so-as to Wx->"wxTE_$thing" it.

>=A0 =A0 =A0 }
>=A0 =A0 },
>
>=A0 =A0 { # second child
>=A0 =A0 ...
>=A0 =A0 }
>=A0 ];

>Whenever I see another language inside Perl, I'm getting really
> nervous - another (possibly incomplete) definition, another (possibly
> buggy) parser ...

Nope, no parser.

>Well, the original example is likely still Perl, but why a subroutine
> where plain hierarchical data structure should suffice ?

The data structure would basically have to be array refs all the way=20
down.  Also, the style() function does some mapping.  The idea was=20
basically to make a mini-language that would add some unverbosity and=20
other conveniencification.

(The Bushism-ated words are jokes.  You should laugh now.  I'm not=20
really going to extendify the language like that.)

A sufficiently expressive data-structure would be good, but it wouldn't=20
be declarative.  The benefit of the declarative bits of code is that=20
their procedural guts can remove the need for ']]]]]]]]]]'(did I get=20
enough brackets in there?)-ish stuff.  I'm still on the fence about=20
many details of implementing either or both.

=2D-Eric
=2D-=20
software:  a hypothetical exercise which happens to compile.
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

Re: [wxperl-users] your wxPerl wishlist?

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

# from Mark Dootson
# on Saturday 17 March 2007 07:40 am:

>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.

It would be rather limiting, but no is html.  It would be interesting to 
see it in use as a way to modularize the code off of your web-app and 
turn it into a standalone (or thick-client) app via polymorphism.

--Eric
-- 
Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it.
--Alan Kay
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

[wxperl-users] mixing positional and named parameters

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

Hi all,

I'm still not sure what I'm doing with the declarative syntax, but I'm 
currently working on a module that will create constructors with 1-2 
required parameters, followed by key => value pairs.  This is just a 
dump of the autogenerated pod chunk which will accompany it.

  http://scratchcomputing.com/tmp/WxPerl-foo.html

Basically, I'm tired of looking at '-1,' and 'wxDefaultPosition'.  This 
lets me jump straight to the style parameter.  Additionally, the code 
which does the mapping from names to indices should be useful in 
something like an xrc replacement where everything is named parameters.

Let me know if there's anything glaringly wrong about that chunk of pod.

At the moment, the only classes that I'm mapping are the ones that match 
newFull() in the XS source.  The code for this is at:

http://scratchcomputing.com/svn/WxPerl-Constructors/trunk/build/xs_proto_map

Suggestions welcome.

Thanks,
Eric
-- 
So malloc calls a timeout and starts rummaging around the free chain,
sorting things out, and merging adjacent small free blocks into larger
blocks. This takes 3 1/2 days.
--Joel Spolsky
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Re: [wxperl-users] declarative syntax

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

Eric Wilhelm wrote:

> Hmm...  I'm trying to make it *less* verbose and more concise.  What's 
> good about verbose?  XML?

We're in different camps here. I view it as a Coke vs Pepsi thing. A
matter of personal taste. And XML is a very good thing when used in an
appropriate context. (Which, I'll admit, is quite infrequently.)
I think parenthesis and more quoting is good and I also, as a general
rule, think 'implicit' anything should only be allowed in an argument
list. But there is no right or wrong here. Just different viewpoints.

> What specifically makes it inaccessible?  Or, is it just unfamiliar?  I 
> understand the aversion to magic, but once you know the trick, it's not 
> magic anymore.

Well, unfamiliar = inaccessible surely? Coke vs Pepsi again, I think.

> Do you have a suggestion (even if you don't think it would compile, I 
> would like to see it.)

I have no code. As noted in a prior mail, I'm presently stuck with

->MyGetControlMethod('controlname');
->MyGetMenuMethod('menuname');

which, of course, works and is I think at least better than
$self->{controlname} or $self->{menuitemisaved}.

I'm undecided on the named accessor thing. On the one hand I think that
any accessors in your classes should behave in a standard way vs
inheritance whether hard coded or added at runtime and if you can't
achieve that you should leave it alone. On the other hand, accessors for
controls would be sooooo nice and you could always take the view that in
practical terms, approach X does the job so lets go for it. Then again,
would it be wise to implement your own scheme rather than the commonly
used Class::Accessor with its known limitations / workarounds? I'm
firmly on the fence today.

I've spent some time staring at

children(
    ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
    ctrl text_ctrl  => -TextCtrl => "",
         style(te => 'MULTILINE|READONLY|DONTWRAP'),

and I can't learn to love it. Perhaps I could learn to love what it does.

Anyhow, if no-one comes up with what you consider a better accessor
scheme it would be great if you actually implemented it. Its the
accessor creation scheme that really matters and how it sits with
use base qw( one two three four );
If I want a more verbose 'children()' that bit alone would be simple.

I'm going to crack on with my pseudo designer template thing. After
spending so much verbage talking about it, it would be shameful if I
didn't produce at least something!
If I stick with MyGetControlMethod('controlname') for now, I can defer
deciding about named accessors until I fall off the fence one way or the
other.

Regards

Mark

Re: [wxperl-users] declarative syntax

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

--- Eric Wilhelm <scr...@gm...> wrote:

> # from Mark Dootson
> # on Saturday 17 March 2007 02:13 pm:
> 
> >the main attraction to me is getting named accessors for your child
> >controls /menus /toolbars etc.
> 
> Yes, I think that's fairly key to cleaning up the syntax.  Assignment 
> statements which could be taken as implied should be.  The same goes 
> for $self (though this is understandably where some people get scared 
> and say "whoa, not so fast.")
> 
> >I think I'd consider something a touch more verbose
> 
> Hmm...  I'm trying to make it *less* verbose and more concise.  What's 
> good about verbose?  XML?
> 
> >involving Class::Accessor::Fast.
> 
> I've run into problems with the typical 'use base qw(Class::Accessor)' 
> approach and multiple inheritance.  Maybe I want a new() method from a 
> package in which I want to override a foo() method with a generated 
> accessor, but the Class::Accessor scheme says "too bad, you get my 
> new()."  The solution that I came up with involves letting the accessor 
> generator have it's way with a "secret" base class.  While I was at it, 
> I realized we can get rid of the whole __PACKAGE__->mk_foo() stuff too.
> 
>   http://search.cpan.org/search?module=Class%3A%3AAccessor%3A%3AClassy
> 
> >With regard to your WxPerl::Declares section...
> >As it stands, the syntax does look very inaccessible.
> 
> What specifically makes it inaccessible?  Or, is it just unfamiliar?  I 
> understand the aversion to magic, but once you know the trick, it's not 
> magic anymore.
> 
> Do you have a suggestion (even if you don't think it would compile, I 
> would like to see it.)
> 
> There are a lot of component parts that I'm trying to put together, and 
> I'm trying to leave out any syntax that isn't needed.
> 
> Thus, the arguments to children() are a flat list, where the keyword 
> 'ctrl' (this is actually a subroutine "sub ctrl ($) {$ctrl_token, @_}") 
> marks the start of a new control declaration.
> 
>   children(
>     ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
>     ctrl text_ctrl  => -TextCtrl => "",
>          style(te => 'MULTILINE|READONLY|DONTWRAP'),
>     ...
> 
> You could probably sprinkle some parenthesis in there without breaking 
> anything, but that might mean you needed to quote more.  I'm also 
> considering having ctrl() be a completely different beast, but I 
> haven't come up with a way to manage that without package variables or 
> something which otherwise assumes a state.  The benefit of using 
> $ctrl_token is that everything is a list of inputs to children() rather 
> than individual statements.  This allows children() to handle lots of 
> implied stuff such as $self, and I think makes it easier to build the 
> single subref which gets installed as the __create_children() method 
> (double-underscores are for wxglade replacement compatibility.)
> 
> --Eric
> -- 
> Turns out the optimal technique is to put it in reverse and gun it.
> --Steven Squyres (on challenges in interplanetary robot navigation)
> ---------------------------------------------------
>     http://scratchcomputing.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
> 

I am not sure I clearly understand what it's about, but why new syntax/language
to describe hierarchical relationship if Perl already supports hierarchical data
structures ?

Something like that:

my $children_array_ref = # or should it be hash ref ?
  [
    { # first child
    custom_bit =>
      {
      type => 'ctrl',
      class => 'Thing::Control',
      args =>
        {
        arg1 => value1,
        ...
        argN => valueN
        }
      }, # custom_bit

    text_ctrl =>
      {
      type => 'ctrl',
      label => "", # I'm not sure about this
      style =>
        {
        te => MULTILINE|READONLY|DONTWRAP # these are meant to be bitwise OR'ed constants
        }
      }
    },

    { # second child
    ...
    }
  ];


Whenever I see another language inside Perl, I'm getting really nervous
- another (possibly incomplete) definition, another (possibly buggy) parser ...

...

Well, the original example is likely still Perl, but why a subroutine where
plain hierarchical data structure should suffice ?


Regards,
  Sergei.

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


 
____________________________________________________________________________________
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

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

# from Peter Gordon
# on Saturday 17 March 2007 02:53 pm:

>DialogBlocks is a Gui Builder, produces XXL code which can be loaded
> by Perl.

What's XXL?

-- 
Consumers want choice, consumers want openness.
--Rob Glaser
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Re: [wxperl-users] declarative syntax

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

# from Mark Dootson
# on Saturday 17 March 2007 02:13 pm:

>the main attraction to me is getting named accessors for your child
>controls /menus /toolbars etc.

Yes, I think that's fairly key to cleaning up the syntax.  Assignment 
statements which could be taken as implied should be.  The same goes 
for $self (though this is understandably where some people get scared 
and say "whoa, not so fast.")

>I think I'd consider something a touch more verbose

Hmm...  I'm trying to make it *less* verbose and more concise.  What's 
good about verbose?  XML?

>involving Class::Accessor::Fast.

I've run into problems with the typical 'use base qw(Class::Accessor)' 
approach and multiple inheritance.  Maybe I want a new() method from a 
package in which I want to override a foo() method with a generated 
accessor, but the Class::Accessor scheme says "too bad, you get my 
new()."  The solution that I came up with involves letting the accessor 
generator have it's way with a "secret" base class.  While I was at it, 
I realized we can get rid of the whole __PACKAGE__->mk_foo() stuff too.

  http://search.cpan.org/search?module=Class%3A%3AAccessor%3A%3AClassy

>With regard to your WxPerl::Declares section...
>As it stands, the syntax does look very inaccessible.

What specifically makes it inaccessible?  Or, is it just unfamiliar?  I 
understand the aversion to magic, but once you know the trick, it's not 
magic anymore.

Do you have a suggestion (even if you don't think it would compile, I 
would like to see it.)

There are a lot of component parts that I'm trying to put together, and 
I'm trying to leave out any syntax that isn't needed.

Thus, the arguments to children() are a flat list, where the keyword 
'ctrl' (this is actually a subroutine "sub ctrl ($) {$ctrl_token, @_}") 
marks the start of a new control declaration.

  children(
    ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
    ctrl text_ctrl  => -TextCtrl => "",
         style(te => 'MULTILINE|READONLY|DONTWRAP'),
    ...

You could probably sprinkle some parenthesis in there without breaking 
anything, but that might mean you needed to quote more.  I'm also 
considering having ctrl() be a completely different beast, but I 
haven't come up with a way to manage that without package variables or 
something which otherwise assumes a state.  The benefit of using 
$ctrl_token is that everything is a list of inputs to children() rather 
than individual statements.  This allows children() to handle lots of 
implied stuff such as $self, and I think makes it easier to build the 
single subref which gets installed as the __create_children() method 
(double-underscores are for wxglade replacement compatibility.)

--Eric
-- 
Turns out the optimal technique is to put it in reverse and gun it.
--Steven Squyres (on challenges in interplanetary robot navigation)
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

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

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

DialogBlocks is a Gui Builder, produces XXL code which can be loaded by
Perl.

So I don't really understand this thread. 

On Sat, 2007-03-17 at 14:03 -0700, Eric Wilhelm wrote:
> # from Bob Hunter
> # on Saturday 17 March 2007 01:44 pm:
> 
> >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.
> 
> Imagine that!  And here everyone else says it's good enough, so it must 
> be, right?
> 
> The solution that I chose involves storing the menu declaration in YAML, 
> though the caller loads the YAML and passes a data-structure to the 
> API.  It's still preliminary and obviously not for everyone, but hey 
> it's not a one-way street that starts in python and drops your menu 
> items on the floor.
> 
>   http://svn.dotreader.com/svn/dotreader/trunk/lib/WxPerl/MenuMaker.pm
>   http://svn.dotreader.com/svn/dotreader/trunk/lib/dtRdr/GUI/Wx/Frame.pm
>   http://svn.dotreader.com/svn/dotreader/trunk/client/data/menu.conf
> 
> --Eric

Re: [wxperl-users] your wxGlade wishlist

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

Eric Wilhelm wrote:

> 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.
> 

So ... (and sorry for getting all gui designer specific) what's needed
is a dialog designer written in perl that gets 80% of things right so
you can fix the other 20% to meet your own needs. The thing is, once one
has attained the level of basic competence that allows one to make a
reasonable job of writing such a thing - one has probably lost a lot of
the incentive to do so. I'm just going to attempt to get the ball
rolling by shoving something out that does stuff the way I want it to.

With regard to your WxPerl::Declares section, the main attraction to me
 is getting named accessors for your child controls /menus /toolbars
etc. I think I'd consider something a touch more verbose involving
Class::Accessor::Fast. As it stands, the syntax does look very inaccessible.

Good luck with it.

Mark

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

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

# from Bob Hunter
# on Saturday 17 March 2007 01:44 pm:

>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.

Imagine that!  And here everyone else says it's good enough, so it must 
be, right?

The solution that I chose involves storing the menu declaration in YAML, 
though the caller loads the YAML and passes a data-structure to the 
API.  It's still preliminary and obviously not for everyone, but hey 
it's not a one-way street that starts in python and drops your menu 
items on the floor.

  http://svn.dotreader.com/svn/dotreader/trunk/lib/WxPerl/MenuMaker.pm
  http://svn.dotreader.com/svn/dotreader/trunk/lib/dtRdr/GUI/Wx/Frame.pm
  http://svn.dotreader.com/svn/dotreader/trunk/client/data/menu.conf

--Eric
-- 
"...our schools have been scientifically designed to
prevent overeducation from happening."
--William Troy Harris
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------