xswt-developer — Talk about developing/developing with XSWT

[Xswt-developer] Images with XSWT

[Raphael B. <bos...@zh...>]

Hello there,

I know that XSWT is able to handle images. I saw Hans Baiers Mail and 
the hint with ImageDataParser. Yet I'm unable to make it work.

Can someone point me to an example where I can find out how to do it?


Thanks,
Raphael

Re: [Xswt-developer] Xswt-developer Digest, Vol 3, Issue 4

[jan p. <mj...@gm...>]

Dave,

I been out of the loop for while - but:

My feeling about this is that I think XSWT should be able to work without R=
CP.
However I do see the trend in moving to RCP, which I personally think
is very cool, but XSWT shouldn't be limited to work in RCP only.
The best scenario would be if we could have both plain old SWT support
as well as RCP (like an add -on).

As far as I can see the problem of using XSWT in RCP is in menu and
toolbar handling, right?
The plain SWT Widgets integrates fine with an RCP view.

Cheers

Jan


On 23/08/06, David J. Orme <dj...@co...> wrote:
> Hallvard Tr=E6tteberg wrote:
> > David,
> >
> >
> >> -----Original Message-----
> >> Date: Thu, 17 Aug 2006 21:32:02 -0500
> >> From: "David J. Orme" <dj...@co...>
> >> Subject: [Xswt-developer] Feedback: Should we focus on supporting RCP
> >>
> > only?
> >
> >> Might we want to make XSWT support Eclipse plugins *only*?
> >> ie: to have an explicit linkage to the Eclipse platform?
> >>
> >
> > I'll have to think about this. My first thought is that I would have li=
ked
> > us to support Windows Mobile with eSWT, but I'm not sure how realistic =
that
> > is.
> >
> Okay.
>
> Jan; Yu; do you have opinions?
> >
> >> ------------------------------
> >> Date: Thu, 17 Aug 2006 22:31:50 -0500
> >> From: "David J. Orme" <dj...@co...>
> >> Subject: Re: [Xswt-developer] Xswt-developer Digest, Vol 2, Issue 5
> >>
> >> Right now I think there's no way to define a style for a layoutData?
> >>
> >
> > No, I guess it's because property nodes (tags) don't use the stylesheet
> > mechanism.
> >
> Thanks for this fix!
>
>
> We're charging toward the finish on our project.  Soon I'll be back. :-)
>
>
>
> Best regards,
>
> Dave Orme
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Xswt-developer mailing list
> Xsw...@li...
> https://lists.sourceforge.net/lists/listinfo/xswt-developer
>

Re: [Xswt-developer] Xswt-developer Digest, Vol 3, Issue 4

[<Yu...@no...>]

About XSWT and eSWT, yes, it's doable. I tried XSWT and eSWT in Nokia =
Communicators (CDC J2ME env. plus eSWT for Nokia 9500 & 9300) one year =
ago. It worked by that time. I never tested new/recent XSWT releases.
Personally I would still like to keep XSWT (or core engine) to be =
independent to Eclipse Platform (e.g. RCP). When time comes, people may =
like to use XSWT for eSWT in mobile devices.

Yu You
Research Engineer
Nokia Research Center, Tampere, FI
=20
=20

>-----Original Message-----
>From: xsw...@li...=20
>[mailto:xsw...@li...] On=20
>Behalf Of ext David J. Orme
>Sent: 23 August, 2006 07:19
>To: xsw...@li...
>Subject: Re: [Xswt-developer] Xswt-developer Digest, Vol 3, Issue 4
>
>Hallvard Tr=E6tteberg wrote:
>> David,
>>
>>  =20
>>> -----Original Message-----
>>> Date: Thu, 17 Aug 2006 21:32:02 -0500
>>> From: "David J. Orme" <dj...@co...>
>>> Subject: [Xswt-developer] Feedback: Should we focus on=20
>supporting RCP
>>>    =20
>> only?=20
>>  =20
>>> Might we want to make XSWT support Eclipse plugins *only*? =20
>>> ie: to have an explicit linkage to the Eclipse platform?
>>>    =20
>>
>> I'll have to think about this. My first thought is that I would have=20
>> liked us to support Windows Mobile with eSWT, but I'm not sure how=20
>> realistic that is.
>>  =20
>Okay.
>
>Jan; Yu; do you have opinions?
>>  =20
>>> ------------------------------
>>> Date: Thu, 17 Aug 2006 22:31:50 -0500
>>> From: "David J. Orme" <dj...@co...>
>>> Subject: Re: [Xswt-developer] Xswt-developer Digest, Vol 2, Issue 5
>>>
>>> Right now I think there's no way to define a style for a layoutData?
>>>    =20
>>
>> No, I guess it's because property nodes (tags) don't use the=20
>> stylesheet mechanism.
>>  =20
>Thanks for this fix!
>
>
>We're charging toward the finish on our project.  Soon I'll be=20
>back. :-)
>
>
>
>Best regards,
>
>Dave Orme
>
>
>---------------------------------------------------------------
>----------
>Using Tomcat but need to do more? Need to support web=20
>services, security?
>Get stuff done quickly with pre-integrated technology to make=20
>your job easier Download IBM WebSphere Application Server=20
>v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&d
>at=3D121642
>_______________________________________________
>Xswt-developer mailing list
>Xsw...@li...
>https://lists.sourceforge.net/lists/listinfo/xswt-developer
>

Re: [Xswt-developer] Xswt-developer Digest, Vol 3, Issue 4

[David J. O. <dj...@co...>]

