Skip to main content

JXBusyLabel

43 replies [Last post]
rbair
Offline
Joined: 2003-07-08

Josh recently brought JXBusyLabel over with the rest of the painter_work branch. It wasn't really supposed to be brought over, but looked pretty useful (especially since it only contains 3 public methods: a constructor and an is/set property pair). I've cleaned it up, added comments, and committed it.

http://swinglabs.org/hudson/job/SwingX%20Continuous%20Build/javadoc/org/...

Of course, API shouldn't be coming over into SwingX unless it has been reviewed (or if it is being included as part of a fix, or preparation for review, for one of the existing components like JXTable). So I'm trying to get this one reviewed.

What do you guys thing? Worthy? There is more that could be done (such as providing a pluggable painter, pluggable timer) but doing more will involve more API review and such, which can always be done later. That is, this is a good basic API that we could grow over time.

Richard

Reply viewing options

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

The commit of these components was an accident. They happened to be
in the branch when I merged it. I've moved the insets and boxpanel to
my incubator. Rich would like to keep the JXBusyLabel around because
it's pretty useful even in it's currently limited api.

- J

On Mar 16, 2007, at 12:52 PM, Patrick Wright wrote:

> Josh
>
> As far as I've understood and seen the process, the idea is you check
> some code into the incubator with one or more demos, then announce it.
> There will be several rounds of feedback leading to either a stable
> proposal, or just a demo in the incubator. If there's a formal
> proposal, then it gets queued for review.
>
> I think this can go pretty quickly, at least, that's what I've seen.
> But experience also shows it tends to weed out ideas that are not
> fully formed or aren't compatible with where the main development is
> headed.
>
> You have committer rights, so of course, you can commit into the main
> trunk, but I think it leads to a better outcome if we respect some
> modicum of process in this.
>
> Regards
> Patrick
>
> ---------------------------------------------------------------------
> 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

> Sure you can access and change the painter ... tho
> this should be perhaps easier then:
> [code]
> BusyPainter p = (BusyPainter) ((PainterIcon)
> busyLabel.getIcon()).getPainter();
> [/code]
> Or am I missing something here?
> And don't forget - make speed/animation time
> configurable.

Josh initially had more methods on this class, and I trimmed them down to just setBusy()/isBusy(). I did this on purpose.

JXBusyLabel introduces a new wrinkle that has not yet been formalized; animated painters. To propose a component that exposed carefully designed forward-compatible API would be a lot more work.

Yes, all those things mentioned are important and should be done. There should be a UI delegate for this thing so that LAFs can initialize what the thing looks like. I know Nimbus would have a take on this component.

Does that mean I have to do it *right now*? Well, maybe, if you make me feel guilty about it :-). At least then you'd have a known path for changing what the animation looks like until I get around to providing public API for it.

I certainly don't want to bake assumptions into the API about what the animation looks like. And I don't want to publicly declare an animation system yet for this, otherwise I'd make it pluggable to get/set the painter being used.

At the same time I don't see any point in making the component sit in the backfield when, even in this very simple state, it could be quite useful to folks.

What is wrong with getting a simple, yet convenient, API out the door, and improve and enhance it over time?

By the way, I plan on putting JXComponentComboBox into the dev pack.

Surely, the setBusy()/isBusy() API isn't going to pose a problem over time, right?

Creating a UI delegate for this should take less time than this email has. Any patches, anyone?

Richard

kleopatra
Offline
Joined: 2003-06-11

> > Having the Painter pluggable would be reasonable
> > middle-path for now - though it stilll leaves to
> > problem to synch the corresponding properties
> > (currently only the colors) between both.
>
> Sure you can access and change the painter ... tho
> this should be perhaps easier then:
> [code]
> BusyPainter p = (BusyPainter) ((PainterIcon)
> busyLabel.getIcon()).getPainter();
> [/code]

haha, and we had been talking about simple and intuitive api

Happy weekend
Jeanette

Joshua Marinacci

Well, then perhaps now is the time to discuss what one would want out
of the API.

- j

On Mar 16, 2007, at 9:34 AM, jdnc-interest@javadesktop.org wrote:

