Call for IntelliJ IDEA user help

[Diego Cirujano]

Hi all,

Christian and me are trying to improve the build.gradle file and it will
let the diverse IDEs import it and it will allow us to remove the specific
IDE files.

If you are an IntelliJ IDEA user and you have at least Version 20.18.3, you
can easily help us.

Please, follow the following steps:

1.- Clone the repo

git clone https://github.com/christianheilmann/openjdk-jfx.git

2.- Remove .idea directory
3.- Open openjfx from Intellij "File" -> "New" -> "Project from existing
sources..."

Can you answer the following questions:
- Can you build from the IDE?
- Can you check if there is any error(dependencies, etc.)?

Thank you very much for your time!

Diego

--
We already test it in Windows and Mac and it should work, but it will help
us to have at least another person(e.g GNU/Linux user)

Thank you very much to Sverre Moe(@DJViking) and Nir Lisker(@nlisker) for
working in the eclipse part.

JDK-8152395: Fix toolbar overflow control

[Diego Cirujano]

Hi,

I'd like to request a review for JDK-8152395 available as a PR on

Github: *https://github.com/javafxports/openjdk-jfx/pull/318
*

JBS: *https://bugs.openjdk.java.net/browse/JDK-8152395
*

Thanks.

Diego

Re: DateAxis..

[Diego Cirujano-Cuesta]

Hi Pedro,

Christian Schudt and me are working in a DateAxis that he create , we are 
using Christian repo (this url): https://bitbucket.org/sco0ter/extfx/src 
and then: src/main/java/extfx/scene/chart/DateAxis.java that extends from 
"Axis". We just have a few problems not important as a consecuence 
of the layoutChildren performance improvements that are not good for a 
DateAxis implementation :). 

Just now we are fixing this issue so you are wellcome to contribute into 
it and problably you could have new ideas. It might make sence to move it 
to ControlsFX or JFXtras and have a common solution.

Cheers,

Diego



From:   openjfx-dev-requ...@openjdk.java.net
To: openjfx-dev@openjdk.java.net
Date:   02.09.2013 08:18
Subject:openjfx-dev Digest, Vol 22, Issue 2
Sent by:openjfx-dev-boun...@openjdk.java.net



Send openjfx-dev mailing list submissions to
 openjfx-dev@openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
 http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
or, via email, send a message with subject or body 'help' to
 openjfx-dev-requ...@openjdk.java.net

You can reach the person managing the list at
 openjfx-dev-ow...@openjdk.java.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openjfx-dev digest..."


Today's Topics:

   1. Re: FocusModel too restricted? (Jonathan Giles)
   2. Why is almost everything in the API final (Pedro Duque Vieira)
   3. DateAxis.. (Pedro Duque Vieira)
   4. Creating custom chart - "XYBarChart" (Pedro Duque Vieira)
   5. Re: Why is almost everything in the API final (Jonathan Giles)
   6. Re: DateAxis.. (Jonathan Giles)
   7. hg: openjfx/8/controls/rt: 4 new changesets (hang...@oracle.com)
   8. Re: DateAxis.. (Sven Reimers)


--

Message: 1
Date: Mon, 02 Sep 2013 08:44:44 +1200
From: Jonathan Giles 
Subject: Re: FocusModel too restricted?
To: openjfx-dev@openjdk.java.net
Message-ID: <5223a73c.2030...@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1

Werner,

It sounds to me like you're trying to use FocusModel where it may not
ideally suit your needs, and rather than roll your own API that is more
applicable to your needs, you're hoping to coerce FocusModel to fit to
be consistent. Whilst I applaud your eagerness to have an API consistent
with the 'official' UI controls, my gut feeling is that this will most
probably not be the best approach. The FocusModel API was really
designed for row-based UI controls like ListView, TableView, etc, and it
may be hard to work into your property sheet component. For this reason
I would suggest rolling your own API (and possibly questioning whether a
switchable FocusModel is actually necessary for your control in the
first place, or whether you can just bake the API directly into the
property sheet).

Note that in this case the term 'focus' is overloaded, as this refers to
the internal 'fake' focus inside these controls - it has nothing to do
with 'real' JavaFX focus traversal. In other words, a ListView always
has the real focus, even if the ListView FocusModel says that row 1 is
focused - this is just for keyboard navigation purposes. For this reason
I'm curious if the FocusModel is what you actually want - I would assume
that what you are really wanting to do is move the real focus between
components in your control? Because of this you'll likely be rewriting
all of the FocusModel implementation anyway.

