Re: [jplugin & swingx] Refactoring project status

Nicola Ken Barozzi wrote:

>
>
> 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.

Of course

>
>
> ...
>
>>> 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. 

Ah understand what you are trying to get at here. 

>
>
> ...
>
>>>
>>> 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. 

Starting to get where you are coming from now.  We where saying the same 
thing but are now coming to a common vocabulary.

>
>
>> 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. 

Ok got you.

>
>
>> 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. 

Getting there.

>
>
> 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. 

When you say actions here what you mean are components that actually 
generate the events to the Director?

To recap what I am getting from this now is the following:

1. A main working area that is a high level component - a JFrame for 
instance lets call it WorkArea.
2. The WorkArea has different regions that a plugin can extend.
    - ToolBar - These would be Holders?
    - MenuBar - These would be Holders?
    - StatusBar - ?
    - Viewing area where all the views are - This would be referred to 
as a Holder and in the monarch example would be SinglSheetActivatingHolder.
       - The holders then hold different views called Sheets
          - JOulookBar on the left is a Holder that holds holds Sheets 
that are made up of Tools
          - The main viewing area is a Holder of JPanel which holds 
Sheets that are made up of Tools.

3. The sheets themselves are the plugins that provide the tools and 
interactive events to the holders via the Director of the avalon engine 
part.

Correct so far?

>
>
> 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. 

I guess by Role I meant it what region would the plugin try to extend.  
Would it intereact with a Menu Bar or act like a Toolbar or be a View.

>
>
>>>
>>> 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? 

Which are the sheets.

>
>
>>>> 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. 

ok

>
>
>>> 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. 

There is the glue I need to be looking at.  Thanks.

>
>
> 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. 

This was one of the topics I was referring to when mentioning about some 
sort of contract with the gui.  A nice XML markup would be cool.

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

Maybe not.  There should not be that many entries to parse.

>
>
>>>> 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
>
>
>
Regards

Kenneth




-------------------------------------------------------
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