Hello, WxPerl is the best way of creating applications with a GUI with Perl. Am I wrong?
Because usually the applications with a GUI are targetted to common users, not IT specialists, it should be easy to create binary executables from those applications and it should be also easy to create installers for them for an easier distribution. For creating binary executables is easy to use PAR, however it doesn't work every time, but for advanced things we have ActiveState PDK which is pretty fine although it costs some money. (At least PDK is OK under Windows, but I haven't tested it under Linux/Mac.) For creating installers however, there is no good solution available. Cava Packager is kind of abandoned but not open source, although for me these are not its worst disadvantages, but the fact that it is inaccessible for screen readers. So I don't know any accessible way of creating installers that can install WxPerl-based applications under Linux and Mac. CitrusPerl also looks to be abandoned unfortunately, so it is even harder to run a WxPerl-based app from source code because it was always hard or impossible to install Alien::wxWIDGETS and WxPerl using cpanm/cpan. (At least for me that I don't know C.) --Octavian ----- Original Message ----- From: Steve Cookson - gmail To: James Lynes ; Ron Grunwald <ron...@yahoo.com.au>; Johan Vromans Cc: herbert breunung ; wxperl-users Sent: Monday, January 04, 2016 1:17 AM Subject: Re: Future of wxperl.it Hi Guys, There is a lot of stuff on the wiki. (See here http://wiki.wxperl.nl/Main_Page). How to structure a good wxPerl GUI? (Possibly an existing GUI design text) - Do you mean a development guide? I don't know of a good one. Herbert started to write one but I don't know how far he got. Installing wxPerl and wxWidgets - There is a good page on the Wiki. A tutorial on the wxPerl widgets and Sizers. - Sizers and their variety have always seemed problematic to me, especially all the flags they come with. In top of that we have parents which, if they conflict with your parent sizer's panel send everything wrong! Extending your wxPerl GUI to a complete application. - I think we all create own architectures and that is probably a large duplication of effort. Advanced topics in wxPerl(Wrapping external libraries) - there is a partial write up of this on the wiki, called NewClass.pod. Reference to wxPerl wxVARIOUS_DEFINED_TERMS available for use - Have you tried perl Makefile.PL --help. It doesn't give you a great deal, but here it is: ~/wxPerl$ perl Makefile.PL --help Usage: perl Makefile.PL [options] --enable/disable-foo where foo is one of: dnd filesys grid help html mdi print xrc stc docview calendar datetime --help you are reading it --mksymlinks create a symlink tree --extra-libs=libs specify extra linking flags --extra-cflags=flags specify extra compilation flags --[no-]wx-debug [Non-] debugging wxWidgets --[no-]wx-unicode [Non-] Unicode wxWidgets --[no-]wx-mslu [Non-] MSLU wxWidgets (Windows only) --wx-version=2.6[.1] --wx-toolkit=msw|gtk|gtk2|motif|mac|wce|... There doesn't seem to be the same for Alien, although there is a page for wxWidgets, here: https://wiki.wxwidgets.org/WxWidgets_Build_Configurations What would you like to see see to make wxPerl be fit for another decade? Regards Steve. On 03/01/16 20:19, James Lynes wrote: Ron: I agree. My journey would have been shorter and more enjoyable with a good "Learning wxPerl" text. I think that the wxDemo is a good tool, but I found that, for a beginner, the glue code used to tie all the widgets into a neat package tended to obscure what was going on, which is why I broke out many of the widgets into separate example programs available on the wiki.(If I rewrote the examples today there are certainly things that could be cleaned up...learning curve). The wxBook is good, but it took me quite a while to translate the C++ syntax into wxPerl. Today I can use the wxBook or the wxWidgets docs and translate pretty quickly, but it took way too long to get there. What I've still found missing is information on extending the GUI into a complete application. I do have a small working application using wxPerl with Perl Threads, but I'm sure there are other ways to structure the non-GUI portions of larger applications. So, I guess the problem has at least six levels: c Nice to see a little discussion started. So again, what needs to be done long term... James On Sat, Jan 2, 2016 at 7:16 PM, Ron Grunwald <ron...@yahoo.com.au> wrote: Good morning all, I use WxPerl and intend to keep using it for a long time to come. However, I am only a beginner with WxPerl. Most of my GUI programming experience comes from PerlTk. One of the things I’ve always missed about WxPerl is a good introductory book. PerlTk has the O’reilly “Learning Perl/Tk” book by Nancy Walsh, which I find invaluable. Imagine if an equivalent “Learning WxPerl” book existed. I believe the German programmer, Herbert Breunung, contemplated writing such a book, but I don’t know what the current state is. My personal view is that WxPerl still has a lot to offer but needs to be more appealing to introductory GUI programmers. Kind Regards. ________________________________________ Ron Grunwald ron...@yahoo.com.au http://www.dvlcorner.org On 2/01/16 1:36 AM, "James Lynes" <jmlyne...@gmail.com> wrote: Johan: I see you got an overwhelming response to your post. Is anyone still using wxPerl? The only response I got to my last couple of questions came from Steve. James On Sat, Dec 26, 2015 at 9:57 AM, Johan Vromans <jvrom...@squirrel.nl> wrote: On Mon, 5 Jan 2015 14:54:35 -0500 James Lynes <jmlyne...@gmail.com> wrote: > Great, but what needs to be done long term? I don't know. I'm about to stop caring for several reasons including age, health, personal circumstances, and the lack of support from others. If anyone wants to continue the wxPerl domains and the wiki it is now to time to step forward. Likewise CitrusPerl and the Cava Packager, two tools geared towards wxPerl support but unfortunately abandoned. -- Johan http://johan.vromans.org/seasons_greetings.html