Hallvard Tr=E6tteberg wrote:
> David,=20
>
>  =20
>> -----Original Message-----
>> Date: Thu, 17 Aug 2006 21:32:02 -0500
>> From: "David J. Orme" <dj...@co...>
>> Subject: [Xswt-developer] Feedback: Should we focus on supporting RCP
>>    =20
> only?=20
>  =20
>> Might we want to make XSWT support Eclipse plugins *only*? =20
>> ie: to have an explicit linkage to the Eclipse platform?
>>    =20
>
> I'll have to think about this. My first thought is that I would have li=
ked
> us to support Windows Mobile with eSWT, but I'm not sure how realistic =
that
> is.
>  =20
Okay.

Jan; Yu; do you have opinions?
>  =20
>> ------------------------------
>> Date: Thu, 17 Aug 2006 22:31:50 -0500
>> From: "David J. Orme" <dj...@co...>
>> Subject: Re: [Xswt-developer] Xswt-developer Digest, Vol 2, Issue 5
>>
>> Right now I think there's no way to define a style for a layoutData?
>>    =20
>
> No, I guess it's because property nodes (tags) don't use the stylesheet
> mechanism.
>  =20
Thanks for this fix!


We're charging toward the finish on our project.  Soon I'll be back. :-)



Best regards,

Dave Orme

Re: [Xswt-developer] Xswt-developer Digest, Vol 3, Issue 4

[<ha...@id...>]

David, 

> -----Original Message-----
> Date: Thu, 17 Aug 2006 21:32:02 -0500
> From: "David J. Orme" <dj...@co...>
> Subject: [Xswt-developer] Feedback: Should we focus on supporting RCP
only? 
> 
> Might we want to make XSWT support Eclipse plugins *only*?  
> ie: to have an explicit linkage to the Eclipse platform?

I'll have to think about this. My first thought is that I would have liked
us to support Windows Mobile with eSWT, but I'm not sure how realistic that
is.

> ------------------------------
> Date: Thu, 17 Aug 2006 22:31:50 -0500
> From: "David J. Orme" <dj...@co...>
> Subject: Re: [Xswt-developer] Xswt-developer Digest, Vol 2, Issue 5
> 
> Right now I think there's no way to define a style for a layoutData?

No, I guess it's because property nodes (tags) don't use the stylesheet
mechanism.

> What I think I wanted to write in the style sheet was the following:
> 
> <composite>
>    <layoutData x:id="grabHorizontal" x:class="gridData" bla 
> bla bla/> </composite>
> 
> Then I could have the following in a regular XSWT file:
> 
> <composite>
>   <layoutData x:style="styles.grabHorizontal"/> </composite>
> 
> which would be much more concise than the usual bag of 
> attributes that normally come with grabbing horizontally.  
> :-)  I don't know if this is hard in the current 
> implementation, but notice that the meta x:class attribute is 
> implicitly included in the style too.
> 
> Does this make sense?  Do you agree that this is a good idea?

Aha! I was confused since in your suggestion markup in the test file it was
the wrapping composite tag that had the x:id="grabHorizontal" attribute.

It wasn't very difficult, just a matter of inserting stylesheet handling
code in processNodeProperty. I'll commit support for this later today,
including a test case:

In a stylesheet:

	<layoutData x:id="grabHorizontal" x:class="gridData"
grabExcessHorizontalSpace="true" horizontalAlignment="FILL"/>

Using the style:

		<layoutData x:style="grabHorizontal"/>

Hallvard

Re: [Xswt-developer] Xswt-developer Digest, Vol 2, Issue 5

[David J. O. <dj...@co...>]

Hallvard Tr=E6tteberg wrote:
> David,=20
>  =20
>> -----Original Message-----
>> Date: Sun, 09 Jul 2006 13:29:20 -0500
>> From: "David J. Orme" <dj...@co...>
>> Subject: [Xswt-developer] New task list
>>
>> Hallvard,
>>
>> b) I've extended the style sheet test, and added comments=20
>> about additional style sheet things it would be nice to support.
>>    =20
>
> Concerning this suggestion (cut from the style test):
>
> 	<!-- Should be able to just define grabHorizontal on the layoutData
> 		and make it apply to any GridData on any type of object -->
> 	<composite x:id=3D"grabHorizontal">
> 		<layoutData x:class=3D"gridData"
> grabExcessHorizontalSpace=3D"true" horizontalAlignment=3D"FILL"/>
> 	</composite>
>
> Is this meant to declare that all children added to a composite with th=
is
> style should automatically "inherit" this particular layout data? I'm n=
ot
> sure if it makes sense to have a mechanism where a parent style pushes
> default values into the children. In this case it makes less sense, sin=
ce
> layout data may apply to the parent (as a child) and the child.
>
> Perhaps you can clarify the suggestion?
>  =20
Sure.  :-)

Right now I think there's no way to define a style for a layoutData?

What I think I wanted to write in the style sheet was the following:

<composite>
   <layoutData x:id=3D"grabHorizontal" x:class=3D"gridData" bla bla bla/>
</composite>

Then I could have the following in a regular XSWT file:

<composite>
  <layoutData x:style=3D"styles.grabHorizontal"/>
</composite>

which would be much more concise than the usual bag of attributes that=20
normally come with grabbing horizontally.  :-)  I don't know if this is=20
hard in the current implementation, but notice that the meta x:class=20
attribute is implicitly included in the style too.

Does this make sense?  Do you agree that this is a good idea?


Regards,

Dave Orme

Re: [Xswt-developer] Xswt-developer Digest, Vol 2, Issue 5

[David J. O. <dj...@co...>]

