Re: [jplugin & swingx] Refactoring project status

tn5250j wrote, On 27/03/2003 14.44:
> Nicola Ken Barozzi wrote:
...
> 
> Will we want to keep the names swallowtail.  I really like the themes of 
> the apache projects or maybe I should say projects with themes.  jplugin 
> and swingx are kind of plain :-)

For now leave them as-is, because they are not part of the JPlugin core, 
just examples. We'll decide this naming later if you don't mind... but I 
don't like that much to have too many fancy names. For example, if I 
didn't explain the packages, would you have found your way around the 
code? Fancy names are bad for comprehension... for the project names 
it's ok, but since JPlugin is more of an API, I prefer to have it 
comprehensible.

...
>> BTW, what about Antialiasing? Is this the only way to do it? Is is 
>> something worth doing at all? 
> 
> I think it should be up to the gui parts or gui theme to decide whether 
> components should be antialiased or not.  Not the plugin in general.
> 

Ok, but I mean in swingx.

...
>>
>> I'm starting to see your point... and think also if one wants to use 
>> jplugin with SWT for example. I'm not sure, but how would we make 
>> holders without depending from a GUI library? 
> 
> 
> This is where we should come up with some kind of contract between the 
> plugin and the gui parts.  

+1

> Example a checkbox the plugin know it wants 
> to be a check box but should not know how to render a checkbox, nor say 
> that it should be antialiased, nor what font it should use.  The gui 
> knows how to render the interface and asks the plugin in what form 
> should I display you.  The plugin says well I should be a checkbox and 
> the gui says ok waves it's magic wand and poof you are now a checkbox.  
> Also only the gui knows where it should display the checkbox.

I get the point.

>>> SingleSheetActivatingHolder contains quite a few dependencies on 
>>> swingx at this time so will remain.  Have not gone deep enough to see 
>>> what it is used for yet.  Any ideas?  Am thinking at this time it is 
>>> the main sheet for the environment so probably should be moved to the 
>>> swingx package somewhere.
>>
>>
>>
>> Well, these holders are part of jplugin, and this one is a holder that 
>> also uses the activation service to fire up a viewer every time an 
>> event of selection goes on the event system.
> 
> 
> OK this is the fifth time am trying to answer this part.

And honestly it's the fifth time I read it! :-O ;-)

Really a tough part to resolve, but very very interesting.

> What I am 
> gathering here is that the jplugin will also provide a certain set of 
> gui type components?  IMO it could provide a SingleSheetActiveHolder 
> that would extend a JPanel that provides a certain set of functionality 
> but up to the implementor of the plugin to provide a gui for it.  We 
> could then go on and provide maybe define a "Role" for different types 
> of Holders.  An example being ToolBarHolder or even better Doclets.
 >
> ToolBarHolder, extending JToolBar, would be a common interface used to 
> define an extra type of toolbar to the interface.  Example being a macro 
> plugin that plays the role of a Toolbar and provides buttons for Run, 
> Pause, Stop, Record.  The macro would be self contained within this type 
> of interface.  

It seems that you are defining a 'Tool'.

We have Tools, Sheets and Holders. Tools are these actions, sheets are 
the visual components and holders 'hold' sheets.

For example, we can have a TabbedPaneHolder or a MultiplwWindowHolder 
that do the same thing just in a different visual way. Their role is to 
"hold" components, that can be tools or sheets.

>It will also export a set of configuration options called 
> ConfigProps[] maybe or Tools[] that the gui interface calls to get a 
> list of different options that are Configurable and maybe 
> Savable/Storable.  The gui then provides a PropertySheet that displays a 
> set of options that are fired when a ConfigProp[x].configureMe().  
> ConfigureMe() then creates a PropertySheet specific to the ConfigProp to 
> be displayed and/or validated.

Yes, config GUI has yet to be done.

> DocletHolder, extending JPanel or JComponent, would be a common 
> interface used to display an AS400 IFS File structure to the interface.  
> Example being an AS400 IFSFileViewer.  This could be presented by a tab 
> in a JTabbedPane new tab if the gui writer uses this or in a new JFrame 
> or JDialog if the gui writer decided not to use a tabbed pane, also as a 
> new tab on the JOutlookBar that swingx provides.  It depends on the gui 
> to decide how to handle Doclets.  