To somewhat answer your questions:
1) In general TreeView and TreeTableView have to jump through hoops, as
to reuse as much internal implementation code they essentially are
treated as if they are lists internally. In actual fact the focusNext /
focusPrevious methods almost weren't even added to the original API -
they were only added because I thought they were quite useful. For a
very long time we were going to be index-only.

2) When designing the FocusModel we were conscious of not providing the
same API with different names, so we settled on having a focus(int)
method and making the focusedIndex property read-only. This meant that
it was not possible for developers to accidentally bind the focus and
break the control. As always API design is a game of trade-offs, many of
which come back to bite you when you encounter new use cases in the
future :-)

At this stage it would be essentially impossible to redo the FocusModel
to remove the index-based addressing, as it would be a breaking change.
It is more possible that more methods could be made public / non-final /
not read-only, but they will need to be handled on a case-by-case basis
and the first step is to file Jira tweak requests.

I hope that helps a little...

-- Jonathan

On 2/09/2013 12:25 a.m., Werner Lehmann wrote:
> Hi,
>
> I am trying to use FocusModel in a custom property sheet component -
> it is probably a good idea to reuse as m

Re: Missed "pulse"?

[Diego Cirujano-Cuesta]

I had a look to the source code Scott sent me(I think that was not the 
same that could be sent to 
Eva-https://javafx-jira.kenai.com/browse/RT-31025- because is not related 
to the bug).  It would be great if we would have all the source code in 
order to see if it affect us too. 

About the code you sent me, I think that there is an error. The code that 
Scott sent me had a line with GridPane.setColumnSpan(gp, 2); 
that wasn't correctly placed. In fact, by removing it the behaviour is 
enough to fix the problem but not enough good to have a clean UI structure

;). There is an strange component structure where gridpanes are added to 
gridcomponents where it shouldn´t be neccesary but it might have test 
purposes.

I didn´t have a look to the other parts. I think that FXML(Scene Builder) 
might help you here a lot.

It would be great if Scott could upload the source code somewhere 
available for all.

Diego 



From:   Scott Palmer 
To: Richard Bair 
Cc: Diego Cirujano-Cuesta , 
"openjfx-dev@openjdk.java.net" 
Date:   31.07.2013 17:18
Subject:Re: Missed "pulse"?



I did notice that commit.  Does that require the use of Canvas?  We aren't

using that, at least not directly.  It didn't sound like the same thing.. 
this one is really strange as *some* nodes are clipped and others aren't. 
 You can download a short video of what I'm experiencing in my app from 
here http://www.screencast.com/t/8Syrqp5nz
This is RT-30591

Scott


On Wed, Jul 31, 2013 at 10:58 AM, Richard Bair  
wrote:
Jim just fixed "RT-30223, RT-30826, RT-31044 - Canvas clears clip on 
Windows/D3D". If you are on Windows and seeing things are drawing that 
should be clipped, it might be related to one of these fixes. He's trying 
to get the fix into the 2.2 line as well as in 8. I only considered just 
now that this might be what you are seeing.

Richard

On Jul 31, 2013, at 7:42 AM, Scott Palmer  wrote:

