gnustep-dev
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]