swpalmer at gmail.com
Mon Sep 10 13:34:30 PDT 2012
On 2012-09-10, at 4:27 PM, Tom Schindl <tom.schindl at bestsolution.at> wrote:
> Am 10.09.12 21:52, schrieb Scott Palmer:
>> On 2012-09-10, at 3:25 PM, Greg Brown <greg.x.brown at oracle.com> wrote:
>>>> See my response to Greg. I don't currently process SVG at runtime. I just think it makes the API more generic if that case is supported better. I don't see why the current FXMLLoader should be limited the way it currently is.
>>> I'm sorry - I don't understand what limitation you are referring to.
>>> Keep in mind that FXMLLoader's sole purpose is loading FXML. It doesn't know about (and thus can't be optimized for loading) any other data format such as SVG. As I suggested earlier - if you want to efficiently load SVG, use an SVG-specific loader.
>> I'm referring to the way it accepts the FXML input only via a URL and not any other form. Ultimately all it wants is XML data and so I think it would be reasonable to provide an interface that accepts data in a more general form. If it could take an InputStream for example, then FXML that was machine generated wouldn't need to go to an intermediate file in order to load.
>> This isn't specific to SVG to FXML conversion, but that is a good example case. I don't have an SVG loader for JavaFX, and didn't find anything with a Google search, but I do know of two SVG to FXML convertors:
> The reason I'd advise against doing this at runtime is that parsing and
> converting SVG to FXML is not as simple as it might look like.
I understand, but in my case if it's going to fail it's going to fail. The operator won't have the skills to fix it and it would only be an in-house tool for the artist to preview some icons in our UI.
Sorry I missed the point of you telling me to use an FXMLLoader instance. Got it all straight in my head now. Sorry for the noise.
More information about the openjfx-dev