Hallvard Tr=E6tteberg wrote:
> David,=20
>
>  =20
>> -----Original Message-----
>> From: "David J. Orme" <dj...@co...>
>> Subject: [Xswt-developer] New task list
>>
>> (I know you won't get this right away, but I'm writing to the=20
>> list for everyone's benefit and as a central place to keep=20
>> these thoughts.)
>>    =20
> I'm back now.
>  =20
Welcome back!
>> I had a chance to look at the new code that just landed. =20
>> Great work! I'm especially impressed with the scripting and style shee=
t=20
>> work.
>>    =20
> :-)
>  =20
>> - Error handling and reporting:
>>
>> a) In addition to pushing line and column information into=20
>> the nodes so that we can just output the tree nodes as you=20
>> suggest, script syntax errors are silently ignored, but the=20
>> layout isn't built either.
>>    =20
> I've now changed the code to using a context object (element) for error
> reporting. The standard element implementation outputs line and column =
for
> the element (should be enough to identify a faulty attribute).
>
> I'll look into the problem of ignored script syntax errors.
>  =20
Excellent.
>> b) There seem to be situations where other syntax errors=20
>> result in a layout not being built, but no error reported either.
>>    =20
> Can you give some hints for when?
>  =20
My recollection is that it often seemed to be related to if there was a=20
syntax error in a style sheet file, but I think I saw some other random=20
cases too.  My second recollection was that I wasn't able to trace it to=20
any specific use-cases.  I guess I didn't leave any explicit test cases=20
in the repository if you're asking.  Sorry, my bad. :-(  If I run into=20
any more cases, I'll make tests and commit them.
>> - Style sheets:
>>
>> a) I didn't attempt to cascade across two or more files, but=20
>> I did try to cascade within a file. i.e: define a style that=20
>> references two other styles in the same file.  That refused=20
>> to build, but also didn't display any error.
>>    =20
>
> I've now included some fixes and a test that cascades styles (in the sa=
me
> sheet file).
>  =20
Cool!  I won't have a chance to test this tonight but I'll try to use=20
this in my presentation if possible... :-)
>> b) I've extended the style sheet test, and added comments=20
>> about additional style sheet things it would be nice to support.
>>    =20
>
> I think I understand what you want the XML to do, but could you anyway =
write
> the test case (java) code to make it clear?
>  =20
OK; but please understand I can't do that tonight (have to get back to=20
work for my client).
>> - Editor / preview view:
>>
>> a) I'm about 95% done migrating the preview code to the new=20
>> editor framework.  Hopefully that will get finished this week=20
>> and we can:
>>    =20
> I understand you had to temporarily stop working on XSWT and work in
> EclipseWorld presentations instead. How far have you come with the edit=
or?
>  =20
Hard to explain without outlining how the editor works.

There are two ways to build a SWT GUI builder that works in the=20
traditional way:

1) Using GEF: build the UI somewhere, grab a bitmap of it, then blit the=20
bitmap into a Draw2d figure and paint on top of it.  Trouble is: a) this=20
is slow; b) it doesn't work reliably across all platforms; c) it's=20
really complicated to get right.

2) Using live SWT widgets: Steve Northover intentionally put a hack into=20
SWT to make this work.  If you someComposite.setEnabled(false), all=20
controls inside someComposite will appear to be enabled, but won't=20
respond to any input.  Further, all input (keystrokes, mouse events) on=20
the contained controls will be delivered to the containing composite,=20
not to the controls themselves.  So you can use this to make the widgets=20
look normal, but intercept their input, resize them, etc.

But we also have data binding tooling in XSWT.  And I've found it so=20
invaluable to be able to interactively play with my data bindings in the=20
XSWT preview's live widgets that I can't imagine writing a traditional=20
GUI builder that lets you look at, but not interact with the UI you are=20
building.  So here's a third way to do it:

3) Build a SWT UI using 100% live widgets, just like we do today in the=20
XSWT preview.  Use Display#addFilter to intercept the events that are=20
sent to the widgets.  Dynamically add and remove paint listeners to the=20
widgets themselves to draw the feedback that folks are used to seeing in=20
a GUI builder.

The XSWT Builder code base was originally designed for #2.  I decided to=20
switch to #3 because I was running into some serious roadblocks that I=20
was convinced would make it impossible to make #2 work for all SWT=20
classes in a reasonable amount of time.  That involved the following:

a) Eliminate the code that inserted the invisible disabled Composite=20
around each control in the UI layout.  This was the source of all the=20
difficulties mentioned above.
b) Make the root editor Composite setEnabled(true).
c) Fix the coordinate hitTest code in the editor so that resizing the=20
layout with the mouse understands the above changes.

So the move is overall to a much simpler architecture that should be=20
much easier to develop and maintain over time since there no longer is=20
any magic that happens in between the XSWT code and the the layout that=20
you see.  What you write in XSWT is now exactly what you get in SWT.

Now I can answer your question. :-)

Everything but (c) above got done.  (c) got partially done.

Other than that, there is basically a whole bunch of packaging grunt=20
work required to make a new release of XSWT including the new editor=20
code base, the pnuts scripting, and so on.

Oh, and we might want to document to the world what we've done so that=20
folks can hopefully appreciate it. ;-)

If you'd like to hack this, I'd be glad to schedule a Skype session to=20
get you up and running with the editor code base on your machine.
>> - See if we can get XSWT brought back into Eclipse in the 3.3=20
>> time frame.  There is some mild interest being expressed by=20
>> the Platform team, and I think we have a shot at it.  This=20
>> would get us quite a bit more exposure.
>>    =20
>
> That would be great!
>  =20
OK.  I'll see what I can do.  In September, that is. :-)


Regards,

Dave Orme

[Xswt-developer] Feedback: Should we focus on supporting RCP only?

[David J. O. <dj...@co...>]

***Prologue: ;-)

Yesterday my team's manager got us together and told us we have to work 
mandatory Saturdays.  She previously had asked us to work whatever 
weeknight overtime we could.  This is expected to continue until early 
September.  And it's in addition to my work on EclipseWorld.  :-(  
Please be patient with my lower level of activity here for the near 
future.  :-)  Thanks.

***The question:

Might we want to make XSWT support Eclipse plugins *only*?  ie: to have 
an explicit linkage to the Eclipse platform?

Maybe this sounds stupid at first glance, so please bear with me...

***The reasoning behind the question:

