Skip to main content

[VOTE] Demos and SwingLabs-Demos

18 replies [Last post]
rbair
Offline
Joined: 2003-07-08
Points: 0

Hey guys,

The more subprojects we add to SwingLabs, the nastier SwingLabs-demos gets. For those not up to speed, the swinglabs-demos project contains both a general demo infrastructure, and specific demos for SwingLabs components.

Unfortunately, this leads to a large inter project dependency that is getting hard to maintain. Whenever a change is made to a SwingX component, for instance, we then have to open up the SwingLabs demos project and update the demo there.

As a result, we often see Josh and myself writing little main methods in the SwingX project to test the component rather than going through the hassle of updating the swinglabs-demos demos. Clearly, this isn't good.

What I propose is clearing out the specific demos from swinglabs-demos. Let swinglabs-demos contain a common demo framework (code for switching look and feels, showing documentation, etc). Let a copy of the swinglabs-demos jar be placed within each swinglabs subproject in a lib/demos directory. Then have a src/demos source directory. So it would look something like this, for all swinglabs sub projects:

<br />
SwingX<br />
    - bin<br />
    - dist<br />
    - lib<br />
        - cobundle<br />
        - optional<br />
        - demos<br />
    - src<br />
        - beaninfo<br />
        - demo<br />
        - java<br />
        - test<br />

What do you think? I'll leave this question open until Jeanette comes back.

Richard

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joshua Marinacci

Netbeans with support for the two JSRs will actively enourage using
actions and not subclassing. Painters will help as well, since you
won't need to subclass to do cool effects.

- Josh

On Dec 7, 2006, at 12:18 PM, Curt Cox wrote:

> One of the reasons that I'm really interested in how NetBeans supports
> JSR 295/296 is to see what kind of application structures it will
> encourage people to use. In the past, the bad practices that were
> adopted in the name of short demos in the Swing Trail started many
> developers down the wrong path. Today the GUI creation tools in
> NetBeans fail to support and even actively discourage following 2
> Swing Labs Imperial Rules:
>
> 1) Do not subclass AWT/Swing/X Components for application needs
> 2) Do use Action instead of ActionListener
>
> NetBeans also discourages the separation of the GUI from the
> application logic.
>
> PS -- Will Semplice use JSR 295/296?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

- Blasting forth in three part harmony!

[att1.html]

Joshua Marinacci

On Dec 7, 2006, at 11:35 AM, Curt Cox wrote:

> Inevitable followups:
>
> 1) Is work underway for NetBeans to support JSR 295/296?

Absolutely. My main job right now is the actions support for JSR 296.

> 2) When can we expect the first Nightly builds with such support?

I don't know yet. I'd say January. We've been busy getting everything
in order for JavaPolis.

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

- Blasting forth in three part harmony!

[att1.html]

Joshua Marinacci

It's coming along. Hans and Scott have promised public versions
soon. They can't wait too long because they have to be public for
our NetBeans support to work, and our feature freeze is around
March. I think you'll like what you'll see. Our demo for JavaPolis
is quite compelling.

- Josh

On Dec 7, 2006, at 10:43 AM, jdnc-interest@javadesktop.org wrote:

> Since YOU brought them up, does anyone have any updated information
> on JSR-295 or JSR-296? Many of us are beginning to get worried
> now. ;)
>
> Erik
> [Message sent by forum member 'evickroy' (evickroy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=183987
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

- Blasting forth in three part harmony!

[att1.html]

Curt Cox

Inevitable followups:

1) Is work underway for NetBeans to support JSR 295/296?
2) When can we expect the first Nightly builds with such support?

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Curt Cox

One of the reasons that I'm really interested in how NetBeans supports
JSR 295/296 is to see what kind of application structures it will
encourage people to use. In the past, the bad practices that were
adopted in the name of short demos in the Swing Trail started many
developers down the wrong path. Today the GUI creation tools in
NetBeans fail to support and even actively discourage following 2
Swing Labs Imperial Rules:

