Re: Re: Why all the different string types?

Jens, thanks for the detailed explanation.  I'm going to narrow this 
post to one particular issue I'm still not clear about.

Jens Miltner wrote:
> The other thing I was referring to were the 'local' settings: In  
> MacCvs, you can have more than one browser window open, each one  
> pointing to a different sandbox. However, the current settings  
> implementation uses global CPersistent instances to access the  
> settings. This means that theoretically, each of the browsers would  
> access the very same settings. The current solution in MacCvs is to  
> switch the settings when bringing another browser window to front,  
> i.e. store the modified settings of the browser/sandbox being  
> deactivated and load the settings for the browser becoming the front/ 
> focused window. This is really a big hack, since if there was some  
> code that would read settings for a background window, this code  
> would suddenly get the settings for the other sandbox!

My unfamiliarity with the Mac runtime environment is causing me 
confusion.  I just fired up one instance of gCvs and set it to one 
sandbox.  Then I opened up a second gCvs instance and set it to a 
different sandbox.  I was able to draw graphs for each of those open 
instances.  Each instance (i.e., process) has it's own gCvsPrefs global 
object.

Are you saying that on the Mac, this gCvsPrefs object is shared among 
all running instances?  So the Mac runtime environment has a shared data 
segment for all running instances of a given executable?  If so, that's 
unique; the only thing like that I've experienced is global data 
segments in Windows.  In Unix as far as I know, all data is private to a 
  process unless you specifically allocate shared memory.

Is the app pointer shared between instances in Mac or is that per 
instance?  If the latter, maybe the most straightforward way to address 
this would be to make the CvsPrefs object a member of the app object. 
If we want truly global settings that are immediately reflected in all 
running instances, we could use a shared memory approach.  Though 
personally, I don't think I'd like the behavior of a running instance to 
change because I changed something in another instance.  I think any 
changes to truly global settings should only be reflected in the 
instance where the change is made, and in all new instances started 
after that change.  That dispenses with the need for shared memory.

-- 
Guy Rouillier


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/