[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shipping Windows binary applications
From: |
Xavier Glattard |
Subject: |
Re: Shipping Windows binary applications |
Date: |
Thu, 1 Mar 2007 15:00:53 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
Fred Kiefer <fredkiefer <at> gmx.de> writes:
(...)
> 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 agree :-)
I suggest to default to GNUstep style with the use of the taskbar...
I'm working on this backend. I'm quite slow as i only spent (part of) my
free time on it, and i'm still trying to understand all the stuff...
Then i didn't change many thing yet!
> 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.
Window levels management are quite obscure to me...
Is this a GNUStep/openstep/cocoa concept ?
If it is : why doesnt AppKit do that ?
(with minimal backend support)
(...)
> 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.
That sounds fine to me ! Especially if the X11 backend is similar.
What was this good old structure ?
> 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.
Kill'em all !! :o)
> 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.
Sounds rather complicated... Would this be worth the effort ?
Doesnt the objc runtime already do that by caching method calls ?
> 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?
Another piece of code i dont understand...
These flags are set on notifications and cleared on MOVE/SIZE events.
Some of them are never tested (?). I didnt understand they block only
the first resize/move.
A comment says : 'this is fix for [5, 25 bug]'. What' this bug ?
Some comments in WIN32Server.h say : 'override GS move/size event on
hide/miniaturize/popup_context'.
Any idea ?
The more i read, the more i think that 'rewritting' would be easier than
'cleaning'
Xavier
- Re: Shipping Windows binary applications,
Xavier Glattard <=