>>> Having the Painter pluggable would be reasonable
>>> middle-path for now - though it stilll leaves to
>>> problem to synch the corresponding properties
>>> (currently only the colors) between both.
>>
>> Sure you can access and change the painter ... tho
>> this should be perhaps easier then:
>> [code]
>> BusyPainter p = (BusyPainter) ((PainterIcon)
>> busyLabel.getIcon()).getPainter();
>> [/code]
>
> haha, and we had been talking about simple and intuitive api
>
> Happy weekend
> Jeanette
> [Message sent by forum member 'kleopatra' (kleopatra)]
>
> http://forums.java.net/jive/thread.jspa?messageID=208461
>
> ---------------------------------------------------------------------
> 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]

Patrick Wright

Josh

As far as I've understood and seen the process, the idea is you check
some code into the incubator with one or more demos, then announce it.
There will be several rounds of feedback leading to either a stable
proposal, or just a demo in the incubator. If there's a formal
proposal, then it gets queued for review.

I think this can go pretty quickly, at least, that's what I've seen.
But experience also shows it tends to weed out ideas that are not
fully formed or aren't compatible with where the main development is
headed.

You have committer rights, so of course, you can commit into the main
trunk, but I think it leads to a better outcome if we respect some
modicum of process in this.

Regards
Patrick

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

rbair
Offline
Joined: 2003-07-08

> As far as I've understood and seen the process, the
> idea is you check
> some code into the incubator with one or more demos,
> then announce it.
> There will be several rounds of feedback leading to
> either a stable
> proposal, or just a demo in the incubator. If there's
> a formal
> proposal, then it gets queued for review.
>
> I think this can go pretty quickly, at least, that's
> what I've seen.
> But experience also shows it tends to weed out ideas
> that are not
> fully formed or aren't compatible with where the main
> development is
> headed.
>
> You have committer rights, so of course, you can
> commit into the main
> trunk, but I think it leads to a better outcome if we
> respect some
> modicum of process in this.

I agree.

The other component that snuck in here, JXBoxPanel, has been (or is gonna be real soon now) removed for the same reason. I only proposed keeping JXBusyLabel around because it is both:

a) Relatively simple to clean up and review
b) Really useful

That was the point of this thread: do others view it as useful too? Should we push it through, or put it in the incubator? I personally think we should have it, because it is really useful for status bars and such. On the other hand, it could use more bake in time.

Let's put it to a vote.

Richard

rah003
Offline
Joined: 2004-05-26

> Having the Painter pluggable would be reasonable
> middle-path for now - though it stilll leaves to
> problem to synch the corresponding properties
> (currently only the colors) between both.

Sure you can access and change the painter ... tho this should be perhaps easier then:
[code]
BusyPainter p = (BusyPainter) ((PainterIcon) busyLabel.getIcon()).getPainter();
[/code]
Or am I missing something here?
And don't forget - make speed/animation time configurable.

sbusch
Offline
Joined: 2004-10-05

I may be out of line here, but can there be a simplified process such that it can be used with SwingWorker? It's not a big deal (as show below), however, I can't imagine wanting to use BusyLabel w/o some type of text updating periodically to prove it isn't broken.

As mentioned above, I have DB with 10K+ rows, that takes 10-20 seconds up to process (slowwww network). So, I would use BusyLabel all over the place.

import java.awt.BorderLayout;
import java.awt.event.ActionEvent;
import javax.swing.AbstractAction;
import javax.swing.JButton;
import javax.swing.JFrame;
import org.jdesktop.swingx.JXBusyLabel;
import org.jdesktop.swingworker.SwingWorker;

public class BusyLabelTest extends JFrame {

public static void main(String[] args) {
BusyLabelTest blt = new BusyLabelTest("Busy Label Test");
blt.setDefaultCloseOperation(EXIT_ON_CLOSE);
blt.pack();
blt.setVisible(true);
}

static SW sw;
static int counter;

public BusyLabelTest(String string) {
super(string);
final JXBusyLabel label = new JXBusyLabel();

add(label);
add(new JButton(new AbstractAction("click me") {
public void actionPerformed(ActionEvent e) {
boolean isBusy = !label.isBusy();
label.setBusy(isBusy);

if (isBusy) {
sw = new SW(label);
sw.execute();
}
else {
if (sw != null)
sw._tick = false;
}
}
}), BorderLayout.SOUTH);
}

class SW extends SwingWorker {
final JXBusyLabel _label;
boolean _tick = true;

public SW(JXBusyLabel label) {
_label = label;
}

@Override public String doInBackground() {
while (_tick) {
_label.setText(Integer.toString(++counter));
try {
Thread.sleep(1000);
} catch (Exception e) { }
}

return "done";
}
}
}