Maybe we don't want to try to be all things to all people.  Maybe we 
want to just recognize that Eclipse apps these days are done using RCP 
and be done with it.

Here's what this means technically:

I'm *using* XSWT for my RCP app I'm developing for EclipseWorld and am 
pretty happy with it.  There's just one catch if you want to use XSWT 
right now in an RCP appp:

RCP apps in general and Eclipse plugins in particular use a special 
custom class loader for each plugin in order to manage plugin name spaces.

So I had to create a custom EclipsePluginClassloader (or something, 
don't remember the exact name) and add a line to set the plugin 
classloader as the XSWT classloader before parsing a file.  Otherwise, 
XSWT works like a champ for RCP applications.

But this means that in order to use XSWT for RCP, you *have* to 
*manually* configure *each* XSWT instance you create with the right 
class loader so that it can load any SWT class on the current plugin's 
classpath.

If we decided to make XSWT focus purely on being an RCP solution, we 
could eliminate a bunch of ugly reflection code that I asked Hallvard to 
write a while back.  And we also could code the necessary class loading 
stuff I referred to above right into XSWT, making XSWT plug and play for 
RCP apps.  Right now, you have to configure XSWT specifically using my 
custom class loader.


What do folks think?


Regards,

Dave Orme

Re: [Xswt-developer] Xswt-developer Digest, Vol 2, Issue 5

[<ha...@id...>]

David, 

> -----Original Message-----
> Date: Sun, 09 Jul 2006 13:29:20 -0500
> From: "David J. Orme" <dj...@co...>
> Subject: [Xswt-developer] New task list
> 
> Hallvard,
>
> b) I've extended the style sheet test, and added comments 
> about additional style sheet things it would be nice to support.

Concerning this suggestion (cut from the style test):

	<!-- Should be able to just define grabHorizontal on the layoutData
		and make it apply to any GridData on any type of object -->
	<composite x:id="grabHorizontal">
		<layoutData x:class="gridData"
grabExcessHorizontalSpace="true" horizontalAlignment="FILL"/>
	</composite>

Is this meant to declare that all children added to a composite with this
style should automatically "inherit" this particular layout data? I'm not
sure if it makes sense to have a mechanism where a parent style pushes
default values into the children. In this case it makes less sense, since
layout data may apply to the parent (as a child) and the child.

Perhaps you can clarify the suggestion?

Hallvard

Re: [Xswt-developer] Xswt-developer Digest, Vol 2, Issue 5

[<ha...@id...>]

David, 

> -----Original Message-----
> From: "David J. Orme" <dj...@co...>
> Subject: [Xswt-developer] New task list
> 
> (I know you won't get this right away, but I'm writing to the 
> list for everyone's benefit and as a central place to keep 
> these thoughts.)

I'm back now.

> I had a chance to look at the new code that just landed.  
> Great work! I'm especially impressed with the scripting and style sheet
work.

:-)

> - Error handling and reporting:
> 
> a) In addition to pushing line and column information into 
> the nodes so that we can just output the tree nodes as you 
> suggest, script syntax errors are silently ignored, but the 
> layout isn't built either.

I've now changed the code to using a context object (element) for error
reporting. The standard element implementation outputs line and column for
the element (should be enough to identify a faulty attribute).

I'll look into the problem of ignored script syntax errors.

> b) There seem to be situations where other syntax errors 
> result in a layout not being built, but no error reported either.

Can you give some hints for when?

> - Style sheets:
> 
> a) I didn't attempt to cascade across two or more files, but 
> I did try to cascade within a file. i.e: define a style that 
> references two other styles in the same file.  That refused 
> to build, but also didn't display any error.

I've now included some fixes and a test that cascades styles (in the same
sheet file).

> b) I've extended the style sheet test, and added comments 
> about additional style sheet things it would be nice to support.

I think I understand what you want the XML to do, but could you anyway write
the test case (java) code to make it clear?

> - Editor / preview view:
> 
> a) I'm about 95% done migrating the preview code to the new 
> editor framework.  Hopefully that will get finished this week 
> and we can:

I understand you had to temporarily stop working on XSWT and work in
EclipseWorld presentations instead. How far have you come with the editor?

> - See if we can get XSWT brought back into Eclipse in the 3.3 
> time frame.  There is some mild interest being expressed by 
> the Platform team, and I think we have a shot at it.  This 
> would get us quite a bit more exposure.

That would be great!

Hallvard

Re: [Xswt-developer] Progress

[David O. <dj...@co...>]

> Hello David,
>
> before I want to wish you a pleasant vacation I would like to ask if th=
ere
> is a Schema for the new syntax available.

We haven't ever had a schema since we moved to the reflection-based XSWT
implementation.  The reason is that as soon as the classpath changes to
include more or fewer SWT controls (or objects that pretend to be SWT
controls), the schema als needs to change.

So we've had an idea for writing a schema generator that would take a lis=
t
of classes on the classpath and generate the XSWT schema for them, but so
far nobody has volunteered to do that and I've personally had higher
priorities.

If you're interested in taking a crack at it, I'd love to accept a
contribution! :-)

If you think you'd like to help, please review:

http://www.coconut-palm-software.com/the_visual_editor/?page_id=3D72

the XSWT IP contribution policy.  Basically, if we're wildly successful
someday and some company gets mad enough at us to sue us or if we ever
decide to merge back into Eclipse proper, I want to have done legal due
dilligence all along so that we can show that we can legally distribute
XSWT under the EPL terms.


Best regards,

Dave Orme



