RT Repo Structure, and tests repo
steve.x.northover at oracle.com
steve.x.northover at oracle.com
Wed Dec 21 12:45:39 PST 2011
I do understand the thinking that says, "core of a ui kit includes
rendering". This is the view of "core" as something that should be
consumed from the outside rather than the view that "core" is something
internal to FX, the "core" needed to bootstrap the toolkit.
Charts was listed twice because basic functionality is part of
controls. This function is build upon by the charts "module".
On 21/12/2011 2:19 PM, Daniel Zwolenski wrote:
> This would likely help the problem of people wrongly raising bugs against 'core'. I definitely got that wrong on a number of occasions (sorry Michael).
> You have charts listed twice. Is the control one correct or a typo?
> Otherwise it reads nicely from my side of the fence. Good balance between modularisation and practicality.
> On 22/12/2011, at 4:53 AM, steve.x.northover at oracle.com wrote:
>> Hi folks,
>> I realize that "core" is a pretty meaningless name but it is in common use inside and outside of FX.
>> It's quite true that we could break FX into many more smaller modules or larger ones (we are using the term "modules" here, but what we are talking about is a hierarchical structure of functional units, each building on the other). Like Richard said, FX is quite modular but this is not captured anywhere (yet). Having FX organized this way sooner rather than later makes sense. The hierarchy means that at some point in the future, it might be possible to run with a subset, for example a headless mode.
>> This breakdown seemed reasonable to me (ignore the javafx- prefix):
>> Although graphics could be broken down further and things like animation separated out, I considered that this would make too many modules.
>> On 21/12/2011 4:23 AM, Michael Heinrichs wrote:
>>> On 21.12.2011, at 07:53, Richard Bair wrote:
>>>>>> charts is, well, charts :-)
>>>>>> concurrent: the javafx.concurrent package (Worker, Task, etc)
>>>>>> controls: controls
>>>>>> core: javafx.util, javafx.beans, javafx.collections, etc
>>>>> We definitely want these all as one? I always get a little suspicious when something is called 'core' or the like. It's a bit of a catch all.
>>>> They will be broken down into sub modules, so core would have javafx-beans, javafx-common, etc as sub modules. I guess by this logic concurrent could be a sub module of core as well... I'm happy to hear other proposals on how to break it up.
>>> I think, it is ok to have javafx.beans (which could be split in two sub-modules properties and bindings btw.) and javafx-collections close together. Often major design choices in one area affected the other. But the name is really bad. "Core" does not mean anything to people unfamiliar with JavaFX. I can see that in JIRA, where I get all kinds of bugs and feature requests linked to the "Core Libraries", which in fact are just properties, bindings, and collections.
>>>>>> fxml: fxml
>>>>>> graphics: CSS, scene graph, prism. Maybe glass should actually be a different top level module and not a sub-module of graphics
>>>>>> layout: javafx.scene.layout
>>>>>> media: javafx.scene.media
>>>>>> swing: javafx.ext.swing
>>>>>> swt: javafx.ext.swt
>>>>>> web: web view
>>>>> Where do animations live?
>>>> Graphics, I think.
>>> Mmmh, the animation API is completely independent from the rest in Graphics. You can easily use it in a program that does not use the SceneGraph at all. I think it should remain separated. Only the graphic-specific transitions (FadeTransition etc.) should remain in the graphics repo.
>>> - Michael
More information about the openjfx-dev