Yes. Call them Sheets.

> The configuration is the same as the 
> ToolBarHolder.  The plugin would be selfcontained to display the IFS 
> file structure and react with the user.  Here we could interact with the 
> SingleSheetActivatingHolder if provided in the same way as the monarch 
> gui does now.

Yes. As long as it publishes events to the director service, others will 
react accordingly.

> Maybe I am mixing apples and oranges here.  Anyway just some ideas.

It's jsut a matter of understanding.

You see, the idea is that an app is constructed of Sheets, Tools and 
Holders.

Sheets are of course heavily GUI-dependent, so they can be made with 
Swing, SWT, or whatever. ATM only Swing and AWT are supported, but SWT 
could be too in the future.

Tools are basically and conceptually just actions.

These two have to be composed in holders, and interact loosly using 
events in the directorService.

  - Swingx should only keep simple swing widgets.
  - JPlugin only the basic framework and engine stuff.
  - (when JPlugin is kinda stable) we need a kind of swallowtail project 
that keeps JPlugin components that can be composed to make the programs.

If we will need extra specification of roles we can do that.

>>
>> It seems that there are some design issues with the "holder" concept. 
>> What do you think?
> 
> Maybe not design issues per-sé but maybe a lack of abstraction between 
> the view and how we define the interaction between the two.

Well, the holder contains one ot more views. That's it. Or not?

>>> Actually now that this is being written it looks like all of the 
>>> modules in jplugin.components package really belong in the swingx 
>>> package as they are used to build the monarch gui interface and 
>>> really have nothing to do with a plugin per-sé.  This will also take 
>>> care of the AntiAliasing concern stated above.
>>
>> Well, jplugin has sheets, holders, tools. These are coarse grained 
>> components that can be plugged-in. Each of the above are basically 
>> plugins. 
> 
> 
> Yes they are plugins.  What I mean is they would be actual 
> "Plugin"-nable Components" - ( I know pluginnable is not a word just 
> using for emphasis) - using the jplugin framework.  Did this make 
> sense?  My idea for the swingx would be a gui front end that provides 
> these types of Pluggable interfaces if they are wanted.  Am I missing 
> the point of what swingx would be in the end?

Yes, we have a different view for that name ;-)

swingx = extra pure swing components
jplugin = plugin framework and engine
'swallowtail-silk' = actual repository for the plugins

So what you call swingx, I call "swallowtail-silk-" (we will need a 
name), and for now I keep it in JPlugin to make initial development 
easier. We can decouple it later.

>> The tools give the actions, the sheets the components, the holders the 
>> containers.
>>
>> So if we create implementations of the above, we are making real life 
>> components. Coarse grained ones. 
> 
> 
> Given but what if I as a plugin developer do not want to use the swingx 
> real life components but only want to be able to interact with others 
> based on a given contract that is provided, that being a plugin framework.

Yes. Using the services. The DirectorService works with events, and that 
is how they communicate now. And to abstract the data, there is a 
storage package.

So as long as I make a tool or sheet that sends an event to the director 
about a storage item being selected, the activating holder shows it, 
whatever the Sheets that apply are.

> Maybe this is the reason nobody has come up with a generic framework 
> because a plugin would be to specific a component to generalize.  Each 
> vendor has there own types of plugins.  For instance the examples given 
> above.  I know they are specific to the plugins that are being asked for 
> in the emulator but also both could be used in other projects as well.

The contract *between* plugins, tools, etc is in the DirectorService.

Now that you say it, we should be sure that a plugin declares the events 
it needs or supplies in a descriptor, so we can plug them, and 
eventually create adaptors in the DirectorService between them.

A cool way would be to make these events also be able to be done in XML 
and transformed in XSLT. Slow but simple ;-)

>>> Any ideas here or am I off base?
>>
>> We need to hash out more precisely what we mean by swingx and jplugin ;-) 
> 
> :-) agreed.  Anybody else have any opinions here



-- 
Nicola Ken Barozzi                   [email protected]
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en