NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Before you lockin that GUI... (Score:1)
Um...why ? or rather, why not the GUI toolkit that is/has supplanted all others, namely, the web browser ? Its 2008. As of about mid-2006, its become increasingly clear that, "if it doesn't run in a browser, it don't mean sh*t."
At the risk of sounding like a buzzword bingo caller, it would be a shame to
Re: (Score:1)
If you want to run everything locally, there's still advantages to doing things in a GUI. Introducing a client server model and the overheads of doing things in Javascript for a process that is inherently local has it's own downsides.
That said, it may well be that some of the client side apps ARE done in HTML/Javascript.
The POD viewer is one example of an application that would be ideal to do browser-based. It's document focus aligns well with th
Re: (Score:1)
I don't understand implementing a "programmer's editor". There are plenty of IDEs for Perl [perl.org] already, aren't there?
It's a good idea to make things work better on Windows, though. Languages like Python or Ruby seem to have already dealt with this better than Perl has.
But what kind of motivation would a Windows programmer have to use Chocolate Perl instead of, say, Visual Studio [microsoft.com]?
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
I'd assume that making it easier for a non-programmer to pick up and program in Perl is a good thing, especially if it results in schools being more willing
Re: (Score:1)
Because they are forced to use Windows by corporate policy.
Because of the CPAN... because there's so much depth to the pre-written code out there, and assembling components in Perl is SO much easier compared to Windows languages once you need to do anything even remotely esoteric or interesting.
Because Windows + Mac + Linux == cross-platform, which is a hugely desirable feature.
Because developers can write GUI business tools on Linux (which th
Re: (Score:1)
> I don't understand implementing a "programmer's editor". There are plenty of IDEs for Perl already, aren't there?
Yes, but they all suck.
POD Viewer (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
Toolkit shoot-out? (Score:1)
I don't anything about the relative merits of the different GUI toolkits that do Windows, but I do know that I was very impressed by the native look'n'feel of the PPM front-end that appeared in recent Activestate distributions.
I think that uses Tkx. The other thing I have heard is that the Wx documentation is pretty poor, and thus the barrier to entry is high.
My point is that whatever toolkit is used, it must be well documented and have lots of examples. I'd really lik
Re: (Score:1)
RE: Tk vs. wx:
FYI: There's a new Tcl/Tk [www.tcl.tk] release that purports to have platform-specific theming. While it probably won't be available from Perl/Tk anytime soon, the other Tk based toolkits may be able to leverage it quickly.Re: (Score:1)
Rule 2: It must be installable via the CPAN.
Rule 3: It must be cross platform
From that set of constraints, only WxWindows meets all three.
Re: (Score:1)
Quickest Path to Subclass (Score:1)
I'd like to have a go at replacing my CatInABox zipped dist folder with a real Perl::Dist that I can rebuild and keep updated that contains a complete running Catalyst install with all the trimmings.
Re: (Score:1)
But completely off the top of my head (and probably a bit buggy) it would look something like this.
package Perl::Dist::CatInABox;
use strict;
use base 'Perl::Dist::Strawberry';
sub app_name { 'Catalyst In a Box' }
sub app_ver_name { 'Catalyst In a Box December 2007' }
sub app_publisher { 'Catalyst' }
Re: (Score:1)