Re: [HWX] Some remarks already

[Jouke V. <jo...@pv...>]

> About the Win32 version, you can compile HWXperl on Linux too. Just get the
> module source from CVS. It need some changes for the linux version that I
> noly made for Win32, just look at Changes.HWX and see what need to be done
> for linux. The bigger problem will be with the extra modules and wxPerl,
> since it need wxWindows compiled. If you can help in the linux part will be
> very good. I have a linux here, got one PC just for HWX on linux, but I
> don't have time to see this now! Realy don't have!!!
I'll have a go to try to get it all to work on Linux.

> HWX has only 2 month of life! I think that first we need to develope it, and
> after create the pod, since during the development time a lot of thing can
> change in the structure (is a new thing, not very defined yet). I started to
> create the files of GML and HWX with the pod, but I cut it off since I
> always need to rewrite them!
I understand. However, I think it would be wise to add comments in your 
code to let other developers understand what's going on in the code...

>>4. You refer to HPL. Maybe that is where the 'H' comes from, but I don't
>>have the slightest idea what it is...can you enlighten me?
> 
> Yes.
...but what *is* HPL? What is the relationship between HWX and HPL?

> HWXperl doesn't have for plus only the DotRef. It has the tool PerlBin, this
> need to recompile the binarys of Perl to be enabled, and are a very useful
> tool!
OK, that's an obvious improvement. On the other hand, just a suggestion 
that comes to mind: why not send your idea about PerlBin to the p5p 
(Perl 5 Porters) so it might be a standard part of Perl? If that will 
happen, every perl installation has the possibility of creating 
standalone executables. That would remove the need for a different Perl 
flavour and would make the project a lot less complicated and more 
attractive to use.

> Well, you can be right in one part. But HWXperl is to run HWX apps, it will
> work in the enverioment HWX, this enverioment need to be equal in any OS,
> Perl can change a lot in different OS. The idea of create HWXperl is to have
> a Perl designed for PORTABLE GUI applications. And HWXperl is not only for
> developers, is for the enduser, that doesn't understand anything of Perl,
> compilers, modules, anything. It will just install HWXperl, like a DirectX,
> to run the App. The instal tool of HWX apps will see if the machine have HWX
> installed, if not it install it from the internet, and after this the app.
This is where I can't follow you. Are you saying that Perl -as it is 
currently- is different in different operating systems? That would be 
new to me.
HWX being a development environment for portable GUI applications in 
Perl sounds like THE idea. I think that goal can be reached in a number 
of different ways. I think taking Perl as it is itself simplifies the 
matter. Of course that also takes Wx as the GUI of choice. GML sounds 
like a great plan too. If we had a GUI Design tool, we'd be a step 
further. After that a full-featured IDE can be built.
PerlBin as a complementary tool is great too. Maybe it is an idea to 
develop PerlBin like Perl2Exe (by indigostar software) is done: release 
it in a kind of binary form per Perl release. PerlBin for ActiveState 
Perl build 633 for Windows, PerlBin for Perl 5.6.1 for Linux, etc.
And another idea is to develop a Perl Debugger with Wx as a part of the 
IDE. It shouldn't be too hard to do this using Devel::ptkdb as an example.

Another thing I don't understand is how you think endusers will use 
HWXperl. I don't see how endusers will develop GUI applications.

>>I think it would be wiser to enable anyone to use the different parts of
>>HWX's IDE *without* forcing them to use another Perl and let them decide
>>for themselves if they want to use the new interpreter.
> 
> Well, I'm doing this too, the DotRef for example, I don't use inside the
> modules, it will be used just for the end user. But the problem is: is very
> simple to use the dotref to control the objects, and I think that any
> developer of HWX apps will use it, and when the app goes out, the end user
> need DotRef too to run the app. But if a developer want to make a HWX app
> that works on any Perl version, it just use the basic things, that exist in
> the other Perl too, and it's free to install HWX, GML and wxPerl in any
> Perl. But the non-hwx-Perl that will run the HWX app, need to be configured
> by someone that understand of Perl and Modules, not a normal end user. And
> if you think, one of the bigger problem of Tk is this, it need to be
> instaled on Perl first. And GUI was created to be a easy thing to use, and
> can't be a hard thing to install, or the peoples don't use your app.
OK. Let's agree we disagree on this :). I don't see endusers using 
HWXperl or any Perl at all. Even less the possibility of a developer 
adjusting the code of the enduser to make it run on a normal Perl 
distro. At least I know I won't use the dot notation if I don't have to 
until Perl 6 comes out :)

> What we need to do is to enable HWXperl in any machine that want to run HWX
> apps, and any user need to be enabled to install it (well, the installation
> will be automatic). And our mission is bigger than just delivery a Perl with
> the same resource in any OS, it need to have module for GUI. For default
> Perl doesn't have anything for GUI, and is hard to get a standart perl and
> turn it on a platform for GUI apps (and portable), imagine ask for each end
> user, that just want to run or test the app, to do this by hand. You need to
> know that the majority of users will be of end users, peoples than don't
> know what is Perl. If the developer want to create a HWX app, it get HWX,
> that have a lot of tools for development. The end user just get the App, it
> don't need to know if it works with HWX, Perl, wxPerl, wxWindows, GML, or
> anything, it just want the app.
This is absolutely true. The important keyword here is PerlBin. Not the 
change of the dotsyntax. That dotsyntax will come in Perl 6. It's not 
something in Perl 5. That's my opinion.
If you're able to compile your script, you can distribute it to any user 
without him or her having to install all kinds of Perlmodules, or even 
perl itself. That's all there is to it.
Making it easier to develop GUI applications in Perl takes a good and 
complete IDE, in my idea containing a good editor, GUI design tool, 
compiler (PerlBin), debugger and maybe projectmanager.

If you feel I disagree with you too strongly to join the project, I'd 
understand. I'll still build a GUI design tool, and try to make it 
compatible with your project. If you still want me to join, I'd be very 
happy to!

Regards,

Jouke Visser