kleopatra
Offline
Joined: 2003-06-11

Josh, Romain,

are we talking about the same component? you state

a) color is already configurable and/or
b) all config can be stuffed into the painter and then plugged into to JXBusyLabel

As I see nothing of these two in the api - it's simply the busy property and a parameterless constructor I begin to suspect we refer to different versions?.

Having the Painter pluggable would be reasonable middle-path for now - though it stilll leaves to problem to synch the corresponding properties (currently only the colors) between both.

Anyway, we disagree - that's not exactly news

Cheers
Jeanette

Romain GUY

My understanding is that the painter picks up the component's
background and foreground colors. Why create new properties when you
can use those?

On 16 mars 07, at 16:56, jdnc-interest@javadesktop.org wrote:

> Josh, Romain,
>
> are we talking about the same component? you state
>
> a) color is already configurable and/or
> b) all config can be stuffed into the painter and then plugged into
> to JXBusyLabel
>
> As I see nothing of these two in the api - it's simply the busy
> property and a parameterless constructor I begin to suspect we
> refer to different versions?.
>
> Having the Painter pluggable would be reasonable middle-path for
> now - though it stilll leaves to problem to synch the corresponding
> properties (currently only the colors) between both.
>
> Anyway, we disagree - that's not exactly news
>
> Cheers
> Jeanette
> [Message sent by forum member 'kleopatra' (kleopatra)]
>
> http://forums.java.net/jive/thread.jspa?messageID=208438
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>

--
Romain GUY
http://www.curious-creature.org
http://www.progx.org

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

kleopatra
Offline
Joined: 2003-06-11

> My understanding is that the painter picks up the
> component's
> background and foreground colors. Why create new
> properties when you
> can use those?
>

it doesn't, at least not always, see my initial message.

Jeanette

kirillcool
Offline
Joined: 2004-11-17

> This component has no standard native equivalent so
> there is nothing
> for a UI delegate to do.

Do all SwingX components have native equivalents on all platforms? Not all LAFs are native...

Joshua Marinacci

This component has no standard native equivalent so there is nothing
for a UI delegate to do.

- Josh

On Mar 15, 2007, at 4:12 PM, jdnc-interest@javadesktop.org wrote:

> Will this have a proper UI delegate support?
> [Message sent by forum member 'kirillcool' (kirillcool)]
>
> http://forums.java.net/jive/thread.jspa?messageID=208298
>
> ---------------------------------------------------------------------
> 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]

Romain GUY

Why should a UI delegate be only applied to components that have
native equivalent?! The UI delegate can be used to make the component
match the style and colors of the overall look and feel. In the case
of Substance, a UI delegate for the busy label would paint the label
in shades of green with a green theme.

I am not advocating that the busy label should have a UI delegate but
I you are using a wrong reason.

On 16 mars 07, at 02:03, Joshua Marinacci wrote:

> This component has no standard native equivalent so there is
> nothing for a UI delegate to do.
>
> - Josh
>
> On Mar 15, 2007, at 4:12 PM, jdnc-interest@javadesktop.org wrote:
>
>> Will this have a proper UI delegate support?
>> [Message sent by forum member 'kirillcool' (kirillcool)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=208298
>>
>> ---------------------------------------------------------------------
>> 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!
>
>

--
Romain GUY
http://www.curious-creature.org
http://www.progx.org

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

Joshua Marinacci

Actually, by default the delegate should do exactly that. It will use
the foreground color of the super class (a JXLabel) as the color for
the spinner.
-J

On Mar 15, 2007, at 6:07 PM, Romain GUY wrote:

> Why should a UI delegate be only applied to components that have
> native equivalent?! The UI delegate can be used to make the
> component match the style and colors of the overall look and feel.
> In the case of Substance, a UI delegate for the busy label would
> paint the label in shades of green with a green theme.
>
> I am not advocating that the busy label should have a UI delegate
> but I you are using a wrong reason.
>
> On 16 mars 07, at 02:03, Joshua Marinacci wrote:
>
>> This component has no standard native equivalent so there is
>> nothing for a UI delegate to do.
>>
>> - Josh
>>
>> On Mar 15, 2007, at 4:12 PM, jdnc-interest@javadesktop.org wrote:
>>
>>> Will this have a proper UI delegate support?
>>> [Message sent by forum member 'kirillcool' (kirillcool)]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=208298
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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!
>>
>>
>
> --
> Romain GUY
> http://www.curious-creature.org
> http://www.progx.org
>
>
> ---------------------------------------------------------------------
> 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]

