Integration of CSSFX into ScenicView

#6 Merged
Repository
mcfoggy
Branch
cssfx-demo-integration
Repository
scenicview
Branch
cssfx-demo-integration
Author
  1. Matthieu Brouillard
Reviewers
Description

Jonathan & others,

this a request in order to publish a first integration of CSSFX into ScenicView. Concretely it contains:

  • a slightly adapted version of CSSFX
  • a new Tab in scenic view that reports the detected CSS and the mapped file
  • an integration into the remote application to monitor CSS used in scenes & nodes

This version does not allow to change the mapping rules of the CSSFX integration, so basically it uses the default settings of CSSFX:

  • maven layout recognition
  • gradle layout recognition
  • execution from netbeans on maven projects
  • ...

I have pushed the PR into a branch to not disturb the master in case of needed modifications.

Matthieu

Comments (10)

  1. Jonathan Giles

    Would you be happy to move out of org.fxmisc and more closely integrate with scenic view, perhaps by placing the code in a package like org.scenicview.view.cssfx or org.scenicview.view.tabs.cssfx? This simplifies the package hierarchy somewhat (because very soon I'm likely to remove the org.fxconnector package and move that under org.scenicview (because I don't want to keep paying for fxconnector.org domain name) :-)

  2. Matthieu Brouillard author

    Jonathan, I refactored cssfx stuff to move it under org.scenicview.extensions.cssfx. The idea behind is to introduce some convention for ScenicView to receive more additions/plugins in the future.

    This could turn into:

    • org.scenicview.extensions.EXTNAME.module : contains the stuff that will be used remotely in injected applications
    • org.scenicview.extensions.EXTNAME.ui : contains the related stuff that will be used in ScenicView app to enrich the base ui (new tab, new menu, ...).

    I think ScenicView would benefit also in some refactoring in order to restructure a little bit the app so that additions become less intrusive and easy to plug (use observable, API for ui plugins, command pattern for remote controlling, ...).

    If you agree I'd open an issue so that we can expose and discuss such ideas.

  3. Matthieu Brouillard author

    I applied the changes you requested.

    For the functional interfaces, I am not sure that using the standard "functions" bring more readibility (especially for the consumer), but they are there also.

    For the formatting changes, sorry I performed a "format action" from my IDE on the whole file.

    1. Jonathan Giles

      Sorry, I've been super busy over the weekend and run out of time to look at this.

      Regarding the functional interfaces - I still think that there is no need for the duplicates in this pull request. The argument for readability is not a strong one - no one will be using these APIs other than us developers, and even then, we've done exactly the same thing in JavaFX - we use the generic Java 8 interfaces wherever possible, rather than custom interfaces for each use case.