Hi Aldo,
Good to hear from you again, I wondered what had happened. Sorry to hear
about the HDD problems, it's happened to me in the past and I know the
feeling.
The idea for the event model is good. I noticed that we're running out of
space to add events to the NEM because it uses the eventmask thing, and
there's only enough bits in that for 32 events. I was wondering if that
whole thing should be done away with, and we should not bother to check the
event mask but rather just look up event names in the "event map" that you
mention, then fire them if they are defined by the user.
I think the events code is very messy right now, supporting both NEM and OEM
with tons of redundant code. It would (I think) be nice to start a new
module. There are several things with Win32::GUI that need to be addressed
and are best addressed from scratch. Things like:
1. Perl context bugs
2. Freeing Win32 objects like windows, dialogs etc. Effectively we want to
be able to destroy these objects when their DESTROY sub is called by Perl
3. Move away from the whole "works like Visual Basic" idea. Originally this
was a nice plan, but this is not VB, but perl, and there are many
differences between the languages that mean making things work similarly to
visual basic *but with subtle differences* is actually a lot more confusing
than making things work in a perly way, as perl coders expect them to work.
Things like hyphens at the start of hash keys and so on should probably be
dropped, for example. I think it's better to basically convert the relevant
APIs (windows shell, gui and gdi) into a useable form implemented in Perl.
In other words, stay close to the C API rather than VB, but give it a Perl
twist that allows easy creation of objects (windows, buttons etc), and gives
a good amount of functions/methods for manipulating those objects and
sending messages to them.
4. wxPerl is eclipsing Win32::GUI, so any new module would have to continue
Win32::GUI's track as being a module that is not, in fact, just about the
GUI. Win32::GUI can now handle resources, controlling other processes via
messages, drawing in GDI, etc.
5. Better support for extending with new controls.
6. A better code structure, move all things like labels, buttons and stuff
into their own XS code, keep GUI.xs as the main repository for common
functions/methods that apply to all related objects. Win32::GUI has
obviously grown kind of like fungus, with bits added on pretty much at
random and not exactly cleanly (like my "hooks" code). This would also help
with point 2.
7. Ramy suggested a name change a few days ago. I like Win32::Windows, as it
describes what Win32::GUI does a little better. The module does control
Windows, not just the GUI. Open to debate, of course.
8. Unicode support would be nice. I know little about unicode and am
confused by all these API functions that have W appended to them for wide
character functionality, and how one should use these functions
appropriately.
Obviously if we're going to extend the module in the above ways (or write a
new one) then we need to rename it and release it in a new form, because
changing things like the 8 points above will really break backward compat. I
think there are a few things that will need to be laid down at the start to
define how we do things, like check user arguments for errors, how we
document stuff, and so on, but all that will have to be discussed if anyone
really wants to help take on a whole new project.
Steve
----- Original Message -----
From: "Aldo Calpini" <[EMAIL PROTECTED]>
To: "Stephen Pick" <[EMAIL PROTECTED]>
Cc: "Win32 GUI Hackers (E-mail)"
<perl-win32-gui-hackers@lists.sourceforge.net>; "Jez White (E-mail)"
<[EMAIL PROTECTED]>
Sent: Friday, February 20, 2004 4:17 PM
Subject: Re: [perl-win32-gui-hackers] Menus and NEM
> hello people :-)
>
> On Mon, 2004-02-16 at 13:53, Stephen Pick wrote:
> > Hello,
> >
> > Looks like menus are indeed a little busted. You can't use both
> > event models on a menu. You can use either the NEM or the OEM, but
> > you can't selectively use NEM here and OEM there. If you add a menu
> > to a window that is using the NEM and your window uses OEM, your menu
> > won't work. Your menu's event model must match that of the window
> > you're adding it into.
>
> as I said a lot of time ago, the current OEM/NEM interoperability
> implementation is going to die. there's too much broken code in there,
> and I thought of a way to simplify things a lot (but they will be
> managed a little bit differently).
>
> the last time I wrote here, I promised a document describing the new
> architecture that I'm going to implement, but in the mean time a damn
> stupid 120 GB external USB HD ate my development directory. more than 1
> GB of stuff, more than 6 years of development, sigh :-(
>
> so, the whole thing exists only in my mind now.
>
> basically, the idea is the following: there will be a single messageloop
> for each window (including controls), which, in pseudocode, should do
> something like this:
>
> if(event_model & BYREF) {
> if(window->eventmap(event_id)) {
> event = window->events{get_event_name(event_id)};
> fire_event(event);
> }
> }
> if(event_model & BYNAME) {
> event_name = window->name . "_" . get_event_name(event_id);
> if(event = perl_get_cv(event_name)) {
> fire_event(event);
> }
> }
>
> the biggest implication is that the OEM (BYNAME event model) will
> probably result a little bit slower: that's because each message to each
> control will trigger a perl_get_cv call (which is orders of magnitude
> slower than a C instruction). on the other hand, every control will have
> the whole range of events (eg. MouseMove, MouseClick, etc.) enabled by
> default.
>
> event_model in the code above is a global variable in C which will be
> controlled by a method (Win32::GUI::SetEventModel or something like
> that) or by a directive in use (eg. use Win32::GUI EventModel =>
> 'BYREF').
>
> I'm a little (oh, well, a little is not enough :-) behind with the
> situation on CVS, but I'm ready to implement this architectural change.
>
> should we branch the CVS repository (or create a new module, which
> sounds better to me) or is the current status quiet enough to begin
> working on this for the next release?
>
>
> cheers,
> Aldo
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Perl-Win32-GUI-Hackers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>