kirillcool
Offline
Joined: 2004-11-17

> Actually, by default the delegate should do exactly
> that. It will use
> the foreground color of the super class (a JXLabel)
> as the color for
> the spinner.

Using this logic, you wouldn't have any UI delegate at all. A specific LAF should decide how to render the component (or just use the basic implementation), perhaps using gradients from the current color theme. In addition, it may decide to add additional fade-in / fade-out animations on the rollover (like i do on the JXTaskPane title pane).

Joshua Marinacci

In many ways this is true. If we were to write Swing today we would
probably use Painters in the place of UI delegates. This may actually
happen in the future. The UI delegate will simply initialize the
painters properly and then the developer can override those painters,
just like how you can override the font, colors, and insets today.

- Josh

On Mar 15, 2007, at 7:03 PM, jdnc-interest@javadesktop.org wrote:

>> Actually, by default the delegate should do exactly
>> that. It will use
>> the foreground color of the super class (a JXLabel)
>> as the color for
>> the spinner.
>
> Using this logic, you wouldn't have any UI delegate at all. A
> specific LAF should decide how to render the component (or just use
> the basic implementation), perhaps using gradients from the current
> color theme. In addition, it may decide to add additional fade-in /
> fade-out animations on the rollover (like i do on the JXTaskPane
> title pane).
> [Message sent by forum member 'kirillcool' (kirillcool)]
>
> http://forums.java.net/jive/thread.jspa?messageID=208317
>
> ---------------------------------------------------------------------
> 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]

kirillcool
Offline
Joined: 2004-11-17

So how it's different if you'd still allow UI delegates to provide LAF-specific painting?

Patrick Wright

On 3/15/07, jdnc-interest@javadesktop.org wrote:
> I thought it was decided many months ago that components/code that wasn't quite "polished" for primetime would be available in an "optional" or "extras" package? I can't remember what package name was decided, but the discussion should be found in the forums.

This was decided more than once in the last couple of years, there was
just never any movement on it. The table/autocomplete/combobox in the
incubator was one example. There's nothing against the "optional"
packaging, although I think we weren't sure of the name (and the
precise intention), since some components might be considered
"experimental", others "nice to have", whatever.

Anyway, there was agreement in principle, just no action taken, as I recall.

Patrick

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

Romain GUY

> The doc reads: "A simple circular animation"--simple? what's simple?
> what color(s)? what is the animation like? how much of the label does
> it take up? Raises more question than it answers.

That's documentation issue, nothing more.

--
Romain GUY
http://www.curious-creature.org
http://www.progx.org

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

kleopatra
Offline
Joined: 2003-06-11

Jumping in ... not necessarily as a reply to Romain only - but "simple API" is one of my favorite a eyecatchers

You probably know what's coming (having said so over and over again): I don't see any inherent value in "simplicity" - the most simple API is an empty one. Value comes from API that allows developers to solve a task. Typically, that task has a range of complexity from trivial to fairly unmanageable. A good api helps in all of that range. It should try to hide complexity if possible - but not more so.

As an aside, take f.i. JXHeader - it's hard on the borderline of having done "more-so": in the last overhaul the component-wise implementation got moved under the tarpet of the plaf (that's a beloved trick of the Swing team , no offense meant!). The "simplified" api now only allows to configure icons, strings. First thing I had to do to keep my incubator webstartables nice looking was to go dirty, drill into the container hierarchy and turn on html on the editorPane showing the description.

Back to JXBusyLabel: it has a single property in addition to JLabel - busy. This smells like not pulling much weight. What is the task it helps developers to solve and how often is a developer expected to need to solve that task? I fully agree with Patrick that the comp's documentation does not convey much about its responsibility. "Simple" simply isn't enough - and no, that's not only a documentation issue.

Take f.i. its appearance: the "highlight" color is taken from the label's foreground. As a well-behaved Swing/X member it must respect ui properties. Which it does - at startup. What happens if the ui is switched at runtime? The comp is a label, so it is expected to update itself if the foreground is set to a different color. But wait, the highlight color is relative to the foreground, so it should update as well. Then: the not-busy color is hard-coded ... ooops, shouldn't it be set in relation to foreground? And what about the hard-coded icon size? And if developers want to use a different icon?

