[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    RT Repo Structure, and tests repo
From:       steve.x.northover () oracle ! com (steve ! x ! northover at oracle ! com)
Date:       2011-12-21 20:45:39
Message-ID: 4EF24573.1070405 () oracle ! com
[Download RAW message or body]

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".

Steve

On 21/12/2011 2:19 PM, Daniel Zwolenski wrote:
> If it's not too hard a change, I'd vote for 'core' being called 'util' (or \
> 'common', 'general', 'ancillary', 'support', etc). Its just as generic a catch-all \
> but 'core' to me implies the foundation on which things are built (for me the core \
> of a ui kit would be the window/rendering stuff), whereas this one is more like the \
> ancillary utilities that are common to the rest of the framework. JavaScript for \
> example is used in a couple of places but I personally wouldn't call it a 'core' \
> component. 
> 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):
> > 
> > javafx-charts
> > javafx.scene.chart
> > 
> > javafx-concurrent
> > javafx.concurrent
> > 
> > javafx-core
> > javafx.beans
> > javafx.beans.binding
> > javafx.beans.property
> > javafx.beans.value
> > javafx.collections
> > javafx.event
> > javafx.util
> > netscape.javascript
> > 
> > javafx-fxml
> > javafx.fxml
> > 
> > javafx-graphics
> > javafx.animation
> > javafx.application
> > javafx.builder.processor
> > javafx.event
> > javafx.geometry
> > javafx.scene
> > javafx.scene.effect
> > javafx.scene.image
> > javafx.scene.input
> > javafx.scene.paint
> > javafx.scene.shape
> > javafx.scene.text
> > javafx.scene.transform
> > javafx.stage
> > 
> > javafx-layout
> > javafx.scene.layout
> > 
> > javafx-media
> > javafx.scene.media
> > 
> > javafx-swing
> > javafx.embed.swing
> > 
> > javafx-swt
> > javafx.embed.swt
> > 
> > javafx-web
> > javafx.scene.web
> > 
> > javafx-controls
> > com.javafx.preview.control
> > javafx.scene.chart
> > javafx.scene.control
> > javafx.scene.control.cell
> > 
> > Although graphics could be broken down further and things like animation \
> > separated out, I considered that this would make too many modules. 
> > Steve
> > 
> > On 21/12/2011 4:23 AM, Michael Heinrichs wrote:
> > > Hi,
> > > 
> > > 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
> > > 
> > > > Richard


[prev in list] [next in list] [prev in thread] [next in thread]