1) Do not subclass AWT/Swing/X Components for application needs
2) Do use Action instead of ActionListener

NetBeans also discourages the separation of the GUI from the application logic.

PS -- Will Semplice use JSR 295/296?

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Bill Snyder

Is the stuff on the Netbeans form_promoh current?

On 12/7/06, Curt Cox wrote:
>
> One of the reasons that I'm really interested in how NetBeans supports
> JSR 295/296 is to see what kind of application structures it will
> encourage people to use. In the past, the bad practices that were
> adopted in the name of short demos in the Swing Trail started many
> developers down the wrong path. Today the GUI creation tools in
> NetBeans fail to support and even actively discourage following 2
> Swing Labs Imperial Rules:
>
> 1) Do not subclass AWT/Swing/X Components for application needs
> 2) Do use Action instead of ActionListener
>
> NetBeans also discourages the separation of the GUI from the application
> logic.
>
> PS -- Will Semplice use JSR 295/296?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
[att1.html]

Joshua Marinacci

Yes, though you need two jars for the JSR support. That will be
coming soon.

- Josh

On Dec 7, 2006, at 1:19 PM, Bill Snyder wrote:

> Is the stuff on the Netbeans form_promoh current?
>
> On 12/7/06, Curt Cox wrote:
> One of the reasons that I'm really interested in how NetBeans supports
> JSR 295/296 is to see what kind of application structures it will
> encourage people to use. In the past, the bad practices that were
> adopted in the name of short demos in the Swing Trail started many
> developers down the wrong path. Today the GUI creation tools in
> NetBeans fail to support and even actively discourage following 2
> Swing Labs Imperial Rules:
>
> 1) Do not subclass AWT/Swing/X Components for application needs
> 2) Do use Action instead of ActionListener
>
> NetBeans also discourages the separation of the GUI from the
> application logic.
>
> PS -- Will Semplice use JSR 295/296?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>

- Blasting forth in three part harmony!

[att1.html]

rbair
Offline
Joined: 2003-07-08
Points: 0

Haven't heard any -1 votes on this thread :-)

> > - the quick'n-really-simple inlined in each
> project
> > - the rich showcase in swinglabs demos

This is the idea. If there are no belated objections, I'll happily write a couple demos for SwingX. Of course, demos are NEVER backwards compatible :-)

Richard

osbald
Offline
Joined: 2003-06-13
Points: 0

Sounds like a plan, think I ran into swinglabs-demo build problems because the incubator build needed it for some reason. The incubator might also need a clearout (not to mention renaming) but I guess it's not such a pain as it lacks any kind of easy holistic build.

Saw someone had kicked off another Swing 2.0 thread today: http://www.javalobby.org/java/forums/t85782.html Much of which I know is already covered in Mustang/SwingX or in the pipeline.. being able to show off some working demos would've been handy.

Did notice a several people asking for more patterns oriented samples in that thread which I'd also like to see - help me follow those Imperial orders.. Or is that more swinglabs-blueprints territory? which is currently pretty barren (here lie monsters)

- Richard v2

Message was edited by: osbald

rbair
Offline
Joined: 2003-07-08
Points: 0

> Did notice a several people asking for more patterns
Hey Rv2

> oriented samples in that thread which I'd also like
> to see - help me follow those Imperial orders.. Or is
> that more swinglabs-blueprints territory? which is
> currently pretty barren (here lie monsters)

:-)

One of these days we'll actually have a blueprint program. First though, I suspect having JSR 295 and 296 done would be nice, since the blueprint will change once those APIs are complete.

Richard

evickroy
Offline
Joined: 2004-07-23
Points: 0

Since YOU brought them up, does anyone have any updated information on JSR-295 or JSR-296? Many of us are beginning to get worried now. ;)

Erik

rbair
Offline
Joined: 2003-07-08
Points: 0

Fear not!

