Before we kick off any further work on the Vanilla family of Perl distributions, now would probably be a good time to outline what I see as the future for project.
I've never really tried to enforce a specific "vision" for these distributions. Rather I see them as naturally evolving in a particular direction based on user requirements, under similar evolutionary pressures to other applications of their class.
So other than coding work, I see my role mainly as the "nudger in chief", keeping things pointed in the right direction, and trying to avoid having them get caught in any of the typical traps or getting distracted by shiny things that might detract from their core benefits.
So far this has worked pretty well.
Creating the initial Vanilla Perl distribution allowed the creation of a fast, cheap and low barrier-to-entry feedback loop for CPAN authors and as a consequence (one we expected) caused a great deal of work on bug-fixing and testing automation to come into existence.
CPAN support for Win32 is vastly improved as a result compared to 2 years ago.
Splitting off a dedicated distribution for users (Strawberry) while keeping our experimental "pure" version (Vanilla) made the distribution much more approachable for experienced Perl programmers without impacting on experimental and research work.
Having the Perl::Dist toolkit itself available for building distributions also satisfies the needs of People That Do Strange Things, and gives them a completely open sandbox to play in.
It reduces the need to add additional options and complexity to the "branded" distributions and this greatly improves the experience of People with straight forward needs, by preventing them having to think about issues they don't care about.
But Strawberry Perl is currently still serving double duty, and we need to split it off again, in two specific directions.
There's a clear contention between the needs of people that are experienced with Perl but not with Windows, and people that are experienced with Windows but not with Perl.
A Unix Perl hacker will look at Strawberry Perl and find it quite intuitive. It cushions the strangeness of the Windows environment by letting them behave in ways they are used to on Unix.
Hence the strawberryperl.com headline, "Complete Platform Equality".
The same cannot be said of a Windows user who is new to Perl.
They will look at a Strawberry Perl installation and feel in unfamiliar territory.
For one thing, there's no GUI interfaces to anything. There's no editor, no IDE, no anything to help them, just Notepad and a command line CPAN installer, and some links to some websites.
Rather than corrupt and bloat out Strawberry Perl with any additional stuff that Unix-focused people may not want, the clear solution here is to create a distribution specifically aimed at people who know Windows better than they know Perl, with the headline use case being the IT professional that has spent their career using Windows, but is just starting to learn Perl.
This class of user is going to want/need a richer, bloatier distribution, with GUIs for most functionality, and a large "core library" of modules available out of the box. As an environment it needs to be far more approachable.
I've previously called this concept "Chocolate Perl", and it can be loosely defined as being "Strawberry + Modules + GUI Tools".
With a stable and sub-classable Strawberry Perl released, I think now is the time to start looking at building it.
On the modules side, I want to bundle most of the major modules that people use on Windows, that are also fully cross-platform. Part of the reason for the cpan.strawberryperl.com CPAN mirror redirector is to see what Straberry users are installing, and work out what this list of modules is.
But at the very least, it will contain things like DBI, Template Toolkit, Imager, WxWindows, the Email family, LWP, WWW::Mechanize, a variety of Test:: modules, tools like Perl::Critic, and as many (good quality) Win32:: as I can reasonably jam in.
The GUI Tools will be a bit trickier, since we'll mostly have to write them from scratch.
But they will be based on WxWindows, and will most likely include things like a POD Viewer, a GUI CPAN Client, and potentially an editor such as Kephra, as well as other tools as needed or available.
In the mean time Strawberry will remain focused on the Unix Perl crowd, people that are comfortable on a command line and are happy to install modules themselves.
I expect to do a Strawberry Update release approximately quarterly, plus a release whenever we get a minor release of Perl itself (5.10.1 etc).
New features will only appear in Strawberry once they are completely stable and tested in test distributions.
The initial work on these new features (like better interaction with the environment, enabling relocation support, etc etc) will be done primarily with Vanilla Perl releases.
The next Vanilla release is already in the works, and is aimed at making the install/uninstall process a bit cleaner, with additions like removing PATH entries on uninstall, and cleaning up ALL of the installed files, including CPAN modules. This might also add the ability to "upgrade" Strawberry Perl versions without uninstalling the previous one first (although you may need to re-install CPAN modules still).
I'd also like to try and implement a "CPAN Offline" feature (basically a streamlined, zero-configuration minicpan) to deal with the common case of people using laptops that want a no-fuss "It Just Works" minicpan mirror.
In the short term however, my first goal is to get the current versions of Perl::Dist and Perl::Dist::Strawberry released, so people can start experimenting with different ideas for their own Perl distributions.
These should appear in the next few days.
But they will be based on WxWindows, and will most likely include things like a POD Viewer, a GUI CPAN Client, and potentially an editor such as Kephra, as well as other tools as needed or available.
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 see your efforts expended on what is increasingly becoming dead technology. Sure, the browser may lack some of the more intricate features of GUIs, but (esp. for Windows development), that gap is shrinking rapidly. Ext 2.0 and Dojo 1.0 have both been released, and TIBCO GI is more mature than either of those. Adobe AIR is GA now, so the distinction between browser and desktop app has nearly evaporated.
Admittedly, that may mean more Javascript than Perl, but if you're willing to jump on the IWL bandwagon, much of the Javascript can be "proxied" out thru Perl.
Having expended a lot of energy on Perl/Tk in the past few years, I've learned the hard way that GUI toolkits are on the way out (unless you're building a web browser). I got annoyed the first few times I heard my beta testers say, "Hey thats pretty cool...can I run it in my browser ?". After a dozen times or so, I realized the problem was between my ears, not theirs.
wx may look kewl (ignoring the doc issues), but I fear that may be a similar glidepath to obsolescence. And a full featured RIA toolkit for Perl would be a big PR win to boot.Re:Before you lockin that GUI...
Alias on 2007-12-27T03:58:20
The big win for browsers has always been automated deployment.
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 the HTML view of the universal.
Conversely I've used the RedHat Satellite "GUI" for module installation and it's just plain hideous.
I also seriously doubt there's many people that are using Javascript/HTML as a programmer's editor, or for their music player, and so on.
There's no "right" way to do it, I'm not saying "everything must be WxWindows Win32 GUI widgets".
I'm just suggesting that since WxWindows is suitably cross-platform, and at least LOOKS like native Win32, that wherever we use a GUI toolkit, we should use that.
You are quite welcome to implement a HTML/Javascript CPAN client or programmer's editor and prove me wrong.Re:Before you lockin that GUI...
slanning on 2007-12-27T13:06:03
I don't understand implementing a "programmer's editor". There are plenty of IDEs for Perl 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?
Re:Before you lockin that GUI...
Alias on 2007-12-27T14:52:08
ActiveState cancelled the Visual Studio Perl version of Perl.Re:Before you lockin that GUI...
slanning on 2007-12-27T17:39:32
I guess this is what I mean. Why would people from the Windows world even want to use Perl, when they can use for example C# or VB? Or maybe you're not trying to win over those people.Re:Before you lockin that GUI...
jhourcle on 2007-12-27T18:36:15
The best example that I can think of is in teaching -- I met someone who was taking a Perl course, and they were using Mac's TextEdit as their editor. I tried convincing the student they'd be better off at the very least using something that did text coloring (I recommended TextWrangler, being that they were a Mac user), but they didn't make the switch.
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 to consider it as a language to teach.
[okay, I admit -- I don't know what the teacher was recommending for the students to write their code; it may be that this student was an exception because she was using a Mac]Re:Before you lockin that GUI...
Alias on 2007-12-28T00:34:51
Why would anyone on 90% of the world's desktops want to use Perl?
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 they prefer) and have their colleagues use Windows (which they prefer).
And then, because of all the other reason that people use Perl everywhere else.Re:Before you lockin that GUI...
Alias on 2007-12-28T00:36:08
I'll add one more point to your original question.
> 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.
Re:POD Viewer
bart on 2007-12-27T12:37:35
There already is a POD viewer in Wx, has been available for 4 years, by the wizard gmpassos, as announced on Perlmonks. It would be a bit of a shame to just duplicate the effort.Re:POD Viewer
sir_lichtkind on 2007-12-27T18:51:31
dear bart, i think it would be chame not to write it. i know this POD browser and will grep all interesting ideas he provides, but please consider 2 major obstacle it has. 1) it stayed 4years with version 0.0.1 or 0.02 and more important it uses IE4 component which makes it ein only and i wrote i want to write an crossplatform POD viewer, so that other OS user can benefit too. cheersRe:POD Viewer
Alias on 2007-12-28T00:29:33
I'll look into it.
they will be based on WxWindows
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 like to write some business apps in Perl at work, it would be a real improvement to Perl's viability on Windows.
Re:Toolkit shoot-out?
renodino on 2007-12-27T16:34:23
RE: Tk vs. wx:
FYI: There's a new 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:Toolkit shoot-out?
Alias on 2007-12-28T00:30:55
Rule 1: It must "look like a Windows program"
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:Toolkit shoot-out?
ChrisDolan on 2007-12-29T02:45:54
Java Swing + Inline::Java?:-)
Re:Quickest Path to Subclass
Alias on 2007-12-27T23:58:46
I'm working on documentation for Perl::Dist as we speak, and it will include a cookbook example of making a sub-class (yes, a subclass is all you need).
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' }
sub app_publisher_url { 'http://catalyst.perl.org/' }
sub app_id { 'catinabox' }
sub output_base_filename { 'catinabox-5.10.0-200712' }
# Apply some default paths
sub new {
shift->SUPER::new(
image_dir => 'C:\\catinabox',
temp_dir => 'C:\\tmp\\cat',
@_,
);
}
# Leave the basic install process the same, but add extra modules
sub install_perl_modules {
my $self = shift;
$self->SUPER::install_perl_modules(@_);
# Lets just add Catalyst::Devel for now
$self->install_module(
name => 'Catalyst::Devel',
);
return 1;
}
# Add a link to the Cat website
sub install_win32_extras {
my $self = shift;
$self->SUPER::install_win32_extras(@_);
$self->install_website(
name => 'Catalyst Website',
url => 'http://catalyst.perl.org/',
);
return 1;
}
1;
On top of the new release I'm doing shortly, that should give you a basic Cat In A Box installer.
Re:Quickest Path to Subclass
jk2addict on 2007-12-28T01:06:49
Thats. Just. Sick.:-)
