search

Insubstantial / insubstantial

Swing look-and-feel library and assorted widgets
193 stars 57 forks source link

Added RibbonFactory and Decoupled JFrame from JRibbon #22

Closed erichschroeter closed 12 years ago

erichschroeter commented 13 years ago

Quite a few changes (somewhat significant I think), but I've ran the JUnit tests and they pass.

RibbonFactory

The RibbonFactory as explained in the previous pull request simply implements a builder pattern saving the user from writing a lot of code. I haven't decided the best way to go about supporting the gallery though; it may need a factory for itself (any thoughts?).

Decoupling JFrame and JRibbon

I didn't see the need to keep JRibbon and JRibbonFrame coupled as there were only a few methods in JRibbon that actually reference JRibbonFrame. I chose to mark the constructor and methods as deprecated in order to give some releases between dropping the support completely (I suppose it's up to you to fully deprecate it though).

A major reason I wanted to decouple the two classes was because I didn't know how else to nicely allow an application icon to be used on the JRibbon when you don't use the JRibbonFrame class. I am currently working on an application which cannot use the JRibbonFrame as the framework I'm using creates it for me (I'm using JIDE JDAF). I didn't/don't understand why the two classes were coupled in the first place; perhaps you have an explanation. The decoupling is essentially solved by simply deprecating the JRibbon(JFrame) constructor and getRibbonFrame() and eventually just removing those.

Application Icon

A reference to the ribbon's icon is stored in the RibbonUI abstract class, thus giving the ribbon a way to get the application icon without being coupled to a JRibbonFrame.

erichschroeter commented 12 years ago

I'm planning on changing the name of RibbonFactory to RibbonBuilder, since it isn't really a factory pattern but rather the builder pattern.

shemnon commented 12 years ago

how soon can you have this ready? I'de like to push a build durring JavaONe

shemnon commented 12 years ago

As it stands this will be rejected because it breaks substance....

C:\git\github.com\insubstantial\insubstantial\substance-flamingo\src\main\java\org\pushingpixels\substance\flamingo\ribbon\ui\SubstanceRibbonApplicationMenuButtonUI.java:58: cannot find symbol symbol : constructor BasicRibbonApplicationMenuButtonUI() location: class org.pushingpixels.flamingo.internal.ui.ribbon.appmenu.BasicRibbonApplicationMenuButtonUI public class SubstanceRibbonApplicationMenuButtonUI extends ^ 1 error

The symbol it cannot find is the BasicRibbonApplicationMenuButtonUI default constructor.

Should be a simple fix (I hope).

erichschroeter commented 12 years ago

Ok, I'll look into it, but I can't guarantee it will be fast. If you want to push a release out, I'd say forget about my pull request for now.

shemnon commented 12 years ago

What I may do this weekend is commit the "plumbing" changes needed to enable the builder, that way we can spin out a different jar that has just the builder pre 7.1. On Sep 30, 2011 7:28 PM, "erichschroeter" < reply@reply.github.com> wrote:

Ok, I'll look into it, but I can't guarantee it will be fast. If you want to push a release out, I'd say forget about my pull request for now.

Reply to this email directly or view it on GitHub:

https://github.com/Insubstantial/insubstantial/pull/22#issuecomment-2255287