Okay, stop being a jerk What I wanted to convey is that even for the most inconspicious looking little widget there is lots of work involved to make it snuggle into a given framework. So one question is: is it worth to work? Weighing effort against gain. And if so: do we have the resources to do it?

In summary:

- it's a nice looking widget
- it's not very near a "ready" state
- it's not yet quite clear which additional properties it needs to pull enough weight (the task is not overly well defined)

Wouldn't expect it in SwingX - but somewhere easily accesible, visible as stuff build from SwingX (which reminds me: why doesn't it inherit from JXLabel? - probably want to add cool decorations as well, given that JXLabel will be functional in future)

Swidgets is a nice name :-)

BTW, what is the status of swingfx? Wouldn't it fit nicely there?

My .02 cents
Jeanette

rah003
Offline
Joined: 2004-05-26

> Back to JXBusyLabel: it has a single property in
> addition to JLabel - busy. This smells like not
> pulling much weight. What is the task it helps
> developers to solve and how often is a developer
> expected to need to solve that task? I fully agree

You would be surprised. I've got lot's of apps pulling loads of DB data and I use busylabel there ever since Josh has shown what was somewhere called "spinner code" to public. And users are loving it (which to me is a very important point). There's nothing more then to add this to the code:
[code]
label.setBusy(true);
swingworker.start();
... and similarly in finished() {
label.setBusy(false);
}
[/code]
Ease of use and minimum setup is what makes lots of developers use this kind of components ... and who benefits in the end is the user.

That being said, you are absolutely right about its readiness and that each component means extra work (just reminds my latest struggle with JXHeader after painter merge).

Romain GUY

> You would be surprised. I've got lot's of apps pulling loads of DB
> data and I use busylabel there ever since Josh has shown what was
> somewhere called "spinner code" to public. And users are loving it
> (which to me is a very important point). There's nothing more then
> to add this to the code:

I totally agree with you. The blog in which I first explained how to
create such a component in Swing is the most successful blog entry I
ever wrote. Even today, more than two years after writing it, I still
get emails about it, from developers who want that feature in their
application.

Back to the "simplicity" of the component... JXBusyLabel is not ready
for prime-time but I still doubt that its API need more methods
beside being able to set the colors (which you can already do
anyway.) Making everything configurable is most of the time pointless
and only add clutters to the documentation and make the component
harder to use. Swing suffers from a very bad reputation because of
that. I love that you can change pretty much everything you want, but
most of the simple tasks prove to be a pain when you start with
Swing, because the methods are lost among hundreds of others.

I am personally a strong advocate of minimizing public APIs and I
would hate to see such a nice, useful and simple component become yet
another bloated pile of fancy methods.

--
Romain GUY
http://www.curious-creature.org
http://www.progx.org

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

Joshua Marinacci

I agree. All of the super custom features can be done by creating a
BusyPainter and stuffing it into the label. The label itself should
be kept very simple. So what do we need to add to make the
JXBusyLabel ready for prime time? Better docs?

- J
On Mar 16, 2007, at 8:08 AM, Romain GUY wrote:

>> You would be surprised. I've got lot's of apps pulling loads of DB
>> data and I use busylabel there ever since Josh has shown what was
>> somewhere called "spinner code" to public. And users are loving it
>> (which to me is a very important point). There's nothing more then
>> to add this to the code:
>
> I totally agree with you. The blog in which I first explained how
> to create such a component in Swing is the most successful blog
> entry I ever wrote. Even today, more than two years after writing
> it, I still get emails about it, from developers who want that
> feature in their application.
>
> Back to the "simplicity" of the component... JXBusyLabel is not
> ready for prime-time but I still doubt that its API need more
> methods beside being able to set the colors (which you can already
> do anyway.) Making everything configurable is most of the time
> pointless and only add clutters to the documentation and make the
> component harder to use. Swing suffers from a very bad reputation
> because of that. I love that you can change pretty much everything
> you want, but most of the simple tasks prove to be a pain when you
> start with Swing, because the methods are lost among hundreds of
> others.
>
> I am personally a strong advocate of minimizing public APIs and I
> would hate to see such a nice, useful and simple component become
> yet another bloated pile of fancy methods.
>
> --
> Romain GUY
> http://www.curious-creature.org
> http://www.progx.org
>
>
> ---------------------------------------------------------------------
> 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

