On approximately 2/24/2004 6:19 AM, came the following characters from
the keyboard of Stephen Pick:
Hello,
Steve, do you agree that it adds all the functionality of hooks?
It does seem to, depending on what event_map actually is. If a user
could add events to the event map that werent already there, something
like:
Win32::GUI::RegisterEvent(0x14,"EraseBackground");
Then it would implement *some* of the functionality of hooks. The
primary thing about the hooks that I thought was a good benefit was the
ability to register several handlers per event.
Interesting. It is nice to have multiple perspectives on the issue,
thanks for responding.
So I agree multiple handlers per event can be useful. In fact, my
"fetch old handler / encapsulate / set new handler that calls old
handler" sequence could possibly be done via multiple handlers.
Ordering of handlers could be an issue, however... performance wise, if
things are done in the wrong order, some things may have to be redone,
and that can be an additional cause of strange flicker on the screen.
It would seem that if, when adding a hook, one could specify "first",
with the default being "last", that most programs could be coded in a
way that would allow things to be done in the best order.
If the underlying data structures support multiple handlers, then all of
OEM, NEM, and HEM could be implemented in terms of UEM. For OEM, one
would scan the symbol table, and eval a wrapper to convert the parameter
list. For NEM, the handlers are passed in at window creation time, and
one would eval a wrapper to convert the parameter list. For HEM, a
handler is passed in via a window object method, and one would eval a
wrapper to convert the parameter list. For UEM, the handlers could be
passed in at window creation time, or later via a window object method,
and no wrappers would be necessary.
This provides:
(1) immediate compatibility, except for late eval'd handlers in OEM [but
see (3d)]
(2) A single mechanism for dispatching handlers.
(3) a clear migration path for each existing model
(3a) OEM migration: alter handlers to expect new parameters, change
their names, and pass them in when creating the window.
(3b) NEM migration: alter handlers to expect new parameters, and change
the "-onClick" type syntax to "-whenClick" type syntax (or whatever
syntax the UEM model uses, to be differentiated from NEM).
(3c) HEM migration: alter handlers to expect new parameters, and call a
differently named method to install the handler, to differentiate HEM
and UEM handlers.
(3d) Although compatibility for late eval'd handlers in OEM isn't
available, there is a clear migration path for them: convert them into
HEM or UEM handlers that are later installed via a method on the window
object.
Performance is hopefully obtained in the normal cases by using the
default handlers as much as possible; and by having a mechanism for
supporting C-written handlers for folks that really really need a
handler on a high-frequency event, that would bypass the C/Perl/C
calling techniques. Rules for writing C handlers and parameter access
techniques for C handlers must be defined, of course, as well as the
mechanism for registering a C handler.
The other points are good, but i've got a small issue with
documentation:
Having used the documentation system currently within Win32::GUI's
source, i found it straightforward and simple to understand, quick to
write and easilly convertable. What I'd like to see is a few
improvements to the parser:
1. Support for a marker of some kind that indicates that the text should
be monospaced
2. Wiki-compatible output would be great. This isn't difficult. What I
mean is, a straight block of text that can be pasted right into a wiki
input form. I think we *need* a wiki because docs are no good lurking in
the source where users can't see them or update them.
If the documentation is in the source, the wiki user can't update it.
If the documentation is in the wiki, the programmer won't likely update
it, because it won't be seen, unless he happens to remember that that is
documented somewhere, and goes and finds it.
Maybe we need to have some documentation sourced from each place.
Documentation for the actual interfaces provided by Win32::GUI should
probably be in the source, and be published to HTML and Wiki.
Examples of use could maybe be separate, but should be "version stamped"
so that it is clear what version of Win32::GUI the example applied to.
Can the Wiki force users to supply a (valid) Win32::GUI version number
with each documentation update? We have to trust them to supply the
correct one, of course, and we have to allow changes if they goof, but
then if documentation isn't updated, at least users would know that it
is old, and might no longer work, if interfaces have been updated.
3. Better support for documenting events, especially with the UEM coming
up.
It'd be good to cross reference to MSDN, except that MS is notorious for
changing the links to their web sites.
4. Bugfix and standardize the "see also xxx" parsing. Perhaps have
automatic See Also parsing which makes any word that is a win32::gui
method or event name a link to docs on that thing.
Those would all be pretty easy to do, and I'm happy with fixing up the
documentation tools if nobody else can be bothered. The ability to
generate POD, HTML and TXT outputs is very handy.
Glenn's other points are well made. I like the idea of checking the
symbol table and resolving OEM events on startup. This would certainly
make things a good deal faster, not that I really notice the slow speed
of events right at the moment (and hell, I use hooks, which are
incredibly slow).
And why are they slow? Is it because of the C/Perl transition, and the
hooking of high-frequency events? Or some other reason? My thoughts
above are now suggesting using a derivative of HEM as the basis for UEM.
If it is some other reason, can the performance be improved?
I mentioned Unicode support because it's been asked for a few times on
the sf bug tracker. Personally I don't need it, but like I said it would
be good to support this. I have noticed that in windows 2000 labels,
buttons etc support Japanese characters under Win32::GUI provided that
your OS language is set to Japanese (_that_ was a disorienting few hours
(no pun intended :/)...). This is true of XP as well.
I'd like to see Unicode support. It allows support of multiple
languages concurrently, with is the nirvana for multi-lingual programs.
Steve
-----Original Message-----
From: Glenn Linderman [mailto:[EMAIL PROTECTED]
Sent: 24 February 2004 02:50
To: Aldo Calpini
Cc: Stephen Pick; Win32 GUI Hackers (E-mail); Jez White (E-mail)
Subject: Re: [perl-win32-gui-hackers] Menus and NEM
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.
