[GEM-dev] GemMan wonderings

james tittle tigital at mac.com
Wed Dec 14 03:48:27 CET 2005


...I just noticed that when I create a border-less window, then  
destroy it and close the patch, if I then open another patch and open  
a window, it will start without a border!  Obviously some window  
state is not being destroyed or re-initialized correctly...

...so then I look and sure enough, we have all the "statics" at the  
top of GemMan.cpp (including "int GemMan::m_border = 1;"), but in  
gemwin a borderMess call directly assigns it's value to  
GemMan::m_border :-(  This doesn't seem right...I mean, if we're  
going to have statics, they shouldn't change, right?

...then I thought to look at the destroyWindow() stuff, and it calls  
windowCleanup(), which does nothing...

...so I look at windowInit(), and it's filling out a WindowHints  
structure from the statics...that's ok, as long as those statics  
aren't touched...but, I'm then confronted with:

   myHints.shared = constInfo.context;

...which I still cannot figure out where constInfo is declared, much  
less constInfo.context!

...does anyone know the real difference between a constWindow and a  
Window?  They both seem to do similar things...

...lastly, I was wondering where GemMan::createContext() was called,  
and it is in gemwin:  seems to me like this should be created outside  
of gemwin, but I guess I don't know where the names derive from...

...I'm imagining that we should have window creation something like  
this (which would also work for multiple_windows):

- somewhere in GemMan, there should be the default, static, initial  
values for window parameters
- create a context not attached to window and assign it as the  
"share" context
- gemwin, when it calls GemMan::createWindow, also passes it's own  
WindowHints structure, such that GemMan::createWindow (or a sub- 
function) takes care of filling in default values or whatever has  
been requested during gemwin's creation, but that shares the "share"  
context
- gemwin then only modifies it's own WindowHints, but can retain them  
when the window is destroyed, and pass them back again if that same  
window is re-created (for instance, if you decided you didn't want a  
titlebar/border, and are on a window system that doesn't allow window  
titlebars to be changed on the fly)

...come to think of it, I bet this is mostly along the lines of  
multiple_windows, but I don't have that project open in front of me...

thoughts?
jamie




More information about the GEM-dev mailing list