> I think as it stands this doesn't reach the bar for
> SwingX
> itself--SwingXtras, sure. It would need (for my
> taste) to have more
> configurability. It seems we should be aiming at more
> general
> components, and widgets like this should go in the
> "extras" or
> "optional" toychest (like statusbar widgets, for
> example--of which
> this might be a good one).

Actually, I was hoping that many as-yet-uncreated status bar components would be in SwingX.

Are you concerned that little components might get lost in the noise, or that SwingX is going to get too big, or something else?

Thanks!
Richard

Patrick Wright

Hi Richard

> Actually, I was hoping that many as-yet-uncreated status bar components would be in SwingX.
>
> Are you concerned that little components might get lost in the noise, or that SwingX is going to get too big, or something else?

I think SwingX is general composed of very high-level, general-purpose
components: frame, table, tree table, datepicker, etc. Those are the
ones that get the attention and they sort of fit together. I think
more specific widgets and tools (and yeah, I could see TOTD and error
dialog being borderline here) don't fit quite with the bulk of the
components, but they would fit together in a sort of "widget-oriented"
kit.

I agree with Richard2 that the (participating) community is small so
of course one will make do, just my sense that this is more of an
incubator component than a SwingX component at this point.

Patrick

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

rbair
Offline
Joined: 2003-07-08

> I think SwingX is general composed of very
> high-level, general-purpose
> components: frame, table, tree table, datepicker,
> etc. Those are the
> ones that get the attention and they sort of fit
> together. I think
> more specific widgets and tools (and yeah, I could
> see TOTD and error
> dialog being borderline here) don't fit quite with
> the bulk of the
> components, but they would fit together in a sort of
> "widget-oriented"
> kit.

I think I got ya. JXHeader is another of those types of components that doesn't quite fit, whereas JXStatusBar and JXTitledSeparator I'd argue belong. So it's not so much an issue of simplicity, or length of code, but of "fitness for Swing", almost.

Richard

rah003
Offline
Joined: 2004-05-26

> I think I got ya. JXHeader is another of those types
> of components that doesn't quite fit, whereas
> JXStatusBar and JXTitledSeparator I'd argue belong.
> So it's not so much an issue of simplicity, or length
> of code, but of "fitness for Swing", almost.

Now we've started to talk about lots of component which are in for quite while and used by many other people ... I would be quite worried about moving them around. I would guess that if you want to move them in some kind of widget kit you want to also change the package name (or am I wrong)? That would make this kind of change quite unpopular and maybe even difficult to switch for other people ... but if this is to come it should be before DevPack is out, afterwards it would be too late.
And one important thing to consider - It is those "non fitting" components that are the sugar that makes lots of people to use it and which Richard and others use in presentations when talking about Swinglabs.

rbair
Offline
Joined: 2003-07-08

> > I think I got ya. JXHeader is another of those
> types
> > of components that doesn't quite fit, whereas
> > JXStatusBar and JXTitledSeparator I'd argue
> belong.
> > So it's not so much an issue of simplicity, or
> length
> > of code, but of "fitness for Swing", almost.
>
> Now we've started to talk about lots of component
> which are in for quite while and used by many other
> people ... I would be quite worried about moving them
> around. I would guess that if you want to move them
> in some kind of widget kit you want to also change
> the package name (or am I wrong)? That would make
> this kind of change quite unpopular and maybe even
> difficult to switch for other people ... but if this
> is to come it should be before DevPack is out,
> afterwards it would be too late.
> And one important thing to consider - It is those
> "non fitting" components that are the sugar that
> makes lots of people to use it and which Richard and
> others use in presentations when talking about
> Swinglabs.

I quite agree.

kirillcool
Offline
Joined: 2004-11-17

Will this have a proper UI delegate support?

Romain GUY

That's the point of painters: not going through the UI delegates ;-)

On 16 mars 07, at 01:12, jdnc-interest@javadesktop.org wrote:

> Will this have a proper UI delegate support?
> [Message sent by forum member 'kirillcool' (kirillcool)]
>
> http://forums.java.net/jive/thread.jspa?messageID=208298
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>

--
Romain GUY
http://www.curious-creature.org
http://www.progx.org

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

Joshua Marinacci

