Re: Reloading stylesheets
This is also impacting Scene Builder. I have filed a Jira with a test case: https://javafx-jira.kenai.com/browse/RT-34863 Jerome On 12/11/13 6:19 PM, David Grieve wrote: There is clearly a bug there somewhere. Would you mind filing an issue on javafx-jira.kenai.com? On Dec 11, 2013, at 11:51 AM, ngalarn...@abinitio.com wrote: Hi David, I have stylesheet SWITCHING working fine. I can switch between 2 different stylesheets on disk without tearing down rebuilding my Scene. To do this I simply do: scene.stylesheets.clear() scene.stylesheets.add(differentStylesheet) and the changes show up immediately (I'm assuming those 2 lines cause a .css recalculation a pulse). I would like to get stylesheet RELOADING to work in my JavaFX 8 app. By this I mean picking up changes in a single .css file. This would allow the developers to tweak the stylesheet reload to see the effects immediately. Unfortunately, it feels like the Filename of the stylesheet is the Key in a cache that isn't getting cleared by my code above. Nothing visible happens when I do: scene.stylesheets.clear() scene.stylesheets.add(sameStylesheet) Given your description below, my impression is that RELOADING should also work... Thank you for any suggestions, Neil From: David Grieve david.gri...@oracle.com To: Werner Lehmann lehm...@media-interactive.de Cc: openjfx-dev@openjdk.java.net Date: 12/10/2013 11:10 AM Subject:Re: Reloading stylesheets Sent by:openjfx-dev-boun...@openjdk.java.net The way it works in 8.0 is that there is a cache of loaded stylesheets. When a scene or parent adds a stylesheet, the stylesheet is added to the cache. Any other scene or parent that uses the same stylesheet will get the one from cache. If a scene or parent later removes the stylesheet, the stylesheet is removed from the cache and the css style cache for any scene or parent that referenced that stylesheet is cleared (since the set of styles may have changed). Any scene or parent that referenced the now removed stylesheet is told to reapply its styles. Since the stylesheet is no longer in cache, it will be re-parsed (or reloaded if there is a binary version of the stylesheet) when it is called for by a scene or parent. The way it worked in 2.x was an abomination. On Dec 10, 2013, at 10:30 AM, Werner Lehmann lehm...@media-interactive.de wrote: Interesting. Assuming the stylesheets are still cached, how would it know when to reload and not use the cached sheet? Or has sheet processing been optimized so much that caching is not necessary anymore... On 10.12.2013 16:15, Tom Schindl wrote: No on FX8 you need to remove and readd them! So the only thing different is that you omit the reload-call on FX8. NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.
hg: openjfx/8u-dev/rt: RT-29816 Custom cursor lost over ComboBox options
Changeset: 0a745cbe7f58 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-12-12 10:23 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0a745cbe7f58 RT-29816 Custom cursor lost over ComboBox options Reviewed by: kcr ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/stage/PopupWindow.java ! modules/graphics/src/test/java/javafx/scene/MouseTest.java ! modules/graphics/src/test/java/javafx/stage/PopupTest.java
Re: Fwd: CFV: New OpenJFX Committer: Vadim Pakhnushev
Vote: YES -- best regards, Anthony On 12/12/2013 01:17 AM, David Hill wrote: I hereby nominate Vadim Pakhnushev to OpenJFX Committer. Vadim is a member of JavaFX Embedded team at Oracle. Vadim's changes are in Glass Windows/D3d: hg log -M -u vadim An incomplete list of Vadim's commits and reviews is also available by the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=vadim Votes are due by Dec 25, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave
Re: Fwd: CFV: New OpenJFX Committer: Vadim Pakhnushev
Vote: yes Artem On 12/12/2013 1:17 AM, David Hill wrote: I hereby nominate Vadim Pakhnushev to OpenJFX Committer. Vadim is a member of JavaFX Embedded team at Oracle. Vadim's changes are in Glass Windows/D3d: hg log -M -u vadim An incomplete list of Vadim's commits and reviews is also available by the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=vadim Votes are due by Dec 25, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave
Re: Fwd: CFV: New OpenJFX Committer: Vadim Pakhnushev
Vote: YES Thanks, Anton. On 12.12.2013 1:17, David Hill wrote: I hereby nominate Vadim Pakhnushev to OpenJFX Committer. Vadim is a member of JavaFX Embedded team at Oracle. Vadim's changes are in Glass Windows/D3d: hg log -M -u vadim An incomplete list of Vadim's commits and reviews is also available by the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=vadim Votes are due by Dec 25, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave
hg: openjfx/8/graphics/rt: RT-34784: [TextField, PasswordField, TextArea] Selected text is removed on focus leaving
Changeset: 0f28c98557a2 Author:Anthony Petrov anthony.pet...@oracle.com Date: 2013-12-12 23:53 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0f28c98557a2 RT-34784: [TextField, PasswordField, TextArea] Selected text is removed on focus leaving Summary: Post IM events only if text composition is active Reviewed-by: pchelko, azvegint, anthony, kcr, snorthov Contributed-by: pchelko, azvegint ! modules/graphics/src/main/java/com/sun/glass/ui/gtk/GtkView.java ! modules/graphics/src/main/native-glass/gtk/glass_general.cpp ! modules/graphics/src/main/native-glass/gtk/glass_general.h ! modules/graphics/src/main/native-glass/gtk/glass_window_ime.cpp ! modules/graphics/src/main/native-glass/mac/GlassView3D.m
Re: discussion about touch events
Hi Anthony, let me throw a few random problems without really thinking this through. First of all, the whole thing relies on HashMaps, but we can't really use nodes in hash-based collections as they are not immutable. To maintain the registrations with the rectangles, we would need to do some computations (bounds) eagerly. There is again the problem of restricting to touch-sensitive nodes only. Finally, even if your proposal turns out to work like a charm, it reduces the number of examined nodes, but the most important and difficult part - how do we choose the right one - needs to be specified. Regards, Pavel On 20.11.2013 10:02, Anthony Petrov wrote: How about you divide the top-level window surface on equal rectangles of size, say, 0.5x0.5 (the size in pixels will depend on the screen DPI.) Each rectangle is basically a hashmap of nodes. The nodes that are touch sensible register and update themselves with the rectangles when their layout information changes (when they're moved and/or resized). This should work reasonably fast given O(1) complexity for hashmap operations. When processing a touch event, given the low-resolution of the rectangle mesh, we can quickly identify a set of rectangles that a touch area (an oval) intersects. There usually will be no more than four such rectangles. After that we construct a union of all nodes laying in those rectangles, and simply iterate over the union to choose a node laying closest to the touch area (or having the largest intersection with it, whatever.) Again, this should work fast because fetching nodes from the hashmaps is fast, and the number of nodes that need to be examined should be relatively small. -- best regards, Anthony On 11/19/2013 08:18 PM, Daniel Blaukopf wrote: On Nov 19, 2013, at 4:34 PM, Pavel Safrata pavel.safr...@oracle.com wrote: Hello Daniel, On 17.11.2013 15:09, Daniel Blaukopf wrote: Hi Pavel, I think we we do use CSS to configure feel as well as look - and this is feel, not look - but I also don’t feel strongly about whether this needs to be in CSS. This was exactly my point. Yes, we agree. I should have phrased the above differently to show that. I like your idea of simply picking the closest touch sensitive node that is within range. That puts the burden on the touch event to describe what region it covers. On the touch screens we are currently looking at, a region would be defined as an oval - a combination of centre point, X diameter and Y diameter. However the touch region can be any shape, so might need to be represented as a Path. I don't think we need to be precise about the shape, all of this is about fixing the imprecise touch where the shape is rather accidental, I think even a circle with an average diameter would be sufficient to achieve the goal. For now it certainly is sufficient. However these touch devices can describe more complex shapes for the touch contact area and it is possible we will want to take advantage of that in the future. We should certainly optimize for a circle or oval shape. Iterating over pixels just isn’t going to work though. If we have a 300dpi display the touch region could be 150 pixels across and have an area of nearly 18000 pixels. Instead we’d want a way to ask a parent node, “In your node hierarchy, which of your nodes’ borders is closest to this region”. So we’d need to come up with an efficient algorithm to answer this question. We’d only ask this question for nodes with extended capture zone. The nodes with extended capture zone may be fully or partially hidden behind nodes without it and this needs to be taken into account. How would it be done when the question would be limited to nodes with extended capture zone? And even if it wasn't, what would the position of the border tell us about the area covered by the node? It can be a line.. Also what I wanted to achieve is pick the node which has visible pixels in the picking area even if its border is hidden behind other node or is somewhere far away. This wouldn't be possible, would it? We could reasonably limit the algorithm to dealing with convex shapes. Can we? What about paths, polygons etc? I realize that it is possible to describe touch sensitive concave shapes, but I am not sure they matter for this. If developers are going to go to the trouble of defining a concave shape that they want to be touch sensitive within its area but not in all of its bounding box, are they really then going to want that area to be extended? I’d consider a concave touch shape with extended capture zone to be sufficiently unlikely that we could treat it as concave. Which, I realize is not quite what my proposed algorithm does. Then we can consider an imaginary line L from the node center point to the touch center point. The intersection of L with the node perimeter is the closest point of contact. It isn't. Imagine a very wide and flat (small height)
Re: discussion about touch events
Hi Assaf, please see my comments inline. On 20.11.2013 16:30, Assaf Yavnai wrote: Pavel, I think that this is a very good example why touch events should be processed separately from mouse events. For example, if you will press a button with a touch it will remain in hover state although you released the finger from the screen. This is done because the hover state listen to the mouse coordinates, which is invalid for touch. Touch events doesn't have the concept of move, only drag. My initial feeling would be for the synthesized mouse events to behave similarly to touch events - when touching the screen you want the application respond certain way regardless of the events used. Do we agree? Specifically, the hover problem can be solved quite easily. On iOS, Glass generates a MOUSE_EXITED event any time all touches are released, which clears the hover state of everything. I suppose all platforms can do that (for synthesized mouse events). As I mentioned before, from my point of view, the goal of this thread is to understand and map the difference and expected behavior between touch events and mouse events and have separate behavior depends of the type of events (Nodes, Controls and application level). One of them is the picking mechanism, the hover is another. I think the discussion of how to implement it is currently in lower priority, as it is only a technical detail. OK. Regarding picking, I believe the logical algorithm pick each pixel and find the touch-sensitive one closest to the center if there's any is the most natural behavior (just let me note that implementation is not really a technical detail because right now I don't see any way to implement it, so we might need to do something different). I already covered hover state. Another major thing on my mind is that scrollable content needs to become pannable (right now an attempt to scroll a list by panning in FX results in selecting an item, or even expanding a tree item, this is just not acceptable). Also I think that the synthesize mouse event should only be used for making applications that doesn't listen to touch event usable (in most cases), but we can't expect them to work 1:1. (touch using a finger is a very different device then a mouse of stylus device). Touch applications supposed to be 'tailor made' for touch this include different UI layout, different UX and of course different logic (because the events and there meaning are different then mouse) Currently the is no reason for an application to listen to touch events, only if you need to support multi-touch, as the events are duplicated. The touch events were added exactly to support multi-touch. The look is one thing - yes, you'd often use different skins. But I believe the behavior of the events can be made such that a majority of application can just use mouse events and their application will behave well with single-touch out of the box, which can save a lot of development effort on user's side. As the mouse events are synthesize in native layer, I think its important to know the origin of the event. Maybe the handlers should check if the event is synthetic and treat it as touch event in this case. We can also double check it by checking if there is currently touch device connected, for example. I agree, I think many handlers will need to take the isSynthesized() flag into account. Regards, Pavel Assaf On 11/19/2013 04:34 PM, Pavel Safrata wrote: Hello Assaf, there is more to it than just listeners. For instance, every node has its hover and pressed states that are maintained based on the picking results and used by CSS. So I believe we can't ignore anything during picking. By the way, I suppose this fuzzy picking should happen also for synthesized mouse events so that all the classic apps and standard controls can benefit. If I'm right, we definitely can't restrict it on touch-listening nodes. Pavel On 18.11.2013 14:10, Assaf Yavnai wrote: I have a question, Would it be possible to search only the nodes that have been registered for touch events notifications instead of the entire tree? (if it's not already been done) Of course if one choose to register the root node as the listener, we will have to go all over the nodes, but it seems as bad practice and I think its OK to have performance hit on that case Assaf On 11/17/2013 04:09 PM, Daniel Blaukopf wrote: Hi Pavel, I think we we do use CSS to configure feel as well as look - and this is feel, not look - but I also don’t feel strongly about whether this needs to be in CSS. I like your idea of simply picking the closest touch sensitive node that is within range. That puts the burden on the touch event to describe what region it covers. On the touch screens we are currently looking at, a region would be defined as an oval - a combination of centre point, X diameter and Y diameter. However the touch region can be any shape, so
hg: openjfx/8/graphics/rt: RT-34685: Regression: TextFieldTableCell in TableView doesn't save edited values in b118
Changeset: 773008dbb998 Author:jgiles Date: 2013-12-13 09:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/773008dbb998 RT-34685: Regression: TextFieldTableCell in TableView doesn't save edited values in b118 ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/StageLoader.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java ! modules/controls/src/test/java/javafx/scene/control/ListViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewMouseInputTest.java
hg: openjfx/8u-dev/rt: 6 new changesets
Changeset: dcda500991c5 Author:jgiles Date: 2013-12-12 14:31 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dcda500991c5 RT-34461: Space doesn't create an anchor for cell-based multiple selection mode. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewKeyInputTest.java Changeset: 022d5863ddd9 Author:jgiles Date: 2013-12-12 16:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/022d5863ddd9 Partial fix for RT-34620: [Default Button] Button set to default is not reacting to ComboBox enter key ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/test/java/javafx/scene/control/ComboBoxTest.java Changeset: 6aa65cf42394 Author:jgiles Date: 2013-12-12 17:04 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6aa65cf42394 RT-34828: TabPane has resize problems when tabs.setAll(tab) is invoked. Also, a general clean up of some of the skin code to make the tab open / close animations nicer. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: 216d3d77c77c Author:jgiles Date: 2013-12-13 07:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/216d3d77c77c Fix possible NPE in NestedTableColumnHeader ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: c9b8d00649f7 Author:jgiles Date: 2013-12-13 08:31 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c9b8d00649f7 RT-31442: Charts should have opaque background by default ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: b6f3f3d2ef2d Author:jgiles Date: 2013-12-13 08:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b6f3f3d2ef2d RT-31132: Focus traversable can't be switched off for date picker ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java
hg: openjfx/8u-dev/rt: Ensemble8: Fix for RT-34881 Modena app tries to load non-existing file
Changeset: 1fe2a517b2cc Author:Alexander Kouznetsov Date: 2013-12-12 17:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1fe2a517b2cc Ensemble8: Fix for RT-34881 Modena app tries to load non-existing file ! apps/experiments/Modena/src/main/java/modena/SamplePageHelpers.java ! apps/experiments/Modena/src/main/java/modena/SamplePageTableHelper.java
