Re: Using flow layout
Brian P Michael <[email protected]>
| Newsgroups | gmane.comp.embedded.carlsbad-cubes |
|---|---|
| Message-ID | <[email protected]> |
Don,
Did this make it to you?
I sent this up the the list and I never received a copy of it?
Brian Michael
---------------------------------
All,
I have been working on a version 2.0 implementation that will solve the
layout dilemma.
I have made many refactoring changes to a possible version 2.0 release.
These changes are in place, so that we can
make maximum code-reuse advantages for the SWT version of the code.
All the SWT code, will use 90% or more of the Swing code. The only
major differences will be in the SWTParser and the associated
classes/converters that get called.
To fix the layout problems, I am adding a layoutLibrary feature,
almost identical to the converterLibrary feature.
Then we can dynamically add the parser classes for different
layoutManagers to the LayoutLibrary (e.g. ->
<layout type="flowlayout"
parser="org.swixml.swing.layoutParsers.FlowLayoutParser" />
<layout type="absolute"
parser="org.swixml.swing.layoutParsers.AbsoluteParser" />
<layout type="borderlayout"
parser="org.swixml.swing.layoutParsers.BorderLayoutParser" />
<layout type="gridlayout"
parser="org.swixml.swing.layoutParsers.GridLayoutParser" />
<layout type="gridbaglayout"
parser="org.swixml.swing.layoutParsers.GridBagLayoutParser" />
<layout type="cardlayout"
parser="org.swixml.swing.layoutParsers.CardLayoutParser" />
<layout type="flow"
parser="org.swixml.swing.layoutParsers.FlowLayoutParser" />
<layout type="border"
parser="org.swixml.swing.layoutParsers.BorderLayoutParser" />
<layout type="grid"
parser="org.swixml.swing.layoutParsers.GridLayoutParser" />
<layout type="gridbag"
parser="org.swixml.swing.layoutParsers.GridBagLayoutParser" />
<layout type="card"
parser="org.swixml.swing.layoutParsers.CardLayoutParser" />
<layout type="jgoodies.form"
parser="org.swixml.swing.layoutParsers.JGoodiesFormLayoutParser" />
The parser has two major methods, buildLayout() and applyLayoutData().
I have a good bit of the code done already. And the tests are going
quite well. My only problem is with
absolute positioning, setpreferredSize and other non-layout manager
issues. I am trying to make sure
all types of layout can be included.
I should be done with the first cut of version 2.0 by end of year and
will release that to Wolf for review.
After Wolf's review, he will determine where to go from there.
The change to a flexible layout manager includes providing two new
tags, <layout type="abc"> and <layoutdata type="abc">. <layout> tag
will replace the layout attribute completely. The <layoutdata> tag
will map all necessary features to manage the "constraints" data. But,
unlike the constraints attribute, this will be an all XML tag. The
constraints attribute than will be obsoleted as well.
When the parser finds an object with a <layout> tag as a child, we
process the <layout> tag.
When the parser finds an object with a <layoutdata> tag as a child, we
process that tag and apply to the
object creation (or in the favor of absolutePositioning, will apply the
setLocation or setPreferredSize.
I need to write a converter that will converter version 1.0 xml files
to version 2.0.
If you want to create a new LayoutManager, then you will be able to
(also, if you feel we haven't done the best at implementing
a specific layoutParser, the code will be quite isolated and can be
improved/fixed easier.
For examples.
E.g
taken from the GridBag.XML Sample file:
Version 1.0 Style:
<button name="btn4" text="Swing">
<gridbagconstraints insets="2,2,2,2" gridx="1" gridy="1" ipadx="0"
ipady="0" weightx="1.0" weighty="1.0"/>
</button>
Version 2.0 Style:
<button name="btn1" text="Wonderful">
<layoutdata id="gbc_1" type="gridbag">
<gridx>0</gridx>
<gridy>0</gridy>
<gridwidth>15</gridwidth>
<gridheight>1</gridheight>
<weightx>1</weightx>
<weighty>1</weighty>
<fill>none</fill>
<anchor>southwest</anchor>
<insets>
<top>2</top>
<left>2</left>
<bottom>2</bottom>
<right>2</right>
</insets>
</layoutdata>
</button>
For more info, I have also added versioning of XML files to the system.
For version 1.0x files, no version will be needed.
The version 2.0 code will look for the following
<swixml version="2.0">
add determine that is version 2.0 (or whatever).
A 2.0 parser will then be used for version 2.0 and a 1.x parser will be
used
for parsing 1.x files.
Also, to determine the engine type, SWT or SWING, a separate tag will
be added.
<engine type="swing"> or <engine type="swt">
The engine type will then dynamically tell which "engine" to use, Swing
or SWT.
The cool thing will be that you will be able to use one XML file and
include both
SWT or SWING templates in it. You could then switch to a different
engine, like SWT if it looks
better on a specific platform, like Linux. The GTK version of SWT is
pretty nice.
But you could run the SWING version of the template on Windows and Mac.
I also expect to create a generic, SWEngine.render(filename,
EngineType) where engineType is either "SWT" or "SWING".
If there are any comments, feedback would be appreciated.
Thanks
Brian P Michael
On Monday, December 8, 2003, at 05:32 PM, Don Brown wrote:
> I agree, that would be nice. IMO, it seems like that would belong in a
> Converter, so perhaps it is the Converter interface that needs to be
> modified.
>
> Don
>
> On Wed, 3 Dec 2003 [email protected] wrote:
>
>> So all 'custom' attributes turn into client properties right? Aka,
>> if a method cannot be found to call with the value in the tag, it
>> turns into a custom property.
>>
>> I just want the engine to be more extensible, and right now it seems
>> like the engine is not very customizable without rewriting it. Like
>> what if you wanted to add another attribute that was handled the same
>> way as the action attribute. Where the client object is queried for
>> an Action object (or any object) by using reflection rather then
>> having to hardcode things in the XML?
>>
>> So you could say this...
>> <frame bounds="frameBounds">
>> ...
>> </frame>
>>
>> and in your client object do this...
>> class Client {
>> public Rectangle frameBounds; // loaded from a config file before
>> rendering of GUI.
>> }
>>
>> One can kind of do this by overriding the setClientProperty method of
>> a custom tag and then processing it there, but one still doesn't have
>> access to the client object, nor is it a very good extension
>> mechanism as you have to then extend all of the objects you want your
>> attribute tag to effect.
>>
>> Or am I the only one that wants the ability to do this?
>>
>> cheers,
>> Steve
>>
>>
>> -----Original Message-----
>> From: Wolf Paulus [mailto:[email protected]]
>> Sent: Wednesday, December 03, 2003 2:12 PM
>> To: List for Users of Carlsbad Cubes' Technologies and Products
>> Subject: Re: [Forum] Using flow layout
>>
>>
>> Look at the sample code:
>>
>> I.e.
>> swixml/samples/ClientAttr.java
>> swixml/xml/clientattr.xml
>>
>> /**
>> * The ClientAttr shows in the usage of client attributes in swixml
>> tags.
>> *
>> ...
>>
>>
>> On Dec 3, 2003, at 1:58 PM, <[email protected]> wrote:
>>
>>> What about custom attributes? Is Swixml going to have a way to add
>>> custom attributes in a similar way as custom tags?
>>>
>>> -----Original Message-----
>>> From: Wolf Paulus [mailto:[email protected]]
>>> Sent: Wednesday, December 03, 2003 10:26 AM
>>> To: List for Users of Carlsbad Cubes' Technologies and Products
>>> Subject: Re: [Forum] Using flow layout
>>>
>>>
>>> Steve,
>>> This is not entirely true. You can have custom LayoutManagers but
>>> need
>>> to register them in the TabLibrary. Moreover, you would have to
>>> write a
>>> Converter.
>>>
>>> Anyway, it has been widely recognized that the way layouts are
>>> handled
>>> in Swixml is far from optimal and the 1st release of Swixml 2 will
>>> have
>>> layouts promoted from an attribute to a tag.
>>>
>>> Please also look at Swixml web site, for some newly added sample.
>>>
>>>
>>> On Dec 3, 2003, at 9:10 AM, <[email protected]> wrote:
>>>
>>>> But you can't extend the layout system that Swixml uses to use your
>>>> own custom layout managers without changing the core code. So you
>>>> are
>>>> stuck with only using the swing layouts.
>>>>
>>>> -----Original Message-----
>>>> From: kate rhodes [mailto:[email protected]]
>>>> Sent: Wednesday, December 03, 2003 6:25 AM
>>>> To: List for Users of Carlsbad Cubes' Technologies and Products
>>>> Subject: Re: [Forum] Using flow layout
>>>>
>>>>
>>>> Unlike Thinlet SWIXML doesn't do it's own layout system. It uses
>>>> Swing
>>>> classes for everything. It supports it exactly as well as the
>>>> version
>>>> of
>>>> java you are using supports it.
>>>>
>>>>
>>>>
>>>> You can use ANY Swing layout you want. There aren't tags for them
>>>> but
>>>> there is nothing to stop you from applying a layout in java to the
>>>> objects generated by SWIXML.
>>>>
>>>> There is no "best layout". You use whatever layout is most
>>>> appropriate
>>>> to the needs of your interface.
>>>>
>>>> again... swixml DOES NOT have ANY layout managers of it's own. It
>>>> uses
>>>> the layout managers in Swing. All SWIXML does is map XML to Swing
>>>> objects and instantiate those Swing objects with the attributes
>>>> specified in your XML via getters and setters.
>>>>
>>>> -Kate
>>>>
>>>> [email protected] wrote:
>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>> I had used thinlet for a quite a while and when i started using
>>>>> swixml i find that the support for flow layout is not that great
>>>>> in
>>>>> swixml.
>>>>>
>>>>> can anyone suggest what is the best layout to use with swixml
>>>>> and can i use flow layout the same way as i do in thinlet.
>>>>>
>>>>> Regards,
>>>>> Akhil
>>>>>
>>>>> "DISCLAIMER: This message is proprietary to Hughes Software Systems
>>>>> Limited
>>>>> (HSS) and is intended solely for the use of the individual to whom
>>>>> it
>>>>> is
>>>>> addressed. It may contain privileged or confidential information
>>>>> and
>>>>> should not be circulated or used for any purpose other than for
>>>>> what
>>>>> it is
>>>>> intended. If you have received this message in error, please notify
>>>>> the
>>>>> originator immediately. If you are not the intended recipient, you
>>>>> are
>>>>> notified that you are strictly prohibited from using, copying,
>>>>> altering, or
>>>>> disclosing the contents of this message. HSS accepts no
>>>>> responsibility for
>>>>> loss or damage arising from the use of the information transmitted
>>>>> by
>>>>> this
>>>>> email including damage from virus."
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Forum mailing list
>>>>> [email protected]
>>>>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Forum mailing list
>>>> [email protected]
>>>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>>>>
>>>> _______________________________________________
>>>> Forum mailing list
>>>> [email protected]
>>>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Forum mailing list
>>> [email protected]
>>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>>>
>>> _______________________________________________
>>> Forum mailing list
>>> [email protected]
>>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>>>
>>>
>>
>>
>> _______________________________________________
>> Forum mailing list
>> [email protected]
>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>>
>> _______________________________________________
>> Forum mailing list
>> [email protected]
>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>>
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>
>
Sincerely,
Brian P Michael
630-897-8364 x17
[email protected]
_______________________________________________
Forum mailing list
[email protected]
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
Brian P Michael.vcf
(text/directory, 374 B)
BEGIN:VCARD VERSION:2.1 N:Michael;Brian;P FN:Brian P Michael ORG:GoldParrot Corporation TITLE:President TEL;WORK;VOICE:630-897-8364 x17 TEL;WORK;FAX:630-897-8364 x21 ADR;WORK:;;1326 Eastwood Dr;Aurora;IL;60506;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1326 Eastwood Dr=0D=0AAurora, IL 60506=0D=0AUSA EMAIL;PREF;INTERNET:[email protected] REV:20020311T030256Z END:VCARD