The JXBusyLabel does us a pluggable painter, actually. See the
BusyPainter. It is (or should be) fully configurable. You can set
the color, length, width, number of frames back to do the fade, etc.
There should probably be a way to set the speed of the animation in
the JXBusyLabel, however.

- Josh

On Mar 15, 2007, at 9:38 AM, jdnc-interest@javadesktop.org wrote:

> Josh recently brought JXBusyLabel over with the rest of the
> painter_work branch. It wasn't really supposed to be brought over,
> but looked pretty useful (especially since it only contains 3
> public methods: a constructor and an is/set property pair). I've
> cleaned it up, added comments, and committed it.
>
> http://swinglabs.org/hudson/job/SwingX%20Continuous%20Build/javadoc/
> org/jdesktop/swingx/JXBusyLabel.html
>
> Of course, API shouldn't be coming over into SwingX unless it has
> been reviewed (or if it is being included as part of a fix, or
> preparation for review, for one of the existing components like
> JXTable). So I'm trying to get this one reviewed.
>
> What do you guys thing? Worthy? There is more that could be done
> (such as providing a pluggable painter, pluggable timer) but doing
> more will involve more API review and such, which can always be
> done later. That is, this is a good basic API that we could grow
> over time.
>
> Richard
> [Message sent by forum member 'rbair' (rbair)]
>
> http://forums.java.net/jive/thread.jspa?messageID=208176
>
> ---------------------------------------------------------------------
> 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]

osbald
Offline
Joined: 2003-06-13

I think in a perfect world an optional swingx extras would be the way to go.. call me wrong but you're hardly beating contributors off with a stick ;) I really don't know how you'd make the judgement call between JXBusyLabel and say JXTipOfTheDay. Just to be awkward It's Josh - it's quite cool so It'd get my vote.

Saying that I have a nagging feeling that some of the stuff in the incubator and other desktop related java.net projects isn't getting the airing they deserve.. i.e. why not commit to swingfx in the first place? For me the individual incubator builds are a bit arcane which I suppose has been colouring some of my thought process on the maven support issues. Having lots of jars just makes the dependencies and inter-dependencies that much harder and we'd be less likely to see any bigger 'more-worthy' components making use of JXBusyLabel in the swingx package. etc..

- Richard

i30817
Offline
Joined: 2006-05-02

I agree an optional package would be nice. Who knows then maybe i could contribute something simple (like that label that captured a keystroke).

evickroy
Offline
Joined: 2004-07-23

I thought it was decided many months ago that components/code that wasn't quite "polished" for primetime would be available in an "optional" or "extras" package? I can't remember what package name was decided, but the discussion should be found in the forums.

I think the general rule was most new things would go into the "optional" package, if they were stable enough, but wouldn't make it into Swingx until they went through the review process and polished up.

Come to think of it, the classes that Kirill asked about in another thread that Richard said was going away should probably just be put into the "optional" package in case someone found them useful. Right?

Erik

rbair
Offline
Joined: 2003-07-08

Yes. I believe the "optional" package was going to be built out of the incubator. The core question that I think Patrick is bringing up is whether a simple component like JXBusyLabel makes sense in SwingX, or if it should be in the incubator or somewhere else and included in this optional bundle.

Richard

Joshua Marinacci

I think there are two issues here. Which ones go in the 'optional'
jar file and where they should go in CVS / package names. Those are
two separate issues. Something can be in org.jdesktop.swingx.* and
still be compiled into either the main or optional jars.

- Josh

On Mar 15, 2007, at 12:16 PM, jdnc-interest@javadesktop.org wrote:

> Yes. I believe the "optional" package was going to be built out of
> the incubator. The core question that I think Patrick is bringing
> up is whether a simple component like JXBusyLabel makes sense in
> SwingX, or if it should be in the incubator or somewhere else and
> included in this optional bundle.
>
> Richard
> [Message sent by forum member 'rbair' (rbair)]
>
> http://forums.java.net/jive/thread.jspa?messageID=208249
>
> ---------------------------------------------------------------------
> 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]

Patrick Wright

On 3/15/07, Joshua Marinacci wrote:
> I think there are two issues here. Which ones go in the 'optional' jar file
> and where they should go in CVS / package names. Those are two separate
> issues. Something can be in org.jdesktop.swingx.* and still be compiled into
> either the main or optional jars.

