On approximately 2/20/2004 8:17 AM, came the following characters from
the keyboard of Aldo Calpini:
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').
This does sound like it would unify the event models, and add all the
functionality Steve has added via the hooks. Steve, do you agree that
it adds all the functionality of hooks? I've not yet played with them
to be 100% sure.
One could, however, provide a very simple migration path from slow OEM
performance to fast OEM performance, with one restriction: If the OEM
functions are required to exist at the time a window is created, then at
window creation time, the namespace could be searched for the names of
event functions, and they could be collected into the same data
structures that are used by NEM.
This would eliminate a dynamic performance penalty of OEM, at the cost
of a creation time performance penalty for OEM. It would eliminate any
need to record, for each window, whether it uses OEM or NEM.
Actually, users could almost perform the OEM->NEM conversion just by
adding the appropriate event names pointing at their old OEM
functions... Except, if the calling convention for the OEM functions and
NEM functions vary, then they couldn't be used interchangably. And that
seems to be part of the design for compatibility... but maybe that is
solvable somehow? With the "automatic" migration, a simple wrapper
function could be interposed between the NEM calling function
parameters, and the OEM calling function parameters, which would still
likely be faster than doing all the perl_get_cv's at run-time? This is
discussed more under "Re: parameter passing" below...
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?
Well, the CVS repository is already branched, bugfix vs development.
However, it would be a shame to lose all the bugfix work, if you are
ready to start implementing afresh.
I would suggest that a cooperative approach would be for you to review
the major code changes, and either accept them, or discuss them in this
forum, until some consensus can be reached.
We should do a release of what we have so far, subject to discussions
started by the last paragraph, before starting another major initiative.
And if you wouldn't mind starting from the current bug-fix branch code
(after the release), then the next release point could be merged back
into the main branch, and you could do your upward-compatible
development there. Bug fixing could continue on the bug fix branch, and
you could pick up the bug fixes from time to time in the main branch, so
there wouldn't be a major synchronization issue later.
It sounds to me like the hooks will become somewhat redundant as a way
of capturing messages, but I doubt that they are seriously difficult to
support in deprecated mode, even if they are redundant.
It is important to me that you retain the ability to set and fetch
pointers to the functions that get invoked for messages, which Steve
only recently added to the NEM.
I'll comment on a few of the other threads of discussion, but won't
reproduce them here.
Re: context: yes, it would be nice to be able to invoke GUI functions
from any thread, and even have "fake-forked" programs be able to have
independent windows, if that is straightforward.
Re: DESTROY: of course it would be nice, but except for really dynamic
programs, not all that necessary. In other words, not the highest priority.
Re: VB-likeness. Not important to me in the least. Useful and usable
are much more important. VB isn't really very object oriented; we can
be much more so in Perl.
Re: PEM. No comment, until we hear more.
Re: Refactoring code: Certainly improvements could and should be made to
the structure of the code.
Re: Unicode, I think you understand the main difficulty, UCS2-LE (I'm
not sure what the -LE means, though) vs UTF-8. But there should be
samples of such conversions inside the Perl core (Windows port).
Re: parameter passing: Passing the object as a first parameter to each
of the event handling functions is an excellant idea. As well as all of
the numbers fromthe event message itself. We need to allow a Win32::GUI
program all the power of the C program. There is a compatibility issue
here. Neither the OEM nor NEM models pass such a parameter at present.
So we can either figure out ways of passing the parameter that isn't
"clean", but is compatible, and new or modified functions can access the
appropriate object, or we need to define UEM (unified event model) which
has the object, and can provide compatible interfaces for existing OEM
and NEM functions. I think the latter is relatively straightforword:
the UEM provides a new interface for UEM-aware functions, and provides
the old interfaces for NEM-aware functions (and a compatibility layer to
call that code, and convert the parameters), and converts pre-existing
OEM functions to NEM functions (with the same, or perhaps with a
slightly different compatibility layer). The only thing
Re: performance: we won't want to see a C/Perl transition on EVERY mouse
move, for performance reasons. Perhaps we need to define a clean way
for defining UEM functions in either Perl, or C? And if the function is
defined in C, there needs to be a way to call it from C without hopping
through Perl. But there also needs to be a way of calling it from Perl,
in case it is overridden by Perl code, that wants to augment the
previous function by doing something, calling the previous function,
doing some more, and then returning. This could be a bit tricky. Maybe
it can be defined away somehow, but the ability to override and augment
the existing functions is important for me. But I'm not sure it is all
that important for the functions which need speed. So if there is not a
universal way to do this, perhaps some restrictions on what functions
may and may not be defined using C is OK.
Re: documentation: What this project doesn't need, is any more
undocumented capabilities. The greatest feature in the world is totally
useless if no one can figure it out. And there are lots of great
features in Win32::GUI that very few people could figure out. Having
all the documentation on sourceforge would help. And maybe wiki's are
the next greatest thing, but the use of too many different types of
technology can prevent a steep learning curve for potential
contributors. Erick's existing Win32::GUI Documentation project suffers
from the inability of contributers to figure out how to contribute, even
with help from Erick. No doubt the system works for Erick, but it's
visual cues aren't consistent with the selected operations I attempted,
so it continually convinced me that it wasn't doing what I asked it to
do, before I got far enough to actually do anything. Calling this new
wiki the "Win32::GUI Documentation Project" is somewhat confusing in
light of Erick's existing project. I think it should be called
something else. I'm also not sure that it should be a wiki, vs simply a
collection of CVS controlled POD files, but feel free to convince me or
ignore me, but I would like some insight as to what made you choose to
create a wiki.
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
