Changing from 2.0 to 2.0.1 (svn-trunk)

[Volker Seibt <vs...@t-online.de>]

Investigating Task PIVOT-656 in the pivot-jira I had two little Problems
with one of my applications after switching from 2.0 to 2.0.1
(svn-trunk).

In task PIVOT-656 Sandro Martini wrote:
>> I tested on the FileBrowsing example from the tutorial (because my
application has little problems with 2.0.1).
> I hope they are problems not caused by Pivot 2.0.1, otherwise please
tell us.

Concerning the second issue below I don't know if I am doing wrong, it's
strange behaviour or a bug, so if anybody has an idea please answer.

This are the two problems switching from 2.0 to 2.0.1:
1. I manipulated GUI-components from within a background task. In 2.0.1
this is no longer allowed. It's much cleaner in 2.0.1 and easy to fix by
moving the stuff to a TaskAdapter. So it's no problem of 2.0.1.

2. For this problem I have to explain a little more what I want to do:
* I use a TablePane for layouting.
* In the last TablePaneRow there is a TableView (inside a ScrollPane)
which will be filled with data by the application.
* If the height of this last TablePaneRow is set to -1 (dynamic), in 2.0
the TableView/ScrollPane will have no size limit and will walk out of
the visible area of the window. In 2.0.1 all rows of the TablePane will
be flattened, maybe proportionaly, but the whole layout is destroyed.
Some TablePaneRows have less height than the components inside.
* So it seems I have to calculate the correct height of the last
TablePaneRow anyway, depending on the window height.
* In 2.0 and 2.0.1 the "sizeChanged" event from ComponentListener (of
the window) is called once when the window opens. On this call
parameters "previousWidth" and "previousHeigth" are "0" and also no
componets y-position is yet set. So calculation relative to a
component's y will go wrong. Putting recalculation into a
ApplicationContext.queueCallback will do the job.
* But on any further recalculation of the height on a window resize
after it has been opened will not work correctly if put into a callback,
so in the sizeChanged method I have to distinguish between y position of
the component redable or not and using a callback or not. Code will be
something like this:
...
@Override
public void sizeChanged(Component component, int previousWidth, int
previousHeight) {
	if(previousHeight > 0) {
		recalculateTablePaneRowHeight();
	} else {	// first resize before window showing
		ApplicationContext.queueCallback(new Runnable() {
			public void run() {
				recalculateTablePaneRowHeight();
			}
		});
	}
}
...

It's also a problem in 2.0 but not so obviously.
Is there an easier way?
Is sizeChanged called to early on opening a window (pivot problem)?
Am I doing something wrong?

Kind regards, Volker Seibt

Re: Changing from 2.0 to 2.0.1 (svn-trunk)

[Sandro Martini <sa...@gmail.com>]

Hi, thanks for the new info ...

> This are the two problems switching from 2.0 to 2.0.1:
> 1. I manipulated GUI-components from within a background task. In 2.0.1
> this is no longer allowed. It's much cleaner in 2.0.1 and easy to fix by
> moving the stuff to a TaskAdapter. So it's no problem of 2.0.1.
Yes, 2.0.1 has the right behaviour, implemented by
https://issues.apache.org/jira/browse/PIVOT-740


> 2. For this problem I have to explain a little more what I want to do:
>
> * I use a TablePane for layouting.
> * In the last TablePaneRow there is a TableView (inside a ScrollPane)
> which will be filled with data by the application.
> * If the height of this last TablePaneRow is set to -1 (dynamic), in 2.0
> the TableView/ScrollPane will have no size limit and will walk out of
> the visible area of the window. In 2.0.1 all rows of the TablePane will
> be flattened, maybe proportionaly, but the whole layout is destroyed.
> Some TablePaneRows have less height than the components inside.
Have you set the preferredHeight in contained components there ?

> * So it seems I have to calculate the correct height of the last
> TablePaneRow anyway, depending on the window height.
Have you tried to set TablePane.Row height="1*", or an absolute pixel
value (as a start value) there ?
Under Tutorials you can see some sample in table_panes.bxml, and run
it for example inside eclipse as a Pivot Scripting Application.
In any case, others can say something more specific on this.

> * In 2.0 and 2.0.1 the "sizeChanged" event from ComponentListener (of
> the window) is called once when the window opens. On this call
> parameters "previousWidth" and "previousHeigth" are "0" and also no
> componets y-position is yet set. So calculation relative to a
> component's y will go wrong. Putting recalculation into a
> ApplicationContext.queueCallback will do the job.
Yes, this should be right.

> * But on any further recalculation of the height on a window resize
> after it has been opened will not work correctly if put into a callback,
> so in the sizeChanged method I have to distinguish between y position of
> the component redable or not and using a callback or not. Code will be
> something like this:
> ...
> @Override
> public void sizeChanged(Component component, int previousWidth, int
> previousHeight) {
>        if(previousHeight > 0) {
>                recalculateTablePaneRowHeight();
>        } else {        // first resize before window showing
>                ApplicationContext.queueCallback(new Runnable() {
>                        public void run() {
>                                recalculateTablePaneRowHeight();
>                        }
>                });
>        }
> }
> ...
>
> It's also a problem in 2.0 but not so obviously.
Yes, could be a problem that was already in 2.0 ...
Under tests, there is WindowTest.java, with a block of code similar to
yours but with little differences ... can you try ?

> Is there an easier way?
> Is sizeChanged called to early on opening a window (pivot problem)?
> Am I doing something wrong?

I'm sorry but on this I can't say you so much ... by others can say to
you something, for sure.
Of course if we find a better/simpler way to do these things, will be
put in the next release (maybe even a maintenance of 2.0.1, without
having to wait for 2.1).

Comments (from all) ?

Bye