RE: [Sweet-swt-develop] (no subject)
Status: Beta
Brought to you by:
dvorme
|
From: Mark M. <mmi...@vi...> - 2003-07-31 23:40:25
|
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 |