Actually, I will be demo'ing JSR 295/296 + NetBeans integration at JavaPolis next week with Hans Muller. For those not in Antwerp, I seriously hope the parties involved decide to post this build on the net so we can get some early access feedback. Nudge nudge :-)

Richard

osbald
Offline
Joined: 2003-06-13
Points: 0

Speaking of which I just came across this via a JavaPolis bulk mail: http://www.finalist.com/en/english/english_news/jsr-296_swing_applicatio...

But I'm none the wiser.

- Richard

kleopatra
Offline
Joined: 2003-06-11
Points: 0

Hi Richard,

Wow - what an active thread Sorry for being so late myself, had to think a bit about why I feel uncomfortable.

Starting with the agreement: swinglabs-demos needs a thorough cleanup (which of our projects' doesn't ). It's poorly maintained - in fact isn't even compiling for some time - the demos are off from the current evolution of the other subprojects.

Not quite sure if we are on the same page about what the dirt is:

>
> The more subprojects we add to SwingLabs, the nastier
> SwingLabs-demos gets. [...]
> Unfortunately, this leads to a large inter project
> dependency that is getting hard to maintain.

I can't see any nastiness in the dependency of swinglabs-demos on the subprojects - it's strictly one-directional from demo to subproject, nothing inter.

> Whenever
> a change is made to a SwingX component, for instance,
> we then have to open up the SwingLabs demos project
> and update the demo there.
>

To me, that looks more like a problem of local workspace setup: dependent projects should be open always to immediately see and fix the ripples of change. Or even better: let the IDE promote the changes automatically (maybe NetBeans can't ?)

> As a result, we often see Josh and myself writing
> little main methods in the SwingX project to test the
> component rather than going through the hassle of
> updating the swinglabs-demos demos. Clearly, this
> isn't good.
>

I agree that this is a no-no - but looks like one or even two different stories:

- SwingLabs-demos is not exactly the place where to put those "little main method" demos (give it a quick look)

- the swingx support for the "quick-look-at" example is InteractiveTestCase (needs cleanup )

- demos in a branch are really a problem (as is developing in a branch as such for a long time - the merge will be nasty ..)

> What I propose is clearing out the specific demos
> from swinglabs-demos. Let swinglabs-demos contain a
> common demo framework (code for switching look and
> feels, showing documentation, etc).

Just to make sure I fully understand what you are at: the proposal is to completely redefine swinglabs-demos scope -
a place to showcase polished highlights of individual classes, projects and their interplay in typical scenarios (including third party libraries) - to a utility project containing some infrastructure to easily write demos?

Hmm ... thinking aloud about implications

- we loose the one-place for all demos
- all subprojects need the third-party downloads in their demo-subsection
- the build complexity of all subprojects increases
- no inter-project demos possible
- it's easier for newbies to have demos along with the project
- it's easier for NetBeans developers to keep everything consistent

In the end, I'm a bit undecided (unusual state, my lame excuse is that I'm brewing my new cold - arrgghhh) with a tendency to not-inline the demos. Maybe there's a need for different levels of demos:

- the quick'n-really-simple inlined in each project
- the rich showcase in swinglabs demos

Jeanette

rbair
Offline
Joined: 2003-07-08
Points: 0

Hi Jeanette

> - demos in a branch are really a problem (as is
> developing in a branch as such for a long time - the
> merge will be nasty ..)

Definitely no demos in a branch. I'm not sure if this was just thrown out there, but for clarity what I'm proposing is a new source tree (just like src/test, src/java, src/beaninfo), in the trunk. Working with branches can be really nasty, I learned my lesson with the binding branch :-)