> Von: xsw...@li... im Auftrag von David =
J.
> Orme
> Gesendet: Fr 8/4/2006 6:06
> An: xsw...@li...
> Betreff: [Xswt-developer] Progress
>
>
>
> Friends,
>
> Progress has slowed for the moment on XSWT.  I've got two EclipseWorld
> presentations I'm working on and a vacation next week.
>
> See you guys on the other end!
>
>
> Dave
>
>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Xswt-developer mailing list
> Xsw...@li...
> https://lists.sourceforge.net/lists/listinfo/xswt-developer
>
>
>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV_______________________________________________
> Xswt-developer mailing list
> Xsw...@li...
> https://lists.sourceforge.net/lists/listinfo/xswt-developer
>

Re: [Xswt-developer] Progress

[Drews, H. <H....@ce...>]

Hello David,
=20
before I want to wish you a pleasant vacation I would like to ask if =
there is a Schema for the new syntax available.
=20
Best regards,
Heinz

________________________________

Von: xsw...@li... im Auftrag von David =
J. Orme
Gesendet: Fr 8/4/2006 6:06
An: xsw...@li...
Betreff: [Xswt-developer] Progress



Friends,

Progress has slowed for the moment on XSWT.  I've got two EclipseWorld
presentations I'm working on and a vacation next week.

See you guys on the other end!


Dave


-------------------------------------------------------------------------=

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
Xswt-developer mailing list
Xsw...@li...
https://lists.sourceforge.net/lists/listinfo/xswt-developer

[Xswt-developer] Progress

[David J. O. <dj...@co...>]

Friends,

Progress has slowed for the moment on XSWT.  I've got two EclipseWorld 
presentations I'm working on and a vacation next week.

See you guys on the other end!


Dave

Re: [Xswt-developer] Inconsistency between different SWT attributes

[David J. O. <dj...@co...>]

Patch applied and released to HEAD.  Thanks!


Best regards,

Dave Orme

Drews, Heinz wrote:
> Hello,
>  
> I'm using the latest version of XSWT checked out from CVS:
>  
> In one of the samples it is said that the color attribute can be 
> specified using CSS names or SWT names.
> In the sample the color name is prefixed by SWT.  But only the name 
> without the prefix is supported.
> This gives an inconsistent behavior, e.g. for fonts SWT.BOLD is used.
>  
> I have attached a patch to allow prefixed names for colors.
>  
> Regards,
> Heinz
> ------------------------------------------------------------------------
>
> Index: src/com/swtworkbench/community/xswt/dataparser/parsers/color/SWTColorsDataParser.java
> ===================================================================
> RCS file: /cvsroot/xswt/com.swtworkbench.community.xswt/src/com/swtworkbench/community/xswt/dataparser/parsers/color/SWTColorsDataParser.java,v
> retrieving revision 1.1
> diff -u -r1.1 SWTColorsDataParser.java
> --- src/com/swtworkbench/community/xswt/dataparser/parsers/color/SWTColorsDataParser.java	20 May 2006 17:13:08 -0000	1.1
> +++ src/com/swtworkbench/community/xswt/dataparser/parsers/color/SWTColorsDataParser.java	3 Aug 2006 19:29:40 -0000
> @@ -12,6 +12,9 @@
>  	}
>  
>  	public Object parse(String source) {
> +		if (source.startsWith("SWT.")) {
> +			source = source.substring(4);
> +		}
>  		Integer rgb = (Integer)super.parse(source);
>  		if (rgb == null) {
>  			return null;
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xswt-developer mailing list
> Xsw...@li...
> https://lists.sourceforge.net/lists/listinfo/xswt-developer
>   

[Xswt-developer] Inconsistency between different SWT attributes

[Drews, H. <H....@ce...>]

SW5kZXg6IHNyYy9jb20vc3d0d29ya2JlbmNoL2NvbW11bml0eS94c3d0L2RhdGFwYXJzZXIvcGFy
c2Vycy9jb2xvci9TV1RDb2xvcnNEYXRhUGFyc2VyLmphdmENCj09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxl
OiAvY3Zzcm9vdC94c3d0L2NvbS5zd3R3b3JrYmVuY2guY29tbXVuaXR5Lnhzd3Qvc3JjL2NvbS9z
d3R3b3JrYmVuY2gvY29tbXVuaXR5L3hzd3QvZGF0YXBhcnNlci9wYXJzZXJzL2NvbG9yL1NXVENv
bG9yc0RhdGFQYXJzZXIuamF2YSx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMQ0KZGlmZiAtdSAt
cjEuMSBTV1RDb2xvcnNEYXRhUGFyc2VyLmphdmENCi0tLSBzcmMvY29tL3N3dHdvcmtiZW5jaC9j
b21tdW5pdHkveHN3dC9kYXRhcGFyc2VyL3BhcnNlcnMvY29sb3IvU1dUQ29sb3JzRGF0YVBhcnNl
ci5qYXZhCTIwIE1heSAyMDA2IDE3OjEzOjA4IC0wMDAwCTEuMQ0KKysrIHNyYy9jb20vc3d0d29y
a2JlbmNoL2NvbW11bml0eS94c3d0L2RhdGFwYXJzZXIvcGFyc2Vycy9jb2xvci9TV1RDb2xvcnNE
YXRhUGFyc2VyLmphdmEJMyBBdWcgMjAwNiAxOToyOTo0MCAtMDAwMA0KQEAgLTEyLDYgKzEyLDkg
QEANCiAJfQ0KIA0KIAlwdWJsaWMgT2JqZWN0IHBhcnNlKFN0cmluZyBzb3VyY2UpIHsNCisJCWlm
IChzb3VyY2Uuc3RhcnRzV2l0aCgiU1dULiIpKSB7DQorCQkJc291cmNlID0gc291cmNlLnN1YnN0
cmluZyg0KTsNCisJCX0NCiAJCUludGVnZXIgcmdiID0gKEludGVnZXIpc3VwZXIucGFyc2Uoc291
cmNlKTsNCiAJCWlmIChyZ2IgPT0gbnVsbCkgew0KIAkJCXJldHVybiBudWxsOw0K

[Xswt-developer] New task list

[David J. O. <dj...@co...>]

Hallvard,

(I know you won't get this right away, but I'm writing to the list for 
everyone's benefit and as a central place to keep these thoughts.)

I had a chance to look at the new code that just landed.  Great work!  
I'm especially impressed with the scripting and style sheet work.

The following is a list of things I noticed still need to be done, in no 
particular order.

- Error handling and reporting:

a) In addition to pushing line and column information into the nodes so 
that we can just output the tree nodes as you suggest, script syntax 
errors are silently ignored, but the layout isn't built either.

b) There seem to be situations where other syntax errors result in a 
layout not being built, but no error reported either.

- Style sheets:

a) I didn't attempt to cascade across two or more files, but I did try 
to cascade within a file.  ie: define a style that references two other 
styles in the same file.  That refused to build, but also didn't display 
any error.

