Kevin, could you please share the reasons for changing your opinion?
For the pure 2D case the distance is now always 1. There are also the
mixed cases - for instance parallel camera, 2D objects, Z translation -
that we need to handle, and as it is, we sometimes need negative
distances. Anyway,
After chatting with Chien about this, and thinking about it a bit more,
I agree with Steve that we shouldn't throw an exception unless we are
certain that the concept of a distance just doesn't make sense in
parallel mode. If we were so convinced, then an exception (UOE or ISE)
would be fine. A
I don't see how returning something wrong is any different than throwing an
exception from a compatibility perspective. Bugs are bugs.
On Oct 16, 2013, at 3:46 PM, Kevin Rushforth wrote:
> I can see your point. There are cases where it can make sense to have a
> restriction now and relax it la
I can see your point. There are cases where it can make sense to have a
restriction now and relax it later, but this isn't exactly that case.
It's really more of a case of not being currently implemented correctly
in some modes.
I guess the other option (which Pavel also mentioned) is to conti
Initial position:
I don't really want to see any exception. Throwing an exception is
unexpected and should really be reserved for when something bad happens,
not when we can't decide how an API works. If the exception goes in,
it's API and it stays forever.
Steve
On 2013-10-16 5:23 PM, Ke
Steve: if Pavel throws IllegalStateException("not yet supported for
parallel camera") or similar, do you think that would be OK or do you
not want to see any exception?
-- Kevin
Kevin Rushforth wrote:
Would IllegalStateException be better here? Usually UOE is for
operations that are simply n
Would IllegalStateException be better here? Usually UOE is for
operations that are simply not supported by the class in question. In
this case, the operation is only unsupported if the camera on the scene
(i.e., the state of an object) is of a certain type which can change at
runtime.
I'm OK
The problem is this: How is anyone supposed to ever do anything with
this? I suppose they call the thing by mistake, get an exception and
then never call it again. Then, later on, we come along and fix it.
If the original people ever catch the exception and do something, then
when we stop t
As I've said, we intend to fix it in the future, so the situation should
not be impossible. It is mostly used that way in the existing code, but
there definitely are precedents for throwing it just temporarily. For
instance:
nodeOrientationProperty().getCssMetaData:
throw new Unsupport
I took a quick look through JavaFX to find how this exception is used.
It is mostly used to indicate impossible situation. Is that the
situation we have here?
Personally, for me, if we throw the exception, then we will generally
just leave it that way forever.
Steve
On 2013-10-16 11:22 AM
On 16.10.2013 17:03, Stephen F Northover wrote:
Could do something useful with what was there now? We can always fix
this in future by adding another API to govern the interpretation of
the value.
Not much useful. Anyway, any such stuff can be quite easily done by
reading the intersectedPoin
Could do something useful with what was there now? We can always fix
this in future by adding another API to govern the interpretation of the
value.
Throwing the exception indicates that the call is unsupported, but
application code can be written to catch the exception and when we
implement
Regarding #2, I'm OK with an exception being thrown.
Regarding #1, do you think moving the clip planes to PerspectiveCamera
(rather than in the base class) be better for FX 8? We can compatibly
move it up to a superclass in a future release. Or would this be too
disruptive?
-- Kevin
Richar
My quick vote would be throwing the exception, but is like to hear from Steve
and Kevin.
> On Oct 16, 2013, at 1:04 AM, Pavel Safrata wrote:
>
> Hello,
> it looks like we can't help releasing a not-fully-baked piece of API with
> FX8. We've added bunch of new APIs for 3D and did our best to m
Hello,
it looks like we can't help releasing a not-fully-baked piece of API
with FX8. We've added bunch of new APIs for 3D and did our best to make
them work well. Unfortunately, there's been not enough time&priority to
fine-tune their behavior in 2D world. Right now I'm concerned about
camera
15 matches
Mail list logo