> Interesting. The problem outlined in RT-31025 does involve GridPane with
> ColumnConstraints.  I will try to dig up the code.
>
> Scott
>
>
>
> On Wed, Jul 31, 2013 at 4:47 AM, Diego Cirujano-Cuesta <
> diego.cirujano-cue...@zeiss.com> wrote:
>
>> Hi Scott,
>>
>> I have a component quite similar to the one you described and I also 
had
>> problems like the ones that you mentioned with the same workarounds. 
BUT I
>> found out that the problem was of my understanding. One of the problems
>> was, I was using invalidation listeners and I wasn't getting always the
>> value and another problem was a gridPane with column constraints.
>>
>> I had a look deeply and I fix them, now they work perfect.
>>
>> I saw in Jira you sent your code to Eva. If you want, you can send me 
the
>> problem also(with the isolated code) I can have a look or much better, 
Eva
>> could publish the code in Jira. I am interested.
>>
>> Regards,
>>
>> Diego
>>
>>> (I'm talking JavaFX2.x, but this happens in 8 as well.)
>>
>>> In my application I occasionally see a situation where the rendering
>> doesn't jive with what it should. For example I have implemented my own
>> scroll pane (ironically enough I did this to workaround manifestations 
of a
>> problem similar to what I am about to describe in the stock ScrollPane)
>> using clipping and translations, but sometimes I see the clipped 
content at
>> the wrong location. So my clipped content is offset from the edge of my
>> pane, or rendered over top of things outside my pane, even though it is
>> impossible for the clipping and translating to not be set together.  If

I
>> mouse over the offending area it suddenly snaps to the way it should be
>> (CSS rules on the content would have forced it to redraw).
>>
>>> In other situations, I may need to coax a proper rendering of certain
>> layouts by nudging the size of something to force another layout.
>>
>>> Obviously things should just paint correctly the first time.  In these
>> situations, the variables appear to be set to the correct values, but
>> somehow that didn't get to the screen.
>>
>>> I'm not certain, but I suspect I might be able to work around these 
issues
>> if I could force a "pulse" or mark things as dirty some way to trigger 
one.
>> The thing is, there doesn't seem to be a publicly accessible way to do
>> this, presumably because it isn't supposed to be necessary in the first
>> place.
>>> Platform.runLater(... requestLayout ...) was one workaround that I 
started
>> to use, in the cases where things were particularly bad, but it isn't 
the
>> sort of things I want to have to scatter throughout my code..

Re: Missed "pulse"?

[Diego Cirujano-Cuesta]

I had problems when we were using column constraints with a fixed size. 
Something like this:

ColumnConstraints cc = new ColumnConstraints();
cc.setMaxWidth(ColumnConstraints.CONSTRAIN_TO_PREF);
cc.setPrefWidth(x);

So there was a ScrollPane with a Gridpane inside and the size of the 
gridpane was defined by the with of all columns. The thing was that 
calling setPrefWidth wasn´t triggeing a pulse.

This is what I found but during the optimization I found out that anothe 
pane was better for my case, so I don't use it anymore.

Regards.



From:   Scott Palmer 
To: Diego Cirujano-Cuesta 
Cc: "openjfx-dev@openjdk.java.net" 
Date:   31.07.2013 16:42
Subject:Re: Missed "pulse"?



Interesting. The problem outlined in RT-31025 does involve GridPane with 
ColumnConstraints.  I will try to dig up the code.

Scott



On Wed, Jul 31, 2013 at 4:47 AM, Diego Cirujano-Cuesta <
diego.cirujano-cue...@zeiss.com> wrote:
Hi Scott,

I have a component quite similar to the one you described and I also had 
problems like the ones that you mentioned with the same workarounds. BUT I

found out that the problem was of my understanding. One of the problems 
was, I was using invalidation listeners and I wasn't getting always the 
value and another problem was a gridPane with column constraints.

I had a look deeply and I fix them, now they work perfect. 

I saw in Jira you sent your code to Eva. If you want, you can send me the 
problem also(with the isolated code) I can have a look or much better, Eva

could publish the code in Jira. I am interested.

Regards,

Diego

>(I'm talking JavaFX2.x, but this happens in 8 as well.)

>In my application I occasionally see a situation where the rendering
doesn't jive with what it should. For example I have implemented my own
scroll pane (ironically enough I did this to workaround manifestations of 
a
problem similar to what I am about to describe in the stock ScrollPane)
using clipping and translations, but sometimes I see the clipped content 
at
the wrong location. So my clipped content is offset from the edge of my
pane, or rendered over top of things outside my pane, even though it is
impossible for the clipping and translating to not be set together.  If I
mouse over the offending area it suddenly snaps to the way it should be
(CSS rules on the content would have forced it to redraw).

>In other situations, I may need to coax a proper rendering of certain
layouts by nudging the size of something to force another layout.

>Obviously things should just paint correctly the first time.  In these
situations, the variables appear to be set to the correct values, but
somehow that didn't get to the screen.

>I'm not certain, but I suspect I might be able to work around these 
issues
if I could force a "pulse" or mark things as dirty some way to trigger 
one.
The thing is, there doesn't seem to be a publicly accessible way to do
this, presumably because it isn't supposed to be necessary in the first
place.
>Platform.runLater(... requestLayout ...) was one workaround that I 
started
to use, in the cases where things were particularly bad, but it isn't the
sort of things I want to have to scatter throughout my code..

>With recent testing on JavaFX 8 I had to remove some of my workarounds
because they caused a stack overflow doing layout. In requestLayout, I
would call requestLayout directly on some specific child nodes (without a
runLater) that seemed to misbehave - somehow this got back to call
requestLayout again in my class and a quick attempt to break the cycle
didn't work.

>I'm sure you can appreciate the frustration in trying to ship a
professional quality application with this sort of instability in the
rendering system.

>Since I suspect these issues aren't going to be fixed before 7u40 ships,
and 8 is a long way off, what is the best thing to do?  I have already
filed bugs for issues in a few specific cases. E.g.
RT-31025<https://javafx-jira.kenai.com/browse/RT-31025> (In

some cases from a long time ago I was unsure if I was doing something 
wrong
so I may not have isolated things into a test case and reported a bug.)


>Regards,

>Scott



This message is intended for a particular addressee only and may contain 
business or company secrets. If you have received this email in error, 
please contact the sender and delete the message immediately. Any use of 
this email, including saving, publishing, copying, replication or 
forwarding of the message or the contents is not permitted. 






 
This message is intended for a particular addressee only and may contain 
business or company secrets. If you have received this email in error, please 
contact the sender and delete the message immediately. Any use of this email, 
including saving, publishing, copying, replication or forwarding of the message 
or the contents is not permitted.  

Re: Missed "pulse"?

[Diego Cirujano-Cuesta]

Hi Scott,

I have a component quite similar to the one you described and I also had 
problems like the ones that you mentioned with the same workarounds. BUT I

found out that the problem was of my understanding. One of the problems 
was, I was using invalidation listeners and I wasn't getting always the 
value and another problem was a gridPane with column constraints.

I had a look deeply and I fix them, now they work perfect. 

I saw in Jira you sent your code to Eva. If you want, you can send me the 
problem also(with the isolated code) I can have a look or much better, Eva

could publish the code in Jira. I am interested.

Regards,

Diego

>(I'm talking JavaFX2.x, but this happens in 8 as well.)

>In my application I occasionally see a situation where the rendering
doesn't jive with what it should. For example I have implemented my own
scroll pane (ironically enough I did this to workaround manifestations of 
a
problem similar to what I am about to describe in the stock ScrollPane)
using clipping and translations, but sometimes I see the clipped content 
at
the wrong location. So my clipped content is offset from the edge of my
pane, or rendered over top of things outside my pane, even though it is
impossible for the clipping and translating to not be set together.  If I
mouse over the offending area it suddenly snaps to the way it should be
(CSS rules on the content would have forced it to redraw).

>In other situations, I may need to coax a proper rendering of certain
layouts by nudging the size of something to force another layout.

>Obviously things should just paint correctly the first time.  In these
situations, the variables appear to be set to the correct values, but
somehow that didn't get to the screen.

>I'm not certain, but I suspect I might be able to work around these 
issues
if I could force a "pulse" or mark things as dirty some way to trigger 
one.
 The thing is, there doesn't seem to be a publicly accessible way to do
this, presumably because it isn't supposed to be necessary in the first
place.
>Platform.runLater(... requestLayout ...) was one workaround that I 
started
to use, in the cases where things were particularly bad, but it isn't the
sort of things I want to have to scatter throughout my code..

>With recent testing on JavaFX 8 I had to remove some of my workarounds
because they caused a stack overflow doing layout. In requestLayout, I
would call requestLayout directly on some specific child nodes (without a
runLater) that seemed to misbehave - somehow this got back to call
requestLayout again in my class and a quick attempt to break the cycle
didn't work.

>I'm sure you can appreciate the frustration in trying to ship a
professional quality application with this sort of instability in the
rendering system.

>Since I suspect these issues aren't going to be fixed before 7u40 ships,
and 8 is a long way off, what is the best thing to do?  I have already
filed bugs for issues in a few specific cases. E.g.
RT-31025 (In
some cases from a long time ago I was unsure if I was doing something 
wrong
so I may not have isolated things into a test case and reported a bug.)


>Regards,

>Scott



 
This message is intended for a particular addressee only and may contain 
business or company secrets. If you have received this email in error, please 
contact the sender and delete the message immediately. Any use of this email, 
including saving, publishing, copying, replication or forwarding of the message 
or the contents is not permitted.