b) I've extended the style sheet test, and added comments about 
additional style sheet things it would be nice to support.

- Editor / preview view:

a) I'm about 95% done migrating the preview code to the new editor 
framework.  Hopefully that will get finished this week and we can:

- Ship beta 1 of XSWT 2.0.

a) Create update site.

b) Write documentation.

c) Create a screen cast or two.

- See if we can get XSWT brought back into Eclipse in the 3.3 time 
frame.  There is some mild interest being expressed by the Platform 
team, and I think we have a shot at it.  This would get us quite a bit 
more exposure.



Regards,

Dave

[Xswt-developer] Tree-based XSWT and XSWTExceptions

[<ha...@id...>]

Hi,=20

There's one snag with the new tree-based design of XSWT: It's more =
difficult
to give precise error messages, since information about line and column =
is
lost. When implementing the new design, I replaced the line and column =
in
many calls to new XSWTException with -1 and -1. I haven't had time to go
through them, but I guess the best solution is to redefine XSWTException =
to
hold an element instead of line, column and then pass the element to the
constructor instead. Hopefully the element's toString() method is
informative, which at least the default element implementation's is. In =
some
cases the line and column is passed into methods that use them for =
throwing
nice XSWTExceptions, and in these cases, the element should be passed
instead.

Have a nice summer!

Hallvard

---
Hallvard Tr=E6tteberg (ha...@id..., http://www.idi.ntnu.no/~hal)
Associate Professor, IS group, Dept. of Computer and Information =
Sciences at
the Norwegian Univ. of Science and Technology

Re: [Xswt-developer] tree builder and stylesheet

[<ha...@id...>]

> -----Original Message-----
> Message: 2
> Date: Wed, 05 Jul 2006 17:01:44 -0500
> From: "David J. Orme" <dj...@co...>
> Subject: [Xswt-developer] Recent changes
> 
> At first glance, they look very nice.  I'll try to review 
> them in more detail later tonight and get back to you on your 
> specific questions.

I've now checked all of it in, including the texteditor plugin (which for
some reason lacked the editor classes). The CVS version is supposed to be
functional now, the tests in the test project work (must be run as SWT
applications) and the pnuts project and examples work too.

> Thanks again and keep up the good work!

Thanks! Concerning keeping up the work, I'm off for my summer vacation
tomorrow afternoon (GMT+1), and won't be connected for the next two weeks.
After that I may find an internet cafe and check my email. I hope there are
no problems that will surface, although I've tried to test the examples and
of course run the new tests.

> From: <Yu...@no...>
> Subject: Re: [Xswt-developer] stylesheets
> 
> Impressive and good job. 

Hope so.

> So I assume nested  or cascading style sheets should work too?

The design should allow it, but I haven't tested it, yet. Since I'm off for
my summer vacation, I don't want to dig too deep into this. Instead I've
focussed on getting the committed version in good (enough) shape.

Hallvard

Re: [Xswt-developer] stylesheets

[<Yu...@no...>]

Impressive and good job.=20

So I assume nested  or cascading style sheets should work too?

Yu You, Ph.D.
Research Engineer
Nokia Research Center, Tampere, FI
=20
=20

