Re: [wxperl-users] wxPerl Community project...

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

# from Donovan Allen
# on Monday 12 February 2007 11:52 am:

>Something in the realm of a killer app that can server as a cool demo
> of WxPerl, a fount of examples (maybe written in a way that is more
> optimal to serve as examples of component/widget use that could be
> stripped and used in other peoples apps). =A0This app would perhaps be
> useful outside of the community itself. =A0You know, get people who
> aren't perl coders downloading it to use and get both WxPerl and Perl
> as a language more exposure. =A0Therefore, this app should also not be
> for Perl itself (not another POD reader!!!).

Well, dotReader is not just another POD reader, though I've been=20
thinking lately about a POD plugin :-D

It is maybe getting somewhat complicated to use as examples, but the GUI=20
stuff is rather cleanly separated from the rest (even if some of the=20
GUI code is sort of messy due to wxGlade brainrot, but we've dropped=20
glade completely and are slowly cleaning that up.)  Note on=20
perlishness:  XRC isn't it.

I think our CMT Manager/Minion stuff is pretty interesting -- it is my=20
way of dodging POE without threading.  Iterators are pretty simple, and=20
they don't require you to turn your entire architecture on its head.

I've also done quite a lot to get the PAR/appbundle stuff working,=20
though the mac build remains stuck as a universal 10.4 (no 10.3, 10.2=20
without installing two cpan trees.)  To deal with the overall size, the=20
recent multi-part par approach does something of a SplashFast (but with=20
some .par juggling) to get the splash screen out within a couple=20
seconds.

And, as I mentioned before, we're working on Wx::WebCore.

And, if I haven't been clear, dotReader is GPL.

  http://dotreader.com/

I have some thoughts on the DC thing, but as I'm not working on CAD apps=20
anymore, I'll not go into that except to say that any perl app doing=20
pixel calculations (including, in particular, "$y =3D $h - $y" inversion=20
junk) is doomed.  None of the canvases are up to the job because they=20
don't provide enough of a high-level interface to the coordinate system=20
and the overall data model, plus their concept of entities is rather=20
specific to on-screen drawing rather than geometric modeling.  Tk::Zinc=20
was neat, but was missing quite a few things.  wxCairo?  Yes, please!

I agree that we need perl-specific documentation.  But think about=20
building a CAD app in Perl, because this is the extreme example -- we=20
also need a perlish API (one that provides brevity, deeply layered=20
complexity, and acknowledges that an interpreted language needs to be=20
able to ball-up big, common tasks and throw them at some high-level=20
interface to compiled code.)

BTW, the TAPx project would love to have a wxPerl gui test harness=20
example.  There's something that could be used by many perl=20
programmers, even programmers of other languages, and has a small, but=20
non-trivial issue of IPC with running children in a fork.  IMO, it=20
would also be a great place to apply a Wx::TreeListCtrl widget.

=2D-Eric
=2D-=20
Introducing change is like pulling off a bandage: the pain is a memory
almost as soon as you feel it.
=2D-Paul Graham
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------