[GEM-dev] GemMan wonderings

IOhannes m zmoelnig zmoelnig at iem.at
Wed Dec 14 10:24:45 CET 2005


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

if i remember it correctly (this is prior to _my_ gem-days), the whole 
constWindow/Window/... comes out of a hackish support for some early 
openGL-cards for pc (like the voodoo);
getting rid of it is one of the intentions of multiple_windows.
(i mean: all the window/context handling should really be rewritten from 
scratch)
> 
> ...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...

i hope to get everything to do with window-handling out of GemMan (ah 
yes: actually i am talking about multiple_windows; but i don't think 
that rewriting the window-handling now to change it again rather sooner 
than later is a splendid idea).
the only windowy left-over should be a GemSharedContext (or similar) 
that is held by GemMan and allows (nona) sharing of..



mfga.sd.r
IOhannes




More information about the GEM-dev mailing list