RE: [Sweet-swt-develop] Properties as Resources

[Scott S. <sc...@ja...>]

MessageCan't reply right now - in release mode at work...

I'll look at it as soon as I get a chance...
-- Scott

====================
Scott Stanchfield
FGM, Inc.
sc...@fg...
====================



  -----Original Message-----
  From: swe...@li...
[mailto:swe...@li...]On Behalf Of Dave Orme
  Sent: Thursday, June 12, 2003 11:00 AM
  To: 'John Bridges'
  Cc: 'swe...@li...'
  Subject: RE: [Sweet-swt-develop] Properties as Resources



    Common resources make life easier when you want to propagate changes
through an application - classic case is a company wants to use "Font Y"
instead of "Font X" as a company standard - can you now go and change all
instances.

    Obviously this can be done with a dumb search and replace - but the use
of a 'named' resource allows you to be more specific - so "Font X" remains
in use for all Labels but is changed in all combo-boxes to "Font Y".

    Definitely not a contrived example - I've had to do this by hand before
and it sucks!
  Sounds like there's a need for a FontManager class that the GUI builder is
aware of and can use optionally in lieu of manually creating fonts.  In
Sweet's parlance, this would be a custom font PropertyEditor that can
interact with a FontManager to generate the appropriate initialization
strings for the individual GUI builder's code generator.

  I've started a new section in the Sweet design doc for Sweet 2.0 ideas and
added this idea to it (giving you attribution, of course).


  Can you think of any other examples?

  Do you have thoughts about this, Scott?


  Thanks for the feedback!


  Best regards,

  Dave