RE: [Sweet-swt-develop] (no subject)

[Mark M. <mmi...@vi...>]

Thanks for your prompt reply.
 
I'll put together some reasonably small examples that can be used for
learning Sweet. I don't know if I'll have time to write the accompanying
documentation/tutorial but I'll see what I can put together.
 
The first example I'm working on is a simple String Property Editor. For
example, something that could be used to change a password.
 
-----Original Message-----
From: swe...@li...
[mailto:swe...@li...] On Behalf Of Dave
Orme
Sent: Thursday, July 31, 2003 1:29 PM
To: 'swe...@li...'
Subject: RE: [Sweet-swt-develop] (no subject)
 
 
I am evaluating Sweet for a GUI Builder that is applicable to the
interactive TV industry. Specifically it is for the OpenCable
Application Platform (OCAP). See http://www.opencable.com/ocap.html for
more information concerning this technology. If we choose to use Sweet,
we plan to put a significant amount of editor components back into the
Sweet community. 
Excellent!
 
Are there any examples on how to write Sweet-compliant components? 
I'll be committing a starter palette to CVS today.  Basically, you
create a BeanInfo that extends OverrideComponentInfo, then edit the
BeanInfo data structure inside your constructor.  The BeanInfo class I
have right now are really minimal and still need a bunch of work to
function optimally.  Look for a "Palette" project to appear in CVS later
today or early tomorrow.
I am struggling, trying to use the PropertyTable mechanism. 
PropertyTable is a property editor SWT control that is designed to be
used either inside of or outside of Eclipse.  It is just a helper class
that makes it easier to write a property editor for Sweet-based SWT
controls.  It depends on a couple of Eclipse classes (mainly
StructuredSelection and its dependants), so you'll need to grab those if
you want your code to work outside Eclipse.
 
Off the top of my head, here's what your GUI builder needs to do:  (I'm
assuming here that you're already familiar with the JFace viewer
framework.  If not, then I have an example of using a JFace table at:
http://www.swtworkbench.com/community/bin/index.cgi?action=viewnews
<http://www.swtworkbench.com/community/bin/index.cgi?action=viewnews&id=
8> &id=8)
 
1) Implement IPropertyEditorFactory and register it with your instance
of PropertyTable.  This class takes an IStructuredSelection of objects
and returns an array of IEditableProperty objects (your own
implementation--see below).  It's analogous to the JFace
IContentProvider in that it takes your GUI builder's data structure for
a SWT component and returns the list of properties that are editable on
that component.
 
2) Create your own implementation of IEditableProperty.  This will be
the class returned by your IPropertyEditorFactory.  There are two issues
here: (a) GUI-builder specific mechanisms for getting/setting property
values and (b) undo/redo management.  (a) is pretty self-explanatory.
The reasoning behind (b) is as follows:  Since each GUI builder will
handle undo/redo differently, the property object must be reimplemented
by each GUI builder in order to register property value changes with the
GUI builder's individual undo/redo stack.
 
3) Use Eclipse's StructuredSelection objects to manage your GUI
builder's current selection.  When the selection changes, your property
table view (or whatever your equivalent thing is that is listening to
selection change events) will call PropertyTable.setInput() (again, just
like JFace).
 
4) Property editors are managed by the PropertyEditorFactory class.
This is a static class that manages the property editor registry and
retrieves property editor classes on request using an algorithm similar
to the one in the original JavaBeans specification/implementation.  By
convention, property editors for built-in classes are registered in a
static initializer block at the bottom of this class.  From this block,
you can see what property editors are currently implemented for what
types and how they work.
 
I think that's about it.
 
 
The property editor table is the part of Sweet under the most heavy
development and as a result is badly under-documented, so I'm not
surprised that it's been tough to use.  If after pursuing the above you
have a more specific question, I'll be glad to try to help.  But I hope
this gets you started. 
 
I know this all needs to be documented somewhere.  ;-}  I guess Sweet is
no different from most other open-source projects in that it tends to
value innovation over documentation.  ;-)
 
 
I look forward to working together!  Once you've gotten your mind
wrapped around this, let's talk some more about what you'd like to do.
 
 
Best regards,
 
Dave Orme