> Just to make sure I fully understand what you are at:
> the proposal is to completely redefine
> swinglabs-demos scope -
> a place to showcase polished highlights of individual
> classes, projects and their interplay in typical
> scenarios (including third party libraries) - to a
> utility project containing some infrastructure to
> easily write demos?
>
> Hmm ... thinking aloud about implications
>
> - we loose the one-place for all demos
> - all subprojects need the third-party downloads in
> their demo-subsection
> - the build complexity of all subprojects increases
> - no inter-project demos possible
> - it's easier for newbies to have demos along with
> the project
> - it's easier for NetBeans developers to keep
> everything consistent
>
> In the end, I'm a bit undecided (unusual state, my
> lame excuse is that I'm brewing my new cold -
> arrgghhh) with a tendency to not-inline the demos.
> Maybe there's a need for different levels of demos:
>
> - the quick'n-really-simple inlined in each project
> - the rich showcase in swinglabs demos

Yes, I think you are right. SwingLabs-demos would still be the preferred place to put any larger inter-project demos. It would be nice if each of these larger interproject demos had its own source tree in swinglabs-demos (src/adventure-bulder, src/uberdemo, etc), and the src/java source tree would be where the "common" framework stuff would be. This would probably just be a few interfaces and a couple classes, nothing major. Have to think on it a bit more.

What I'm hoping to enable, is to move development of the "JXTaskPaneDemoPanel" type classes out of SwingLabs-Demos into the specific project themselves. Here are the benefits:

- Developers who have downloaded the swingx project can run the demos standalone; no additional downloads required
- Easier for us to write these demos as we are building the components themselves
- Ability to embed these demos as applets within the javadoc for the component
- Just as easy for the SwingXDemo in SwingLabs-Demos to include a demo written in SwingX, as to include a demo written in SwingLabs-Demos

I agree with you that larger demos should be in swinglabs-demos. I also agree that we don't want to include a bunch of third party libs in each of the sub projects. I propose *just* including the swinglabs-demos.jar (stripped of everything except the core "framework", such as the DemoPanel class) in swingx and the other subprojects.

Cheers
Richard

pdoubleya
Offline
Joined: 2004-02-09
Points: 0

What I'd add here is that we have an interest in making demo development and maintenance easier, in having working demos for stable releases, and being able to demo new features and APIs that are in-progress.

I definitely thing SWL-D is a good place for common demo framework. Things like startup panel, common resources, template JNLP files, etc. can all go there. However, I'd argue that those pieces should only be Java 5 standard + last stable SwingX release (0.8), not CVS HEAD.

Same for the "main" demo. That should be built against the latest stable release and should link to those JARs. Anyone downloading 0.8 should have a good, solid set of demos + code to look at.

Outside of that, there are ongoing demos, like the Painter or Filter stuff recently. I think people are on their own, but would expect them to package their own cut of CVS and bundle it with their demo. Most of those demos will be incubator quality or meant only as JNLP or quick look-see. However, they can benefit from some standard classes and templates to make demos quickly and have them look good.

Features like "view source" should be standard, as (probably) should be a little panel with scripting language support. We can add BeanShell in Java 5 without breaking a sweat and people can actually modify the running demo! It'll be like Smalltalk! Hey! "SwingTalk--now with SwingTalk(tm) Technology *you* tha Man to talk to!

OK, little detour.

Anyway, I think it's a fool's errand to maintain a (set of) demo applications that work against HEAD. But I think that a release-stable demo app is a good deliverable.

etc.

Regards
Patrick

rbair
Offline
Joined: 2003-07-08
Points: 0

> Anyway, I think it's a fool's errand to maintain a
> (set of) demo applications that work against HEAD.
> But I think that a release-stable demo app is a good
> deliverable.

Agreed.

fester
Offline
Joined: 2006-11-06
Points: 0

Do you guys conside using Maven (http://maven.apache.org/) to build SwingX? It would be nice to follow the standard directory layout(http://maven.apache.org/guides/introduction/introduction-to-the-standard...).

In Maven the recommended structure would probably look like this (supposing that you only need 2 projects):

SwingX
- pom.xml
--- swingx-core
------ pom.xml
------ src/main/java
------ src/test/java
--- swingx-demo
------ pom.xml
------ src/main/java
------ src/test/java

For more info on Maven: http://maven.apache.org/what-is-maven.html

regards,

Wim