NotifyIcon I certainly have on my list of candidates. I haven't thought much beyond that, but I am hopeful that a restructuring like this might reduce GUI.xs and GUI.pm to more manageable sizes. I also want to experiment with moving a lot of the per-control methods from XS back into perl. There are many methods implemented in XS that do a single call to SendMessage. By moving them back into perl I don't think we'll see much of a performance hit (there's still one 'thunk' between perl and XS, which I suspect to be the largest time overhead), and will be able to move all such methods to be AUTOLOADed, so we only take compile time and memory hits if we use them in our apps.
I think we also have to bare in mind that a Win32-GUI app isn't deployed and run in the same way as a normal perl module/application. Most of the time a Win32-GUI app is run as an exe produced by PerlApp/Perl2exe/PAR. Even if the dll is reduced in size by moving out simple sendmessage calls, we just add bloat to the perl packages which would increase the size of the exe - even if those functions are never used. OK - if we split things out into separate packages they shouldn't be included in the exe - but I'm just wondering if we're making work for ourselves without any "real" tangible benefits i.e., if it's not broke why "fix it"?
I'm a little "sensitive" when it comes to memory usage, as one of my Win32-GUI apps uses 50 meg before it's even done anything - a good chunk of that is due to Win32-GUI - I use a lot of controls, and think of all those SV's that are used for each one:) Getting rid of the tied hash would be a good start:)
Assuming you mean the typemap code when you talk about the "thunk" - the Win32-GUI typemap it's relatively efficient - more so than the "classic" way of doing a typemap conversion (when you check for the correct object) - so it'll probably be worth doing some performance testing to see what (if any) the impact would be.
Cheers, jez.
