From: Stephen P. <Ste...@uc...> - 2004-02-16 12:57:18
|
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. This is because menu commands are processed in their parent window's = wndproc, and the wndproc assigned to a window depends on the event model = it is using. A bit of bashing and hacking on my (and others) part could = make multi-event-model menus work properly, but I'd like to know if this = functionality is actually required by anyone. I mean, if you're a NEM = user you're going to use the NEM for everything, and if you're an OEM = user you're going to use the OEM for everything. So is there any point = to allowing you to mix and match in menus? I'm inclined to believe "yes" just for flexibility, but if I discover = that it looks too annoying to implement I might change my mind to "no". Steve |
From: Jez W. <je...@je...> - 2004-02-16 13:56:20
|
Interesting. Now I know what the problem is I can use a work around (create a child window within the main window being the parent, then attach all controls = to the child :) ) In an ideal world it should be fixed - but I can see the logic for not do= ing it. In my case, I'm trying to convert my app to exclusively use NEM but keep running into various problems - such as this one:) Most of my app is stil= l OEM... Cheers, jez. ----- Original Message -----=20 From: "Stephen Pick" <Ste...@uc...> To: "Win32 GUI Hackers (E-mail)" <per...@li...>; "Jez White (E-mail)" <je...@je...> Sent: Monday, February 16, 2004 12:53 PM Subject: [perl-win32-gui-hackers] Menus and NEM Hello, Looks like menus are indeed a little busted. You can't use both event mod= els on a menu. You can use either the NEM or the OEM, but you can't selective= ly use NEM here and OEM there. If you add a menu to a window that is using t= he NEM and your window uses OEM, your menu won't work. Your menu's event mod= el must match that of the window you're adding it into. This is because menu commands are processed in their parent window's wndproc, and the wndproc assigned to a window depends on the event model = it is using. A bit of bashing and hacking on my (and others) part could make multi-event-model menus work properly, but I'd like to know if this functionality is actually required by anyone. I mean, if you're a NEM use= r you're going to use the NEM for everything, and if you're an OEM user you= 're going to use the OEM for everything. So is there any point to allowing yo= u to mix and match in menus? I'm inclined to believe "yes" just for flexibility, but if I discover tha= t it looks too annoying to implement I might change my mind to "no". Steve ------------------------------------------------------- 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_id438&op=3Dick _______________________________________________ Perl-Win32-GUI-Hackers mailing list Per...@li... https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers |
From: Glenn L. <pe...@ne...> - 2004-02-16 20:07:19
|
Way back when, I tried to convert a whole program to NEM, and menus didn't work at all. And I'd converted them to NEM too, I thought. But maybe I did something wrong. I'll try again after the next release of Win32::GUI. On approximately 2/16/2004 4:53 AM, came the following characters from the keyboard of Stephen Pick: > 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. > > This is because menu commands are processed in their parent window's wndproc, and the wndproc assigned to a window depends on the event model it is using. A bit of bashing and hacking on my (and others) part could make multi-event-model menus work properly, but I'd like to know if this functionality is actually required by anyone. I mean, if you're a NEM user you're going to use the NEM for everything, and if you're an OEM user you're going to use the OEM for everything. So is there any point to allowing you to mix and match in menus? > > I'm inclined to believe "yes" just for flexibility, but if I discover that it looks too annoying to implement I might change my mind to "no". > > Steve > > > ------------------------------------------------------- > 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_id56&alloc_id438&op=click > _______________________________________________ > Perl-Win32-GUI-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers > > -- 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. |
From: Aldo C. <da...@pe...> - 2004-02-20 16:32:10
|
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 |
From: Steve P. <st...@ba...> - 2004-02-23 00:46:00
|
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" <da...@pe...> To: "Stephen Pick" <Ste...@uc...> Cc: "Win32 GUI Hackers (E-mail)" <per...@li...>; "Jez White (E-mail)" <je...@je...> 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers > |
From: Aldo C. <da...@pe...> - 2004-02-23 11:48:41
|
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 |
From: Jez W. <je...@je...> - 2004-02-23 20:02:40
|
I'm looking at this more from the users perspective, not as a hacker. I think a decision has to be made whether to make any new module is going to be backward compatible or not. Personally, I think this would be a good time to "start from scratch" and incorporate all the lessons that have been learnt so far. Why not deprecate the OEM and only support NEM - this would make the job easier for you guys, while reducing the amount of confusion on our part? Users who are still reliant on OEM (myself included) would just use the current code line until they are ready to upgrade. Some users would be alienated, but in the medium term it would be a win win situation for everyone. A clean, simple code line would be a benefit to all. General things I'd like to see: * Destroy working correctly on all objects. * The parent window (and or the control?) passed as first parameter for every event (this would allow context aware event handlers - as Johan Lindstom suggested a few weeks back). * A Win32::GUI website hosted on sourceforge (with lots content, documentation and examples). The first two points would allow you to create and destroy controls/windows dynamically - and more importantly - handle them in a simple OO design methodology (rather than using closures, evals and symbol table manipulation). Cheers, jez. ----- Original Message ----- From: "Aldo Calpini" <da...@pe...> To: "Steve Pick" <st...@ba...> Cc: "Win32 GUI Hackers (E-mail)" <per...@li...> Sent: Monday, February 23, 2004 11:31 AM Subject: Re: [perl-win32-gui-hackers] Menus and NEM > 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 > > > > ------------------------------------------------------- > 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 > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers |
From: Aldo C. <da...@pe...> - 2004-02-23 20:02:10
|
On Mon, 2004-02-23 at 18:05, Jez White wrote: > I'm looking at this more from the users perspective, not as a hacker. > > I think a decision has to be made whether to make any new module is going to > be backward compatible or not. Personally, I think this would be a good time > to "start from scratch" and incorporate all the lessons that have been > learnt so far. Why not deprecate the OEM and only support NEM - this would > make the job easier for you guys, while reducing the amount of confusion on > our part? Users who are still reliant on OEM (myself included) would just > use the current code line until they are ready to upgrade. Some users would > be alienated, but in the medium term it would be a win win situation for > everyone. A clean, simple code line would be a benefit to all. still, I don't see the need to "start from scratch" as you say. once the new NEM will be implemented, supporting OEM will be absolutely transparent in terms of coding. think of it as a Unified Event Model architecture. OEM will be deprecated in terms of performance, but it can stay as it is. developers will be able to concentrate on events itself and not worry about users calling them as OEM or NEM, trust me :-) > General things I'd like to see: > > * Destroy working correctly on all objects. as I said, this is a little nasty, but it can be implemented. > * The parent window (and or the control?) passed as first parameter for > every event (this would allow context aware event handlers - as Johan > Lindstom suggested a few weeks back). no. the current plan is: - the object itself will be passed as the first parameter for every event with NEM (*and* there will be a method to get a reference to its parent, as well as another method to get a reference to its topmost container) - OEM will stay as it is, that is no object is passed to events > * A Win32::GUI website hosted on sourceforge (with lots content, > documentation and examples). I have already set up a simple wiki (a Kwiki, actually) at: http://perl-win32-gui.sourceforge.net/cgi-bin/index.cgi I just hacked Kwiki a bit to let it grok POD text, because I *want* documentation to be in POD natively. personally, I find the concept of wiki to be a good idea in this case, so this site (eg. the home of perl-win32-gui.sourceforge.net implemented as a wiki) could be the repository of all things Win32::GUI, and everybody could contribute. cheers, Aldo |
From: Jez W. <je...@je...> - 2004-02-23 20:01:29
|
> still, I don't see the need to "start from scratch" as you say. once the > new NEM will be implemented, supporting OEM will be absolutely > transparent in terms of coding. think of it as a Unified Event Model > architecture. OEM will be deprecated in terms of performance, but it can > stay as it is. developers will be able to concentrate on events itself > and not worry about users calling them as OEM or NEM, trust me :-) No problem:) I still think there is scope and opertunity for change if you guys need it... > no. the current plan is: > - the object itself will be passed as the first parameter for every > event with NEM (*and* there will be a method to get a reference to its > parent, as well as another method to get a reference to its topmost > container) > - OEM will stay as it is, that is no object is passed to events Sounds good to me. I assume you could something like: sub SomeEventHandler { my $self=shift; my $win=$self->Parent; } > > I have already set up a simple wiki (a Kwiki, actually) at: > > http://perl-win32-gui.sourceforge.net/cgi-bin/index.cgi > > I just hacked Kwiki a bit to let it grok POD text, because I *want* > documentation to be in POD natively. personally, I find the concept of > wiki to be a good idea in this case, so this site (eg. the home of > perl-win32-gui.sourceforge.net implemented as a wiki) could be the > repository of all things Win32::GUI, and everybody could contribute. Sounds good. Steve has added lots and lots of doco in the last few weeks - may that effort continue, with us all contrubuting:) One thing I would suggest, is to add a way for people to submit example code (perhaps catagorised by control?). Cheers, jez. |
From: Glenn L. <pe...@ne...> - 2004-02-24 02:49:52
|
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. |