Moved identical Prefs wrapper logic up to single XAP implementation.
Added XAP_App::getPrefsValueBool() wrapper, too.

  M src/af/xap/beos/xap_BeOSApp.h
  M src/af/xap/mac/xap_MacApp.h
  M src/af/xap/unix/xap_UnixApp.h
  M src/af/xap/win/xap_Win32App.h
  M src/af/xap/xp/xap_App.cpp
  M src/af/xap/xp/xap_App.h
  M src/af/xap/xp/xap_Prefs.h
  M src/hello/ap/win/ap_Win32App.cpp
  M src/hello/ap/win/ap_Win32App.h
  M src/wp/ap/beos/ap_BeOSApp.cpp
  M src/wp/ap/beos/ap_BeOSApp.h
  M src/wp/ap/mac/ap_MacApp.cpp
  M src/wp/ap/mac/ap_MacApp.h
  M src/wp/ap/unix/ap_UnixApp.cpp
  M src/wp/ap/unix/ap_UnixApp.h
  M src/wp/ap/win/ap_Win32App.cpp
  M src/wp/ap/win/ap_Win32App.h
  M src/wp/ap/xp/ap_Prefs.h

No rocket science here.  I just wanted to use a getPrefsValueBool() wrapper 
function, and couldn't stomach the idea of touching all those files to allow 
four identical implementations three levels deep in the XAP_Prefs class 
hierarchy.  So I went the other way instead.  

I have to admit to leaving getPrefsValueDirectory() implementations down 
there, but at least they had some token differences.  Even so, I probably 
should have done the path-munging work to move them up too -- perhaps using 
a trick similar to UT_catPathname().  

>From a quick look, there seems to be an awful lot of code factored all the 
way out to AP solely due to the lack of a few good platform-specific UT 
methods for path-munging.  Sounds like a good rainy day project for someone. 

Full rebuild, unfortunately.  

Paul,
code janitor

Reply via email to