In the long run, I'd still prefer an optionals project with its own
jars, but would agree if BusyLabel were bundled in an "optional"
package in SwingX for now--the only question then is why this is in
SwingX and some other components (which we talked about as 'optional'
before) are still in the incubator. Generally (I believe) components
are supposed to go to incubate first, then get voted in to the main
component tree.

Patrick

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

rah003
Offline
Joined: 2004-05-26

Small demo never hurts, for those who wants to see it in action ...
[code]
import java.awt.BorderLayout;
import java.awt.event.ActionEvent;
import javax.swing.AbstractAction;
import javax.swing.JButton;
import javax.swing.JFrame;
import org.jdesktop.swingx.JXBusyLabel;

public class BusyLabelTest extends JFrame {

public static void main(String[] args) {
BusyLabelTest blt = new BusyLabelTest("Busy Label Test");
blt.setDefaultCloseOperation(EXIT_ON_CLOSE);
blt.pack();
blt.setVisible(true);
}

public BusyLabelTest(String string) {
super(string);
final JXBusyLabel label = new JXBusyLabel();
add(label);
add(new JButton(new AbstractAction("click me") {
public void actionPerformed(ActionEvent e) {
label.setBusy(!label.isBusy());
}
}), BorderLayout.SOUTH);
}
}
[/code]

I for one like it, but agree with Patrick that it could offer much more. Then again it's a start. I think whatever public API it offers right now (set/getBusy + constructor) will not need to be changed to add functionality and it will be pretty useful to other people already as it is. I guess that means - keep it.

Jan

Patrick Wright

I think as it stands this doesn't reach the bar for SwingX
itself--SwingXtras, sure. It would need (for my taste) to have more
configurability. It seems we should be aiming at more general
components, and widgets like this should go in the "extras" or
"optional" toychest (like statusbar widgets, for example--of which
this might be a good one).

Patrick

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

Romain GUY

I disagree. Lack of configurability of features is not, IMHO, a
shortcoming. On the contrary. Swing (and SwingX) desperately needs
easy to use widgets. That is widgets with simple APIs.

On 15 mars 07, at 19:02, Patrick Wright wrote:

> I think as it stands this doesn't reach the bar for SwingX
> itself--SwingXtras, sure. It would need (for my taste) to have more
> configurability. It seems we should be aiming at more general
> components, and widgets like this should go in the "extras" or
> "optional" toychest (like statusbar widgets, for example--of which
> this might be a good one).
>
>
> Patrick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>

--
Romain GUY
http://www.curious-creature.org
http://www.progx.org

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

Patrick Wright

On 3/15/07, Romain GUY wrote:
> I disagree. Lack of configurability of features is not, IMHO, a
> shortcoming. On the contrary. Swing (and SwingX) desperately needs
> easy to use widgets. That is widgets with simple APIs.

Swing needs widgets, there is no history of SwingX accumulating them.

The doc reads: "A simple circular animation"--simple? what's simple?
what color(s)? what is the animation like? how much of the label does
it take up? Raises more question than it answers.

I'm not against easy to use anything, I just don't think there's any
place for this in SwingX, not given the direction things have been
going so far. Put it in the incubator for now, then add it to a
widget/component library. Call it "Swidgets".

A component like this will receive much better (and proper) attention
from developers if it's packaged along with others of its kind.

Regards
Patrick

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

Bill Snyder

I agree, its not a component I'd expect to see in a 'framework/toolkit'
library like SwingX. Though it is a _great_ idea to have a separate
place(swingx package) for the widgets that get built from the swingx core.

--Bill

On 3/15/07, Patrick Wright
wrote:
>
> On 3/15/07, Romain GUY wrote:
> > I disagree. Lack of configurability of features is not, IMHO, a
> > shortcoming. On the contrary. Swing (and SwingX) desperately needs
> > easy to use widgets. That is widgets with simple APIs.
>
> Swing needs widgets, there is no history of SwingX accumulating them.
>
> The doc reads: "A simple circular animation"--simple? what's simple?
> what color(s)? what is the animation like? how much of the label does
> it take up? Raises more question than it answers.
>
> I'm not against easy to use anything, I just don't think there's any
> place for this in SwingX, not given the direction things have been
> going so far. Put it in the incubator for now, then add it to a
> widget/component library. Call it "Swidgets".
>
> A component like this will receive much better (and proper) attention
> from developers if it's packaged along with others of its kind.
>
> Regards
> Patrick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
[att1.html]