Even at this early stage, before any actual installers have appeared, things are looking pretty good for Strawberry Professional Alpha 2.
Padre is starting to firm up as a usable editor, Frozen Bubble works quite well and is completely playable, and I think my wxFormBuilder work is coming along nicely (which bodes well for quickly and easily creating GUI apps in some Alpha 3...)
My biggest remaining concern at the moment though, is also one of the smallest and seemingly trivial issues.
Although we can much more easily build and install large, rich and good looking desktop applications there is still no way to launch these applications without resorting to the command line.
Any iconography that are filled into the start menu in Strawberry Professional will do so because Curtis has put them there himself.
A Perl installation, via the %Config information, lets an installer know where to put libraries, binaries, documentation etc. Shared files in the File::ShareDir model are really just a hack, putting them in an agreed location within lib.
File::HomeDir isn't any use to us either for this. It is designed to let programs deal with user-owned data at run-time, NOT with system integration at install time.
Without the ability to install programs in a way that desktop users can easily launch, our little nascent desktop revolution will never really be able to get up to speed.
Having a post-install step where you need to launch a Windows command line, and then run "padre --desktop" just to install a desktop icon is simply not good enough.
Likewise, having to run Frozen Bubble from the command line is silly as well.
So consider this a challenge to anyone out there that likes tackling tricky puzzles, to try and build a File::Launcher (or whatever you want to call it) that can locate install paths, and be integrated into module installers, so we can make proper use of the Start Menu, Desktop, Quick Launcher, and all the equivalent features on all three major desktop platforms (Windows, Mac, and FreeDesktop.org).
If you build it, Padre will use it.
I did some stuff getting windows to launch perl stuff without user intervention on locked down corporate machines a couple of years ago or so. Here are my findings for reference. Some of this might be useful, but it might now.
Here's the appropriate incantation from vbscript to get a
Set fso = CreateObject("Scripting.FileSystemObject")
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run chr(34) & fso.GetParentFolderName(wscript.ScriptFullName) & "\perlshell.bat"& Chr(34), 0
Set WshShell = Nothing
And here's an ultra-crude "installer" designed for installing single cuser catalyst apps onto locked down corporate machines without admin access:
@echo off
set bindir=%~dp0
set bindir=%bindir:~0,-1%
mkdir "%APPDATA%\MyPersonalHomePage"
echo
echo Copying application to hard drive, please be patient
xcopy
echo
echo Creating link in startup folder
echo
mkdir "%APPDATA%\..\Start Menu\Programs\Startup"
Shortcut.exe
"%APPDATA%\MyPersonalHomePage\startmyphp.vbs"
echo Starting server, please be patient
ping 127.0.0.1 -n 10 -w 1000 > nul
start http://127.0.0.1:35900/
I need a system tray launcher too. I realized today that my newest work in the perl debugger really wants a desktop component so that I can just keep my running debugger multi-prompt going and ready for new connections, etc but have an appropriate UI to it.
