|
Replies:
31
-
Last Post:
Jan 12, 2007 2:45 PM
by: evickroy
|
|
|
|
|
|
|
Major Painter API Change
Posted:
Jan 10, 2007 10:36 AM
|
|
|
We finally had our API review with the experts and came to a difficult decision. We have decided to remove Painter layers and the JXComponent interface. This was not an easy decision to come to so I want to explain the pros and cons and why we did what we did.
Our dream was to have all JX* components be very hackable. A developer should be able to change the drawing of an existing component at runtime without having to subclass or look at the original source code. This is a really cool idea but it depends on Swing components having a layered drawing behavior that is both completely separable and semantically useful. Let me explain what I mean here.
1) Having layered drawing behavior that is completely separable means that we can separate the drawing of a component's foreground from it's background. For example, if I wanted to put a dropshadow on the text of a JButton I would need to separate the foreground and background layers. Sadly, Swing just doesn't work this way. Drawing is handled by UI delegates which are unknown until runtime. The API for UI delegates doesn't expose layering and even if it did this still probably wouldn't work because layering becomes undefined when you get resources from the OS for native look and feels. What does it mean to change the background color of a JButton on Windows XP? As it turns out there is no right answer and several bugs have been filed against it. So what would it mean to set the background painter of a JButton but not the foreground painter? Can we predictably draw something that makes sense and will work across *all* JComponent subclasses? Alas, no. In summary, we can't provide useful behavior for even the foreground and background behavior that is guaranteed to work everywhere. Thus we can't have layering.
2) Semantically useful. Is it useful to set a background painter on a JLabel? What about a JButton? It has a foreground and background, but what we really care about is rollover states. What about a JList? Should you set a painter on the list or each item, or both. Or what about above them? What about a JSlider or JScrollBar? They each have many parts to be painted. To be useful we would need to define layers for each part, but then we would have layer constants in JXComponent that only apply to certain components. Basically there is set of painters (other than maybe background painter) that makes sense across all components. And many components would greatly benefit from having painters that are semantically useful to *it*, not to all components. For the JList it would be more useful to have a background, list item, selected item, and overlay painter; rather than to have a stack of numbered layers. In summary, we need semantically useful painters for each component, not a single set of painters for all. Thus the JXComponent interface is useless.
But what about other uses for layers?! What about Overlays and Validation? Well, those won't work on all components anyway, only JX* components. So you'd have to subclass every component in Swing just to add painter support, and then each component would have to know about the painters set on them, and you'd have to manage them, and ... well, it just becomes a mess. A *much* better idea is to use the glass pane for overlays and validation. The JXGlassPane makes it very easy to put a painter on top of *any* component, not just JX* components. Validation badges become trivial to implement with this class.
So what have I just committed to the painter branch?
First of all, I removed JXComponent and PainterSupport, since they aren't needed anymore. Then I modified JXPanel, JXLabel, and JXButton to handle the painters on their own instead of with PainterSupport. Then I removed all references to layering. You can still set the background painter on JXPanel, just not the foreground. For 99% of the use cases this is enough. In fact, I was able to do all of the refactoring across SwingX, SwingX-WS, and my mapping demos in less than an hour. Even 95% of the test cases in the demo app didn't need to be changed. I think that shows how less important this feature was than we originally though.
The default background painter for JXPanel (and other components if we choose) calls super.paintComponent(). This lets you grab the painter and wrap it in a compound painter to do things like adding dropshadows or affine transforms. Setting the backgroundPainter to null will make the JXPanel call super.paintComponent(); (perhaps setting it to null should make it draw nothing instead, or is that what setVisible(false) is for?)
* Additional minor changes
We have removed setUseCache. It's really up to the painter to know if caching makes sense, so now the decision of whether to cache is up to the painter by overriding the protected isUseCache() method in AbstractPainter to return true. setUseCache() is gone. If isUseCache returns true then caching will be used, as before. It is off by default. (maybe it should be on when you add an image effect?) We are considering adding a BufferedPainter which will be a CompoundPainter with caching turned on so that you can explicitly cache the portions of your painter tree that you care about.
Changed Painter<T extends Object> to just be Painter<T>
Updated docs for Painter.paint() to indicate that Object can be null and that the width and height must be greater than zero
Moved the Style enum from AbstractPainter to AbstractPathPainter, since it only applies there.
We know this is going to be controversial but we really feel like it's the simplest thing that leaves open as many options as possible for the future (including adding layers later if we can figure out a way that makes sense). If you want or need to have layers in your component, then your component can add those methods. As Josh Bloch says, "When in doubt, leave it out". Layers, and how to implement them, is definitely in doubt, so we're leaving them out. Please let us know what you think.
Thanks,
Josh and Rich
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 10:46 AM
in response to: joshy
|
|
|
> If isUseCache returns true then caching will be used, as before.
> It is off by default. (maybe it should be on when you add an image
> effect?)
It should be on when an image effect is added. At least this should
be the default behavior in the abstract painter and subclasses could
remove that if they want to.
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
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
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 11:54 AM
in response to: Romain GUY
|
|
|
I censor myself because what I would write you wouldn't like and it would be a waste of time anyways since the decision has been made.
The API theorists won this round. 
Cheers,
Mikael
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 11:57 AM
in response to: mikaelgrev
|
|
|
Be censoring yourself this way you just said what you wanted to say
you did not say  I guess layers can still be added later on.
On 10 janv. 07, at 20:54, jdnc-interest@javadesktop.org wrote:
> I censor myself because what I would write you wouldn't like and it
> would be a waste of time anyways since the decision has been made.
>
> Cheers,
> Mikael
> [Message sent by forum member 'mikaelgrev' (mikaelgrev)]
>
> http://forums.java.net/jive/thread.jspa?messageID=192926
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
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
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 11:59 AM
in response to: Romain GUY
|
|
|
I am Sneaky.
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 1:04 PM
in response to: mikaelgrev
|
|
|
I am with Mikael on this one, and I wish those same API theorists would apply their same golden rules on the Swing API itself. Because if they had done that, we would have had Swing 2.0 by now, and the painter API support would have been a natural fit. I think proper support for cool, and innovative features like painters, and others should drive changes to the Swing API rather than the other way around.
Message was edited by: mikeazzi
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 1:27 PM
in response to: mikeazzi
|
|
|
I feel there's a larger problem than just the decision, it's the
(apparently absolute) failure in process.
A huge amount of discussion went into the layers idea, there was
(largely) good consensus around it by the end, and after (one or more)
(private, offline) review(s) it all gets thrown out the window. Not
exactly a comforting thought for those who want to throw their (free)
time in with the project.
I'd suggest that you (project leadership) need to take a look at how
to avoid this in the future. It would have been easier to have gotten
the big picture (what's allowed and what's not) before proceeding too
far. While I understand some experimentation is necessary before
making decisions, it seems to me it went pretty far beyond
experimenting and there there was no sign of the pretty vigorous
opinions against the idea until now.
Basically, it needs to be more clear what it is possible to do in the
context of SwingX and what is not. The discussion on layers made it
clear that there are people using this approach in production systems
and libraries, so the question is how we identify the boundaries of
Swing in such a way that we don't spend community time
counter-productively.
That said, I realize you all have the best intentions in all this.
Best regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 2:24 PM
in response to: Patrick Wright
|
|
|
I knew Mikael wouldn't be happy, but I didn't expect Patrick to be the most fired up! I love to see the passion! At least you guys aren't asleep out there
I was involved in all the online discussions regarding painters and layers. I'm neither a theorist nor do I live in an ivory tower (though for the price of rent in San Jose you'd think I did!). I am as much responsible for voting down the layer API as anybody else. There are at least 3 of us who wanted to remove the layers: Scott, me, and Romain. There also has not been what I'd consider general consent from the community. It is not as if we are ignoring unanimous opinion. Bill Snyder for one said:
"The whole idea of layers really adds some complexity to the Painter
idea. I guess it just depends on how much layers functionality is really
needed vs how flexible the 'Layers api' should be for the future."
I agreed that it was raising red flags with me as well, and said
"Really, layers is about letting frameworks add/remove painters from the
component automatically. If we accept that as a use-case we want to
support, then I think this API is close to what we want."
That has been the question for me all along. Is this an acceptable use case? At the moment, my feeling is, "no".
All of the discussions we have had are very important for outlining the boundaries of the problem, and for discovering the key uses, edge cases, and developer interest. For all the discussion, thank you! You have contributed to the process!
At the end of this thread http://forums.java.net/jive/thread.jspa?forumID=73&threadID=20577&messageID=180238#180238 there was no consensus reached. At least, I don't see any in there. It just died out.
Josh also did a good job of posting the _many_ issues with regards to integrating layers into Swing painting. That doesn't mean that layers are a bad idea, just that they don't make any sense to integrate into existing Swing components. Perhaps in Java 7 we can rearrange the painting and API of the UI delegates to support Painters, but for Java 5 and Java 6 there is no solution.
What does that mean? Does that mean you can't define a PainterLayerable interface? Does that mean that your custom component (or maybe even JXPanel) couldn't support layers? Of course not. What it means is that there is no known clean way to implement layers for Swing painting. Should we add APIs that are, out of the gate, broken?
Also keep in mind that API can always be added, but it cannot be removed. When in doubt, leave it out! For several of us, there was *quite* a bit of doubt.
For what reasons do you want layers? For badges? Better served with the glass pane, since a badge often wants to paint partway outside the border of the component. Do you want to allow the user to insert custom painting into the pipeline? As Josh amply demonstrated, it *cannot be done* for general Swing components, only those that have purposefully separated their painting routines in a manner than could support it. And for those components, what is wrong with exposing API for layers or other forms of custom painting?
Why can't MiGCalendar use Painters and keep their own layers? Why do we need to support, in JXComponent (and ostensibly in JComponent) layers when they are incompatible with all current standard Look and Feel implementations?
I cannot over emphasis this point. Layers are broken with all Swing components that don't specifically handle them. Thus, components that support layers should expose API. If we want a common interface for that, fine. But it doesn't belong in J(X)Component.
At least, that is our reasoning. If there is another proposal for layers that makes more sense (such as a PainterLayerable interface, though with a better name , allowing a class to implement layers if it can support them), then let's do it!
Richard
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 2:40 PM
in response to: rbair
|
|
|
I should also add, that the internal reviews are not the final word. The purpose of the internal review is to expedite the review process. Debating API over email is a really time consuming task, compared to a whiteboard and a phone call. It's all about trying to be efficient.
After having talked it over with the others, it just doesn't seem to be a good solution.
Richard
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 4:42 PM
in response to: rbair
|
|
|
> Perhaps in
> Java 7 we can rearrange the painting and API of the
> UI delegates to support Painters, but for Java 5 and
> Java 6 there is no solution.
"Rearrange" as in "change" or as in "extend"?
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 4:51 PM
in response to: kirillcool
|
|
|
> > Perhaps in
> > Java 7 we can rearrange the painting and API of
> the
> > UI delegates to support Painters, but for Java 5
> and
> > Java 6 there is no solution.
>
> "Rearrange" as in "change" or as in "extend"?
Hmm. Whichever one means "in a compatible way". We don't know yet if that is even possible since we haven't put much thought into it yet.
Richard
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 10, 2007 4:56 PM
in response to: rbair
|
|
|
Hopefully this will be discussed and decided with third-party LAF writers / vendors.
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 11, 2007 9:41 AM
in response to: rbair
|
|
|
Hi Richard
First, I want to apologize if my tone was too harsh. I probably should
have saved the message and waited a few days; I'm on deadline on my
current project, have been working overtime, and am more stressed than
appropriate for posting such replies.
> I was involved in all the online discussions regarding painters and layers. I'm neither a theorist nor do I live in an ivory tower (though for the price of rent in San Jose you'd think I did!). I am as much responsible for voting down the layer API as anybody else. There are at least 3 of us who wanted to remove the layers: Scott, me, and Romain. There also has not been what I'd consider general consent from the community. It is not as if we are ignoring unanimous opinion.
I agree there was not unanimous consent, but I think people were in
general agreement about the approach.
> All of the discussions we have had are very important for outlining the boundaries of the problem, and for discovering the key uses, edge cases, and developer interest. For all the discussion, thank you! You have contributed to the process!
Agree that it's been useful.
> At the end of this thread http://forums.java.net/jive/thread.jspa?forumID=73&threadID=20577&messageID=180238#180238 there was no consensus reached. At least, I don't see any in there. It just died out.
I thought the consensus was embodied in Josh's most recent checkin
before he backed the code out; maybe I misunderstand.
> Josh also did a good job of posting the _many_ issues with regards to integrating layers into Swing painting. That doesn't mean that layers are a bad idea, just that they don't make any sense to integrate into existing Swing components. Perhaps in Java 7 we can rearrange the painting and API of the UI delegates to support Painters, but for Java 5 and Java 6 there is no solution.
That's fine, there are at least two issues here from my POV. One is
whether the decision is correct and one is about how the decision was
made.
While we are waiting for clarification about the relationship between
this "community" and the Swing team (or others at Sun). I understand
the general principle that someone ("the Swing team", altho I don't
know how those calls are made) makes the decisions about whether a
design in SwingX makes sense in the context of Swing in the JDK. What
I'd prefer to see are clearer guidelines so that we don't spend too
much (limited) time designing things that will never be included.
The incubator is one alternative, to have elements that don't fit into
the standard guidelines, but it's always been just a whiteboard, it's
not a place to store things "outside the box" so to speak.
What I feel took place here is that a lot of discussion, coding,
testing, overall effort was put into this idea, then we get an email
several weeks later saying: no way, out the window. Similar problems
have come up in the past, I recall some components that had to change
sharply after one of these reviews, and then there's poor Thomas B's
beloved combobox, which got rejected after he'd gone through rounds of
feedback and improvements from us.
As always, I appreciate that Sun is hosting/sponsoring this project at
all, but would like to find some way to be more effective with what
few resources we have.
Regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 11, 2007 1:48 PM
in response to: Patrick Wright
|
|
|
> First, I want to apologize if my tone was too harsh.
> I probably should
> have saved the message and waited a few days; I'm on
> deadline on my
> current project, have been working overtime, and am
> more stressed than
> appropriate for posting such replies.
Hey man, nothing to worry about.
> > At the end of this thread
> http://forums.java.net/jive/thread.jspa?forumID=73&thr
> eadID=20577&messageID=180238#180238 there was no
> consensus reached. At least, I don't see any in
> there. It just died out.
>
> I thought the consensus was embodied in Josh's most
> recent checkin
> before he backed the code out; maybe I misunderstand.
To me, what Josh was putting together was a proposal, which would then go through both the internal and external review process. I don't know of any way of adequately evaluating code until it is all thought out and put together.
> While we are waiting for clarification about the
> relationship between
> this "community" and the Swing team (or others at
> Sun). I understand
> the general principle that someone ("the Swing team",
> altho I don't
> know how those calls are made) makes the decisions
> about whether a
> design in SwingX makes sense in the context of Swing
> in the JDK. What
> I'd prefer to see are clearer guidelines so that we
> don't spend too
> much (limited) time designing things that will never
> be included.
In principle I agree. I don't want to waste anybodies time. In this particular case, I'm not sure how it could have been done any better. From my perspective, everything worked exactly as it should. We got good design feedback from those on the mailing list, both positive and negative (that is, some were for the proposal and some against). Josh, who has taken ownership for this feature, took these designs into account, produced a proposal, and then ran it by Scott and I. We gave our honest feedback, he agreed with the problems we were seeing, he modified his proposal, and is getting it ready for more reviews (we haven't reviewed the AbstractPainter API in enough detail).
> What I feel took place here is that a lot of
> discussion, coding,
> testing, overall effort was put into this idea, then
> we get an email
> several weeks later saying: no way, out the window.
I don't know what to say. We aren't all going to agree on API design, not even in trivial cases such as JXStatusBar was there any decent agreement. At some point a decision has to be made, some people will cheer, some will boo.
> As always, I appreciate that Sun is
> hosting/sponsoring this project at
> all, but would like to find some way to be more
> effective with what
> few resources we have.
And I appreciate all the time and energy of those of you out there giving of your own time for the project.
Richard
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 11, 2007 3:34 PM
in response to: rbair
|
|
|
And anyway, isn't it better to shipping without a feature that can be
added later rather than shipping with a feature that might become a
problem in the future? I guess we have enough examples of that kind
of stuff in the JDK...
On 11 janv. 07, at 22:48, jdnc-interest@javadesktop.org wrote:
>> First, I want to apologize if my tone was too harsh.
>> I probably should
>> have saved the message and waited a few days; I'm on
>> deadline on my
>> current project, have been working overtime, and am
>> more stressed than
>> appropriate for posting such replies.
>
> Hey man, nothing to worry about.
>
>>> At the end of this thread
>> http://forums.java.net/jive/thread.jspa?forumID=73&thr
>> eadID=20577&messageID=180238#180238 there was no
>> consensus reached. At least, I don't see any in
>> there. It just died out.
>>
>> I thought the consensus was embodied in Josh's most
>> recent checkin
>> before he backed the code out; maybe I misunderstand.
>
> To me, what Josh was putting together was a proposal, which would
> then go through both the internal and external review process. I
> don't know of any way of adequately evaluating code until it is all
> thought out and put together.
>
>> While we are waiting for clarification about the
>> relationship between
>> this "community" and the Swing team (or others at
>> Sun). I understand
>> the general principle that someone ("the Swing team",
>> altho I don't
>> know how those calls are made) makes the decisions
>> about whether a
>> design in SwingX makes sense in the context of Swing
>> in the JDK. What
>> I'd prefer to see are clearer guidelines so that we
>> don't spend too
>> much (limited) time designing things that will never
>> be included.
>
> In principle I agree. I don't want to waste anybodies time. In this
> particular case, I'm not sure how it could have been done any
> better. From my perspective, everything worked exactly as it
> should. We got good design feedback from those on the mailing list,
> both positive and negative (that is, some were for the proposal and
> some against). Josh, who has taken ownership for this feature, took
> these designs into account, produced a proposal, and then ran it by
> Scott and I. We gave our honest feedback, he agreed with the
> problems we were seeing, he modified his proposal, and is getting
> it ready for more reviews (we haven't reviewed the AbstractPainter
> API in enough detail).
>
>> What I feel took place here is that a lot of
>> discussion, coding,
>> testing, overall effort was put into this idea, then
>> we get an email
>> several weeks later saying: no way, out the window.
>
> I don't know what to say. We aren't all going to agree on API
> design, not even in trivial cases such as JXStatusBar was there any
> decent agreement. At some point a decision has to be made, some
> people will cheer, some will boo.
>
>> As always, I appreciate that Sun is
>> hosting/sponsoring this project at
>> all, but would like to find some way to be more
>> effective with what
>> few resources we have.
>
> And I appreciate all the time and energy of those of you out there
> giving of your own time for the project.
>
> Richard
> [Message sent by forum member 'rbair' (rbair)]
>
> http://forums.java.net/jive/thread.jspa?messageID=193619
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
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
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 11, 2007 5:27 PM
in response to: Romain GUY
|
|
|
> And anyway, isn't it better to shipping without a
> feature that can be
> added later rather than shipping with a feature that
> might become a
> problem in the future? I guess we have enough
> examples of that kind
> of stuff in the JDK...
Does this mean that the only goal of SwingX is to develop Swing-related code for future inclusion in JDK? This can be pretty restrictive.
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 11, 2007 5:52 PM
in response to: kirillcool
|
|
|
I never said anything like that. I'm just taking the JDK as an
example of what not to do. That's all. Besides, given what's
available in SwingX as of today you perfectly know that the
developing code for future inclusions in the JDK is not the only goal.
Features can be added later on. Features cannot be removed as easily
(at least without cries of anguish from API users.) Apparently layers
might be troublesome so it's safer to leave them out of SwingX (I
guess there could be support for them in the incubator for those who
want them badly enough.)
On 12 janv. 07, at 02:27, jdnc-interest@javadesktop.org wrote:
>> And anyway, isn't it better to shipping without a
>> feature that can be
>> added later rather than shipping with a feature that
>> might become a
>> problem in the future? I guess we have enough
>> examples of that kind
>> of stuff in the JDK...
>
> Does this mean that the only goal of SwingX is to develop Swing-
> related code for future inclusion in JDK? This can be pretty
> restrictive.
> [Message sent by forum member 'kirillcool' (kirillcool)]
>
> http://forums.java.net/jive/thread.jspa?messageID=193709
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
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
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 11, 2007 6:01 PM
in response to: Romain GUY
|
|
|
> I never said anything like that. I'm just taking the
> JDK as an
> example of what not to do. That's all. Besides, given
> what's
> available in SwingX as of today you perfectly know
> that the
> developing code for future inclusions in the JDK is
> not the only goal.
My bad  But i'm confused. When you say "shipping", do you mean JDK or SwingX? Will SwingX have the same policy (as JDK) of *never* removing an API once it reaches the 1.0 release?
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 11, 2007 6:07 PM
in response to: kirillcool
|
|
|
> My bad But i'm confused. When you say "shipping", do you mean
> JDK or SwingX? Will SwingX have the same policy (as JDK) of *never*
> removing an API once it reaches the 1.0 release?
I mean SwingX. I don't know what the policy is/was/will be/would be/
should be but no matter what it is, users would not be happy if
features were to be removed. That said, it does not mean that
discussions about painters should be definitely closed.
I am personally in favor of keeping this API as simple as possible
and not try to cover all use cases, but most of them. I like easy and
simple API. At least that's what I had in mind when Richard and I
first started working on painters.
If you guys really want more features, go ahead and start a new
discussion. It's just that the Swing guys raised very important
issues. Maybe we could find a way to address them?
> [Message sent by forum member 'kirillcool' (kirillcool)]
>
> http://forums.java.net/jive/thread.jspa?messageID=193713
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
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
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 11, 2007 7:30 PM
in response to: Romain GUY
|
|
|
Thanks for the explanation. Which brings me to another point. Does SwingX have a government model that defines what the community (outside Sun) members can expect, who makes the decisions (besides the CVS access) - especially on the final API, what is the release schedule (or at least expectations / aspirations) and so on.
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 7:54 AM
in response to: kirillcool
|
|
|
> Thanks for the explanation. Which brings me to
> another point. Does SwingX have a government model
> that defines what the community (outside Sun) members
> can expect, who makes the decisions (besides the CVS
> access) - especially on the final API, what is the
> release schedule (or at least expectations /
> aspirations) and so on.
Not a very good one, which is probably the source of frustration.
Richard
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 10:37 AM
in response to: rbair
|
|
|
When you guys say that some of the layering would be better handled by the glass pane, are you still considering a JXGlassPane component for this? I believe Richard mentioned it as a possible new component in some prior Painter discussions.
Erik
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 10:42 AM
in response to: evickroy
|
|
|
Is there any reason to use a new component when we already have
JLayeredPane in Swing?
On 12 janv. 07, at 19:37, jdnc-interest@javadesktop.org wrote:
> When you guys say that some of the layering would be better handled
> by the glass pane, are you still considering a JXGlassPane
> component for this? I believe Richard mentioned it as a possible
> new component in some prior Painter discussions.
>
> Erik
> [Message sent by forum member 'evickroy' (evickroy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=193909
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
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
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 11:06 AM
in response to: Romain GUY
|
|
|
This was just meant to automate the kinds of things that we typically do with the glass pane. It's just a JComponent subclass so it could be set as a layered pane instead of the glass pane if desired. The glass pane just seemed to be the way we always do things.
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 11:13 AM
in response to: joshy
|
|
|
I see what you mean. But the more I use the glass pane, the more I am
afraid to run into a situation in which I would need two glass panes
at once. Having APIs like SwingX offer you glass pane make that even
more probable.
Besides, there are many use cases in which the glass pane is *not*
the place where you want your painting code. Take the example of
badges drawn over invalid components. In a glass pane scenario, the
badges would appear on top of everything else: internal frames, popup
menus (!), toolbars being dragged, and so on.
That's why I think the JXGlassPane should be renamed. If all it does
is apply painters over components, maybe it should be called
JXOverlay. Also it'd be nice to have utility methods to make it easy
to set it up on a JFrame's layered pane (as this requires components
listeners to resize the component since layered pane do not use
layout by default - and Swing layouts do not work well with
JLayeredPane anyway.)
On 12 janv. 07, at 20:06, jdnc-interest@javadesktop.org wrote:
> This was just meant to automate the kinds of things that we
> typically do with the glass pane. It's just a JComponent subclass
> so it could be set as a layered pane instead of the glass pane if
> desired. The glass pane just seemed to be the way we always do
> things.
> [Message sent by forum member 'joshy' (joshy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=193919
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
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
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 11:26 AM
in response to: Romain GUY
|
|
|
> But the more I use the glass
> pane, the more I am
> afraid to run into a situation in which I would need
> two glass panes
> at once. Having APIs like SwingX offer you glass pane
> make that even
> more probable.
while (true) {
+1
}
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 2:14 PM
in response to: Romain GUY
|
|
|
It sounds like your volunteering to write us a crazy cool JXOverlay! Awesome!
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 2:30 PM
in response to: joshy
|
|
|
When the book's done
On 12 janv. 07, at 23:14, jdnc-interest@javadesktop.org wrote:
> It sounds like your volunteering to write us a crazy cool
> JXOverlay! Awesome!
> [Message sent by forum member 'joshy' (joshy)]
>
> http://forums.java.net/jive/thread.jspa?messageID=193990
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
--
Romain GUY <romain.guy@mac.com>
http://jroller.com/page/gfx
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
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 2:45 PM
in response to: Romain GUY
|
|
|
> When the book's done
You're writing a book on JXOverlay!? Even better!
Erik
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 11:19 AM
in response to: joshy
|
|
|
Cool thanks! Is it in a Painter branch in cvs?
Erik
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 12, 2007 11:05 AM
in response to: evickroy
|
|
|
Yes. It's already in CVS. It's a glass pane that will apply a painter to a list of components. This lets you easily do things like drawing a badge over each of five invalid components.
|
|
|
|
|
|
|
|
|
Re: Major Painter API Change
Posted:
Jan 11, 2007 5:16 AM
in response to: mikaelgrev
|
|
|
>
> The API theorists won this round.
on first skimming this thread I missed the "h" in the word and had a hearty chuckle (naturally, no offense meant, but couldn't resist to censoring myself
The base conflicting constraints - as f.i. stated and discussed near the end of
http://forums.java.net/jive/thread.jspa?threadID=20224
are still unresolved. The last we (the community) heard from us (the paid project members) was a "Thanks for the input".
Jeanette
|
|
|
|
|
java.net RSS
