Re: Shipping Windows binary applications

[Fred Kiefer]

Nicola Pero schrieb:
>> I *think* it used to open the server preferences panel rather than  
>> pop up an alert panel ... not sure why that's happening.
>> Also, it should only happen first time ... so if it keeps happening  
>> then there is a bug somewhere.
> 
> I think at the moment it boths pops up an alert panel *and* the
> server preferences panel. ;-)
> 
> It does happen only the first time ... but for any application. :-(
> 
> So I guess it would be better to have a system-wide default ?
> 
> 
> Anyway my suggestion would be that we start with whatever default makes more
> sense for the average user.  The first 'minute' of user experience
> should be very smooth - no questions asked, everything just works,
> and the user feels they like the application.
> 
> Asking confusing technical questions at the beginning spoils the initial 
> Computer-Human Interaction honeymoon.
> 
> Most users go around and once they like the application they will 
> find the 'Server Preferences' menu and try out other options if they 
> want.
> 

I would even go further here and remove the menu option to set the
style. It does not belong here. This is a task for a preference
application.
I was really annoyed to see this code, when I had a look at the windows
backend two weeks ago. Also all the stuff that goes on in the
notifications that have been added just to support this processing,
looks wrong to me. Most of the stuff that is there belongs in the
setting of the window level. Yes, we don't have proper window level on
MS Window, but we can set different settings for a window here, for
example if it is the main window.

My overall suggestion for this code is to remove all the debug stuff.
Yes, I mean all of it, except for the NSDebugLLog calls. You may move it
to a separate file and keep it for a while, but to me this looks like
code you use once for debugging while you develop the backend and not
like debug code that belongs into a stable product.

We also should remove all the stubs methods in Win32Server.m, next
remove all the code that was added just in case it would be needed later
on. Like the method setFlagsforEventLoop: and so many more unfinshed
pieces. I would even suggest to go back to the original code structure
with just two main file, where it was easy to find the code you needed.
But this may be caused by nostalgia, so you may safely ignore this idea.

I am not sure, how we should handle all the empty dispatch methods. They
surely are a slowdown for the Windows message handling and add no
benefit to the user in the current state. You may argue that they allow
to subclass or add categories implementing them. Perhaps we could come
up with a cleaver idea to decide once at run time, which methods
actually exist and then dispatch to them? This would be similar to the
way Borland handled window messages a long time ago.

What I currently don't understand in this code are the HOLD_XXX_FOR_SIZE
or MOVE settings. They seem to block the first resize/move of a
window/menu. Is this to prevent recursion? And how does the x11 backend
handle these cases?