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 _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
