Just wondering how would the JavaFX WebView if you change the style from
GWT, instead from CSS file. For instance:
public static void setFxPadding(com.google.gwt.user.client.Element element)
{
element.getStyle().setProperty("FxPadding", "0px 0px 0px 22px");
}
On Wednesday, November 6, 2013 10:33:33 AM UTC-5, Michael Prentice wrote:
>
> I've posted this question to StackOverflow here:
> http://stackoverflow.com/questions/19816129/how-do-i-left-pad-a-div-in-a-javafx-webview
>
> On Tuesday, November 5, 2013 6:40:08 PM UTC-5, Michael Prentice wrote:
>>
>> Thank you for the idea about escaping the first dash. It made the CSS
>> editor in GWT Designer a bit happier (no longer red). But it didn't end up
>> fixing the issue. I tried the following without any luck as well (all
>> worked great in Chrome):
>>
>> .foo-bar-values {
>> padding: 0px 0px 0px 22px;
>> }
>>
>> .foo-bar-values {
>> margin: 0px 0px 0px 22px;
>> }
>>
>> .foo-bar-values {
>> margin-left: 22px;
>> }
>>
>> .foo-bar-values {
>> padding-left: 22px;
>> \-fx-label-padding: 0px 0px 0px 22px;
>> }
>>
>> .foo-bar-values {
>> padding-left: 22px;
>> \-fx-padding: 0px 0px 0px 22px;
>> }
>>
>> As far as migration to JavaFX, we did not see a smooth migration path
>> there. We can't run our Swing screens in a browser and we can't convert
>> everything to JavaFX in a single release. We also don't want to have half
>> of our app run in the browser and half in a Swing application. We don't use
>> Java WebStart for deployment and we aren't able to change the installation
>> of our client to require users to browse to a certain site to install the
>> application. It is pushed out Enterprise wide via Enterprise level
>> installers.
>>
>> Using web technologies (GWT) hosted in a JavaFX WebView allows for us to
>> replace a screen at a time (or more) within our current Swing application
>> without needing to completely change the deployment/installation strategy.
>> It also minimizes the end user training with each release. Eventually (2-3
>> years), we will be in a situation where we can replace the last of the
>> Swing screens and go to a completely web based solution. We are hoping that
>> Chromium runtime will be available by then so that we can switch straight
>> to it (installed as part of our app and not by the user or IT) rather than
>> having to depend on older versions of IE installed throughout the
>> Enterprise.
>>
>> *Some other info about JavaFX WebView:*
>>
>> - In order to handle Confirmation and Alert dialogs, you must
>> implement handlers for these in your WebEngine JavaFX code. It isn't hard
>> and it is quite customizable, but it doesn't come out of the box.
>> - Deploying and testing within the WebView is quite a pain. FireBug
>> Lite provides for some limited debugging, but with GWT we don't get
>> anything useful on the Script tab (Access to restricted URI denied.)
>> So debugging has to be done in DevMode in Chrome or in the WebView via
>> alert() dialogs (like debugging with printf's ages ago). This is
>> minimized
>> by the fact that so far our only code that would need to be debugged in
>> the
>> WebView is the navigation code that talks between GWT and Swing via JSNI
>> and JavaFX.
>>
>>
>> Michael Prentice
>> GDG Space Coast
>> http://gdgspacecoast.org
>>
>> On Tuesday, November 5, 2013 6:06:53 PM UTC-5, Oliver Krylow wrote:
>>>
>>> If the CSS snippet you have shown happens to reside in a uibinder file,
>>> try escaping prefixed rules with a \ .
>>>
>>> \-fx-label-padding ...
>>>
>>> The CSS parser of gwt used to have trouble with those .
>>>
>>> Thank you for reporting your experience with the javafx webview. It has
>>> been an interesting read.
>>>
>>> Could you explain your decision to migrate to web technologies instead
>>> of migrating to javafx and deploying it in the browser
>>> http://docs.oracle.com/javafx/2/deployment/deployment_toolkit.htm ?
>>> On Nov 5, 2013 10:44 PM, "Michael Prentice" <spla...@gmail.com> wrote:
>>>
>>>> I've been working on a project for the last few months which involves
>>>> creating new screens for our Swing application. We wanted to start moving
>>>> towards a web based interface, but we cannot re-do hundreds of screens in
>>>> a
>>>> single release/year. So after doing some testing and being satisfied with
>>>> the HTML5 / CSS 2.1 support in the JavaFX 2.2 Webview, we decided that
>>>> this
>>>> was a possible migration path. I am currently working on the first leg of
>>>> this path and things have gone quite well so far. I chose GWT to build the
>>>> front-end of the app due to our team's experience with WindowBuilder/Swing
>>>> and it's focus on Enterprise web applications. Our application is a
>>>> complex
>>>> Enterprise app that must be maintained over many years by different
>>>> people.
>>>>
>>>> *Here are some of the results and issues:*
>>>>
>>>> *Success:*
>>>>
>>>> - General GWT development has been very productive (learning and
>>>> architecting the app took considerable time).
>>>> - Performance running in the WebView has been acceptable on
>>>> machines with decent GPUs which includes all of our client machines (8
>>>> MB
>>>> video card servers don't do well).
>>>> - We have been able to implement communication to/from
>>>> GWT<->JavaScript<->JavaFX<->Swing without any major issues and with
>>>> very
>>>> minimal code (some simple JSNI and JSON serialization).
>>>> - Performance of passing data and opening/closing windows between
>>>> GWT<->...<->Swing has been very good. Note that we aren't passing
>>>> large data sets over 1 MB.
>>>> - The new GWT app fits into our Swing application and feels very
>>>> nearly 'just like another screen' due to GWT's out of the box styling.
>>>> - GWT's out of the box styling has worked great and impressed our
>>>> customers without us having to put forth much effort.
>>>>
>>>>
>>>> *Issues:*
>>>>
>>>> - The JavaFX WebView does not quite behave like other browsers. It
>>>> uses the Safari (chrome, webkit) user agent.
>>>> - Drop downs (ListBox) have rounded edges (unlike Chrome) which we
>>>> don't really like.
>>>> - Drop downs (select elements) are not very usable in the WebView.
>>>> They can't be styled. They show as many elements as fit on the window
>>>> (extending beyond the borders of the app). Scrolling these drops downs
>>>> with
>>>> the mouse wheel isn't supported until JavaFX 8. I've opened some bugs
>>>> for
>>>> these issues with Oracle.
>>>> - Buttons get rounded edges if we override the default GWT style.
>>>> - Alignment between Chrome and the WebView does not match up for
>>>> some elements. This causes a number of layout issues.
>>>> - JavaFX WebView does not support CSS3 and has some of its own
>>>> rules with vendor extensions of "-fx-". This includes things like
>>>> "JavaFX CSS does not support CSS layout properties such as *float*,
>>>> *position*, *overflow*, and *width*."
>>>> - "CSS *padding *and *margins *properties are supported on some"
>>>> objects. I tried to use a "padding-left: 22px" today which worked fine
>>>> in
>>>> Chrome but had no effect on the same Label in the WebView.
>>>> - Asking Oracle for fixes or enhancements appears to involve a
>>>> significantly long wait, even if quickly approved, you may not see your
>>>> issue resolved for 6-18+ months. It seems to be possible to fix issues
>>>> yourself via the OpenJDK project, but it appears to require significant
>>>> time and effort just to get setup/approved to do this.
>>>>
>>>> Now so far none of these issues have been a complete show stopper. But
>>>> after running into the padding issue today and researching, it seemed like
>>>> this might be the time to at least attempt to request (I know it is likely
>>>> not interesting or high priority to most people) a user agent for the
>>>> JavaFX WebView since it appears to need special handling to work properly
>>>> (which appears to be one main goals of GWT - to eliminate the troubles of
>>>> supporting multiple browsers).
>>>>
>>>> I found out that JavaFX has their own CSS rules including a special "
>>>> -fx-label-padding" rule. There does not appear to be anything like
>>>> padding-left or padding-top, so you need to specify all 4 ("if a set
>>>> of four padding values is specified, they are used for the top, right,
>>>> bottom, and left edges of the region, in that order."). I added this
>>>> to my existing rule which already has the "padding-left: 22px" rule.
>>>>
>>>> .foo-bar-values {
>>>> padding-left: 22px;
>>>> -fx-label-padding: 0px 0px 0px 22px;
>>>> }
>>>>
>>>> Chrome handled things fine in DevMode (ignored the unknown rule with a
>>>> warning). But when I loaded up the WebView version, it had no effect. I
>>>> thought that this was quite odd, so I debugged it with FireBug Lite and
>>>> apparently that specific CSS rule isn't there in the CSS on the page. I
>>>> checked my .css file in the .WAR and it is there. Strange...
>>>>
>>>> For more information on how JavaFX WebView handles CSS and defines its
>>>> own CSS rules see here:
>>>> http://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html
>>>>
>>>> Has anyone else looked into this at all?
>>>>
>>>> Does anyone have any pointers for making GWT/JavaFX play nice together
>>>> for these 'vendor' extended CSS rules?
>>>>
>>>>
>>>> Thank you,
>>>>
>>>> Michael Prentice
>>>> GDG Space Coast
>>>> http://gdgspacecoast.org
>>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
