Menu
▾
▴
Re: [wxperl-users] wxPerl Community project...
|
From: Donovan A. <al...@Zo...> - 2007-02-12 23:08:48
|
> Well, dotReader is not just another POD reader, though I've been > thinking lately about a POD plugin :-D > It is maybe getting somewhat complicated to use as examples, but the = GUI > stuff is rather cleanly separated from the rest (even if some of the > GUI code is sort of messy due to wxGlade brainrot, but we've dropped > glade completely and are slowly cleaning that up.) Note on > perlishness: XRC isn't it.=20 Lol...wXGlade brainrot...hehe. I like that. Yep. It is easy for me to = wave the wand of "keep your GUI code from logic code", but obviously it = isn't exactly that easy. My code hackery breaks this rule on a regular = (if not habitual) basis. =20 And don't get me wrong...there are many of us making perfectly good = products with WxPerl...just so far, very niche software in very niche = markets that I have seen (and made). =20 DotReader looks cool, but I wonder if the horde of people is there to = leverage into general WxPerl interest...dunno. If it can help blog = drones spy into other peoples lives better, then could be. ;-) =20 That being said, it might be a good way to start, and maybe instead of = one amazing app upfront, we can use our own apps as foundations for the = educational/demo material, but rather than just either toss them out as = open source stuff that people can look at, rework them into more formal = educational material (tutorials, cookbooks, whatever). > I think our CMT Manager/Minion stuff is pretty interesting -- it is my > way of dodging POE without threading. Iterators are pretty simple, = and > they don't require you to turn your entire architecture on its head. =20 Agreed. Actually, at this point, just about any solution looks better = to me than POE. After walking the POE road, I am backing out now and = re-working the problem with a combination of things. I think POE is = pretty neat, but to turn my code on its head and still not get true = concurrency is really just not turning out to be worth it. If I want to = mangle my architecure, I better get more for it. > And, as I mentioned before, we're working on Wx::WebCore. And I will welcome that with open arms! > I have some thoughts on the DC thing, but as I'm not working on CAD = apps > anymore, I'll not go into that except to say that any perl app doing > pixel calculations (including, in particular, "$y =3D $h - $y" = inversion > junk) is doomed. None of the canvases are up to the job because they > don't provide enough of a high-level interface to the coordinate = system > and the overall data model, plus their concept of entities is rather > specific to on-screen drawing rather than geometric modeling. = Tk::Zinc > was neat, but was missing quite a few things. wxCairo? Yes, please! DCs was just an example of my point about things that are unclear and = non-trivial to a new WxPerl user. A CAD app in perl is madness (which = is the sort of statement that invites it to be done...heh). > I agree that we need perl-specific documentation. But think about > building a CAD app in Perl, because this is the extreme example -- we > also need a perlish API (one that provides brevity, deeply layered > complexity, and acknowledges that an interpreted language needs to be > able to ball-up big, common tasks and throw them at some high-level > interface to compiled code.) Agreed. But, I think that the perlish API could come out of the killer = app by necessity (or at least be born from), which is more or less what = my point is as a whole. =20 The killer app breeds and propogates these things: * Tutorial material * Example source * Demo of WxPerl * Marketing * Higher level APIs (developed for the app and designed by the = community) * Improvements to WxPerl (out of necessity to get the bits we need = working) * Make the world a better place (one open source app at a time) =20 One very useful thing of a community website would be to document what = would be useful contributions... like what people would like to ball-up = big in higher level APIs that are generic enough to be useful to many. ________________________________ From: wxp...@li... on behalf of Eric = Wilhelm Sent: Mon 2/12/2007 1:22 PM To: wxp...@li... Subject: Re: [wxperl-users] wxPerl Community project... # 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). This app would perhaps be > useful outside of the community itself. You know, get people who > aren't perl coders downloading it to use and get both WxPerl and Perl > as a language more exposure. Therefore, 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 thinking lately about a POD plugin :-D It is maybe getting somewhat complicated to use as examples, but the GUI stuff is rather cleanly separated from the rest (even if some of the GUI code is sort of messy due to wxGlade brainrot, but we've dropped glade completely and are slowly cleaning that up.) Note on perlishness: XRC isn't it. I think our CMT Manager/Minion stuff is pretty interesting -- it is my way of dodging POE without threading. Iterators are pretty simple, and 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, though the mac build remains stuck as a universal 10.4 (no 10.3, 10.2 without installing two cpan trees.) To deal with the overall size, the recent multi-part par approach does something of a SplashFast (but with some .par juggling) to get the splash screen out within a couple 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 anymore, I'll not go into that except to say that any perl app doing pixel calculations (including, in particular, "$y =3D $h - $y" inversion junk) is doomed. None of the canvases are up to the job because they don't provide enough of a high-level interface to the coordinate system and the overall data model, plus their concept of entities is rather specific to on-screen drawing rather than geometric modeling. Tk::Zinc was neat, but was missing quite a few things. wxCairo? Yes, please! I agree that we need perl-specific documentation. But think about building a CAD app in Perl, because this is the extreme example -- we also need a perlish API (one that provides brevity, deeply layered complexity, and acknowledges that an interpreted language needs to be able to ball-up big, common tasks and throw them at some high-level interface to compiled code.) BTW, the TAPx project would love to have a wxPerl gui test harness example. There's something that could be used by many perl programmers, even programmers of other languages, and has a small, but non-trivial issue of IPC with running children in a fork. IMO, it would also be a great place to apply a Wx::TreeListCtrl widget. --Eric -- Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it. --Paul Graham --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job = easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ wxperl-users mailing list wxp...@li... https://lists.sourceforge.net/lists/listinfo/wxperl-users |
