On Mon, 2004-02-23 at 01:38, Steve Pick wrote:
> 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.
not so directly. the big win in using an eventmask thing is that, before
trying to call the Perl event itself, Win32::GUI can do a quick bit
comparison on a C variable, and it does take an infinitesimal amount of
time. doing a hash lookup, instead, is a costly operation. not as costly
as doing a perl_call_pv, granted, but costly. if we want to keep
performance at an acceptable level (remember that NEM events are always
checked for existence, even several times in a second (think about
MouseMove)) this lookup should be implemented somehow in C, perhaps with
an ad-hoc data structure.
> 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:
erm... I wasn't talking about starting a new "module" in Perl terms, but
a new "module" in *CVS terms*, which is a quite different thing! :-)
the upcoming implementation is called Win32::GUI 1.00 in my mind, and I
see no reason to change this to something else. so, let's see if your
reason convince me :-)
> 1. Perl context bugs
this means adding a plethora of pTHX_ and aTHX_ everywhere, I suppose. I
have to check the correct formula for this, but should not be a big
deal.
> 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
this can be done easily enough. the main point seems to be that a
reference to a control is placed in its parent hash. eg. if you make
$Window->AddButton( -name => 'foo'), you are adding an hash key
$Window->{foo}. so, just deleting this key and calling DestroyWindow on
the button should free all resources. the problem with DESTROY is that
the order of calling (and, in my experience, the exact time at which
this happens) is not guaranteed at all. I had all kinds of problems
trying to implement a proper DESTROY, but I can revamp my experience in
this field if this is an important issue :-)
> 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.
that's true, oh so true :-)
> 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.
I think hypens at the start of hash keys are a Good Thing. remember that
controls are stored in their parent's hash, and without the hypens, you
could make a big mess out of it.
> 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.
well, Win32::GUI already does that. the only thing "borrowed" from VB
was the event model (eg. Button_Click). but I expect, with the new
implementation of NEM, that OEM will be absolutely deprecated. we can't
just remove it (for backward compatibility issues), but once people
realize that NEM performs a lot better, nobody will want to use OEM
anymore. but still, if they feel comfortable with OEM, they will be able
to use it.
> 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.
well, your mileage may vary. in the past, I've used Win32::GUI to
generate bitmaps for a website (which I later converted to png, of
course) by drawing a path in a window and dumping its DC to a file. that
was because GD and other drawing techniques were not giving me the same
antialiasing on TrueType fonts that Win32::GUI did :-)
Win32::GUI never claimed to be "the killer module" for GUI frontends, so
if there's a better toolkit (which is portable also), this is not a
problem. Win32::GUI will be there if (for whatever reason) one wants to
hook directly into the Win32 SDK APIs. it's also (reportedly to me) much
simpler to program with than wx for small applications.
> 5. Better support for extending with new controls.
that's the next issue in my mind, after NEM, and is called PEM (Package
Event Model). stay tuned for more :-)
> 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.
that's another issue, and I can really use some help from you all. at a
certain point, I started doing such a "separation", and if you look
closely at the code, you'll see that there are several things that still
needs to be completely implemented (for example, each .xs file should
have its own onParseOption, onPreCreate, onPostCreate hooks).
we could (should?) rethink package organization based on the "nature" of
the stuff Win32::GUI does manage. for example, there are windows with
position and size (eg. Buttons, Labels, etc.) and windows which should
not have an "explicit" position and size (eg. Statusbars).
currently, the Win32::GUI package contains *all* methods that refers to
windows (and so position, size, style, etc.) as well as functions
directly imported from the Win32 SDK APIs (eg. GetTextExtentPoint32).
anyway, the code surely needs a bit of refactoring, but this is not
something that should be visible to the end user.
> 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.
yes, this is the main point to debate :-)
Win32::GUI is what it is and has its history. we can extend the codebase
and add functionality to do other things than building GUI frontends,
but I'm afraid that the "core" (what most people will use this module
for) will always be GUI stuff. from another point of view, every window
on the screen, every graphical resource on the system has to do with
User Interaction, so GUI still seems a reasonable name to me. back to
the roots of the module, the Win32 "bits" it implements are mainly
USER32.DLL and GDI32.DLL. if you take the "U" from the first and the "G"
and "I" from the second, you still can make "GUI" :-)
> 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.
well, I've never really investigated this issue. I don't think simply
appending a 'W' to API calls will do some good. the main point, I guess,
is how to seamlessly integrate Win32's idea of Unicode (which isn't
Unicode really, but rather UCS2-LE) and Perl's idea of Unicode (which is
UTF-8 really).
> 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.
my personal opinion is to avoid breaking things that much. Perl itself
lived for something like 15 years and 5 major releases before needing to
throw backward compatibility away. we are still at 0.0.something, so
there's plenty of time :-)
still, the need to clearly *define* things before embarking on this
journey is perfectly correct. and to me, one of the biggest thing to be
defined at this point is how to document stuff. but let's this be
another topic :-).
cheers,
Aldo
