Re: Programmatic (Java) access to style / layout ?
I agree that different people would like different things
here is mine ;)
button.border().hover().setColor(red);
This styling is widely used in scripting languages, jQuery is a good
example. Its done by always return an object from an operation, in this
example setColor() will return the same object that was returned from
hover(), allowing further manipulation in the same line of code. For
example
button.border().hover().setColor(red).setStrokeWidth(10).setBlink(false).setHandler(()-{});
If readability is an issue it can be formatted as:
button.border().hover()
.setColor(red)
.setStrokeWidth(10)
.setBlink(false)
.setHandler(()-{});
And this reminds me another issue, which may be a fork, but in my point
of view its originated from the same approach, which is users manipulate
internal data structures directly to do operations.
I didn't understand the design decision to expose internal structures in
FX to do operations and manipulate them directly. In this case
properties, another example is root.getChilderen().add(). This not only
expose the internal data structure, but also requires more coding for
simple trivial operation. users 90% don't need/care about the internal
data structures, but 100% want to write less and simpler code. Usually
user just want to do some trivial thing, add, remove, traverse..., for
those common cases an alias can be used that encapsulate inside it the
data structure used and the language quirks. In this example root.add()
would do the trick. Other operations could look similar, like
root.clear(), root, remove(...). root.traverse()(will return an
iterator). For those edge cases which requires manipulating the data
structure directly API can expose them, like root.getChildrensAsList(),
or root.getChildren()
Combining the 2 approaches and the ability to retrieve the nodes related
to the operations in 2 levels, say through .base() and .parent(), would
yield the results that Oliver suggested (as I understood them)
(hope the layout wouldn't get scrambled upon send)
Group root = new Group()
.add( new Button()
.border()
.hover()
.setColor(red)
.setStrokeWidth(10)
.setBlink(false)
.setHandler(()-{})
.parent() //parent()
return border
.setColor(blue)
.setBlink(true)
.base().caption()
//base() return button
.setText(button1)
.setFontSize(30)
.base(),
new Button(button 2).caption()
.setSize(25)
.setHandler(()-{}))
.base()
)//end of add()
.some().other().operation.onGroup()
);
my 0.002$
Assaf
On 12/17/2013 11:18 PM, David Grieve wrote:
It is possible, but probably not in the way that
https://javafx-jira.kenai.com/browse/RT-17293 would provide. By that I mean, it would be
nice to be able to progammatically say the border color for this button when
hovered is red. This can be done now by adding an invalidation listener to the
hoverProperty and setting the border on Region, but I don' t think this is what you are
after.
I think RT-17923 means different things to different people. I'd be interested
to know what such and API would look like to you.
On Dec 17, 2013, at 3:39 PM, Oliver Doepner odoep...@gmail.com wrote:
Hello,
This might have been asked before but I haven't found it:
Is it possible to style JavaFX components using pure Java (i.e. without
CSS)?
If this is being worked on, does anyone know what the status is?
I think this is one of the areas where JavaFX can actually be better than
HTML5/CSS because a nicely typed Java representation of CSS could provide
great tooling and features that others had to invent LESS or SASS for.
I have seen this (from Oct 2012):
http://stackoverflow.com/questions/12943501/style-javafx-components-without-css
I have also seen this: https://javafx-jira.kenai.com/browse/RT-17293
Last update: Brian
Beckhttps://javafx-jira.kenai.com/secure/ViewProfile.jspa?name=bcbeckadded
a comment - Mar,
12 2012 09:01 PM : It is now past the point where this feature can be
added for 2.1. Will need to be considered for a future release
Thanks
Oliver
--
Oliver Doepner
http://doepner.net/
Re: discussion about touch events
Pavel, See RT-34945 https://javafx-jira.kenai.com/browse/RT-34945 for a good example to the case that touch and mouse event should behave differently on controls. Assaf On 12/15/2013 05:43 PM, Assaf Yavnai wrote: Pavel, I will summarize my answers here, and not inline, I hope I will touch all your points. Let me start my answer with a different perspective. I think that it is correct to try and make mouse oriented application to work under touch screens, but its not the same as looking how UI should behave with touch screens. To explain myself, here an example tested on the iPhone. It doesn't mean that we need to do the same, but rather a pointer for checking how UI can behave under touch. In iPhone, when you press on a control, say send button, and you start dragging it away the button will remain 'armed' for quite large distance, even if you drag it on top of other controls. Only after a large distance is passed, the button is been deactivated and the operation is canceled, this is true a cross the platform. What I'm trying to say that we first need to define how we would like touch behave from UI/UX point of view and only then try to resolve the technical issues. After saying that its very important to note that JFX is cross platform and device specific as smartphones are for example. So I believe that: - mouse events should act as mouse events (regardless to touch) - touch events should act as touch events (regardless to mouse) and - mouse applications that run on a touch device should have 80/20 functionality working i.e usable but not perfect (again the way the application behaved and designed could not overlap in 100%, like small UI elements) - a question how we want touch application work on mouse platform (migrating embedded application to desktop for example) But UI should behave differently on touch platforms and mouse platform, or more accurately when events derived from touch device or a pointer device. And this (mainly) is currently not supported. I would like to suggest the following, hoping its feasible for the next release (8u20 or 9) 1) define UI/UX requirements for touch devices 2) check overlaps and unique behavior between mouse and touch behaviors 3) suggest 3 UI paths 1) mouse based UI 2) touch based UI 3) common behavior 4) discuss and define technical approach We might end up in a solution very similar to what we have now, or as you said, something completely new. The challenge is to come to it with 'empty minds' (that why it would be best if UX engineer will define it and not us) Further more, I think that solutions like Glass generates a MOUSE_EXITED event any time all touches are released should be implemented in the shared code in not platform specific point, for obvious reasons as this example provide. I apologize if it was hinted that the technical chalnges are not imoprtent or not challenging, I meant that it isn't the time to tackle them (top down approach vs bottom-up) I believe that we both want to to deliver a top notch platform and not one that works most of the time, the difference between us, I think, is that I focus on the differences and you on the commonalities. Maybe it would be best if we assemble a team to discuss those issues by phone instead of mails, what do you think? Hope its clearer. Assaf On 12/12/2013 10:30 PM, Pavel Safrata wrote: 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
Re: discussion about touch events
Pavel, I will summarize my answers here, and not inline, I hope I will touch all your points. Let me start my answer with a different perspective. I think that it is correct to try and make mouse oriented application to work under touch screens, but its not the same as looking how UI should behave with touch screens. To explain myself, here an example tested on the iPhone. It doesn't mean that we need to do the same, but rather a pointer for checking how UI can behave under touch. In iPhone, when you press on a control, say send button, and you start dragging it away the button will remain 'armed' for quite large distance, even if you drag it on top of other controls. Only after a large distance is passed, the button is been deactivated and the operation is canceled, this is true a cross the platform. What I'm trying to say that we first need to define how we would like touch behave from UI/UX point of view and only then try to resolve the technical issues. After saying that its very important to note that JFX is cross platform and device specific as smartphones are for example. So I believe that: - mouse events should act as mouse events (regardless to touch) - touch events should act as touch events (regardless to mouse) and - mouse applications that run on a touch device should have 80/20 functionality working i.e usable but not perfect (again the way the application behaved and designed could not overlap in 100%, like small UI elements) - a question how we want touch application work on mouse platform (migrating embedded application to desktop for example) But UI should behave differently on touch platforms and mouse platform, or more accurately when events derived from touch device or a pointer device. And this (mainly) is currently not supported. I would like to suggest the following, hoping its feasible for the next release (8u20 or 9) 1) define UI/UX requirements for touch devices 2) check overlaps and unique behavior between mouse and touch behaviors 3) suggest 3 UI paths 1) mouse based UI 2) touch based UI 3) common behavior 4) discuss and define technical approach We might end up in a solution very similar to what we have now, or as you said, something completely new. The challenge is to come to it with 'empty minds' (that why it would be best if UX engineer will define it and not us) Further more, I think that solutions like Glass generates a MOUSE_EXITED event any time all touches are released should be implemented in the shared code in not platform specific point, for obvious reasons as this example provide. I apologize if it was hinted that the technical chalnges are not imoprtent or not challenging, I meant that it isn't the time to tackle them (top down approach vs bottom-up) I believe that we both want to to deliver a top notch platform and not one that works most of the time, the difference between us, I think, is that I focus on the differences and you on the commonalities. Maybe it would be best if we assemble a team to discuss those issues by phone instead of mails, what do you think? Hope its clearer. Assaf On 12/12/2013 10:30 PM, Pavel Safrata wrote: 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
review request: [RT-34477] [Lens] Command-line option to track input device raw events
Hi Daniel, Would you please review the patch for RT-34477 https://javafx-jira.kenai.com/browse/RT-34477 (attached ti the JIRA) Thanks, Assaf
review request - RT-34481 [Lens] [touch] Saving of pending points may result in a bad state
Hi Dave, Would you please review the webrev attached to RT-34481 https://javafx-jira.kenai.com/browse/RT-34481 Thanks, Assaf
Re: discussion about touch events
is the fair division of capture zones among siblings. It's an interesting idea, let's explore it. What pops first is that children can also overlap. So I think it would behave like this (green capture zones omitted): Child in parent vs. Child over child: http://i.imgur.com/e92qEJA.jpg ..wouldn't it? From user's point of view this seems confusing, both cases look the same but behave differently. Note that in the case on the right, the parent may be still the same, developer only adds a fancy background as a new child and suddenly the red child can't be hit that easily. What do you think? Is it an issue? Or would it not behave this way? Regards, Pavel On 12.11.2013 12:06, Daniel Blaukopf wrote: (My original message didn't get through to openjfx-dev because I used inline images. I've replaced those images with external links) On Nov 11, 2013, at 11:30 PM, Pavel Safrata pavel.safr...@oracle.com mailto:pavel.safr...@oracle.com wrote: On 11.11.2013 17:49, Tomas Mikula wrote: On Mon, Nov 11, 2013 at 1:28 PM, Philipp Dörfler phdoerf...@gmail.com mailto:phdoerf...@gmail.com wrote: I see the need to be aware of the area that is covered by fingers rather than just considering that area's center point. I'd guess that this adds a new layer of complexity, though. For instance: Say we have a button on some background and both the background and the button do have an onClick listener attached. If you tap the button in a way that the touched area's center point is outside of the buttons boundaries - what event will be fired? Will both the background and the button receive a click event? Or just either the background or the button exclusively? Will there be a new event type which gets fired in case of such area-based taps? My suggestion would therefore be to have an additional area tap event which gives precise information about diameter and center of the tap. Besides that there should be some kind of priority for choosing which node's onClick will be called. What about picking the one that is closest to the center of the touch? There is always something directly on the center of the touch (possibly the scene background, but it can have event handlers too). That's what we pick right now. Pavel What Seeon, Assaf and I discussed earlier was building some fuzziness into the node picker so that instead of each node capturing only events directly on top of it: Non-fuzzy picker: http://i.imgur.com/uszql8V.png ..nodes at each level of the hierarchy would capture events beyond their borders as well: Fuzzy picker: http://i.imgur.com/ELWamYp.png In the above, Parent would capture touch events within a certain radius around it, as would its children Child 1 and Child 2. Since Child 1 and Child 2 are peers, they would have a sharp division between them, a watershed on either side of which events would go to one child node or the other. This would also apply if the peer nodes were further apart; they would divide the no-man's land between them. Of course this no-man's land would be part of Parent and could could be touch-sensitive - but we won't consider Parent as an event target until we have ruled out using one of its children's extended capture zones. The capture radius could either be a styleable property on the nodes, or could be determined by the X and Y size of a touch point as reported by the touch screen. We'd still be reporting a touch point, not a touch area. The touch target would be, as now, a single node. This would get us more reliable touch capture at leaf nodes of the node hierarchy at the expense of it being harder to tap the background. This is likely to be a good trade-off. Daniel Tomas Maybe the draw order / order in the scene graph / z buffer value might be sufficient to model what would happen in the real, physical world. Am 11.11.2013 13:05 schrieb Assaf Yavnai assaf.yav...@oracle.com mailto:assaf.yav...@oracle.com: The ascii sketch looked fine on my screen before I sent the mail :( I hope the idea is clear from the text (now in the reply dialog its also look good) Assaf On 11/11/2013 12:51 PM, Assaf Yavnai wrote: Hi Guys, I hope that I'm right about this, but it seems that touch events in glass are translated (and reported) as a single point events (x y) without an area, like pointer events. AFAIK, the controls response for touch events same as mouse events (using the same pickers) and as a result a button press, for example, will only triggered if the x y of the touch event is within the control area. This means that small controls, or even quite large controls (like buttons with text) will often get missed because the 'strict' node picking, although from a UX point of view it is strange as the user clearly pressed on a node (the finger was clearly above it) but nothing happens... With current implementation its hard to use small features in controls, like scrollbars in lists, and it almost impossible to implement something like 'screen navigator' (the series of small dots
review request - RT-34191 Lens: [touch] wrong logic for drag starting outside a window
JIRA - RT-34191 https://javafx-jira.kenai.com/browse/RT-34191(webrev attached) Summary: 2 problems where identified: 1) the logic issue described above 2) native mouse drag detection was relaying on an obsolete variable Fixing item 2 also solved RT-34137 https://javafx-jira.kenai.com/browse/RT-34137 Unit tests were also updated to reflect the change of logic Attaching fix patches Fix was tested using helloworld.HelloSanity, BrickBreaker, FXML-LoginDemo, Calculator and LinuxInputTest
Re: discussion about touch events
on either side of which events would go to one child node or the other. This would also apply if the peer nodes were further apart; they would divide the no-man’s land between them. Of course this no-man’s land would be part of “Parent” and could could be touch-sensitive - but we won’t consider “Parent” as an event target until we have ruled out using one of its children’s extended capture zones. The capture radius could either be a styleable property on the nodes, or could be determined by the X and Y size of a touch point as reported by the touch screen. We’d still be reporting a touch point, not a touch area. The touch target would be, as now, a single node. This would get us more reliable touch capture at leaf nodes of the node hierarchy at the expense of it being harder to tap the background. This is likely to be a good trade-off. Daniel Tomas Maybe the draw order / order in the scene graph / z buffer value might be sufficient to model what would happen in the real, physical world. Am 11.11.2013 13:05 schrieb Assaf Yavnai assaf.yav...@oracle.com mailto:assaf.yav...@oracle.com: The ascii sketch looked fine on my screen before I sent the mail :( I hope the idea is clear from the text (now in the reply dialog its also look good) Assaf On 11/11/2013 12:51 PM, Assaf Yavnai wrote: Hi Guys, I hope that I'm right about this, but it seems that touch events in glass are translated (and reported) as a single point events (x y) without an area, like pointer events. AFAIK, the controls response for touch events same as mouse events (using the same pickers) and as a result a button press, for example, will only triggered if the x y of the touch event is within the control area. This means that small controls, or even quite large controls (like buttons with text) will often get missed because the 'strict' node picking, although from a UX point of view it is strange as the user clearly pressed on a node (the finger was clearly above it) but nothing happens... With current implementation its hard to use small features in controls, like scrollbars in lists, and it almost impossible to implement something like 'screen navigator' (the series of small dots in the bottom of a smart phones screen which allow you to jump directly to a 'far away' screen) To illustrate it consider the bellow low resolution sketch, where the + is the actual x,y reported, the ellipse is the finger touch area and the rectangle is the node. With current implementation this type of tap will not trigger the node handlers __ / \ / \ ___/ __+_ \___in this scenario the 'button' will not get pressed |\ /| |___\ ___ / __ | \___/ If your smart phone support it, turn on the touch debugging options in settings and see that each point translate to a quite large circle and what ever fall in it, or reasonably close to it, get picked. I want to start a discussion to understand if my perspective is accurate and to understand what can be done, if any, for the coming release or the next one. We might use recently opened RT-34136 https://javafx-jira.kenai. com/browse/RT-34136 for logging this, or open a new JIRA for it Thanks, Assaf
Re: discussion about touch events
The ascii sketch looked fine on my screen before I sent the mail :( I hope the idea is clear from the text (now in the reply dialog its also look good) Assaf On 11/11/2013 12:51 PM, Assaf Yavnai wrote: Hi Guys, I hope that I'm right about this, but it seems that touch events in glass are translated (and reported) as a single point events (x y) without an area, like pointer events. AFAIK, the controls response for touch events same as mouse events (using the same pickers) and as a result a button press, for example, will only triggered if the x y of the touch event is within the control area. This means that small controls, or even quite large controls (like buttons with text) will often get missed because the 'strict' node picking, although from a UX point of view it is strange as the user clearly pressed on a node (the finger was clearly above it) but nothing happens... With current implementation its hard to use small features in controls, like scrollbars in lists, and it almost impossible to implement something like 'screen navigator' (the series of small dots in the bottom of a smart phones screen which allow you to jump directly to a 'far away' screen) To illustrate it consider the bellow low resolution sketch, where the + is the actual x,y reported, the ellipse is the finger touch area and the rectangle is the node. With current implementation this type of tap will not trigger the node handlers __ / \ / \ ___/ __+_ \___in this scenario the 'button' will not get pressed |\ /| |___\ ___ / __ | \___/ If your smart phone support it, turn on the touch debugging options in settings and see that each point translate to a quite large circle and what ever fall in it, or reasonably close to it, get picked. I want to start a discussion to understand if my perspective is accurate and to understand what can be done, if any, for the coming release or the next one. We might use recently opened RT-34136 https://javafx-jira.kenai.com/browse/RT-34136 for logging this, or open a new JIRA for it Thanks, Assaf
did anyone encountered this?
:apps:experiments:3DViewer:compileJava FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':apps:experiments:3DViewer:compileJava'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 39.292 secs assaf@assaf-Latitude-E6410:~/ws/udev-refactoring/rt$ java -versionjava version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b113) Java HotSpot(TM) Server VM (build 25.0-b55, mixed mode) Thanks, Assaf
Re: mouse vs. touch events on touch systems like iOS/Android/Dukepad
Matthias, Please look inline On 10/22/2013 07:33 PM, Richard Bair wrote: Hi Matthias, I think Assaf, one of the embedded engineers, is now on the mailing list and can help answer these questions. Thanks Richard On Oct 21, 2013, at 1:58 AM, Matthias Hänel hae...@ultramixer.com wrote: Hi, I believe my conceptual question on touch/mouse events has been missed because of the other questions in the JAVAFX on ANDROID thread. That's why I would like to start a new discussion about touch events. 1. The main question is how are touch and internal mouse events handled? Javafx controls seem to rely on mouse events. That's why I assume there must be some kind of an emulation layer. Are these emulated in Prism, Glass (Java-Glasses) or even lower? Where is it suppose to emulate the mouse events? What I've seen right now is that iOS-native glass does the mouse emulation by itself in GlassViewDelegate.m. Touch events and Mouse events are sent from the lowest layer. In Android there are only touch events passed to the lens implementation. On udev which I assume is the implementation that's used for Dukepad it does only pass touch events. Udev and Android are lens implementations so, they are using the same Java classes which do kind of mouse emulation for toch events. But it's not exactly the same as the iOS codes does. iOS: sends Touch, Mouse-Enter and Mouse-Down Lens (Android/Dukepad): sends Mouse-Enter and Touch The major differences in calling order and the missung mouse down leeds me to the assumption that the events are actually missing. Basically the Glass port resbonsible to simulate mouse events from touch events. On Windows, for example, its done automaticaly by the OS, in other implementations its emulated in the native layer, in Lens currently its done in several places and layers (the input driver, the window manger and the java glass code). There are currently several issues with the touch support in Lens implementaion that effects all the ports that are using it. You can track the work through the master bug RT-32802. https://javafx-jira.kenai.com/browse/RT-32802 I'm curently working on solving those issues, and one of the fixes is to make mouse simulation more unified. Please feal free to open more bugs for specific scenrios and link them to the master bug, so we can track it and solve it. 2. Is that mouse emulation supposed to be eliminated due to the latest lensWindow changes? I believe that must be handled in higher layers not in the input layer itself. What do you mean by 'latest lensWindow changes'? please clarify the question. 3. What is the input layer for the Dukepad? I think it's the udev implementation and this does pretty much the same as the current android implementation. I just want to have a stable reference to look at ;) The input driver, as we call it, is depend on the system you are running and not the application you are running. From Application prespective its all the same. So on embedded devices, like the Raspberry PI, it will be udevInput, on Windows it will be Window's Glass implementation (not Lens based), on Android it will be Android porting + Lens and so on. 4. Has anyone with a Dukepad the opportunity to test the ListView-Example? For me on Android, it doesn't scroll at all with any touches. With the automatic scrolling (from Richard sources) I get around 30fps on the Samsung Galaxy Tab 10.1. I didn't. Again if you find a problem or a bug please open a JIRA against so we will be able to track and fix it. Thanks, Assaf regards Matthias