>-----Original Message-----
>From: xsw...@li...=20
>[mailto:xsw...@li...] On=20
>Behalf Of ext Hallvard Tr?tteberg
>Sent: 06 July, 2006 00:48
>To: xsw...@li...
>Subject: [Xswt-developer] stylesheets
>
>Hi,
>
>After implementing the tree builder, I've been working on the=20
>stylesheet mechanism, based on the design suggestions at=20
>http://www.coconut-palm-software.com/the_visual_editor/?page_id
>=3D61. The current design is as follows:
>
>When the import/stylesheet tag is encountered, another=20
>instance of XSWT is used to load that stylesheet. Parsing a=20
>stylesheet differs somewhat from parsing an ordinary file, as=20
>it expects to find all the styles at the top level, and each=20
>must have an id. No objects are created, but the id map is=20
>used to "remember" the styles. What is important is that that=20
>XSWT instance keeps track of its own imports (and other state).
>
>When a style is referenced, the corresponding style=20
>tag/element/node is retrieved and parsed by the XSWT object=20
>that loaded it, but in the context of the referencing object.
>
>I think the basic design works, but haven't gone through all=20
>the details.
>However, I've written the first test that works(!):
>
>public class StyleTest extends XSWTTestCase {
>
>	public void testStyle() {
>		Label label =3D (Label)getChild(0, Label.class);
>		Color col =3D label.getBackground();
>		assertEquals(255, col.getRed());
>		assertEquals(0, col.getGreen());
>		assertEquals(0, col.getBlue());
>		assertTrue((label.getStyle() & SWT.BORDER) > 0);
>	}
>=09
>	public static void main(String[] args) {
>		doRun(StyleTest.class);
>	}
>}
>
>StyleTest.xswt
><xswt xmlns:x=3D"http://sweet_swt.sf.net/xswt">
>	<import xmlns=3D"http://sweet_swt.sf.net/xswt">
>		<package name=3D"java.lang"/>
>		<package name=3D"org.eclipse.swt.widgets"/>
>		<package name=3D"com.swtworkbench.community.xswt.test"/>
>		<stylesheet x:id=3D"styles" relativeTo=3D"StyleTest"
>path=3D"StyleTestStyles.xswt"/>
>	</import>
>	<x:children>
>		<label x:style=3D"styles.redLabel"/>
>	</x:children>
></xswt>
>
>StyleTestStyles.xswt:
><xswt xmlns:x=3D"http://sweet_swt.sf.net/xswt">
>	<import xmlns=3D"http://sweet_swt.sf.net/xswt">
>		<package name=3D"java.lang"/>
>		<package name=3D"org.eclipse.swt.widgets"/>
>	</import>
>	<label x:id=3D"redLabel"
>		x:style=3D"BORDER"
>		background=3D"Red"/>
></xswt>
>
>Note how the stylesheet has its own id and how the style in=20
>that stylesheet is referenced using <stylesheet-id>.<style-id>.
>
>Hallvard Tr=E6tteberg (ha...@id...,=20
>http://www.idi.ntnu.no/~hal) Associate Professor, IS group,=20
>Dept. of Computer and Information Sciences at the Norwegian=20
>Univ. of Science and Technology
>
>
>Using Tomcat but need to do more? Need to support web=20
>services, security?
>Get stuff done quickly with pre-integrated technology to make=20
>your job easier Download IBM WebSphere Application Server=20
>v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&d
>at=3D121642
>_______________________________________________
>Xswt-developer mailing list
>Xsw...@li...
>https://lists.sourceforge.net/lists/listinfo/xswt-developer
>

Re: [Xswt-developer] the XML parser

[David J. O. <dj...@co...>]

Drews, Heinz wrote:
> Hello,
>
> I have started to experiment with XSWT by using the latest binary download.
>
> I have also checked out the plugin project and found, that there are a lot
> of enhancements and modifications.
> E.g. the samples in the project don't work with the installed plugin.
>
> Which of the projects in the source repository are required to build an
> installable plugin?
> Are there some guidelines available?
>   
The com.swtworkbench.community.xswt and org.kxml plugins should be what 
you need to get the engine running.  The editors are currently broken as 
we are in the middle of a large refactoring.

Hope this helps.  If there's anything else I can do to help, please let 
me know.


Regards,

Dave Orme

[Xswt-developer] Recent changes

[David J. O. <dj...@co...>]

Hallvard,

Yesterday was Independence Day celebrations here in the United States 
and so I only got a chance to briefly look at the new changes today.

At first glance, they look very nice.  I'll try to review them in more 
detail later tonight and get back to you on your specific questions.

One thing that would help me a lot though is if you could keep the 
texteditor plugin in sync with your changes.  Although the XSWT Preview 
view is going away, this will help me know what I need to do to sync the 
new XSWT editor plugins with your changes as you work.

Thanks again and keep up the good work!


Best regards,

Dave Orme

[Xswt-developer] stylesheets

[<ha...@id...>]

Hi,

After implementing the tree builder, I've been working on the stylesheet
mechanism, based on the design suggestions at
http://www.coconut-palm-software.com/the_visual_editor/?page_id=3D61. =
The
current design is as follows:

When the import/stylesheet tag is encountered, another instance of XSWT =
is
used to load that stylesheet. Parsing a stylesheet differs somewhat from
parsing an ordinary file, as it expects to find all the styles at the =
top
level, and each must have an id. No objects are created, but the id map =
is
used to "remember" the styles. What is important is that that XSWT =
instance
keeps track of its own imports (and other state).

When a style is referenced, the corresponding style tag/element/node is
retrieved and parsed by the XSWT object that loaded it, but in the =
context
of the referencing object.

I think the basic design works, but haven't gone through all the =
details.
However, I've written the first test that works(!):

public class StyleTest extends XSWTTestCase {

	public void testStyle() {
		Label label =3D (Label)getChild(0, Label.class);
		Color col =3D label.getBackground();
		assertEquals(255, col.getRed());
		assertEquals(0, col.getGreen());
		assertEquals(0, col.getBlue());
		assertTrue((label.getStyle() & SWT.BORDER) > 0);
	}
=09
	public static void main(String[] args) {
		doRun(StyleTest.class);
	}
}

StyleTest.xswt
<xswt xmlns:x=3D"http://sweet_swt.sf.net/xswt">
	<import xmlns=3D"http://sweet_swt.sf.net/xswt">
		<package name=3D"java.lang"/>
		<package name=3D"org.eclipse.swt.widgets"/>
		<package name=3D"com.swtworkbench.community.xswt.test"/>
		<stylesheet x:id=3D"styles" relativeTo=3D"StyleTest"
path=3D"StyleTestStyles.xswt"/>
	</import>
	<x:children>
		<label x:style=3D"styles.redLabel"/>
	</x:children>
</xswt>

StyleTestStyles.xswt:
<xswt xmlns:x=3D"http://sweet_swt.sf.net/xswt">
	<import xmlns=3D"http://sweet_swt.sf.net/xswt">
		<package name=3D"java.lang"/>
		<package name=3D"org.eclipse.swt.widgets"/>
	</import>
	<label x:id=3D"redLabel"
		x:style=3D"BORDER"
		background=3D"Red"/>
</xswt>

Note how the stylesheet has its own id and how the style in that =
stylesheet
is referenced using <stylesheet-id>.<style-id>.

Hallvard Tr=E6tteberg (ha...@id..., http://www.idi.ntnu.no/~hal)
Associate Professor, IS group, Dept. of Computer and Information =
Sciences at
the Norwegian Univ. of Science and Technology

[Xswt-developer] XSWT and tree-based parser

[<ha...@id...>]

Hi,

I now have an experimental XSWT implementation, that is based the
IMinimalParser interface proposed in a previous message. Instead of =
directly
using the pull parser, the pull parser is used to build a tree, which is
then given to XSWT wrapped in an IMinimalParser implementation. The =
tests
run OK.

The IMinimalParser implementation and pull parser-based tree builder is =
a
little less than 300 lines of code, while XSWT is a bit over 100 lines
shorter, since the code for reading XML data is simplified.

What is the best way to review the code?

Hallvard Tr=E6tteberg (ha...@id..., http://www.idi.ntnu.no/~hal)
Associate Professor, IS group, Dept. of Computer and Information =
Sciences at
the Norwegian Univ. of Science and Technology

[Xswt-developer] new test project

[<ha...@id...>]

Hi,

I've added a new project for testing and implemented two tests, as a =
start.
They both rely on methods in the XSWTTestCase class, which handles =
creating
the XSWT object, a Shell and using the Shell as the parent. Since the =
tests
require SWT, they must be run with the SWT applicaiton launcher, and =
invoke
a TestRunner manually. This requires a main method, which calls a =
utility
method in XSWTTestCase, as shown below. Two getChild methods are =
provided
for getting hold of Controls below the Shell in the widget hierarchy.

An XSWTTestCase assumes that there is a an XSWT file of the same name as =
the
test class, i.e. WidgetCreationTest.xswt for the WidgetCreationTest =
class
below. The content of this file is shown below. The XSWTTestCase class
provides setUp methods for reading the XSWT code from an InputStream or =
a
String instead. This requires overriding the no-arg setUp method and =
calling
one of the inherited ones.

Please critique the design! And if anybody knows how to make the =
launching
code more elegant, please enlighten me :-)

public class WidgetCreationTest extends XSWTTestCase {

	public void testLabel() {
		Label label =3D (Label)getChild(0, Label.class);
		assertEquals("Label", label.getText());
	}
=09
	public static void main(String[] args) {
		doRun(WidgetCreationTest.class);
	}
}

<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<xswt xmlns:x=3D"http://sweet_swt.sf.net/xswt">
	<import xmlns=3D"http://sweet_swt.sf.net/xswt">
		<package name=3D"java.lang"/>
		<package name=3D"org.eclipse.swt.widgets"/>
	</import>
	<x:children>
		<label text=3D"Label"/>
	</x:children>
</xswt>

Hallvard Tr=E6tteberg (ha...@id..., http://www.idi.ntnu.no/~hal)
Associate Professor, IS group, Dept. of Computer and Information =
Sciences at
the Norwegian Univ. of Science and Technology

Re: [Xswt-developer] the XML parser

[<ha...@id...>]

> -----Original Message-----
> Date: Thu, 29 Jun 2006 20:42:40 -0500
> From: "David J. Orme" <dj...@co...>
> Subject: Re: [Xswt-developer] the XML parser
> I'm still of two minds about this.
> 
> One of the things we all like about XSWT is that it _isn't 
> XUL_.  It comes from a "less is more" design philosophy.

I like that philosophy, as it reduces the threshold for accepting it e.g. as
a part of other projects.

> On the + side for this idea, having such a layer would make 
> this migration easier

The layer is supposed to be light-weight, to hide the difference in API of
different XML parsers. The goal is to focus on what XSWT needs from a
parser, to give developers (including us) more freedom in which underlying
parser to use. There are other arguments I'd like to mention:
- I don't know all the contexts that use XSWT, but it is best if XSWT does
not dictate that parser used for other parts. I know from my own experience,
that it's sometimes difficult to use several parsers within one application.
- I believe we need this freedom ourselves, so we can work on the style
mechanism before we settle on the parser.
- Using a tree-oriented API will clean up XSWT, as the event-based pull
parsing makes it more difficult to read than a similar one, based on
tree-traversal.
- If XSWT is to be tightly coupled with an application, like an editor,
passing a tree is leaner and quicker than writing and reading a file.

> If you feel strongly that having the abstraction is worth more than the
weight
> it would add, I think I'll defer to your opinion.  If you're not totally
convinced
> yourself, then let's keep discussing it.

I'm convinced I want to, but I don't want to force it on XSWT without a
proper discussion. My suggestion for API is shown below. Design decisions:
- It is based on opaque objects, where the parser knows how to interpret it.
This makes it easier to support different representations and does not
require specific Element and Attribute classes. If a parser already builds
an object tree, this makes it possible to return this as is, and the parser
just needs to return the appropriate information, given little extra
overhead.
- There is no separate document object, as XSWT currently just uses the
root.
- It is based on positional access instead of Iterators. I don't feel
strongly about this, as XSWT only uses sequential access. Positional
traversal use less space, but may be slower if it requires scanning the list
each time (e.g. if the source list interleaves different child nodes, like
text and elements). Note that we can introduce Iterators for either child
elements or attributes or both.

A test implementation wrapping KXML, with one fairly generic class for
representing the tree and one subclass for building it, uses 230 lines (110
+ 120, respectively).

Please comment on both the general idea of an XML tree abstraction and the
suggested interface.

public interface IMinimalParser {
	// Builds an object tree from an InputStream input
	public Object build(InputStream input);
	
	// Returns the name of the element
	public String getElementName(Object element);
	// Returns the namespace (URI) of the element
	public String getElementNamespace(Object element);

	// Returns the number of children of element
	public int getChildElementCount(Object element);
	// Returns the child element of element at the given position 
	public Object getChildElement(Object element, int i);
	
	// Returns the number of attributes of element
	public int getAttributeCount(Object element);
	
	// Returns the name of the given attribute of element
	public String getAttributeName(Object element, int i);
	// Returns the namespace (URI) of the given attribute of element
	public String getAttributeNamespace(Object element, int i);
	// Returns the text value of the given attribute of element
	public String getAttributeValue(Object element, int i);

	// Returns the text content of element
	public String getElementText(Object element);
}