[FLAMINGO-8] ClassCastException when pressing space on JCommandButton Created: 24/Jul/08  Updated: 31/Jul/08  Resolved: 31/Jul/08

Status: Closed
Project: flamingo
Component/s: common components
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: flynnk Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 8

 Description   

Anytime the spacebar is pressed on any JCommandButton, the exception below is
thrown. Looks like the key bindings where not updated when JCommandButton no
longer descended from AbstractButton (this did not happen until after that change).

Set as P1 since it means that pressing the space bar in the app effectively
crashes it.

Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:
org.jvnet.flamingo.common.JCommandButton cannot be cast to
javax.swing.AbstractButton
at
javax.swing.plaf.basic.BasicButtonListener$Actions.actionPerformed(BasicButtonListener.java:275)
at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1636)
at javax.swing.JComponent.processKeyBinding(JComponent.java:2849)
at javax.swing.JComponent.processKeyBindings(JComponent.java:2884)
at javax.swing.JComponent.processKeyEvent(JComponent.java:2812)
at java.awt.Component.processEvent(Component.java:5818)
at java.awt.Container.processEvent(Container.java:2058)
at java.awt.Component.dispatchEventImpl(Component.java:4413)
at java.awt.Container.dispatchEventImpl(Container.java:2116)
at java.awt.Component.dispatchEvent(Component.java:4243)
at
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1848)
at
java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:697)
at
java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:962)
at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:834)
at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:661)
at java.awt.Component.dispatchEventImpl(Component.java:4285)
at java.awt.Container.dispatchEventImpl(Container.java:2116)
at java.awt.Window.dispatchEventImpl(Window.java:2440)
at java.awt.Component.dispatchEvent(Component.java:4243)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)



 Comments   
Comment by kirillcool [ 24/Jul/08 ]

This should be fixed in the latest 3.1dev drop. The new
utest.common.CommandButtonTestCase is the first version of unit testing the UI
interaction aspects of command button component.

Thanks
Kirill

Comment by flynnk [ 31/Jul/08 ]

Working now. Marking as closed.





[FLAMINGO-11] JCommandToggleButton groups not working for single selection Created: 02/Aug/08  Updated: 02/Aug/08  Resolved: 02/Aug/08

Status: Closed
Project: flamingo
Component/s: common components
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: flynnk Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11

 Description   

The easiest way to reproduce this bug is to run the Flamingo Ribbon
demonstration application and select the various items in the quick styles task
band; more than one can be selected. This behavior is inconsistent with the
documentation and what one would expect from toggle buttons.

The CommandButtonGroup class does not call setGroup() on the action model from
the JCommandToggleButton, so the underlying model never makes the callback to
the group to cause the group to then deselect the other buttons and enforce the
single selection.

From my examination of the code, it looks like to get this functionality and
continue to use the JToggleButton.ToggleButtonModel as the underlying model for
the JCommandToggleButton, CommandButtonGroup would have to extend ButtonGroup,
but button group requires the buttons to extend AbstractButton. I think you are
going to have to reimplement the ToggleButtonModel as well since you no longer
want the CommandButtons to extend AbstractButton.

Workaround:

There is a good workaround to this issue, which lowers the priority a bit. In
the action listener for the toggle button, you can call the underlying button
group directly to set the selected button. For example, in a JRibbonBand, you
can call:

ribbonBand.setSelectedRibbonGalleryButton("GALLERY_NAME", button);

Might be a good idea to add this workaround to the example applications until
the primary issue is fixed (I checked there to see if this was called to see if
I was screwing up; others might as well...)



 Comments   
Comment by kirillcool [ 02/Aug/08 ]

Should be fixed in the latest 3.1dev drop.

Thanks
Kirill

Comment by flynnk [ 02/Aug/08 ]

Confirm fix in latest dev drop.





[FLAMINGO-12] Tooltips in popup gallery appear behing popup Created: 02/Aug/08  Updated: 02/Aug/08  Resolved: 02/Aug/08

Status: Closed
Project: flamingo
Component/s: ribbon
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: flynnk Assignee: kirillcool
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File tooltipbug.jpg    
Issuezilla Id: 12

 Description   

In a ribbon, with a popup gallery displayed, tooltips for the
JCommandToggleButtons appear behind the popup in the part of the popup that
extends below the ribbon. In the part of the popup on top of the ribbon, the
tooltips appear in the right place.

This is much easier explained in the screenshot I'm about to attach.



 Comments   
Comment by flynnk [ 02/Aug/08 ]

Created an attachment (id=3)
Image of screen with tooltip bug

Comment by kirillcool [ 02/Aug/08 ]

At the present moment, the solution would be to force heavyweight tooltips with
ToolTipManager.sharedInstance().setLightWeightPopupEnabled(false). I do have
long term plans to add "super tooltips" [1] to command buttons. Marking as
WONTFIX since the setToolTipText on AbstractCommandButton will eventually be
deprecated and forwarded to using rich tooltips.

Thanks
Kirill

[1] http://blogs.msdn.com/jensenh/archive/2005/12/02/499371.aspx

Comment by flynnk [ 02/Aug/08 ]

I've reworked my GUI to use a JCommandButton with a drop down menu; the zone
names (what would appear on the tooltip) are mainly text anyway so I suspect
this will be clearer to my users. So I'll live.

Super tooltips would be really cool; I'm all for that. I read the linked
article and took a look at the implementation in Word, and I think that's a much
better approach to online help than others I've seen. Just my $0.02.

Do you have a timetable for implementing super tooltips (3.1 or 3.2?)? This is
probably a better question for your blog than the issue tracker...





[FLAMINGO-10] StringIndexOutOfBoundsException with empty JRibbonBand Created: 31/Jul/08  Updated: 03/Aug/08  Resolved: 03/Aug/08

Status: Closed
Project: flamingo
Component/s: ribbon
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Trivial
Reporter: flynnk Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10

 Description   

The following exception occurs when using an empty JRibbonBand. While empty
JRibbonBands aren't particularly useful (hence P5), this is likely to occur
during development (using them as placeholders for work to come shortly).

Exception in thread "AWT-EventQueue-0"
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1938)
at
org.jvnet.flamingo.ribbon.ui.BasicRibbonBandUI.paintBandTitle(BasicRibbonBandUI.java:644)
at
org.jvnet.flamingo.ribbon.ui.BasicRibbonBandUI.paint(BasicRibbonBandUI.java:613)
at javax.swing.plaf.ComponentUI.update(ComponentUI.java:143)
at
org.jvnet.flamingo.ribbon.ui.BasicRibbonBandUI.update(BasicRibbonBandUI.java:583)
at javax.swing.JComponent.paintComponent(JComponent.java:763)
at javax.swing.JComponent.paint(JComponent.java:1027)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:564)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5129)
at
javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:285)
at javax.swing.RepaintManager.paint(RepaintManager.java:1128)
at javax.swing.JComponent.paint(JComponent.java:1013)
at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:21)
at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:60)
at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:97)
at java.awt.Container.paint(Container.java:1797)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:734)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679)
at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659)
at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)



 Comments   
Comment by kirillcool [ 31/Jul/08 ]

Should be fixed in the latest 3.1dev drop.

Thanks
Kirill

Comment by flynnk [ 02/Aug/08 ]

The exception no longer occurs under the default (Metal) L&F, but still occurs
when using Substance-Flamingo. (I could file a bug in that project, but
probably easier to just note it here--let me know if you prefer different.)

Furthermore, the ribbon band now shows up as two pixels wide. It might be nicer
for it to show up as having the width of the specified title and be empty.
Principle of least surprise, pretty much.

Comment by kirillcool [ 02/Aug/08 ]

Reopening to fix for Substance-Flamingo and provide enough width to show the title.

Comment by kirillcool [ 03/Aug/08 ]

Should be addressed in the latest 3.1dev drop of the core Flamingo library -
respecting the title string of an empty ribbon band. This also fixes the
exception under Substance.

Thanks
Kirill

Comment by flynnk [ 03/Aug/08 ]

Do I need to update to the latest Substance-Flamingo dev drop?

Comment by flynnk [ 03/Aug/08 ]

Never mind the previous comment.

Closing, as I confirm it is fixed. I appreciate this one--I know it's not a big
deal, but this exception drove me crazy for about 20 minutes as I tried to
figure out exactly what I was doing wrong...





[FLAMINGO-65] KeyTip not visible in popup of a collapsed band Created: 21/Dec/09  Updated: 21/Dec/09  Resolved: 21/Dec/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: dhennig Assignee: kirillcool
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 65

 Description   

When a ribbon band collapses, a special KeyTip is used to
open a popup with its content. This KeyTip can be set with
setCollapsedStateKeyTip. That works fine. But in the popup,
the KeyTips are not shown. They still work, but you have to
guess them. This looks like a bug to me.

You can reproduce this with the Ribbon test webstart. In
"Page Layout" (P), the "Clipboard" has "Paste" (V). In
normal state, pressing Alt,P,V works. When you resize the
windows to a small size, where the "Clipboard" changes to
collapsed state, you can see (ZC) for the "Clipboard". The
popup opens, but no KeyTips are shown. But Alt+P+ZC+V works.



 Comments   
Comment by kirillcool [ 21/Dec/09 ]

Key tips on components in popups are not supported by Flamingo ribbon. This is
mainly due to the current implementation that paints the key tips in a special
layer in the overall JRibbonFrame. The popups live outside the main frame, and
would require special handling. Especially challenging is the case when the key
tips are painted outside the popup bounds (as they do in Office 2007).

Marking this as WONTFIX since i do not have resources to do this myself. You're
more than welcome to explore how the current support can be extended to popup
content.

Thanks
Kirill





[FLAMINGO-46] Change Title of a RibbonTask Created: 28/May/09  Updated: 28/May/09  Resolved: 28/May/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: pd Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Attachments: Java Source File JRibbonTest.java    
Issuezilla Id: 46

 Description   

to reproduce the error click the click me! button. afterwards the flamingo
component is frozzen until the window get's a repaint by minimizing and
maximizing ...

Sounds like a bug to me. Please create a new issue in the project issue tracker
and attach a small (<100 lines) test application that shows this problem.

Thanks
Kirill

--------------------------------------------------------------------------------
From: Peter Dahm <pd@itsd-consulting.de>
To: users@flamingo.dev.java.net
Sent: Wednesday, May 27, 2009 4:05:00 AM
Subject: Change Title of a RibbonTask

Hi,

I want to change the title of a RibbonTask at runtime. If I do so, the
RibbonTask disappears and the complete Ribbon does not work any more.

In the source documentation is a hint to use JRibbon#setTaskTitle instead
the setTitle Method in RibbonTask. But this Method is missing.

Does someone has a solution for this problem ?

Peter



 Comments   
Comment by pd [ 28/May/09 ]

Created an attachment (id=24)
example to reproduce the error

Comment by kirillcool [ 28/May/09 ]

The 4.1_01 release addresses this issue.

Note that you cannot use the same ribbon band in multiple ribbon tasks, and the
code now throws an IllegalArgumentException when you try to do so. You'll have
to tweak your app to use different bands for different tasks.

Thanks
Kirill





[FLAMINGO-23] Layout of ribbon could be better Created: 06/Nov/08  Updated: 13/Nov/08  Resolved: 13/Nov/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: mattnathan Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File LayoutProblems.png     PNG File ResizeBug.png    
Issuezilla Id: 23

 Description   

The layout of the buttons and controls in the ribbon is both inconsistent and in
some cases incorrect for ribbons of the same size.

I've attached a screen shot of three ribbons all at exactly the same size, all
showing a different layout. Also if you change the look and feel to metal and
adjust to the shown size then change the height you will see constant re-layout.



 Comments   
Comment by mattnathan [ 06/Nov/08 ]

Created an attachment (id=7)
Shows layout of ribbons of the same size

Comment by kirillcool [ 06/Nov/08 ]

Indeed, this is one of the areas where the current implementation needs to be
much improved before the final 4.0 release. This work is planned to include
custom layout policies similar to what is available in the ribbon components
shown at PDC 08.

Thanks
Kirill

Comment by mattnathan [ 06/Nov/08 ]

Good to hear you're already on top of it

Comment by kirillcool [ 12/Nov/08 ]

Should be much better now. See [1] for more details.

Thanks
Kirill

[1] http://www.pushing-pixels.org/?p=816

Comment by mattnathan [ 12/Nov/08 ]

Created an attachment (id=8)
Flickering of resize policy

Comment by mattnathan [ 12/Nov/08 ]

Good work on the resize policy re-factoring, unfortunately the resizing still
'flickers' at certain sizes (tested with the demo on your blog).

See attached screen shots of demo on windows Vista with Windows look and feel
showing ribbon at three different sizes alternating between layouts.

Comment by kirillcool [ 12/Nov/08 ]

Thanks for reporting this scenario. I will look into this.

Kirill

Comment by kirillcool [ 12/Nov/08 ]

Interesting case. Should be fixed in the latest 4.0dev drop.

Thanks for reporting this issue and attaching the screenshots. They have been
very helpful in pinpointing the problem.
Kirill

Comment by mattnathan [ 13/Nov/08 ]

Looks good to me, haven't tested on vista yet but looks good under the other
look and feels

Comment by kirillcool [ 13/Nov/08 ]

Thanks for verifying the fix.

Kirill





[FLAMINGO-85] Dealock on JRibbon Created: 03/Nov/10  Updated: 04/Nov/10  Resolved: 04/Nov/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: deleted_user Assignee: kirillcool
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 85

 Description   

The method getTaskbarComponents has, as of version 5.0, the following signature:

public synchronized List<Component> getTaskbarComponents();

making this method synchronized might cause a deadlock. I'll post the stack
trace once I get it reproduced again.

The suggested fix is to remove the synchronized keyword or use reentrant locks
to synchronize this class.



 Comments   
Comment by kirillcool [ 03/Nov/10 ]

As long as any access to UI elements is done on the UI thread, you should not
see a deadlock.

Comment by deleted_user [ 03/Nov/10 ]

You are correct I made one call outside the UI thread by mistake.

Sorry for the waste of time, you can close it.

Thanks!

Comment by kirillcool [ 04/Nov/10 ]

Access to UI components must be done on the UI thread.





[FLAMINGO-80] Setting the application icon is not working Created: 02/Aug/10  Updated: 03/Aug/10  Resolved: 03/Aug/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: nitram1 Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File flamingo80.diff     Text File flamingo80.diff     Zip Archive flamingoBug.zip    
Issuezilla Id: 80

 Description   

I found a bug while setting the application icon of the JRibbonFrame. The
problem is that the working thread that is supposed to load the icon stalls
while the
icon is load just fine.

The problem occures in the thread created in
org.pushingpixels.flamingo.api.ribbon.JRibbonFrame.setApplicationIcon(ResizableIcon).
The icon finishes loading after the "isLoading()" query and before the
AsynchronousLoadListener is added.

My proposal is that adding the listener automatically triggers a isLoading query
and in case this returns false a completed is fired using the listener that was
just added.

This can be done in the method:
org.pushingpixels.flamingo.api.common.icon.ImageWrapperIcon.addAsynchronousLoadListener(AsynchronousLoadListener)
that should be changed from:

public void addAsynchronousLoadListener(AsynchronousLoadListener l) {
this.listenerList.add(AsynchronousLoadListener.class, l);
}

to:

public void addAsynchronousLoadListener(AsynchronousLoadListener l) {
this.listenerList.add(AsynchronousLoadListener.class, l);
if (this.isLoading())

{ fireAsyncCompleted(true); }

}



 Comments   
Comment by nitram1 [ 02/Aug/10 ]

I tried my solution against the latest source state in the SVN.
Sadly it not working at all.

I'm looking for the real reason.

Comment by kirillcool [ 02/Aug/10 ]

I will need to see a small (<100 lines) test application that reproduces this
issue under the latest 5.0RC drop of the library. Anything above 100 lines will
be postponed and not fixed in time for the final 5.0 release.

Thanks
Kirill

Comment by nitram1 [ 02/Aug/10 ]

Created an attachment (id=39)
Java Project to rebuild the Bug

Comment by nitram1 [ 02/Aug/10 ]

The test application is attached to this post.

How ever I found the real reason for the problem. The
java.util.concurrent.ThreadPoolExecutor that maintails the
javax.swing.SwingWorker is for some reason set to corePoolSize 1 for me.
According to the source of Java 1.6 b20 it should be this way for everyone. How
ever while setting this icon a first SwingWorker is created to load the image
that are needed. This Worker issues the ResizeableIcon to prepare the image in
the sizes that are needed for the display. And to prepare this image the
ResizeableIcon tries to start another SwingWorker. That can't be started because
only one of these workers can run at the same time and the first can't finish
its task before the second is not finished. And there we go the classic
concurrency bug.

I have yet no idea how to fix this efficient.

Comment by nitram1 [ 03/Aug/10 ]

Created an attachment (id=40)
Proposed Solution

Comment by nitram1 [ 03/Aug/10 ]

The problem is mainly caused by the point that setting the images is run in 2
additional threads. The first thread is a normal own created thread, the second
is a swing worker. There is no real point in using 2 threads at this point,
since the first created thread quits after the new swing worker is started
anyway. So no reason why it shouldn't do the work itself.

My proposal is the remove the swing worker and have the first thread doing the
whole job. The diff file will put the solution in place. Its tested and working
just fine.

Regards,
Nitram

Comment by kirillcool [ 03/Aug/10 ]

Can you attach a diff file that does not remove the copyright notice and does
not change the formatting of the entire class?

Thanks
Kirill

Comment by nitram1 [ 03/Aug/10 ]

Created an attachment (id=41)
Solution - Second try

Comment by nitram1 [ 03/Aug/10 ]

Sorry... I underestimated the ability of Eclipse to screw a entire source file
in no time...

Comment by kirillcool [ 03/Aug/10 ]

I did a slightly different change, wrapping the UI calls with a
SwingUtilities.invokeLater. Should be part of the latest 5.0RC drop.

Thanks
Kirill





[FLAMINGO-76] Missing the ability to mix CommandButton with regular Swing components Created: 06/Jul/10  Updated: 07/Jul/10  Resolved: 07/Jul/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: New Feature Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File WordComboBoxAndActionButton.JPG    
Issuezilla Id: 76

 Description   

The ability to mix CommandButtons within the same band and the same group is
missing.
Right now if you want to add a CommandButton in it's medium or small size,
along side some Swing components you'll have to start a new group add the
commandbutton and then restart a new group to resume adding more swing
components. This ends up taking to much space on the band and also doesn't look
good.

This functionality is available in office2007 - see attached image
<WordComboBoxAndActionButton.JPG>



 Comments   
Comment by dukke [ 06/Jul/10 ]

Created an attachment (id=34)
CommandButton and Combobox in same group

Comment by kirillcool [ 07/Jul/10 ]

This is unlikely to happen. The current APIs do not provide any guarantee on the
actual displayed order of the controls. If you add a MEDIUM button and then a
BIG button (priority-wise), the second button will be shown before the first.
Also, command buttons can change the display state based on how much space is
available.

Mixing wrapped components and command buttons will introduce much more rigidity
into the implementation, and this is something that i do not want to see there.
My best suggestion would be to reorganize the controls to fit into the current
capabilities of the ribbon APIs.





[FLAMINGO-77] Multi Column component cutoff Created: 23/Jul/10  Updated: 23/Jul/10  Resolved: 23/Jul/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Archive File forms_rt.jar     Java Source File MultiColumnComponentCutoff2.java     Java Source File PropertyPicker.java    
Issuezilla Id: 77

 Description   

When adding a JPanel which has two components as a RibbonComponent it gets cut off.

The test case follows.
It has a dependency on a Intellij (which will be attached) library because it
uses a layout manager from it.



 Comments   
Comment by dukke [ 23/Jul/10 ]

Created an attachment (id=35)
test case

Comment by dukke [ 23/Jul/10 ]

Created an attachment (id=36)
intellij library

Comment by kirillcool [ 23/Jul/10 ]

What is PropertyPicker?

Comment by dukke [ 23/Jul/10 ]

Created an attachment (id=38)
Forgot to attach this.. (part of the test case)

Comment by kirillcool [ 23/Jul/10 ]

Horizontal cutoff should be fixed in the latest 5.0RC drop. Vertical cutoff is
expected - if the wrapped component does not respect the bounds that it has been
given.





[FLAMINGO-75] Problem with 16 pixel icon on JRibbonFrame Created: 21/May/10  Updated: 30/May/10  Resolved: 30/May/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File 1274286488_start-here.png     Java Source File ResizableBufferedImage16.java     JPEG File resultWithCurrentImplementation.jpg     Java Source File RibbonFrame16pIcon.java    
Issuezilla Id: 75

 Description   

After setting a 16 pixel buffered image as the application icon, everything
seems fine except for the icon on the windows task bar.

I'm going to attach 3 filed that constitute the test case.

I'm using windows Vista



 Comments   
Comment by dukke [ 21/May/10 ]

Created an attachment (id=30)
test case main entry

Comment by dukke [ 21/May/10 ]

Created an attachment (id=31)
A wrapper for a 16 pixel buffered image

Comment by dukke [ 21/May/10 ]

Created an attachment (id=32)
the 16pixel image

Comment by kirillcool [ 21/May/10 ]

I'll have to defer the debugging to you, since i do not have ready access to
non-Mac environment. The relevant code is in JRibbonFrame.setApplicationIcon
method. For non-Mac environment it creates three versions of the icon, 16, 32
and 64 and passes them to Window.setIconImages method.

This flow may be broken because your implementation of the ResizableIcon
interface does nothing in setDimension (which is bad), and the logic in the
JRibbonFrame.setApplicationIcon expects those values to match the size of the
image later passed to the core Swing method (Window.setIconImages).

Thanks
Kirill

Comment by dukke [ 21/May/10 ]

Thanks for the info.

OK. So my final purpose is to be able to provide a 16pixel raster image (instead
of vector one) to be used as the icon on the task bar of windows and on the
JFrame header.

You could add a method on ResizableIcon to query if a certain dimension is
supported by the class implementing ResizableIcon.
Than when you create the list of images to pass to setLegacyIconImages(...) you
would create a list with only the supported icon sizes in this case only an
image with 16x16 dimension.

I'm going to attach an image so you see what happens with the current
implementation.

I hope to have been clear enough, most of the times my message doesn't get
interpreted as I would want it to.

Thanks again,
Pedro DV

Comment by kirillcool [ 21/May/10 ]

I am not going to add such a method since this would encourage further use of
pixel-based image implementations of the ResizableIcon interface. Instead, i
suggest that you create a correct implementation of the ResizableIcon from
either a vector source or from a collection of pixel-based images (16*16, 32*32,
64*64 and choosing the best one in paintIcon).

Thanks
Kirill

Comment by dukke [ 21/May/10 ]

Created an attachment (id=33)
End result image of current implementation on windows vista

Comment by dukke [ 21/May/10 ]

Thanks for the answer. I'll comment your observations below:

"I am not going to add such a method since this would encourage further use of
pixel-based image implementations of the ResizableIcon interface"

The problem is that all the methods on Flamingo take a ResizableIcon and there
is no methods for taking in Buffered Images (raster images).
On the debate of vector images vs raster images, I think raster images are best
when dealing with reduced sized icons. The available size is so low that it is
hard to work with at a vector level. Office 2007 uses raster images for icons
rather than vector ones.

"Instead, i
suggest that you create a correct implementation of the ResizableIcon from
either a vector source or from a collection of pixel-based images (16*16, 32*32,
64*64 and choosing the best one in paintIcon)."

This will work but the final result would be that on Vista, core swing would use
the 64x64 image and than scale it back to 16x16 to put it on the task bar. So it
would be more practical and visually better to just pass a 16x16 image for swing
to use as the image to put on the windows taskbar.

Alternatively there could be one more method on JRibbonFrame to pass in a list
of BufferedImages - setApplicationIcon(BufferedImage[]). So you would end up
having two choices: use the method that receives a ResizableIcon or the method
that receives a list of BufferedImages.

Comment by kirillcool [ 29/May/10 ]

You can now call setIconImages / setIconImage method in addition to
setApplicationIcon. If the setIconImage* is called before setApplicationIcon,
the resizable icon passed to setApplicationIcon will only be set on the
application menu button.

Thanks
Kirill

Comment by dukke [ 30/May/10 ]

Thanks a lot, it worked!!

Pedro DV





[FLAMINGO-73] Resizing ribbon frame on left side, makes the ugly flickering effect Created: 09/Apr/10  Updated: 10/Apr/10  Resolved: 10/Apr/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: krzych_nowak Assignee: kirillcool
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 73

 Description   

Steps to reproduce:

  • Start demo,
  • Start resizing the frame holding the left side
    Can notice that the right side is flickering, occasionally making the right side
    become larger

Expected behaviour:

  • Start resizing the frame holding the right side
  • Notice no flickering on left side

Tested only on linux



 Comments   
Comment by kirillcool [ 09/Apr/10 ]

Is this the same behavior as described at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5079688 ?

Thanks
Kirill

Comment by kirillcool [ 09/Apr/10 ]

To further clarify my question - is this specific to Flamingo / Substance, or
does this happen under other decorated Swing applications of similar visual
complexity running on the same machine?

Comment by krzych_nowak [ 10/Apr/10 ]

I'm confirming that this is not Flamingo/Substance related bug but rather it's
java problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5079688

Think that makes the bug closed,

Could the example code contain the comment with the link to the sun bug be added
when setDefaultLookAndFeelDecoreded is called ?

Comment by kirillcool [ 10/Apr/10 ]

There's a lot of Substance / Flamingo / Trident test apps that use decorated
mode. At the present time i will leave the FAQ link and will not add comment to
each one of the test apps.

Thanks
Kirill





[FLAMINGO-74] Bad icon aligment Created: 21/May/10  Updated: 21/May/10  Resolved: 21/May/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 74

 Description   

The vertical alignment of icons of JRibbonComponents doesn’t seem to be correct.
It appears to be vertically too low.

Here is a sample test case:

import org.pushingpixels.flamingo.ribbon.*;
import org.pushingpixels.substance.api.SubstanceLookAndFeel;
import org.pushingpixels.substance.api.skin.CremeSkin;

import javax.swing.*;

import test.svg.transcoded.*;

public class RibbonBadAlignmentOfIcons extends JRibbonFrame {
public RibbonBadAlignmentOfIcons()

{ super("Icon alignemnt Test"); this.setSize(600, 300); this.setLocationRelativeTo(null); JRibbonBand band = new JRibbonBand("Test", new edit_select_all()); band.addRibbonComponent(new JRibbonComponent(new edit_copy(), "textfield", createTextField())); band.addRibbonComponent(new JRibbonComponent(new edit_cut(), "textfield2", createTextField())); band.addRibbonComponent(new JRibbonComponent(new edit_paste(), "textfield3", createTextField())); band.startGroup(); band.addRibbonComponent(new JRibbonComponent(new document_new() ,"textField4", createTextField())); RibbonTask task = new RibbonTask("test", band); getRibbon().addTask(task); this.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); }

private JTextField createTextField()

{ JTextField aTextField = new JTextField(); aTextField.setColumns(5); return aTextField; }

public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run()

{ JFrame.setDefaultLookAndFeelDecorated(true); SubstanceLookAndFeel.setSkin(new CremeSkin()); new RibbonBadAlignmentOfIcons().setVisible(true); }

});
}

}



 Comments   
Comment by kirillcool [ 21/May/10 ]

Should be addressed in the latest 5.0dev drop.

Thanks
Kirill

Comment by dukke [ 21/May/10 ]

Thanks, it now works fine.

Pedro DV





[FLAMINGO-71] KeyTips not shown Created: 06/Apr/10  Updated: 06/Apr/10  Resolved: 06/Apr/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: krzych_nowak Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 71

 Description   

KeyTips are not shown correctly, when ribbon-task is shown first time
Steps to reproduce:

  • Start the Ribbon demo
  • Press alt-W
    Result - not all keytips are shown

Hide the keytips(escape key) and again press alt-w
Result - more keytips are shown (expected behaviour)



 Comments   
Comment by kirillcool [ 06/Apr/10 ]

Should be fixed in the latest 5.0dev branch.

Thanks
Kirill





[FLAMINGO-72] NullPointerException Created: 09/Apr/10  Updated: 09/Apr/10  Resolved: 09/Apr/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: krzych_nowak Assignee: kirillcool
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 72

 Description   

Unable to reproduce, stack trace:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at
org.pushingpixels.substance.flamingo.common.ui.SubstanceCommandButtonUI.isInside(SubstanceCommandButtonUI.java:719)
at
org.pushingpixels.substance.internal.utils.RolloverControlListener.mouseEntered(RolloverControlListener.java:96)
at java.awt.AWTEventMulticaster.mouseEntered(AWTEventMulticaster.java:283)
at java.awt.Component.processMouseEvent(Component.java:6272)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6028)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4630)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4574)
at java.awt.LightweightDispatcher.trackMouseEnterExit(Container.java:4363)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4220)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)



 Comments   
Comment by kirillcool [ 09/Apr/10 ]

This was fixed in Substance Flamingo 6.0RC drop from April 1. What version of
substance-flamingo.jar are you using?





[FLAMINGO-70] Setting popup rich tooltip to null hides the action tooltip Created: 30/Mar/10  Updated: 31/Mar/10  Resolved: 31/Mar/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: krzych_nowak Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 70

 Description   

When setting the popup rich tooltip to null, commandbutton is unregistered from
RichTooltipManager.
Current implementation does not check if the commandbutton action rich tooltip
is != null, it just unregisters the component.
Expected behaviour is that modifing popup tooltip will not modify the action tooltip

Current impl:
this.popupRichTooltip = richTooltip;
RichToolTipManager richToolTipManager = RichToolTipManager
.sharedInstance();
if (richTooltip != null)

{ richToolTipManager.registerComponent(this); }

else

{ richToolTipManager.unregisterComponent(this); }
Should be replaced with something like:
this.popupRichTooltip = richTooltip;
RichToolTipManager richToolTipManager = RichToolTipManager
.sharedInstance();
if (hasRichTooltip()) { // tests if the component has any tooltip to display richToolTipManager.registerComponent(this); } else { richToolTipManager.unregisterComponent(this); }

Also the popupRichTooltip, and actionRichTooltip cant be obtained as they are
private and there is no getters. They could be protected (to allow for example
disabled tooltips)

Krzysztof



 Comments   
Comment by kirillcool [ 31/Mar/10 ]

This issue should be fixed in the latest 5.0dev drop. If this still happens,
please attach a small (<100 lines) test application that reproduces this
behavior under the latest 5.0dev drop.

The second part is more of an RFE - please do not mix two different issues in
one bug report. If you want to discuss this, the forum is a better place -
especially to describe what do you mean by the "disabled tooltips".

Also, please do not reply to the automated e-mail and keep the discussion of the
original bug in the bug tracker so that its history is not lost.

Thanks
Kirill





[FLAMINGO-69] Ribbon is not hidden when double click on active task Created: 26/Mar/10  Updated: 26/Mar/10  Resolved: 26/Mar/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: krzych_nowak Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 69

 Description   

When double click on task, ribbon goes to the 'collapsed' state, but it's not
hidden. Expected behaviour is that ribbon is hidden when using collapse key
combination, or when double clicking on active task.

Steps to reproduce:

  • Make sure ribbon is NOT collapsed
  • Double click on active task
    Result: ribbon is in 'collapsed'=='floating' state, but still visible
    Expected result - ribbon is collapsed AND hidden

Notice:



 Comments   
Comment by kirillcool [ 26/Mar/10 ]

This should be addressed in the latest 5.0dev drop of Flamingo core.

Thanks
Kirill





[FLAMINGO-63] gallery bug: showing selected element Created: 28/Nov/09  Updated: 30/Nov/09  Resolved: 30/Nov/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: xvik Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File ribbon_bug_step1.jpg     JPEG File ribbon_bug_step2.jpg    
Issuezilla Id: 63

 Description   

Hello Kirill,

There is a bug in gallery active element selection: some selected elements are
not shown on gallery component (after gallery popup disappearing).

Reproducing (webstart 4.2 release from pushing-pixels):
select style 6 in quickstyle gallery (see attachments).

This was working in 4.1 release



 Comments   
Comment by xvik [ 28/Nov/09 ]

Created an attachment (id=28)
selecting style 6

Comment by xvik [ 28/Nov/09 ]

Created an attachment (id=29)
selected style 6 is not visible in gallery viewport

Comment by kirillcool [ 28/Nov/09 ]

Moving to 5.0dev branch for the fix.

Comment by kirillcool [ 28/Nov/09 ]

This should be fixed in the latest 5.0dev drop.

Thanks
Kirill

Comment by kirillcool [ 28/Nov/09 ]

Marking issue as FIXED.

Comment by xvik [ 29/Nov/09 ]

Sorry, but bug is still there...

I've tried the latest flamingo 5 build: BasicCheckRibbon test

Try to activate "Style 2" in quick styles.. it wouldn't be visible on gallery
viewport

Try to activate items one by one - you'll note that every second selection is
not visible

Comment by kirillcool [ 29/Nov/09 ]

Indeed. This still happens when the button in just the next row is selected.

Comment by kirillcool [ 29/Nov/09 ]

Please test the latest 5.0dev drop.

Thanks
Kirill

Comment by xvik [ 30/Nov/09 ]

test successful
Thank you!!





[FLAMINGO-62] enhanced application menu Created: 28/Nov/09  Updated: 28/Nov/09  Resolved: 28/Nov/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.2
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: xvik Assignee: kirillcool
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: JPEG File ribbon_enhansment.jpg    
Issuezilla Id: 62

 Description   

Hello Kirill,

I run into little issue with main application menu (left top ribbon corner):
Issue occurs when one of sub menus contains more items than main menu: ribbon
just cuts out bottom part of sub menu.

Please see in attachment probable solution



 Comments   
Comment by xvik [ 28/Nov/09 ]

Created an attachment (id=27)
example of long submenu solution

Comment by kirillcool [ 28/Nov/09 ]

This enhancement is out of scope for Flamingo. I have double checked the menu
entries for Word, PowerPoint and Excel, and none have the overflowing secondary
menu entries.

I would suggest revisiting the structure of your application menu to remove
those entries or create third-level menus.

Thanks
Kirill





[FLAMINGO-60] Resize policy consitency check fails for core policies Created: 24/Nov/09  Updated: 25/Nov/09  Resolved: 25/Nov/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.2
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: toker5 Assignee: kirillcool
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 60

 Description   

In the 4.2 release, the "permissive" and "restrictive" core resize policies
fails in FlamingoUtilities.checkResizePoliciesConsistency(). This means that the
Ribbon will fail with an IllegalStateException if it has bands that use the
default resize policies.



 Comments   
Comment by toker5 [ 25/Nov/09 ]

This is actually not a bug - more that the core resize policies and the
consistency check doesn't necessarily play nice together "out of the box".

This occurs especially if you have few controls in the band (e.g. just one
command button), at which case the MEDIUM element priority will result in a
wider size than HIGH.

Of course, a Ribbon should be well thought out, planned and tested, but the core
resize policies could either be smarter, or maybe ribbon bands should have no
resize policies by default (the simplest solution).

Comment by kirillcool [ 25/Nov/09 ]

Removing the default set of resize policies will require that all application
ribbon band need to explicitly set the matching resize policies. This actually
makes the code more complex.

Indeed for a small number of cases - especially for ribbon bands with extremely
low number of components - the default resize policy list is not adequate. In
such cases the application designer needs to figure out what is the right set of
resize policies that does not violate the rule.

This behavior is by design to address the most common ribbon cases and to ensure
a predictable resizing behavior of the ribbon frame.

Marking as INVALID since there is no AS_DESIGNED resolution.

Thanks
Kirill





[FLAMINGO-61] Ribbon task buttons can be deselected Created: 25/Nov/09  Updated: 28/Nov/09  Resolved: 28/Nov/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: toker5 Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 61

 Description   

The selected ribbon task button (e.g. "Home") can be deselected by selecting it
a second time.

See example:
http://img694.imageshack.us/img694/1998/ribbontaskbutton.png



 Comments   
Comment by toker5 [ 25/Nov/09 ]

After looking at the code in CommandToggleButtonGroup, I suggest either
enhancing the class or creating two different group implementations: One that
allows the selection to be cleared (current) and one that don't.

Comment by kirillcool [ 28/Nov/09 ]

CommandToggleButtonGroup should be enhanced to support the mode that disallows
unselecting the currently selected button and clearing the selection.

Moving to 5.0dev branch for fix.

Comment by kirillcool [ 28/Nov/09 ]

This should be fixed in the latest 5.0dev drop.

Thanks
Kirill





[FLAMINGO-58] Popup menu from secondary menu placement is incorrect Created: 29/Oct/09  Updated: 26/Mar/10  Resolved: 26/Mar/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.2
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jhawthorne Assignee: kirillcool
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 58

 Description   

If I create a secondary menu as CommandButtonKind.ACTION_AND_POPUP_MAIN_ACTION
and register a PopupPanelCallback using the setPopupCallback() method, the
popup menu is not displayed to the right of the secondary menu but is about 200
pixels below the secondary menu - the x location seems to be correct. The
placement of the popup menu is correct if I use CommandButtonKind.POPUP_ONLY or
CommandButtonKind.ACTION_AND_POPUP_MAIN_POPUP.



 Comments   
Comment by kirillcool [ 29/Oct/09 ]

Is this observed in the main ribbon test application? If not, i will need to see
a small (<100 lines) test app that reproduces this behavior under the latest
4.2RC drop.

Thanks
Kirill

Comment by jhawthorne [ 02/Nov/09 ]

I cannot reproduce this issue in the BasicCheckRibbon application with the
formal release of 4.2. I will search out the differences between my
application and the test application.

Comment by kirillcool [ 02/Nov/09 ]

I would imagine that a test app will contain one empty ribbon task, and the
application menu that has only that specific menu entry that results in
incorrect placement of the popup menu - all under the just released 4.2.

Thanks
Kirill

Comment by kirillcool [ 28/Nov/09 ]

This issue will be closed as WORKSFORME without a reproducible test app.

Thanks
Kirill

Comment by kirillcool [ 26/Mar/10 ]

No reproducible test case after five months. Closing.





[FLAMINGO-56] Support for placing ribbon bands in the task bar Created: 21/Sep/09  Updated: 21/Sep/09  Resolved: 21/Sep/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.2
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: kirillcool Assignee: kirillcool
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 56

 Description   

Office 2007 supports adding ribbon bands to the task bar. It adds a non-flat
command button that shows the ribbon band in a popup. The button does not have
an arrow - it's an action button. The content of the ribbon band is effectively
cloned - the screen can show the contents of the original band and the popup
band at the same time.



 Comments   
Comment by kirillcool [ 21/Sep/09 ]

Unfortunately, this looks like it cannot be supported by the library for all
possible ribbon bands. The main issue is that the content of the original band
needs to be duplicated to be shown in the popup.

Suppose the original ribbon band has a few command buttons, and a combobox.
Then, the popup ribbon band needs to have exactly the same controls - with
exactly the same behavior. While it is possible to recreate the simple
characteristics of the command buttons - such as text and priority, the rest is
more difficult - if not too difficult.

First, the icon instances cannot be reused across different command buttons.
While this can be addressed, a much bigger issue is with listeners. Application
code can register custom listeners with the model + the action listeners. In
addition, the internal UI delegates wire their own listeners for different
purposes. Since in Swing a control can only have one parent, the button will
effectively need to be cloned to be able to show it in two different places at
the same time. The listener list cannot be cloned - some of the listeners come
from the original UI delegate and should not be part of the cloned button. This
can also be addressed by overriding the tracking of listeners and somehow
differentiating between application listeners and listeners coming from UI
delegates.

The same applies for core / third-party controls placed in the ribbon - where we
have even less control over the component code, and even more functionality
exposed to the applications. Here, we're talking about models, renderers,
editors, documents etc.

Given this complexity, this enhancement is marked as WONTFIX. It will be known
as a feature gap between Flamingo and Office 2007.

Interested applications will need to provide this functionality by maintaining a
separate copy of a ribbon band. A command button is added to the task bar. An
action listener is added to the command button. This action listener uses
PopupPanelManager to show the relevant (copy) ribbon band. See code in
BasicCommandButtonUI.processPopupAction for sample code on how to do this.

Kirill





[FLAMINGO-55] Flamingo 4.1 cannot be compiled with OpenJDK because of a stray import Created: 09/Sep/09  Updated: 10/Sep/09  Resolved: 10/Sep/09

Status: Resolved
Project: flamingo
Component/s: base
Affects Version/s: 4.2
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: scherpbier Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 55

 Description   

The file src/test/common/TestWebStartLAF.java line 15 has an import that isn't
available in OpenJDK and causes the compile to fail:

import com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel;

The import isn't actually used, so simply removing the import makes the project
compile with OpenJDK.



 Comments   
Comment by kirillcool [ 09/Sep/09 ]

Will remove the unused import.

Thanks
Kirill

Comment by kirillcool [ 10/Sep/09 ]

This should be available in the latest 4.2dev drop.

Thanks
Kirill





[FLAMINGO-54] IcoWrapperResizableIcon and SvgBatikResizableIcon not loading icon from resources when in jar Created: 26/Aug/09  Updated: 09/Sep/09  Resolved: 09/Sep/09

Status: Resolved
Project: flamingo
Component/s: common components
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: scherpbier Assignee: kirillcool
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 54

 Description   

This is bizarre. I'm sure I'm doing something wrong, but I don't know what!

Using IcoWrapperResizableIcon.getIcon(InputStream, Dimension) when the
inputstream is from a resource (getClass().getResourceAsStream(path)) works as
expected until the project is bundled up into one jar file.

In the ribbon UI I have created, the icons showed up correctly when running
using "java -cp build packagepath.RibbonThingy".

When I packaged up the same files into a jar file, the ico icons don't show up
using "java -cp packaged.jar packagePath.RibbonThingy"

(png icons show up just fine)

$ java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu11)
OpenJDK 64-Bit Server VM (build 14.0-b08, mixed mode)

I've tried to eliminate as many variables as I can think of. I've tried running
with OpenJDK under linux as well. Also tried OS X Java 6 and MS Windows Java 6.
All of those show the PNG icons just fine but not ICO nor SVG icons.



 Comments   
Comment by scherpbier [ 26/Aug/09 ]

Follow up...
I'm using the code below to load icons. Maybe I'm just doing something really
stupid.

/**

  • Takes care of loading icons in an efficient manner.
    */
    public class IconManager {

private final static Object mAnchor = new Object();
private static Map<String, ResizableIcon> mCachedIcons = new HashMap<String,
ResizableIcon>();

/**

  • Loads an icon from the resources. For every path, only one icon object
  • will ever be created.
  • @param resourcePath
  • the path to the icon.
  • @param size
  • the horizontal size of the icon (icons are assumed to be square)
  • @return the icon or null if the resource could not be found.
    */
    public static ResizableIcon getIcon(String resourcePath, int size) {
    ResizableIcon icon = mCachedIcons.get(resourcePath + size);
    if (icon == null) {
    InputStream resourceStream = mAnchor.getClass()
    .getResourceAsStream(resourcePath);
    if (resourceStream != null)
    Unknown macro: { byte[] contents = null; try { contents = getContents(resourceStream); } catch (IOException e) { e.printStackTrace(); } ByteArrayInputStream in = new ByteArrayInputStream(contents); if (resourcePath.endsWith(".png")) { icon = ImageWrapperResizableIcon.getIcon(in, new Dimension( size, size)); } else if (resourcePath.endsWith(".svg")) { icon = SvgBatikResizableIcon.getSvgIcon(in, new Dimension( size, size)); } else if (resourcePath.endsWith(".ico")) { icon = IcoWrapperResizableIcon.getIcon(in, new Dimension( size, size)); } }

    else

    { System.out.format("Resource %s not found\n", resourcePath); }

    if (icon != null)

    { mCachedIcons.put(resourcePath + size, icon); }

    else

    { System.out.format("No icon loaded for resource %s\n", resourcePath); }

    }
    System.out.format("Icon for %s and size %d: %s\n", resourcePath, size,
    icon);
    return icon;
    }

/**

  • Reads the contents of a stream without closing it.
  • @param in
  • the stream to read from.
  • @return the contents.
  • @throws IOException
    */
    private static byte[] getContents(InputStream in) throws IOException {
    ByteArrayOutputStream bout = new ByteArrayOutputStream();
    byte[] buffer = new byte[40000];
    while (true)
    Unknown macro: { int bytesRead = in.read(buffer); if (bytesRead <= 0) { break; } bout.write(buffer, 0, bytesRead); }

    System.out.format("Got contents: %d bytes\n", bout.size());
    return bout.toByteArray();
    }
    }

Comment by scherpbier [ 26/Aug/09 ]

The output produced during UI creation in my app is as follows:
Got contents: 1660 bytes
Icon for /images/x32/location.png and size 32:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@53077fc9
Got contents: 1881 bytes
Icon for /images/x32/search.png and size 32:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@52c00025
Got contents: 717 bytes
Icon for /images/x16/0204-scroll_search.png and size 16:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@70e434d
Got contents: 702 bytes
Icon for /images/x16/2034-left2.png and size 16:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@26789869
Got contents: 670 bytes
Icon for /images/x16/2035-right2.png and size 16:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@56e2ecc7
Got contents: 65643 bytes
Icon for /images/tomcat.svg and size 16:
org.jvnet.flamingo.svg.SvgBatikResizableIcon@288b567c
Got contents: 1893 bytes
Icon for /images/x32/filters.png and size 32:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@10987197
Got contents: 537 bytes
Icon for /images/x16/0181-text_tool.png and size 16:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@45c3e9ba
Got contents: 462 bytes
Icon for /images/x16/0200-scroll.png and size 16:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@259a8416
Got contents: 687 bytes
Icon for /images/x16/0177-calendar.png and size 16:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@7df1bd98
Got contents: 2141 bytes
Icon for /images/x32/savedsearch.png and size 32:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@25071521
Got contents: 1726 bytes
Icon for /images/x32/0025-search.png and size 32:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@5d2a73d9
Icon for /images/x32/0025-search.png and size 32:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@5d2a73d9
Icon for /images/x32/0025-search.png and size 32:
org.jvnet.flamingo.common.icon.ImageWrapperResizableIcon@5d2a73d9

Note that /images/tomcat.svg is loaded (the contents is 65643 bytes)
I added the getContents() method to see if this had anything to do with possible
problems with either closing the resource stream or other loading from a jar issues.

Comment by kirillcool [ 27/Aug/09 ]

From the description i'm not sure what is the environment. What is in the jar?
The flamingo classes, your classes, or images?

Please create a small (<100 lines) test application that illustrates the issue
(along with a main() method). Eliminate everything that is not necessary - for
example, your code handles three types of icon sources. Also, if there is
special deployment configuration (images in jars or what not), i'll need that
information too.

Thanks
Kirill

Comment by scherpbier [ 09/Sep/09 ]

My sincere apologies! The problem was between the screen and the back of my head!

Turns out I wasn't packaging up the "xml-apis-ext.jar" in my final jar file.
Adding it made both the ICO and SVG images work as expected.

Could you add a blurb in the docs about packaging up an app using flamingo and
which additional dependencies need to be included? (By process of elimination,
all the other jars in the "lib" directory except the batik and xml-apis-ext jars
weren't required...)

I see no way to mark this issue as invalid, so could you do that please?

Comment by kirillcool [ 09/Sep/09 ]

There is no documentation on Flamingo components - see [1] for the reasons why.

Closing this issue as INVALID since it was confirmed to be the deployment
configuration.

Thanks
Kirill

[1] http://www.pushing-pixels.org/?p=1043





[FLAMINGO-57] 4.2 Relase causes IllegalStateException at startup Created: 29/Oct/09  Updated: 02/Nov/09  Resolved: 02/Nov/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.2
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jhawthorne Assignee: kirillcool
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 57

 Description   

Under flamingo release 4.1_01 there are not exceptions on startup. When
running with flamingo release 4.2 (Oct 25), I get the following exception when
starting up my application:

java.lang.IllegalStateException: Inconsistent preferred widths
Ribbon band 'Preferences has the following resize policies
org.jvnet.flamingo.ribbon.resize.CoreRibbonResizePolicies$None with
preferred width 72
org.jvnet.flamingo.ribbon.resize.CoreRibbonResizePolicies$Low2Mid with
preferred width 72
org.jvnet.flamingo.ribbon.resize.CoreRibbonResizePolicies$Mid2Mid with
preferred width 72
org.jvnet.flamingo.ribbon.resize.CoreRibbonResizePolicies$Mirror with
preferred width 72
org.jvnet.flamingo.ribbon.resize.CoreRibbonResizePolicies$Mid2Low with
preferred width 72
org.jvnet.flamingo.ribbon.resize.CoreRibbonResizePolicies$High2Mid with
preferred width 119
org.jvnet.flamingo.ribbon.resize.IconRibbonBandResizePolicy with
preferred width 72
org.jvnet.flamingo.ribbon.resize.CoreRibbonResizePolicies$Mid2Low with pref
width 72 is followed by resize policy
org.jvnet.flamingo.ribbon.resize.CoreRibbonResizePolicies$High2Mid with larger
pref width

at
org.jvnet.flamingo.utils.FlamingoUtilities.checkResizePoliciesConsistency
(FlamingoUtilities.java:575)

It is unclear how to resolve this issue from the application code standpoint.



 Comments   
Comment by kirillcool [ 29/Oct/09 ]

This is the designed behavior to enforce predictable resizing at runtime. For
more information please see the thread at [1], and specifically my message at
[2] - formatting is a little off, so you'll have to scroll.

By the way, what controls do you have in "Preferences" ribbon band?

Since there is no AS_DESIGNED resolution, i'm marking this as INVALID. Use
AbstractRibbonBand.setResizePolicies API to set the specific list of resize
policies.

[1]
https://flamingo.dev.java.net/servlets/BrowseList?list=users&by=thread&from=2017721
[2] https://flamingo.dev.java.net/servlets/ReadMsg?list=users&msgNo=429

Comment by jhawthorne [ 02/Nov/09 ]

The Preferences Ribbon Band contains a single ACTION_ONLY JCommandButton. It
is the fourth band within the RibbonTask.

Comment by kirillcool [ 02/Nov/09 ]

There are two factors that you should consider when creating ribbon bands with
very small number of controls.

1. Design wise, a ribbon band is a logical grouping of related controls. It
shouldn't have too many controls, but it shouldn't have too few. I would say
that a ribbon band with a single button is not the right use of the ribbon control.
2. The rule enforced on resize policies may not allow you to create such ribbon
bands at all. The last resize policy must always be the ICON state (when the
ribbon band is collapsed), and if the ribbon band title is longer than the title
of that single action command button, this rule can only be satisfied when the
only available resize policy is ICON - effectively enforcing this ribbon band to
always be collapsed. This behavior is by design and you will need to consider
redesigning this specific band to comply with the resize policy rule that
enforces predictable dynamic runtime behavior when the user resizes your
application.

Thanks
Kirill





[FLAMINGO-53] BasicBreadcrumBarUI still not threadsave Created: 17/Aug/09  Updated: 10/Sep/09  Resolved: 10/Sep/09

Status: Resolved
Project: flamingo
Component/s: breadcrumb bar
Affects Version/s: 4.2
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: schlm3 Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 53

 Description   

I got an exception concerning a missing synchronisation.

The member "stack" of BasicBradcrumbBarUI must always be accessed within a
synchronize(stack){}. The current code misses such a synchronisation inside
"updateComponents()". The access to the Iterator must be synchronized for the
whole loop. It is not sufficent to synchonize the method alone, because
synchrnized on method level synchonizees on the "this"-instance, while the other
accesses to the stack synchronize on "stack".



 Comments   
Comment by kirillcool [ 10/Sep/09 ]

This should be available in the latest 4.2dev drop.

Thanks
Kirill





[FLAMINGO-51] support for command buttons without icons Created: 12/Aug/09  Updated: 10/Sep/09  Resolved: 10/Sep/09

Status: Resolved
Project: flamingo
Component/s: common components
Affects Version/s: 4.2
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: cfmfluit Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 51

 Description   

I would like to use command buttons with only text, no icon.

I noticed that passing 'null' as icon to the JCommandButton constructor results in
NullPointerExceptions during rendering.

Passing a new EmptyResizableIcon(0) works, but the button then shows a lot of
empty space to the left of the button text. This looks very awkward and is unlike
what JButton et al do.



 Comments   
Comment by kirillcool [ 10/Sep/09 ]

This should be available in the latest 4.2dev drop.

Thanks
Kirill





[FLAMINGO-52] BreadCrumbBar does not display html-markup consistently Created: 17/Aug/09  Updated: 20/Aug/09  Resolved: 20/Aug/09

Status: Resolved
Project: flamingo
Component/s: breadcrumb bar
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: schlm3 Assignee: kirillcool
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 52

 Description   

Whe are using the BreadcrumbBar as an alternative for our JTree navigation.
In the JTree, we use HTML-Markup to style the TreeNodes.

Now we would like to use the same markup inside BreadcumbBar.
Unfortunately, this seems to work only within the DropDown, but not within the
Breadcrumbs. The Breadcrumbs show the markup itself instead like
"<html><body>MyText</body></html>".

The reason for thi is in the Class BasicBreadcrumbParticleUI. This class
inherits from BasicLabelUI and overwrites some methods.
The method installListeners(..) lacks the call to
"particle.addPropertyChangeListener(this);", while uninstallListener(..) should
contain the call "particle.removePropertyChangeListener(this);".

InstallComponents(..) should contain "BasicHTML.updateRenderer(particle,
particle.getText());", while uninstallComponents(..) should contain
"BasicHTML.updateRenderer(particle, "");"

Sincerely
Markus Schlegel



 Comments   
Comment by kirillcool [ 20/Aug/09 ]

The breadcrumb bar does not support HTML by design. Current internal
implementation is using BasicLabelUI but that will change in the future to use
command buttons - and those do not and will not support HTML text.

Marking as WONTFIX since supporting HTML is not planned for any Flamingo
components, including both command buttons and breadcrumb bar.

Thanks
Kirill





[FLAMINGO-49] IllegalStateException exception running the webstart Created: 05/Jun/09  Updated: 09/Jun/09  Resolved: 09/Jun/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.2
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: johanpr Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 49

 Description   

JNLP JREDesc in Component ignored:
https://substance.dev.java.net/webstart/substance-all.jnlp
JNLP JREDesc in Component ignored:
https://flamingo.dev.java.net/webstart/flamingo-all.jnlp
Substance-Flamingo-BuildStamp: June 1, 2009 20:27:53 PDT
Substance-BuildStamp: June 1, 2009 20:25:42 PDT
Flamingo-BuildStamp: June 3, 2009 20:46:15 PDT
Look-and-feel change from null to Metal
Look-and-feel change from Metal to Substance Office Blue 2007
Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: Ribbon
band 'Find (toggle)' has resize policy
org.jvnet.flamingo.ribbon.resize.CoreRibbonResizePolicies$Mid2Low has pref width
80 which is followed by resize policy
org.jvnet.flamingo.ribbon.resize.IconRibbonBandResizePolicy with pref width 86
at
org.jvnet.flamingo.ribbon.AbstractRibbonBand.checkResizePoliciesConsistency(AbstractRibbonBand.java:432)
at
org.jvnet.flamingo.ribbon.AbstractRibbonBand.setRibbonTask(AbstractRibbonBand.java:537)
at org.jvnet.flamingo.ribbon.RibbonTask.<init>(RibbonTask.java:90)
at test.ribbon.BasicCheckRibbon.configureRibbon(BasicCheckRibbon.java:1037)
at test.substance.ribbon.NewCheckRibbon.configureRibbon(NewCheckRibbon.java:60)
at test.substance.ribbon.NewCheckRibbon$3.run(NewCheckRibbon.java:169)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)



 Comments   
Comment by kirillcool [ 05/Jun/09 ]

Are you running the WebStart on Windows XP like you specified in the issue report?

Thanks
Kirill

Comment by johanpr [ 05/Jun/09 ]

Yes - win XP with jdk 1.6 u 13

Comment by kirillcool [ 07/Jun/09 ]

Can't seem to reproduce it. Here is my console output:

Java Web Start 1.6.0_10-rc
Using JRE version 1.6.0_14 Java HotSpot(TM) Client VM

--------------------------------------------------------

Substance-Flamingo-BuildStamp: June 1, 2009 20:27:53 PDT
Substance-BuildStamp: June 6, 2009 15:07:51 PDT
Flamingo-BuildStamp: June 6, 2009 23:55:51 PDT
Look-and-feel change from null to Metal
Look-and-feel change from Metal to Substance Office Blue 2007

You see that the Flamingo / Substance Flamingo build stamps are from June 6 -
i've added support for small buttons in ribbon galleries, but nothing regarding
the layout / resizing.

Can you clean your WebStart cache and run the demo once again under the 6u14
release?

Thanks
Kirill

Comment by kirillcool [ 07/Jun/09 ]

Can't reproduce under XP SP3 as well. Do you have any custom font settings, or
custom DPI settings on your machine? Can you attach a screenshot of the main
Substance test application from https://substance.dev.java.net/see.html ?

Thanks
Kirill

Comment by johanpr [ 09/Jun/09 ]

Hi Kirill - I re-tested today with the June 6 build - it worked perfectly.
We can close this issue.

Comment by kirillcool [ 09/Jun/09 ]

Confirmed to be fixed.

Thanks
Kirill





[FLAMINGO-48] error with using JRibbon without JRibbonFrame Created: 03/Jun/09  Updated: 05/Jun/09  Resolved: 05/Jun/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Task Priority: Major
Reporter: gonzo125 Assignee: kirillcool
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 48

 Description   

i tried to use Ribbon without JRibbonFrame. When i clicked on ...
i got exception:
Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:
com.softnet.ribbontest.Ribboner cannot be cast to
org.jvnet.flamingo.ribbon.JRibbonFrame
at
org.jvnet.flamingo.ribbon.ui.appmenu.BasicRibbonApplicationMenuButtonUI
$1.getPopupPanel(BasicRibbonApplicationMenuButtonUI.java:119)
at org.jvnet.flamingo.common.ui.BasicCommandButtonUI.processPopupAction
(BasicCommandButtonUI.java:1091)
at org.jvnet.flamingo.common.ui.BasicCommandButtonUI$4.actionPerformed
(BasicCommandButtonUI.java:1064)
at org.jvnet.flamingo.common.JCommandButton
$DefaultPopupButtonModel.firePopupActionPerformed(JCommandButton.java:314)
at org.jvnet.flamingo.common.JCommandButton
$DefaultPopupButtonModel.setPressed(JCommandButton.java:346)
at org.jvnet.flamingo.common.ui.BasicPopupButtonListener.mousePressed
(BasicPopupButtonListener.java:119)
at java.awt.Component.processMouseEvent(Component.java:6213)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3265)
at java.awt.Component.processEvent(Component.java:5981)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4583)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4413)
at java.awt.LightweightDispatcher.retargetMouseEvent
(Container.java:4556)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4217)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4150)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2475)
at java.awt.Component.dispatchEvent(Component.java:4413)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at java.awt.EventDispatchThread.pumpOneEventForFilters
(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter
(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy
(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

I looked at the source code and i changed method in
BasicRibbonApplicationMenuButtonUI from:

@Override
protected void installComponents() {
super.installComponents();

final JRibbonApplicationMenuButton appMenuButton =
(JRibbonApplicationMenuButton) this.commandButton;
appMenuButton.setPopupCallback(new PopupPanelCallback() {
@Override
public JPopupPanel getPopupPanel(final JCommandButton
commandButton) {
JRibbonFrame ribbonFrame = (JRibbonFrame)
SwingUtilities
.getWindowAncestor
(commandButton);
final JRibbon ribbon = ribbonFrame.getRibbon();
...

to:

@Override
protected void installComponents() {
super.installComponents();

final JRibbonApplicationMenuButton appMenuButton =
(JRibbonApplicationMenuButton) this.commandButton;
appMenuButton.setPopupCallback(new PopupPanelCallback() {
@Override
public JPopupPanel getPopupPanel(final JCommandButton
commandButton) {
JFrame frame = (JFrame)SwingUtilities.getWindowAncestor
(commandButton);
JRibbon res = null;
if (frame instanceof JRibbonFrame)

{ JRibbonFrame ribbonFrame = (JRibbonFrame) SwingUtilities .getWindowAncestor (commandButton); res = ribbonFrame.getRibbon(); }

else {
Container parent = commandButton.getParent();
System.out.println(parent);
while (!(parent instanceof JRibbon))

{ System.out.println(parent); parent = parent.getParent(); }

res = (JRibbon)parent;
}
final JRibbon ribbon = res;

and i think it fixed this problem. Maybe this should be merged to repository ?

I want to use Ribbon without JRibbonFrame because im writing an application in
ULC. Im using BorderLayoutPane and putting Ribbon to North, and it works fine
now ( after this fix )



 Comments   
Comment by kirillcool [ 05/Jun/09 ]

JRibbonFrame is the only supported way to have the full functionality of the
ribbon. Application menu button is one example that is only supported on ribbons
placed in JRibbonFrame.

Closing as INVALID since the current behavior is by design. If your application
code absolutely cannot use the JRibbonFrame, you will not be able to use the
application menu button from the core library.

Thanks
Kirill





[FLAMINGO-44] Empty Ribbon with undecorated frame causes NPE Created: 26/Apr/09  Updated: 26/Apr/09  Resolved: 26/Apr/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: flynnk Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File EmptyRibbon.java    
Issuezilla Id: 44

 Description   

When the ribbon is undecorated and empty, you can get an NPE when resizing the
window. The NPE is below. I'll attach a sample program (a very slightly
modified version of EmptyRibbon from the test packages.

Workaround: Set a minimum size on the ribbon manually (doesn't seem to matter
the size).

NPE:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at
org.jvnet.flamingo.ribbon.ui.BasicRibbonUI$RibbonLayout.minimumLayoutSize(BasicRibbonUI.java:692)
at java.awt.Container.minimumSize(Container.java:1633)
at java.awt.Container.getMinimumSize(Container.java:1618)
at javax.swing.JComponent.getMinimumSize(JComponent.java:1714)
at java.awt.BorderLayout.minimumLayoutSize(BorderLayout.java:651)
at java.awt.Container.minimumSize(Container.java:1633)
at java.awt.Container.getMinimumSize(Container.java:1618)
at javax.swing.JComponent.getMinimumSize(JComponent.java:1714)
at
javax.swing.plaf.metal.MetalRootPaneUI$MetalRootLayout.minimumLayoutSize(MetalRootPaneUI.java:484)
at java.awt.Container.minimumSize(Container.java:1633)
at java.awt.Container.getMinimumSize(Container.java:1618)
at javax.swing.JComponent.getMinimumSize(JComponent.java:1714)
at java.awt.BorderLayout.minimumLayoutSize(BorderLayout.java:646)
at java.awt.Container.minimumSize(Container.java:1633)
at java.awt.Container.getMinimumSize(Container.java:1618)
at
javax.swing.plaf.metal.MetalRootPaneUI$MouseInputHandler.mouseDragged(MetalRootPaneUI.java:821)
at java.awt.Component.processMouseMotionEvent(Component.java:6182)
at javax.swing.JComponent.processMouseMotionEvent(JComponent.java:3283)
at java.awt.Component.processEvent(Component.java:5903)
at java.awt.Container.processEvent(Container.java:2023)
at java.awt.Component.dispatchEventImpl(Component.java:4501)
at java.awt.Container.dispatchEventImpl(Container.java:2081)
at java.awt.Component.dispatchEvent(Component.java:4331)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4301)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3982)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3895)
at java.awt.Container.dispatchEventImpl(Container.java:2067)
at java.awt.Window.dispatchEventImpl(Window.java:2458)
at java.awt.Component.dispatchEvent(Component.java:4331)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)



 Comments   
Comment by flynnk [ 26/Apr/09 ]

Created an attachment (id=18)
Sample program to reproduce the problem

Comment by kirillcool [ 26/Apr/09 ]

Will fix this, but empty ribbon content isn't really a target scenario

Thanks
Kirill

Comment by flynnk [ 26/Apr/09 ]

Understood.

I do kind of like the application menu by itself, though. I understand the
concerns with very small amounts of content in the ribbon (Notepad shouldn't
have a ribbon, although I've found 5 versions of that on the 'net...), but I
think the application button by itself is probably better than the "just a file
menu" option. Or at least, I think that enough to try it out and see what kind
of feedback I get. I haven't read through all the Ribbon guidelines, but I
wonder about this specific scenario.

Just a thought. Issue tracker is probably not the best place for
philosophical musing though....

Comment by kirillcool [ 26/Apr/09 ]

Moving to version 4.1 to fix.

Comment by kirillcool [ 26/Apr/09 ]

The NPE should be fixed in the latest 4.1dev drop.

Thanks
Kirill





[FLAMINGO-41] "C:/temp" is hard coded in SvgFileViewPanel Created: 22/Feb/09  Updated: 25/Feb/09  Resolved: 25/Feb/09

Status: Resolved
Project: flamingo
Component/s: base
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Task Priority: Major
Reporter: fofuca Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 41

 Description   

I try SvgViewer to convert svg to java class. It succeed to generate the java
class but I got the error :

draw.svg
java.io.FileNotFoundException: C:/temp/draw.java (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
at java.io.FileOutputStream.<init>(FileOutputStream.java:70)
at java.io.PrintWriter.<init>(PrintWriter.java:146)
at
org.jvnet.flamingo.svg.SvgFileViewPanel$1$1.actionPerformed(SvgFileViewPanel.java:173)
at
org.jvnet.flamingo.common.AbstractCommandButton.fireActionPerformed(AbstractCommandButton.java:506)
at
org.jvnet.flamingo.common.AbstractCommandButton$ActionHandler.actionPerformed(AbstractCommandButton.java:458)
at
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at
org.jvnet.flamingo.common.model.ActionRepeatableButtonModel.setPressed(ActionRepeatableButtonModel.java:117)
at
org.jvnet.flamingo.common.ui.BasicPopupButtonListener.mouseReleased(BasicPopupButtonListener.java:141)
at
...

I am using a linux OS and there is no C:\temp directory!

Paul



 Comments   
Comment by kirillcool [ 23/Feb/09 ]

This actually should be in the test package. It will be moved there in version
4.1. Do not use this class in your applications, it was meant to be for
testing purposes only.

Thanks
Kirill

Comment by kirillcool [ 25/Feb/09 ]

This class has been moved to the test.svg package where it belongs. It is a demo
container that shows how to use some of the Flamingo components and does not
belong in the core distribution.

If you need this functionality in your app, you can replace the hard-coded
location with opening a file chooser and storing the transcoded class in the
selected folder.

Thanks
Kirill





[FLAMINGO-40] Support for components that span 2 or more rows Created: 02/Feb/09  Updated: 26/Apr/09  Resolved: 26/Apr/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 40

 Description   

Right now adding a component that spans 2 or more rows is not supported, say
like a textArea with two rows.

Thanks,
Pedro DV



 Comments   
Comment by kirillcool [ 26/Apr/09 ]

New JRibbonBand.addRibbonComponent(JRibbonComponent, int rowSpan) can be used to
add multi-row components.

Thanks
Kirill





[FLAMINGO-39] RichToolTip for JRibbonBand expandbutton Created: 02/Feb/09  Updated: 26/Apr/09  Resolved: 26/Apr/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: jegewecke Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 39

 Description   

The RichToolTip functionality should be added to the expand button that can be
placed on the title area of the JRibbonBand.



 Comments   
Comment by kirillcool [ 26/Apr/09 ]

The AbstractRibbonBand.setExpandButtonRichTooltip API can be used to associate a
rich tooltip with the ribbon band expand button.





[FLAMINGO-38] Empty taskbar panel pushes the ribbon frame title to the right Created: 29/Jan/09  Updated: 30/Jan/09  Resolved: 30/Jan/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 38

 Description   

The title of ribbon frame appears a little too much to the right.

Use the simple test from the resize issue to see this problem.



 Comments   
Comment by kirillcool [ 29/Jan/09 ]

Changed the summary of the issue. This should be fixed in the latest 5.1RC drop
of Substance Flamingo plugin.

Thanks for reporting this issue.
Kirill

Comment by dukke [ 30/Jan/09 ]

Tested it under latest 5.1 drop, works fine now.

Thanks,
Pedro DV

Comment by kirillcool [ 30/Jan/09 ]

Thanks for verifying the fix.

Kirill





[FLAMINGO-37] Strange resize behaviour of JRibbonFrame Created: 29/Jan/09  Updated: 26/Apr/09  Resolved: 26/Apr/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File StrangeResize.java    
Issuezilla Id: 37

 Description   

Resize a ribbon frame using either one of the 4 corners.

What is the problem?
Strange resize behavior. The resize of the frame doesn't follow the mouse position.

(Will attach simple test program)



 Comments   
Comment by dukke [ 29/Jan/09 ]

Created an attachment (id=13)
test program showing problem

Comment by kirillcool [ 29/Jan/09 ]

I don't see this on my environment - Vista SP 1 + Java 6u10.

What is your environment? Would it be possible to attach a small compressed
video that illustrates this (or perhaps host it on YouTube or Vimeo)?

Thanks
Kirill

Comment by dukke [ 30/Jan/09 ]

Strangely I can't reproduce the problem now, using the same jars.

I'll file this bug again if it happens.

By the way, answering to your question, I have Windows Vista SP1 and java 6
update 6.

Thanks,
Pedro DV

Comment by kirillcool [ 26/Apr/09 ]

Closing as WORKSFORME since this is not reproducible in my environment.

Thanks
Kirill





[FLAMINGO-35] command button text cut out Created: 29/Jan/09  Updated: 30/Jan/09  Resolved: 30/Jan/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File RibbonCutoff.java    
Issuezilla Id: 35

 Description   

Ribbon command button text appears cut out.

Will attach a simple test program.



 Comments   
Comment by dukke [ 29/Jan/09 ]

Created an attachment (id=11)
test program showing problem

Comment by kirillcool [ 29/Jan/09 ]

Confirmed to be reproducible. Will fix for the final 4.0 release.

Thanks
Kirill

Comment by kirillcool [ 29/Jan/09 ]

Should be fixed in the latest 5.1RC drop of Substance Flamingo plugin.

It no longer enforces min size (around 70*20, depending on the desktop font
settings) on command buttons in the ribbon. Instead, it respects the preferred
size as computed by the current resize policy.

Thanks for reporting this issue.
Kirill

Comment by dukke [ 30/Jan/09 ]

Tested it under latest version and works fine now.

Thanks,
Pedro DV





[FLAMINGO-34] Impossible to use ribbon without jribbonframe Created: 12/Jan/09  Updated: 12/Jan/09  Resolved: 12/Jan/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mustaukko Assignee: kirillcool
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 34

 Description   

When using jribbon inside an application that does not derive from jribbonframe
rendering of application menu throws an exception. This is due lines 119-121 in
BasicRibbonApplicationMenuUI (in those lines it queries JRF for JRibbon).

In my case: I have my jframe and changeable content in it. Impossible to use
ribbon in the way specified (more likely: I'd rather use it my way, it being
inside a panel).

Workarounds tried: expand JRF in my main frame, override getribbon to return
correct ribbon. FAILS DUE: private method initribbon (it adds extra ribbon to
the north).



 Comments   
Comment by kirillcool [ 12/Jan/09 ]

JRibbonFrame is the only supported way to have a ribbon with the full
functionality. The JRibbon constructor is made public only for those
applications that absolutely cannot use the JRibbonFrame. In such scenarios, the
JRibbon functionality will only be partial - by design. This includes, among the
rest, missing support for application menu button and key tips.

Closing this as WONTFIX.

Thanks
Kirill





[FLAMINGO-33] No Application Button (Diamond Button) Created: 17/Dec/08  Updated: 19/Dec/08  Resolved: 19/Dec/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 33

 Description   

Don't show app menu button when none is associated with the ribbon.



 Comments   
Comment by kirillcool [ 17/Dec/08 ]

Moving to version 4.0

Comment by kirillcool [ 19/Dec/08 ]

Support for not calling JRibbon.setApplicationMenu or calling it with null has
been added. In both cases the app menu button should be not showing.

Thanks
Kirill





[FLAMINGO-30] Ribbon resize width smaller throws IllegalStateException Created: 08/Dec/08  Updated: 08/Dec/08  Resolved: 08/Dec/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: ericscroger Assignee: kirillcool
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 30

 Description   

If I resize the ribbon bar horizontally to make the ribbon as small as possible,
I get an exception during layout of the ribbon because the actual 'collapse
kind' does match the expected kind, and the available width is larger than the
actual width. (see below)

The actual ribbon renders OK as far as I can tell, so I think this exception
looks like a debug print statement to me, and if so, the
RibbonLayout.layoutContainer() method should probably just return and not throw
the exception in a future release.

java.lang.IllegalStateException: Available width of 'Report' under ICON was
reported to be 56, but the actual collapse kind is HIGH_TO_LOW with width 42
at
org.jvnet.flamingo.ribbon.ui.BasicRibbonUI$RibbonLayout.layoutContainer(BasicRibbonUI.java:737)
at java.awt.Container.layout(Container.java:1432)
at java.awt.Container.doLayout(Container.java:1421)
at java.awt.Container.validateTree(Container.java:1519)
at java.awt.Container.validateTree(Container.java:1526)
at java.awt.Container.validateTree(Container.java:1526)
at java.awt.Container.validateTree(Container.java:1526)
at java.awt.Container.validateTree(Container.java:1526)
at java.awt.Container.validate(Container.java:1491)
at java.awt.Window.dispatchEventImpl(Window.java:2438)
at java.awt.Component.dispatchEvent(Component.java:4243)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at
com.lefthandnetworks.Hardware_API_GUI.MyEventQueue.dispatchEvent(MyEventQueue.java:193)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)



 Comments   
Comment by kirillcool [ 08/Dec/08 ]

The entire layout layer has been rewritten in version 4.0. Please try the latest
4.0dev drop to see whether this issue has been addressed.

Thanks
Kirill

Comment by ericscroger [ 08/Dec/08 ]

Works fine in 4.0. I would recommend closing as WONTFIX since it's fixed in 4.0.

Comment by kirillcool [ 08/Dec/08 ]

Moving to 4.0 for verification and fixing.

The entire layout layer has been rewritten to be more robust and flexible (see
[1]). This exception is no longer happening (and i'm not sure if it's thrown at
all). marking as WONTFIX.

Thanks
Kirill

[1] http://www.pushing-pixels.org/?p=874

Comment by kirillcool [ 08/Dec/08 ]

Actually, WORKSFORME would be a better resolution (at least in my view). WONTFIX
implies that it's either working as designed, and is not going to be fixed. But
it was already fixed

Comment by kirillcool [ 08/Dec/08 ]

Marking as WORKSFORME for version 4.0.

Comment by ericscroger [ 08/Dec/08 ]

Your choice on the status. You can definitely reproduce the exception in the
version 3.1 as stated, so I reckon you didn't test it there. After rereading
the status options, I see that LATER is probably better for this scenario:

LATER: The problem described is an issue which will not be fixed in this version
of the product.

Comment by kirillcool [ 08/Dec/08 ]

Doesn't really matter. Since i don't have resources to support older versions,
in my projects the bug reports are always moved to the latest dev branch to be
tested there. In this case, while it fails under 3.1, that code base is no
longer supported for bug fixes.

Thanks
Kirill





[FLAMINGO-20] create a JCommandButton from an Action Created: 22/Sep/08  Updated: 22/Sep/08  Resolved: 22/Sep/08

Status: Resolved
Project: flamingo
Component/s: common components
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: nderwin Assignee: kirillcool
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 20

 Description   

It would be helpful if a JCommandButton could be created from a
javax.swing.Action, similar to how a javax.swing.JButton can be created from an
Action.



 Comments   
Comment by kirillcool [ 22/Sep/08 ]

Currently i do not have plans to provide this functionality. Command buttons
require more information than is conveyed by the Action class (resizable icon
and kind are the two most important ones), and resorting to property names is
inferior when compared to specific API methods.

Closing as WONTFIX.





[FLAMINGO-22] getting exceptions when trying to integrate jribbon Created: 26/Sep/08  Updated: 05/Jun/09  Resolved: 05/Jun/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dennisnoto Assignee: kirillcool
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 22

 Description   

kirill,

Trying to put a ribbon in the open source project TN5250J which can be located
at http://tn5250j.sourceforge.net/. When I try to extend TN5250J JFrame with
your JRibbonFrame, I get null pointer exceptions in the layoutContainer. While
debugging the code I found a null pointer that is being returned from
ribbon.getSelectedTask() which causes For (JRibbonBand ribbonBand :
selectedTask.getBands()) to fail.

TN5250 is a rather large app, I can try and whittle down. You may just want to
bring the source down and extend the TN5250jFrame.java class. I took your
basiccheckribbon example and made it a class and changed JFRAME to my class in
TN5250jFrame.java.

If you have other ideas, I would be open to discuss. I thought that maybe I
could put your components on a JPanel, but looks like you require a jframe?

Thanks,

Dennis



 Comments   
Comment by kirillcool [ 26/Sep/08 ]

Do you have any content in the ribbon? If you have at least one ribbon task,
then the ribbon should always have the selected task. If you just extend the
JRibbonFrame and don't add any content to the ribbon, what's the point of
extending that class?

Thanks
Kirill

Comment by kirillcool [ 27/Sep/08 ]

Please do not reply directly to this e-mail. Click the link in this e-mail and
put the comments in the Issue Tracker.

To your comment - the class that you have send me is pretty much the copy of the
Flamingo test application. I don't understand your comment about extending
extending the TN5250J JFrame with the JRibbonFrame. The JRibbonFrame is the main
frame class, and you can subclass it to add additional functionality.

So that would look something like

public class TN5250JFrame extends JRibbonFrame

Just as in the example that you have sent me. Look in the BasicCheckRibbon for
the supported way to have the ribbon component in your application.

Thanks
Kirill

Comment by dennisnoto [ 27/Sep/08 ]

Kirill,

Sounds we are having trouble understanding each other.

Yes, I did take your BasicCheckRibbon example and changed the class name to
CRIRibbon. I then went into Tn5250jframe.java and made the change to replace
"extends JFRAME" with "extends CRIRibbon". Finally, in TN5250 when the frame was
created, I added the code to call ribbonInit, which is a duplicate of your
main.run method.

The exceptions are coming from your jar file in the BasicRibbonUI class which I
have no control. The below exception happens:

org.jvnet.flamingo.ribbon.ui.BasicRibbonUI$RibbonLayout.layoutContainer(BasicRibbonUI.java:655)

I did this as the easiest example just to try your product within the TN5250J
project.

Have I described the problem better?

Den

Comment by dennisnoto [ 27/Sep/08 ]

Sorry the complete exception is:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at
org.jvnet.flamingo.ribbon.ui.BasicRibbonUI$RibbonLayout.layoutContainer(BasicRibbonUI.java:655)

Comment by kirillcool [ 27/Sep/08 ]

Apologies for misunderstanding your hierarchy.

A question - why not to extend the JRibbonFrame directly and add the required
functionality before showing the frame for the first time? Why do you need to
copy-paste the entire code from the test application that just shows how to use
a ribbon.

Is it possible that your ribbonInit (i guess that it's a copy of configureRibbon
from BasicCheckRibbon) is called after you're doing setVisible(true) or pack()
on your main frame? In this case it's quite possible that this exception is
happening.

Thanks
Kirill

Comment by dennisnoto [ 27/Sep/08 ]

kirill,

I would agree with your assessment,but when I debug the application I make sure
that configureRibbon has executed before any pack/setVisable occurs in TN5250.
Seems to me that when AWT calls dolayout then it calls your dolayout and your
class cannot find the ribbons tasks??? ie

In BasicRibbonUI.RibbonLayout.layoutContainer
RibbonTask selectedTask = ribbon.getSelectedTask(); is null.

Your thoughts?

Den

Comment by kirillcool [ 27/Sep/08 ]

At that point (in the debugger), what does ribbon.getTaskCount() return? Or
alternatively you can see the contents of the JRibbon.tasks list and see how
many items are there.

Thanks
Kirill

Comment by dennisnoto [ 27/Sep/08 ]

While debugging
In initRibbon after configureRibbon
TaskCount is 5

When the call returns back to TN5250
TaskCount is 0

Doesn't make sense. Why would the ribbon loose it tasks; bands are gone too. It
like the class was lost?? No code was executed in TN5250 after the call?

Your thoughts?

Den

Comment by kirillcool [ 27/Sep/08 ]

Perhaps you have two different JRibbon instances? You can see in the JRibbon API
that once a task is added, there is no way to remove it (or all existing tasks).
You can see an object ID in the debugger or set a breakpoint in the JRibbon
constructor and see how many JRibbon objects are created in your app. The only
one should be created from the JRibbonFrame.initRibbon called from the
JRibbonFrame constructor that you're calling in your custom frame constructor.

Thanks
Kirill

Comment by dennisnoto [ 28/Sep/08 ]

kirill,

You were right, had an extra instance of the ribbon class. That problem is
fixed, but now I'm having an issue with the application hanging. While
debugging, the application will hang on wait() operations which no longer
complete when I use JRibbonFrame? The wait operations are in a splashscreen
class that creates a Window() with a Frame() to display a progress bar.

Your Thoughts?

Den

Comment by dennisnoto [ 28/Sep/08 ]

More info...

The wait() calls work the first three times until the below thread shows up.
When this thread is present in the stack, the wait() calls no longer complete.

Daemon Thread [Rollover cleaner for Flamingo ribbon bands] (Running)

Den

Comment by dennisnoto [ 28/Sep/08 ]

Some more info....

Looks like your code and TN5250 have overridden the update() and paint()
methods. This maybe the problem because in TN5250jSplashScreen, there is a
Notify() buried in the paint method.

In BasicRibbonUI
public void update(Graphics g, JComponent c)
public void paint(Graphics g, JComponent c)

In TN5250jSplashScreen
public void update(Graphics g)
public synchronized void paint(Graphics g)

Your thoughts?

Den

Comment by kirillcool [ 28/Sep/08 ]

This sounds like a possible EDT violation in the code. The code in
RolloverCleanerThread is accessing UI-related properties of the ribbon frame,
and is such is running on the EDT - with SwingUtilities.invokeLater. You can
test your code with Substance 5.0 release that tests the EDT violations on
component creation, or use the CheckThreadViolationRepaintManager from
SwingHelper project on swinghelper.dev.java.net

As i said once again - if you can provide a small (<100 lines) test class to
illustrate the issue, that would help me to analyze the problem on my machine.
The longer the test class is (certainly for downloading the entire project), the
less likely it is that i can get to it with the time i have.

Thanks
Kirill

Comment by dennisnoto [ 28/Sep/08 ]

More info ....

For a test, I changed the wait() to wait(1) to get around the notify. Then the
application hung on an invokeAndWait in the EventQueue which came from a
dispose() statement in TN5250jSplashScreen.

EventQueue.invokeAndWait(action) hangs

Seems that the object monitor has changed when using your product?? That would
be the only way I can think of why the calls to invokeAndWait calls don't work
anymore.

Your thoughts?

Den

Comment by kirillcool [ 28/Sep/08 ]

Just as i said before - use the proposed methods to detect whether you have EDT
violations in your code.

Thanks
Kirill

Comment by kirillcool [ 05/Jun/09 ]

Closing as WORKSFORME since there has been no communication from the originator
since last September. Please reopen if you have a small test application that
reproduces this issue under the latest 4.2dev drop.

Thanks
Kirill





[FLAMINGO-27] Must have at least ONE taskbar component Created: 29/Nov/08  Updated: 29/Nov/08  Resolved: 29/Nov/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: cicavey Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 27

 Description   

In integrating the ribbon into my own application, I discovered that there must
always be at least taskbar component, otherwise the internal taskbar panel will
be zero width resulting in a IllegalArgumentException in LinearGradientPaint.

Example code:

private static class RibbonTest extends JRibbonFrame
{
public RibbonTest(String title) throws HeadlessException

{ super(title); JRibbonBand band = new JRibbonBand("TestBand", new EmptyResizableIcon(16)); band.addCommandButton(new JCommandButton("Test Command", new EmptyResizableIcon(16)), RibbonElementPriority.TOP); band.setTitle("Band Title"); RibbonTask rt = new RibbonTask("TestTask", band); getRibbon().addTask(rt); // Required. Comment next line to see IllegalArgumentException getRibbon().addTaskbarComponent(new JButton("Test Taskbar")); }

Stack trace:
Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: Start
point cannot equalendpoint
at java.awt.LinearGradientPaint.<init>(LinearGradientPaint.java:271)
at java.awt.LinearGradientPaint.<init>(LinearGradientPaint.java:221)
at java.awt.LinearGradientPaint.<init>(LinearGradientPaint.java:157)
at
org.jvnet.substance.painter.gradient.StandardGradientPainter.paintContourBackground(StandardGradientPainter.java:99)
at
org.jvnet.substance.flamingo.ribbon.ui.SubstanceRibbonFrameTitlePane.paintTaskBarPanelOutline(SubstanceRibbonFrameTitlePane.java:567)
at
org.jvnet.substance.flamingo.ribbon.ui.SubstanceRibbonFrameTitlePane.paintComponent(SubstanceRibbonFrameTitlePane.java:524)
at javax.swing.JComponent.paint(JComponent.java:1027)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:564)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5122)
at
javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:277)
at javax.swing.RepaintManager.paint(RepaintManager.java:1217)
at javax.swing.JComponent._paintImmediately(JComponent.java:5070)
at javax.swing.JComponent.paintImmediately(JComponent.java:4880)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:803)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:714)
at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:694)
at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)



 Comments   
Comment by cicavey [ 29/Nov/08 ]

I did not post the complete example, Here is the entire code example:

package epi.resourcestream;

import java.awt.HeadlessException;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.SwingUtilities;
import javax.swing.UIManager;

import org.jvnet.flamingo.common.JCommandButton;
import org.jvnet.flamingo.common.icon.EmptyResizableIcon;
import org.jvnet.flamingo.ribbon.JRibbonBand;
import org.jvnet.flamingo.ribbon.JRibbonFrame;
import org.jvnet.flamingo.ribbon.RibbonElementPriority;
import org.jvnet.flamingo.ribbon.RibbonTask;
import org.jvnet.substance.skin.SubstanceBusinessBlackSteelLookAndFeel;

public class Init
{
private static class RibbonTest extends JRibbonFrame
{

public RibbonTest(String title) throws HeadlessException

{ super(title); JRibbonBand band = new JRibbonBand("TestBand", new EmptyResizableIcon(16)); band.addCommandButton(new JCommandButton("Test Command", new EmptyResizableIcon(16)), RibbonElementPriority.TOP); band.setTitle("Band Title"); RibbonTask rt = new RibbonTask("TestTask", band); getRibbon().addTask(rt); // Required ! getRibbon().addTaskbarComponent(new JButton("Test Taskbarcomponent")); }

}

public static void main(String[] args)
{
JFrame.setDefaultLookAndFeelDecorated(true);
try

{ UIManager.setLookAndFeel(new SubstanceBusinessBlackSteelLookAndFeel()); }

catch(Exception e)

{ System.out.println("Substance Raven Graphite failed to initialize"); }

SwingUtilities.invokeLater(new Runnable()
{
public void run()

{ JFrame frame = new RibbonTest("Test"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(500, 500); frame.setLocation(0, 0); frame.setVisible(true); }

});
}
}

Comment by kirillcool [ 29/Nov/08 ]

Needs to be fixed in both the core Flamingo (paints incorrect outlines) and
Substance Flamingo plugin (exception).

Thanks
Kirill

Comment by kirillcool [ 29/Nov/08 ]

This should be fixed in the latest 4.0dev of core Flamingo and 5.1dev of
Substance Flamingo plugin.

Thanks
Kirill





[FLAMINGO-28] Band w/ no command buttons cause StringIndexOOB exception Created: 30/Nov/08  Updated: 30/Nov/08  Resolved: 30/Nov/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: cicavey Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 28

 Description   

Created a band and didn't add any component to it, I expected and empty area. I
get a StringIndexOOB exception since the region ends up w/ negative with. I
understand that a band is useless w/o buttons, just thought maybe you could
throw a more useful exception or do something less painful.

public class Init
{
private static class RibbonTest extends JRibbonFrame
{

public RibbonTest(String title) throws HeadlessException

{ super(title); JRibbonBand band = new JRibbonBand("TestBand", new EmptyResizableIcon(16)); //band.addCommandButton(new JCommandButton("Test Command", new EmptyResizableIcon(16)), RibbonElementPriority.TOP); RibbonTask rt = new RibbonTask("TestTask", band); getRibbon().addTask(rt); // Required ! getRibbon().addTaskbarComponent(new JButton("Test Taskbarcomponent")); }

}

public static void main(String[] args)
{
JFrame.setDefaultLookAndFeelDecorated(true);
try

{ UIManager.setLookAndFeel(new SubstanceBusinessBlueSteelLookAndFeel()); }

catch(Exception e)

{ System.out.println("Substance Raven Graphite failed to initialize"); }

SwingUtilities.invokeLater(new Runnable()
{
public void run()

{ JFrame frame = new RibbonTest("Test"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setSize(500, 500); frame.setLocation(0, 0); frame.setVisible(true); }

});
}
}



 Comments   
Comment by kirillcool [ 30/Nov/08 ]

Should be fixed in the latest Substance Flamingo 5.1dev drop.

Thanks
Kirill





[FLAMINGO-19] EDT Violation in Breadcrumb Bar Created: 17/Sep/08  Updated: 22/Sep/08  Resolved: 22/Sep/08

Status: Resolved
Project: flamingo
Component/s: breadcrumb bar
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: aakashm Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 19

 Description   

Hi,

I'm using the RepaintManager checker from SwingHelper. I'm getting this
exception when I click the scroll "arrows" on the breadcrumb bar.

javax.swing.JScrollPane$ScrollBar[,0,0,0x0,hidden,layout=org.jvnet.substance.SubstanceScrollBarUI,alignmentX=0.0,alignmentY=0.0,border=,flags=20971840,maximumSize=,minimumSize=,preferredSize=,blockIncrement=10,orientation=HORIZONTAL,unitIncrement=1]
at java.lang.Thread.getStackTrace(Thread.java:1436)
at
com.geenergy.rep.Framework.substanceUI.CheckThreadViolationRepaintManager.checkThreadViolations(CheckThreadViolationRepaintManager.java:88)
at
com.geenergy.rep.Framework.substanceUI.CheckThreadViolationRepaintManager.addDirtyRegion(CheckThreadViolationRepaintManager.java:79)
at javax.swing.JComponent.repaint(JComponent.java:4732)
at java.awt.Component.repaint(Component.java:2952)
at
org.jvnet.substance.SubstanceScrollBarUI$3.adjustmentValueChanged(SubstanceScrollBarUI.java:1539)
at javax.swing.JScrollBar.fireAdjustmentValueChanged(JScrollBar.java:675)
at javax.swing.JScrollBar.access$100(JScrollBar.java:64)
at javax.swing.JScrollBar$ModelListener.stateChanged(JScrollBar.java:697)
at
javax.swing.DefaultBoundedRangeModel.fireStateChanged(DefaultBoundedRangeModel.java:348)
at
javax.swing.DefaultBoundedRangeModel.setRangeProperties(DefaultBoundedRangeModel.java:285)
at javax.swing.JScrollBar.setValues(JScrollBar.java:592)
at
javax.swing.plaf.basic.BasicScrollPaneUI.syncScrollPaneWithViewport(BasicScrollPaneUI.java:316)
at
javax.swing.plaf.basic.BasicScrollPaneUI$Handler.viewportStateChanged(BasicScrollPaneUI.java:1064)
at
javax.swing.plaf.basic.BasicScrollPaneUI$Handler.stateChanged(BasicScrollPaneUI.java:1006)
at javax.swing.JViewport.fireStateChanged(JViewport.java:1384)
at javax.swing.JViewport.setViewPosition(JViewport.java:1140)
at javax.swing.JViewport.scrollRectToVisible(JViewport.java:415)
at javax.swing.JComponent.scrollRectToVisible(JComponent.java:3063)
at
org.jvnet.flamingo.bcb.ui.BasicBreadcrumbBarUI$ScrollablePanel$1$1.run(BasicBreadcrumbBarUI.java:431)

Thanks,
Aakash



 Comments   
Comment by kirillcool [ 17/Sep/08 ]

Moving to version 4.0.

Comment by kirillcool [ 22/Sep/08 ]

This has been fixed in the first 4.0dev drop which features a significant
internal and external rewrite of the breadcrumb bar component. While the main
concepts are the same, the component has been heavily refactored to remove old
code inherited during the original code delivery.

The new JBreadcrumbBar component has a proper model-view separation with the
BreadcrumbBarModel class and the associated BreadcrumbPathListener and
BreadcrumbPathEvent classes. The cleanup of the internal painting implementation
will continue in the next few weeks with little changes planned to the component
API itself.

Thanks
Kirill





[FLAMINGO-14] Scroll bar in 'Format' button does not update when LnF changed Created: 08/Aug/08  Updated: 23/Aug/08  Resolved: 23/Aug/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mattnathan Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14

 Description   

In the demo application (
https://flamingo.dev.java.net/webstart/testBasicRibbon.jnlp ) click the format
button, then change the look and feel (to any look and feel I think) then click
the format button again. The scroll bar retains a similar look the original look
and feel, it looks like a similar effect to when cell renderers aren't updated
as a result of updateUI, in any case it is not the look and feel that is
currently selected.



 Comments   
Comment by kirillcool [ 08/Aug/08 ]

Thanks for reporting this issue. This will be addressed in the final 3.1 release
after i get back from a vacation.

Kirill

Comment by kirillcool [ 23/Aug/08 ]

Should be fixed in the latest 3.1dev drop and the WebStart.

Thanks for reporting this issue.
Kirill





[FLAMINGO-15] Double click on tab should hide ribbon Created: 08/Aug/08  Updated: 17/Dec/08  Resolved: 17/Dec/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: mattnathan Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 15

 Description   

In office double clicking on the tabs will hide the ribbon content, clicking on
tabs after this point will overlay the ribbon content on top of the document
content until focus is moved away from the ribbon, at which point the ribbon
content is hidden again.

Double clicking on the tabs will restore the original behaviour of always
showing the content.



 Comments   
Comment by kirillcool [ 08/Aug/08 ]

This is one of the known missing features in ribbon and will be implemented in
the future releases.

Thanks
Kirill

Comment by kirillcool [ 17/Sep/08 ]

Moving to version 4.0

Comment by kirillcool [ 17/Dec/08 ]

Closing as fixed. Support for minimizing the ribbon with API, Ctrl+F1 and
double-clicking task buttons has been added.

Thanks
Kirill





[FLAMINGO-16] Increase the scrollable block increment in galleries Created: 08/Aug/08  Updated: 23/Aug/08  Resolved: 23/Aug/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: mattnathan Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 16

 Description   

The expanded gallery view could be improved if the scrollable block increment
was to be increased. I'm not sure what Office does but the current 1 pixel block
increment make scrolling awkward when using this view.



 Comments   
Comment by kirillcool [ 08/Aug/08 ]

Thanks for reporting this issue. This will be addressed in the final 3.1 release
after i get back from a vacation.

Kirill

Comment by kirillcool [ 23/Aug/08 ]

Should be fixed in the latest 3.1dev drop and the WebStart to use higher values
for both scroll and block scroll on popup galleries.

Thanks for reporting this issue.
Kirill





[FLAMINGO-7] SVG Icons AsyncLoadlistener waiting on completion for cached icons Created: 11/Jul/08  Updated: 24/Jul/08  Resolved: 24/Jul/08

Status: Resolved
Project: flamingo
Component/s: common components
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: calum Assignee: kirillcool
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7

 Description   

If I create a SvgBatikResizableIcon and assign an AsynchronousLoadListener to
it, the first time, the AsyncListener will call completed, and updateUI() will
be called, however, if I supply the same, cached Icon instance to another
Button, the call to completed will not occur. The issue is that if I want to
wait for the Icon to be completed before setting it, there is no way to check
if the Icon is already loaded.

Would it be possible to add an isCompleted() method on the
SvgBatikResizableIcon, so that you can check whether to add the
AsynchronousLoadListener to the Icon, other wise the listener just hangs around
forever, or immediatly call completed() on the listener



 Comments   
Comment by kirillcool [ 11/Jul/08 ]

Is the isLoading() method not good enough for this purpose?

Thanks
Kirill

Comment by kirillcool [ 24/Jul/08 ]

Closing since no response received from the original poster on the isLoading()
method.





[FLAMINGO-6] button group rendering Created: 26/Jun/08  Updated: 06/Jul/08  Resolved: 06/Jul/08

Status: Resolved
Project: flamingo
Component/s: common components
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: redstar Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File exampleflamingo.jpg    
Issuezilla Id: 6

 Description   

While under substance the alternate highlighting of button groups in the command
button panel is pretty, under other looknfeels it can appear ugly.

Thus I'd like the option to instead display only a single background colour,
possibly having dividers to the side of button group headers/titles like the way
sections appear in windows explorer when set as 'show in groups'.



 Comments   
Comment by redstar [ 26/Jun/08 ]

Created an attachment (id=2)
example image

Comment by kirillcool [ 26/Jun/08 ]

This is a reasonable request.

Comment by kirillcool [ 06/Jul/08 ]

The visual difference between different button groups is now much milder, and
there are separators next to each button group title (painted in the
LAF-consistent style).

Thanks
Kirill





[FLAMINGO-3] columns not being resorted on resize Created: 19/Jun/08  Updated: 24/Jul/08  Resolved: 24/Jul/08

Status: Resolved
Project: flamingo
Component/s: common components
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: redstar Assignee: kirillcool
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File iconpopupPanel.jpg    
Issuezilla Id: 3

 Description   

I have a JIconPopupPanel and a JCommandButtonPanel with JCommandButton objects
inside.

I noticed that depending upon what parameters I give the JIconPopupPanel
constructor I get 2 different behaviours, both fo which are flawed.

Behaviour 1: It all works as expected however the actual area of the
iconpopuppanel extends past what it contains resulting in a huge area of empty
space underneath the last button group.

I can fix behaviour 1 by changing my constructor to:

icons = new JIconPopupPanel(panel, 0, 0);

Which fixes behaviour 1 and all appears to work fine until the window is
resized. Rather than reduce the number of columns or show a horizontal scroll
bar the icon popup panel resizes and you can see that the contents have not
resized. Half truncated icons are show where the button extends beyond the edge
of the icon popup panel and beyond which lie the rest of the columns.



 Comments   
Comment by redstar [ 19/Jun/08 ]

Created an attachment (id=1)
A screenshot of the behaviour 1 bug, setting the second parameter of the constructor to a none zero value results in this

Comment by redstar [ 19/Jun/08 ]

hmm version 3.1 not 1.1, not sure why it wouldn't let me choose 3.1

Comment by kirillcool [ 19/Jun/08 ]

There have been major improvements in supporting resize on command button panel
component (in addition to allowing column-first fill mode). Are you running
under the latest 3.1dev drop?

If so, and the problem still persists, please attach a small test app along with
the scenario to reproduce the problem.

Moving to newly added 3.1 version tag.

Thanks
Kirill

Comment by kirillcool [ 24/Jul/08 ]

Closing as INVALID since no response received for a test app. Feel free to
reopen if this behavior is still present under the latest 3.1dev drop + a small
test app to reproduce the scenario.

Thanks
Kirill





[FLAMINGO-5] Command Button Resizable Icons Created: 26/Jun/08  Updated: 06/Jul/08  Resolved: 06/Jul/08

Status: Resolved
Project: flamingo
Component/s: common components
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: redstar Assignee: kirillcool
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5

 Description   

I've got several command buttons in a ribbon bar behaving as toggles, and it
would be of great help if I could change the icons on the command buttons, this
way users wouldnt have to read the label to see the current state of the toggle,
and I can better represent the function of those buttons.

For example I have a toggle indicating whether the user is ready or not, for
which I have a switch icon in shades of red and green, I'd like it if I could
use either icon and switch the two at runtime.



 Comments   
Comment by kirillcool [ 26/Jun/08 ]

Did you see the setIcon() API?

Comment by kirillcool [ 06/Jul/08 ]

The setIcon API allows changing the existing icon. Closing as INVALID.





[FLAMINGO-2] ProgressGlassPane doesn't handle resize or color assignment changes Created: 26/Feb/07  Updated: 31/Jul/08  Resolved: 31/Jul/08

Status: Resolved
Project: flamingo
Component/s: common components
Affects Version/s: 1.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: jmorgan Assignee: kirillcool
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2

 Description   

When the JRootPane owner changes size or the 3 colors are modified after the
GlassPane has painted once, the light/mid/dark BufferedImages are not updated.
A boolean attributeModified flag that is set by a JRootPane resize and color
change request could manage this. A ComponentListener/Adapter.componentResized
could handle the width changed part and the setGlassPaneColors method the other
part. Then, in the paint method, this boolean flag could trip a recreation of
the 4 BufferedImages. This would be safer than just setting the oddLine
BufferedImage to null. (This flag would also need to be initialized to true for
the initial creation.)



 Comments   
Comment by kirillcool [ 26/Feb/07 ]

The resize should already be handled by the 2.0dev drop. The color change will
be fixed.

Thanks
Kirill

Comment by kirillcool [ 31/Jul/08 ]

The progress glass pane has been removed from Flamingo component suite. Marking
this issue as WONTFIX.





[FLAMINGO-4] Command Button in ribbon bar and SetText Created: 22/Jun/08  Updated: 22/Jun/08  Resolved: 22/Jun/08

Status: Resolved
Project: flamingo
Component/s: common components
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: redstar Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4

 Description   

I have a button in my ribbon bar which I use to lock and unlock the game being
hosted. So I want it to say 'lock the game' and when I click on it the game gets
locked and it changes to 'unlock the game'. However SetText() has no effect on
the button at all.

There's no way to remove the button and re-add a new button with the new text
either, it seems once the text is set in the constructor, its set for the life
of the button. I would have to recreate the entire ribbon bar it seems to get
around this =\.



 Comments   
Comment by kirillcool [ 22/Jun/08 ]

Fixed in the latest 3.1dev drop. Calling setText() will have effect on the
matching command button.





[FLAMINGO-1] Update scroller buttons on breadcrumb bar resize Created: 11/Feb/06  Updated: 11/Feb/06  Resolved: 11/Feb/06

Status: Resolved
Project: flamingo
Component/s: breadcrumb bar
Affects Version/s: 1.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: kirillcool Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1

 Description   

The scroller buttons are set only when the path is updated. When the application
is resized, they are not updated (should be shown / hidden).



 Comments   
Comment by kirillcool [ 11/Feb/06 ]

Fixed - added a component listener on the breadcrumb bar.





[FLAMINGO-66] Right to Left Language Support Created: 21/Dec/09  Updated: 21/May/10  Resolved: 21/May/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Improvement Priority: Minor
Reporter: dhennig Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 66

 Description   

With Java being Unicode, the ribbon should support right-to-left languages like
arabic.

As far as my test show, the ribbon stays left-aligned after
a call like frame.applyComponentOrientation. Even worse, the
tabs are cluttered very narrow on the right edge of the
window.



 Comments   
Comment by kirillcool [ 21/Dec/09 ]

Marking this as ENHANCEMENT. The RTL support is on the long term plan, but i
don't have any schedule for when this will be available. If this is important to
your application, you're more than welcome to explore the codebase to see what
needs changing.

Thanks
Kirill

Comment by kirillcool [ 21/May/10 ]

http://www.pushing-pixels.org/?p=1723

Forgot to close this.





[FLAMINGO-42] JRibbonFrame should override setContentPane() to throw IllegalArguementException Created: 26/Apr/09  Updated: 26/Apr/09  Resolved: 26/Apr/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Improvement Priority: Minor
Reporter: flynnk Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 42

 Description   

Calling setContentPane() on JRibbonFrame with a JPanel results in the ribbon
failing at runtime with an error about the "ribbon not being visible."
Regardless, for consistency with the rest of the API (such as setJMenuBar,
setLayout, etc.), it would be better to just prevent this method from being called.

I found this while adapting an existing application to use the JRibbonFrame
parent class instead of JFrame; others may see the same bug when adapting an
existing frame.

This is a low priority issue, now that I've figured out what I was doing wrong.



 Comments   
Comment by kirillcool [ 26/Apr/09 ]

This has been added in the latest 4.1dev drop.

Thanks
Kirill





[FLAMINGO-26] Over -> Press -> Out -> Over does not display correctly Created: 20/Nov/08  Updated: 23/Dec/08  Resolved: 23/Dec/08

Status: Resolved
Project: flamingo
Component/s: common components
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: mattnathan Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File Improved_Rollover_Support_In_JCommandButton.patch    
Issuezilla Id: 26

 Description   

Pressing a command button then hovering out then over again does not display the
button correctly. Compare the JCommandButton with a standard JButton to see the
difference.



 Comments   
Comment by mattnathan [ 20/Nov/08 ]

Created an attachment (id=10)
Patch to improve the rollover support of JCommandButton

Comment by mattnathan [ 20/Nov/08 ]

I've added a patch which improves the behaviour of the rollover support.

There is one issue with the patch, when running the JRibbon demo the some
buttons do not show their background when they should do on the first paint.
This resolves itself on subsequent paints.

The patch also removes the <paint over the whole button before painting the
action and popup areas> line of code as this gave artefacts when painting
translucently.

Hope this helps

Comment by kirillcool [ 22/Nov/08 ]

Thanks for the scenario and the fix. I will look into this in the next few days.

Kirill

Comment by kirillcool [ 23/Dec/08 ]

Apologies for taking so long to address this issue.

The proposed patch has been applied, except the line that removes the painting
of the main background layer. Commenting that line results in incorrect painting
of non-flat command buttons.

Thanks
Kirill





[FLAMINGO-21] Ribbon task highlighted when over gallery Created: 24/Sep/08  Updated: 20/Nov/08  Resolved: 20/Nov/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: mattnathan Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File AWTRolloverListener_JRibbonBand.patch    
Issuezilla Id: 21

 Description   

When a gallery is expanded the ribbon task ui for all LnFs still gets
un/highlighted even when the mouse is over the gallery popup.

Steps to reproduce:

1) open a ribbon demo (i.e. BasicCheckRibbon)
2) click the expand arrow next to the gallery (i.e. the one in Quick Styles)
3) move the mouse within the popup so that it crosses the now hidden task group
4) notice that the task group gets un/highlighted when the mouse is over it even
though it's not directly over it

This also happens with task groups that are not the owner of the expanded
gallery. To reproduce resize the ribbon so that the gallery popup would overlap
another task group and repeat from above.

I think this is a problem with the
BasicRibbonBandUI$RolloverCleanerThread.iteration() method.



 Comments   
Comment by kirillcool [ 24/Sep/08 ]

Moving to version 4.0 for fixing. The fix indeed will have to account for the
visible popup panels in the rollover tracker thread.

Thanks
Kirill

Comment by kirillcool [ 03/Oct/08 ]

Should be fixed in the latest 4.0dev drop.

Thanks for reporting this issue.
Kirill

Comment by mattnathan [ 07/Oct/08 ]

I believe this problem still appears but now when over the paste popup in the
new shortcut toolbar .

To reproduce, open the BasicCheckRibbon test class -> click the down arrow next
to the paste shortcut at the top -> move down when over the popup and notice the
highlighting of the group.

Note this does not happen when over the new start menu

Comment by mattnathan [ 07/Oct/08 ]

Note: also happens with all popup menus, not just te paste shortcut popup.

Easiest to see with the Copy popup in the example app

Comment by kirillcool [ 07/Oct/08 ]

Thanks for testing the fix and reopening on the popup menus. Needs to be fixed.

Kirill

Comment by kirillcool [ 13/Oct/08 ]

This should be fixed since all the popups are now using the new unified popup
layer. There are no more JPopupMenus in Flamingo.

Thanks
Kirill

Comment by mattnathan [ 13/Oct/08 ]

Unfortunately it looks like the problem is not yet fixed as of the most recent
HEAD revision today.

The symptoms have now changed slightly in that instead of the task group
changing to the roll-over state it now flashes in the roll-over state before
returning to the non-roll-over state.

This can be seen when opening any pop-up (either gallery or not) and while it is
open moving the mouse over buttons in the main ribbon component.

E.G. click the down arrow in the paste shortcut menu, then move your mouse
between the 'Styles1' and 'Styles2' command buttons.

Also, not sure if this is relevant but it does not manifest when moving between
the buttons in the same button group.

Comment by kirillcool [ 13/Oct/08 ]

One more try

The previous decision was a little overly complicated. The latest 4.0dev drop
only shows rollover effects on ribbon bands when there are no popups. When there
is at least one popup, there are no rollover effects on ribbon bands.

Thanks
Kirill

Comment by mattnathan [ 06/Nov/08 ]

Sorry to keep reopening this issue but it's still not fixed.

The problem still presents when using anything other than the Flamingo popups.
For example:

  • when using a JDialog (even a modal one) - try clicking on the 'expand button'
    and using those dialogs
  • when using a standard java popup over the top of the ribbon - make the ribbon
    frame short in height and move it close to the bottom of your screen then click
    the look and feel JComboBox to see this
  • when using a native popup - try right-clicking on the title bar to show the
    context menu
  • when using any other window - open any window and overlay it over your ribbon
    to see the group light up
Comment by kirillcool [ 06/Nov/08 ]

Thanks for reporting these. Perhaps Window.isActive / Window.isFocused should
take part in deciding whether the band has rollover status. Not sure how to
tackle the combobox though... Perhaps that would be left as a "feature".

Thanks
Kirill

Comment by kirillcool [ 07/Nov/08 ]

I have added the check for active and focusable windows, and i don't think that
i will go any further than that. I've played with other applications, and they
don't prevent rollover effects when the focus is on another program. I've tried
with Firefox (hovering over the links), Eclipse (hovering over the package
explorer) and Windows Explorer itself. As such, the current cases where the
ribbon band rollover is shown even though technically it shouldn't are
acceptable to me.

Thanks
Kirill

Comment by mattnathan [ 14/Nov/08 ]

While I'm not re-opening this issue (this have been run into the ground already)
I think that there is still a better solution to this problem, for example the
mouse over the window title bar pop-up still produces a roll-over effect.

I guess the only way to really solve this would be to not use a separate thread
to monitor mouse movement and instead rely on the basic inbuilt event handling
instead.

A few options off the top of my head.

1) Use a glasspane/layered pane approach with event forwarding to register the
roll-over (like JXLayer)
2) Add a listener to every child of the group to watch for mouse entered events
3) Manually process events from the EventQueue to watch out for mouse events
that would be interesting

Unfortunately I can't find any suitable component level API to implement that
would give the desired effect (Container.getMouseEventTarget comes close but is
package-private).

Any way, good work on the fixes

Comment by mattnathan [ 19/Nov/08 ]

Created an attachment (id=9)
Patch to add new rollover support to JRibbonBand

Comment by mattnathan [ 19/Nov/08 ]

Kirill,

I've added a patch to this issue that demonstrates an alternative method of
providing rollover support. This method is based on the method used by
JInternalFrame to become selected when a child component becomes focused.

I haven't done extensive tests on it other than to see if it works or not.
Generally speaking the band will be rolled over when any children will be rolled
over.

Comment by kirillcool [ 19/Nov/08 ]

Thanks for the patch. I took the liberty of modifying it slightly, ripping out
the old code and creating a supported way to indicate mouse enter / exit for the
UI delegate. The code is in CVS, downloads section and the WebStart demo.

Kirill

Comment by mattnathan [ 20/Nov/08 ]

Tested and works well





[FLAMINGO-17] Focus ring on the wrong item in collapsed gallery (Substance LnF) Created: 16/Sep/08  Updated: 05/Jun/09  Resolved: 05/Jun/09

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Minor
Reporter: mattnathan Assignee: kirillcool
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File Screenshot-Ribbon longer title to check contextual tabs.png    
Issuezilla Id: 17

 Description   

(Sorry for submitting here but the substance-flamingo issue tracker hasn't got
the required components)

Under substance look and feel (i.e. from the demos at
http://www.pushing-pixels.org/?p=500 ), when clicking on an item in the
collapsed gallery view the keyboard focus ring (the dotted border) appears over
the wrong item, generally the item to the right of the clicked item, though not
always as can be seen when choosing an item from the expanded or non-first-line
of the gallery.

Haven't tested under other look and feels.



 Comments   
Comment by mattnathan [ 16/Sep/08 ]

Created an attachment (id=5)
Screen showing focus ring on item to right of just clicked item

Comment by kirillcool [ 17/Sep/08 ]

Moving to version 4.0.

Couldn't reproduce on standalone toggle buttons (placed in the same group). Need
to investigate further why this happens only in ribbon gallery component.

Comment by mattnathan [ 13/Oct/08 ]

I think I found another instance of this problem that reproduces under all look
and feels. It manifests slightly differently but is probably the same problem.

To reproduce:
1) launch the ribbon demo
2) open the styles gallery pop-up
3) click on 'Style 3'
4) click on 'Style 2' once the pop-up has been hidden (make sure you don't roll
over the 'State 3' button when doing this)

Note that the 'Style 3' command button still remains in the 'hover' state until
you hover over that button again; even if you show the gallery pop-up again.

Comment by kirillcool [ 05/Jun/09 ]

The painting of focus ring has been removed from the command buttons. Closing
this as INVALID since it is no longer relevant.

Thanks
Kirill





[FLAMINGO-79] Really trivial punctation issue on resize policies error Created: 30/Jul/10  Updated: 31/Jul/10  Resolved: 31/Jul/10

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Trivial
Reporter: flynnk Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 79

 Description   

builder.append("Ribbon band '" +
ribbonBand.getTitle() +
" has the following resize policies\n");

is missing the close quote mark. So you get errors like:

Ribbon band 'Location has the following resize policies

instead of

Ribbon band 'Location' has the following resize policies

Yep, this is the most trivial bug ever. I'm mainly filing it because I was
actually confused by the incorrect punctuation (I had forgotten my ribbon band
names). It's also rather easy to fix...



 Comments   
Comment by kirillcool [ 30/Jul/10 ]

Should be fixed in the latest 5.0RC

Thanks
Kirill

Comment by flynnk [ 31/Jul/10 ]

Thanks!





[FLAMINGO-47] package distribution into directory Created: 03/Jun/09  Updated: 28/Nov/09  Resolved: 28/Nov/09

Status: Resolved
Project: flamingo
Component/s: base
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Improvement Priority: Trivial
Reporter: thhart Assignee: kirillcool
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 47

 Description   

Only a very little hint, please package the distribution into a directory like
flamingo-4.1
I believe this is standard nowadays and makes a start easier



 Comments   
Comment by kirillcool [ 28/Nov/09 ]

Seems that this issue has not been addressed on my part. I do not have plans to
change the distribution packaging of Flamingo in the foreseeable future.

Thanks
Kirill





[FLAMINGO-29] task auto-hide position and cpu problem Created: 05/Dec/08  Updated: 17/Dec/08  Resolved: 17/Dec/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Trivial
Reporter: houtman Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 29

 Description   

Hi,

I compiled the version (5-dec-08) against jdk 1.6u10
When i doubleclick the ribbontask-title to make it 'auto-hide' it sometimes
pops up here:
+-----------------

( )+-------+----
( ) title1 title2
----------+---
..
.. <--- ?
-------------
Band1a Band1b
-------------
Bands are working. One repaint hides the misplaced ribbon-bands.

Changing from 'auto hide' to 'always visibe' and vice-versa,
my total cpu(core2duo) stays using about 20% kernel time and 50% total cpu.

But my buttons are not slow yet..
From then on, when i set it to 'not auto-hide',
the kernel time goes up another 20%, but total cpu stays 50%
(ive got core2duo but both cpus use about 50%..)
and the whole UI is slugish

Changing the size of my JFrame always recovers from both.
There is no debug-output

I used the dev4.0(5-nov-08) version in my app which didnt have that problem
Hope this explanation helps.

Regards,
Roland



 Comments   
Comment by kirillcool [ 05/Dec/08 ]

Would you mind attaching a picture instead of the schematics? Also, is this only
happening when you build Flamingo yourself? I would need to see a sample program
with exact sequence of steps so that i can reproduce this on my machine.

The CPU issue is a known one. Sometimes an infinite layout / repaint loop is
happening which can be solved by resizing the frame. This will be fixed before
the final release.

In the future please consider filing separate bug reports for separate problems,
so that they can be tracked independently.

Thanks
Kirill

Comment by kirillcool [ 05/Dec/08 ]

The CPU issue should be addressed.

As i said before, please attach a sample screenshot that illustrates the
incorrect position of ribbon bands, along with simple test app and exact
scenario that reproduces it.

Thanks
Kirill

Comment by kirillcool [ 17/Dec/08 ]

Closing this as FIXED - the CPU problem was fixed. If you have a reproducible
scenario for the incorrect band popup location, please create a new CR with
code, screenshots and the step-by-step instructions on how to reproduce the
behavior.

Thanks
Kirill





[FLAMINGO-24] ArrayIndexOutOfBoundsException in empty tabs Created: 13/Nov/08  Updated: 13/Nov/08  Resolved: 13/Nov/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Trivial
Reporter: mattnathan Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 24

 Description   

The following exception is thrown when switching to empty tabs in the standard
ribbon demo.

Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.get(ArrayList.java:324)
at org.jvnet.flamingo.ribbon.RibbonTask.getBand(RibbonTask.java:99)
at
org.jvnet.flamingo.ribbon.resize.CoreRibbonResizeSequencingPolicies$RoundRobin.next(CoreRibbonResizeSequencingPolicies.java:52)
at
org.jvnet.flamingo.ribbon.ui.BasicRibbonUI$RibbonLayout.layoutContainer(BasicRibbonUI.java:736)
at java.awt.Container.layout(Container.java:1398)
at java.awt.Container.doLayout(Container.java:1387)
at java.awt.Container.validateTree(Container.java:1485)
at java.awt.Container.validateTree(Container.java:1491)
at java.awt.Container.validateTree(Container.java:1491)
at java.awt.Container.validateTree(Container.java:1491)
at java.awt.Container.validate(Container.java:1457)
at javax.swing.RepaintManager.validateInvalidComponents(RepaintManager.java:670)
at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:127)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

To reproduce simply click on the Filler 1 or Filler 2 tabs under the core ribbon
test app, any look and feel.



 Comments   
Comment by kirillcool [ 13/Nov/08 ]

Moving to P5. It's highly unlikely that real applications will have empty tasks

  • they are there in the test app just to make enough room for the title under
    Substance LAF when contextual task groups are showing. Will need to fix nonetheless.

Thanks
Kirill

Comment by kirillcool [ 13/Nov/08 ]

Should be fixed in the latest 4.0dev drop.

Thanks
Kirill





[FLAMINGO-25] NPE at BasicRibbonBandUI$RolloverCleanerThread$1.run Created: 14/Nov/08  Updated: 14/Nov/08  Resolved: 14/Nov/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Trivial
Reporter: houtman Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 25

 Description   

When my app is running for some time(an hour of doing absolutely nothing),
it gets these npe's. it runs in the hundreds. one per minute maybe.
As a result, the complete app. doesn't redraw itself.

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at
org.jvnet.flamingo.ribbon.ui.BasicRibbonBandUI$RolloverCleanerThread$1.run(BasicRibbonBandUI.java:645)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)



 Comments   
Comment by kirillcool [ 14/Nov/08 ]

Should be addressed in the latest 4.0dev drop.

Thanks
Kirill





[FLAMINGO-13] preferredPopupMaxVisibleButtonRows in addRibbonGallery is off by 1 Created: 02/Aug/08  Updated: 02/Aug/08  Resolved: 02/Aug/08

Status: Resolved
Project: flamingo
Component/s: ribbon
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Trivial
Reporter: flynnk Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File notenoughspace.jpg    
Issuezilla Id: 13

 Description   

If you specify 4 for the preferredPopupMaxVisibleButtonRows value to
addRibbonGallery, you get 3 visible rows in the popup. This can be seen in the
JRibbon demo application, which specifies 4 rows, and gets 3 on the Quick Styles.

This is not that big a deal (P5), but probably worth tightening up.



 Comments   
Comment by kirillcool [ 02/Aug/08 ]

The specific example that you're using has three visible rows because there are
also two group headers visible. If you scroll to the bottom, you would see four
button rows visible.

So, the parameter name really means "preferred popup max visible button rows
when no group headers are visible". Otherwise, the implementation would have to
continuously shrink and expand the popup window height as you scroll up and down
the contents.

Marking as INVALID since the current behavior is what is designed.

Thanks
Kirill

Comment by kirillcool [ 02/Aug/08 ]

Marked FIXED incorrectly.

Comment by kirillcool [ 02/Aug/08 ]

Marking as INVALID.

Comment by flynnk [ 02/Aug/08 ]

Hmmm. I would contend that since the group headers are always visible, you
should probably calculate enough space to include at least one group header.
However, I'm not sure that is the only problem.

Even if you scroll to where no group headers are visible, there is still not
enough room for the specified number of rows. I'll attach a screenshot
momentarily to show what I mean.

Comment by flynnk [ 02/Aug/08 ]

Created an attachment (id=4)
Screenshot illustrating the problem

Comment by flynnk [ 02/Aug/08 ]

In the attached screenshot, I've scrolled to the bottom where no group headers
are visible, and the top row is still cut off.

I agree that it would be hideous to change to handle the headers on the fly, but
it would seem like a compromise would be to include enough space for the first
required group header.

Comment by kirillcool [ 02/Aug/08 ]

Yes, right now the preferred height does not include the top / bottom insets and
inner-row gaps. This should be addressed - reopening this issue.

Thanks
Kirill

Comment by flynnk [ 02/Aug/08 ]

Makes sense. This is not a really big deal, but I think little things like this
are important to how the overall API/widget is perceived, and it did throw me
for a loop when it first happened.

Comment by kirillcool [ 02/Aug/08 ]

The latest 3.1dev drop should respect the gaps, insets and one title string in
the preferred height of the ribbon gallery popup panel.

Thanks
Kirill





[FLAMINGO-9] build.xml lib mismatch Created: 27/Jul/08  Updated: 27/Jul/08  Resolved: 27/Jul/08

Status: Resolved
Project: flamingo
Component/s: base
Affects Version/s: 3.1
Fix Version/s: milestone 1

Type: Bug Priority: Trivial
Reporter: lorselli Assignee: kirillcool
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9

 Description   

in the build.xml the flamingo.module.classpath point to forms-1.2.0.jar while in
the lib the jgoodie forms module is version 1.1.0.



 Comments   
Comment by kirillcool [ 27/Jul/08 ]

Both CVS [1] from three days ago and the downloadable zip file have
forms-1.2.0.jar in the build.xml. Where do you see the reference to forms-1.1.0.jar?

[1]
https://flamingo.dev.java.net/source/browse/*checkout*/flamingo/build.xml?content-type=text%2Fplain&rev=1.28

Comment by lorselli [ 27/Jul/08 ]

the build.xml is correct with forms-1.2.0.jar but the jar in the lib directory
is 1.1.0 version and it should be updated

[1]
https://flamingo.dev.java.net/source/browse/flamingo/lib/forms-1.1.0.jar?rev=1.1&view=log

Comment by kirillcool [ 27/Jul/08 ]

CVS has been updated to contain forms-1.2.0.jar

Thanks
Kirill





[FLAMINGO-81] SvgBatikIcon allocates thread pool but never shuts it down Created: 03/Aug/10  Updated: 03/Aug/10

Status: Open
Project: flamingo
Component/s: common components
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Blocker
Reporter: flynnk Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 81

 Description   

SvgBatikIcon allocates a static thread pool:

private static ExecutorService loadService = Executors.newFixedThreadPool(5);

but never calls shutdown() on this. This means that if you ever create an SVG
icon, you hang the shut down sequence (forcing a System.exit(0) call) since the
VM won't shut down when the event thread shuts down after the last window is
disposed.

Workaround is to not use SVG icons...






[FLAMINGO-59] Allow JRibbonFrames to be garbage collected after disposal Created: 23/Nov/09  Updated: 25/Nov/09

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Improvement Priority: Critical
Reporter: flynnk Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 59

 Description   

JRibbonFrame registers several listeners with the AWT Toolkit that are not
removed when the window is disposed(). The culprits are the AWTEventListener
and KeyTipManager.KeyTipListener registered in initRibbonFrame().

If we open up a JRibbonFrame and then close it, all resources associated with
that frame are held onto as it cannot be garbage collected due to these
listeners. This makes a pattern where we construct and show JRibbonFrames on
demand, and then destroy them when they are closed difficult due to the
resulting memory leak.

Since JRibbonFrame is the only supported way of accessing the Ribbon, it is very
hard to work around this. For the AWTEventListener you can work out which
listener the constructor added in a subclass and hold on to a reference to it to
remove it when the frame is closed, but for the key tip listener, there is no
way to view the current listener list and grab the last entry. We could
probably work around this if the KeyTipManager had a public method to return all
listeners--if the larger issue is more difficult to fix in the short term, the
addition of a getKeyTipListeners() method would likely enable a workaround.

These references were from tracing down what was referencing the JRibbonFrame in
the NetBeans heap walker.



 Comments   
Comment by kirillcool [ 25/Nov/09 ]

Moving to version 5.0





[FLAMINGO-86] Memory "leak" in BasicCommandPopupMenuUI Created: 30/Nov/10  Updated: 30/Nov/10

Status: Open
Project: flamingo
Component/s: common components
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: heigum Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 86

 Description   

Hi,after some memory analysis on our (Exie's) Swing application I have found what appears to be a memory problem.

The method org.pushingpixels.flamingo.internal.ui.common.popup.BasicCommandPopupMenuUI#uninstallListeners()

line 503
does: PopupPanelManager.defaultManager().addPopupListener(this.popupListener);

instead of: PopupPanelManager.defaultManager().removePopupListener(this.popupListener);

To me this seem to be incorrect, I admit that there might be aspects of the code I don't understand. After recompiling with
this change. The detected memory leak in our system was gone. And no new problems were introduced to the application.

Hope this isn't a duplicate I tried searching for similar problems couldn't find any.

-Jørn






[FLAMINGO-87] Missing License Created: 12/Jan/11  Updated: 12/Jan/11

Status: Open
Project: flamingo
Component/s: base
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: deleted_user Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 87

 Description   

The following source file has no license attached:
src/org/pushingpixels/flamingo/api/svg/TranscoderListener.java

Please could you add the BSD license header used in the remainder of the source?

Thanks,
Andy






[FLAMINGO-83] Add popup menu to JRibbon component Created: 20/Sep/10  Updated: 20/Sep/10

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: hoesterholt Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 83

 Description   

I can add a popupMenu to a JRibbon using the following code:

JRibbon _toolbar=_ribbonFrame.getRibbon();
final JPopupMenu minimize=new JPopupMenu();
JMenuItem itm=new JMenuItem(_.t("Toggle Ribbon"));
itm.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e)

{ _toolbar.setMinimized(!_toolbar.isMinimized()); }

});
minimize.add(itm);

{
for(int n=_toolbar.getComponentCount(),i=0;i<n;i++) {
Component c=_toolbar.getComponent;
if (c instanceof JScrollablePanel)

{ ((JComponent) c).setComponentPopupMenu(minimize); }

}
}

However, it would be nice if the same were possible to add the popup menu, using
this line of code:

_toolbar.setComponentPopupMenu(minimize)






[FLAMINGO-84] Not shown popup at JCommandButton Created: 21/Sep/10  Updated: 21/Sep/10

Status: Open
Project: flamingo
Component/s: common components
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: eshkel Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 84

 Description   

The popup can fall in state when it not shown longer.

This situation reproduced with next snippet of code.

/******************************************************************************/
JFrame frame = new JFrame();
frame.setSize(640, 480);
final JCommandButton btn = new JCommandButton("Call", null);
btn.setCommandButtonKind(CommandButtonKind.ACTION_AND_POPUP_MAIN_ACTION);
btn.setDisplayState(CommandButtonDisplayState.MEDIUM);
btn.setPopupCallback(new PopupPanelCallback()
{
public JPopupPanel getPopupPanel(JCommandButton commandButton)

{ JCommandPopupMenu menu = new JCommandPopupMenu(); menu.addMenuButton(new JCommandMenuButton("test1", null)); menu.addMenuButton(new JCommandMenuButton("test2", null)); return menu; }

});

btn.addActionListener( new ActionListener()
{

@Override
public void actionPerformed(ActionEvent e)

{ btn.doPopupClick(); }

});

JPanel content = new JPanel(new FlowLayout());
content.add(btn);
frame.getContentPane().add(content);

frame.setVisible(true);
/******************************************************************************/

1. Press popup button (\/).
2. Press 'Call' button when popup is shown.

After that the popup button (\/) don't show the popup when pressed.

Use case:
If user press 'Call' button but primary phone number is not defined - show other
available phone numbers.






[FLAMINGO-78] Labels are too close Created: 23/Jul/10  Updated: 24/Jul/10

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: JPEG File labelsTooCloseRibbonComponent.jpg    
Issuezilla Id: 78

 Description   

Refer to issue 77 for the test case.

The labels are too close to the RibbonComponent. I'll attach an image
illustrating this.



 Comments   
Comment by dukke [ 23/Jul/10 ]

Created an attachment (id=37)
Image illustrating the issue

Comment by kirillcool [ 23/Jul/10 ]

If this is still reproducible under the latest 5.0RC with fix for issue 77, i
will need to see a small test application.

Comment by dukke [ 24/Jul/10 ]

Just tried latest jars. These issue is also fixed.
THanks.





[FLAMINGO-82] Help button could also have a tooltip Created: 30/Aug/10  Updated: 30/Aug/10

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: hoesterholt Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 82

 Description   

In MS Word, the help button has a tooltip. Although not a big issue, it would be
great if Flamingo Ribbon could also have a (rich)tooltip for the help button.






[FLAMINGO-68] ComboBox popup, contained in collapsed ribbon is incorectly rendered on windows Created: 26/Mar/10  Updated: 29/Mar/10

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: krzych_nowak Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 68

 Description   

When displaying the combobox poup on windows, part of the popup is rendered
behind the collapsed ribbon.
Steps to reproduce:

  • Collapse ribbon
  • Click on task to show the ribbon (ribbon is still in 'collapsed' state, and it
    will be hidden when the mouse click outside it)
  • Click on the empty area of near the combobox (so that ribbon has focus)
  • Click on the combobox arrow to display the combobox popup with items
    Result: part of the popup is drawn as if behind 'floating' ribbon

This bug can be reproduced in sample application (from flamingo.dev.java.net)not
tested with the substance, as the web start does not work)



 Comments   
Comment by kirillcool [ 29/Mar/10 ]

Does this happen when you run the demo locally, or only under the WebStart
environment?





[FLAMINGO-67] LinuxOnly: ComboBox in collapsed ribbon is not showing the popup with items Created: 26/Mar/10  Updated: 29/Mar/10

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: krzych_nowak Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 67

 Description   

This happens only on linux, on windows (xp) it's fine.
Steps to reproduce:

  • Collapse ribbon - so that it is hidden
  • Single Click on task to show the ribbon (ribbon is still in 'collapsed' state
  • will hide when mouse click outside ribbon)
  • Single click on combobox arrow to show the combobox popup with items
    Result: ribbon is hidden, and popup is not shown
    Expected behaviour: popup should be shown with all combobox items to choose

Not sure if this is really a bug, depends if ribbon is supported on linux, i
would give lowest priority but not sure if lowest is p1 or p5 :/



 Comments   
Comment by kirillcool [ 29/Mar/10 ]

Does this happen when you run the demo locally, or only under the WebStart
environment?





[FLAMINGO-64] CTRL+ALT opens KeyTip Created: 21/Dec/09  Updated: 21/Dec/09

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: dhennig Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 64

 Description   

When you press CTRL and ALT, the
KeyTips are shown when the ALT-key is released.

MS office shows the KeyTips only when ALT alone is pressed
and released. That makes more sense, because CTRL+ALT are
used for shortcuts.






[FLAMINGO-50] Enable CommandButtons to be configured via Actions Created: 08/Jun/09  Updated: 12/Jun/09

Status: Open
Project: flamingo
Component/s: common components
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: aalmiray Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 50

 Description   

It would be great if CommandButtons be allowed to be configured via an
javax.swing.Action, the tricky part is syncing action properties upon changes,
sadly the Swing team decided that the basic support classes for AbstractButton
and Actions be package protected (sigh).



 Comments   
Comment by aalmiray [ 08/Jun/09 ]

Incorrectly filed as DEFECT, changed to ENHANCEMENT.

Comment by kirillcool [ 09/Jun/09 ]

Just like AbstractButton class has not scaled in the last few years to meet the
needs of modern UIs, the same is true for the Action / AbstractAction.

The set of properties supported by the Action / AbstractAction is either too
small or not adequate for what AbstractCommandButton / JCommandButton components
support:

  • smallIcon / largeIcon are just two states, while command buttons use the
    ResizableIcon interface.
  • enabled / selected cover just two facets for one model. Command buttons have
    two separate models, one for action area and one for popup area, with more
    facets to each one.
  • additional model facets include fire-action-on-press, auto-repeat-action-fire
    and popup-showing. Using string-object map in AbstractAction has very bad API
    smell (see later).
  • simple string tooltip is not enough. Command buttons have rich tooltips - one
    for action area and one for popup area.

There are two more points. In the ribbon, there should only be one UI control
for the specific command, unlike in menubar / toolbar where you can have
multiple places for the same command. Having an action to serve as a source for
multiple controls may not be a requirement for such applications.

In addition, the Action / AbstractAction are just not enough. I'll need to do
one of the following:

  • Use the String->Object map - which is a bad API smell.
  • Extend the AbstractAction and inherit all the junk - perhaps throwing
    unsupported exceptions along the way - bad API smell as well.
  • Reimplement the action class (as CommandAction) - just as i did with the
    AbstractCommandButton which does not extend the AbstractButton.

Unless i see compelling reasons why creating command buttons from actions is
absolutely necessary, this functionality will be left for interested third-party
builder-style libraries.

Thanks
Kirill

Comment by aalmiray [ 12/Jun/09 ]

Understood, Flamingo's guidelines prefer immutability however
AbstractCommandButton is certainly mutable, you can change the following
properties after it has been created [text, icon, toolTipText, actionListener]
(just to name a few) which are pretty much the same properties an Action can
provide.

A CommandAction may choose to ignore getValue(SMALL_ICON) and other properties
that do not make sense, it could provide new properties like ICON and RICH_TOOL_TIP.

Given that ACB is a base class for 3 other classes (JCommandButton,
JCommandMenuButton & JCommandMenuButton) it would be a good idea to add the
action handling code directly to it. Third-party libraries would need to create
3 subclasses & 1 helper class at least (yay for no having mixins/traits in plain
Java, not!).

I trust that this issue will be revised in the future, thank you for your time
and effort!

Andres

Comment by kirillcool [ 12/Jun/09 ]

The immutability is on the ribbon level - not allowing changing the ribbon
structure once it's created. However, the command button is more flexible - like
you point out.

I will keep this enhancement open.

Thanks
Kirill





[FLAMINGO-45] dropdown popups overlapping in minimized ribbon Created: 16/May/09  Updated: 12/Jun/09

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: xvik Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: JPEG File flamingobug.jpg     JPEG File flamingobug2.jpg     JPEG File repaint_bug_sample.jpg     JPEG File repaint_bug_sample2.jpg     JPEG File ribbonbug3.JPG     JPEG File ribbonbug3.JPG     JPEG File ribbonbug4.jpg    
Issuezilla Id: 45

 Description   

Hello,

Bug occures with components with dropdown popups (like combobox or office like
style selector).
When ribben is in minimized mode (acts like popup itself), it overlaps dropdown
popup.

How to reproduce:
precondition: ribbon with combobox
1. set ribbon to minimized mode (doubleclick on tab)
2. open ribbon and click on combobox (it should be shown normally)
3. loose focus (so ribbon becomes closed again) and repeat step 2 (dropdown
popup will be below ribbon itself)

tested on windows vista and xp
sun jre 1.6u10
J2D_D3D=false

Regards,



 Comments   
Comment by xvik [ 16/May/09 ]

Created an attachment (id=19)
bug with ribbon minimized mode

Comment by xvik [ 16/May/09 ]

Created an attachment (id=20)
bug with ribbon minimized mode

Comment by kirillcool [ 17/May/09 ]

Can't seem to reproduce on my Vista machine under the latest 4.1RC drop of
Flamingo. Which version of Flamingo are you using?

Thanks
Kirill

Comment by xvik [ 17/May/09 ]

Hello Kirill,

I made screenshots with JNLP version from 4.1RC announce (from pushing-pixels).

I want to note one more time that i'm always switching off new java windows
rendering pipline (J2D_D3D=false)

So i tried to test without disabling it.
First time im also failed to reproduce it, but clicking on popups on differen
ribbon tabs soon gets bug visible (see attach 3)

Regards

Comment by xvik [ 17/May/09 ]

Created an attachment (id=21)
ribbon popup bug

Comment by xvik [ 17/May/09 ]

Created an attachment (id=22)
ribbon popup bug

Comment by kirillcool [ 17/May/09 ]

Yes, i do see it happening under JNLP, but not in my local environment where i
can debug it. Not sure if i can address this before the final 4.1 release since
i don't really know how to debug a WebStart app.

Comment by xvik [ 18/May/09 ]

I have discovered this problem on my own application, so it is not related to
JNLP.
It would be great if you could fix it.. it is very annoying
Thank you for attention!

Comment by kirillcool [ 18/May/09 ]

Do you see this behavior in your local application? If so, i'll need a small
test application that reproduces this outside the WebStart.

Thanks
Kirill

Comment by xvik [ 19/May/09 ]

Hello Kirill,

Yes, i see it in my local application.
I have tried test.ribbon.BasicCheckRibbon test application from flamingo 4.0
release.
It takes some time clicking on different ribbon tabs and different dropdown
controls (about 10 clicks), but bug appears once again (see screenshot 4)

Local java: 1.6.0_13-b03 (win vista)

Regards

Comment by xvik [ 19/May/09 ]

Created an attachment (id=23)
ribbon FLAMINGO-4

Comment by kirillcool [ 19/May/09 ]

Do you see the same behavior under the latest 4.1RC drop?

Thanks
Kirill

Comment by xvik [ 21/May/09 ]

Hello Kirill,

Yes, it still there (tested with 4.1rc (may 17)).
But it takes some time to see it and i can't provide you exact algorithm. (just
clicking different controls on different tabs)

Regards

Comment by kirillcool [ 25/May/09 ]

Sorry, but i still cannot reproduce it. I'm afraid that without the debugging on
your side this will have to be deferred.

The JRibbonFrame has the following lines in the initRibbon() method:

ToolTipManager.sharedInstance().setLightWeightPopupEnabled(false);
JPopupMenu.setDefaultLightWeightPopupEnabled(false);

This makes sure that the core popups use heavyweight windows. Not sure about the
popup type used for the minimized ribbon and expanded ribbon galleries. There i
use PopupFactory.getSharedInstance().getPopup() API to get the popup.

If this bug is critical in your environment, you are more than welcome to fire
up a debugger and see what happens with the light / mid / heavy weight states of
these popups. As i have already said, i cannot seem to reproduce this on my machine.

Thanks
Kirill

Comment by xvik [ 31/May/09 ]

Hello Kirill,

I've tried webstart demo of flamingo 4.1 release (from pushing-pixels).
This version is much more stable. I tried hard to reproduce the bug but reach
success only one time (after long loooong clicking time).
So, the bug still there but now it is very (very!) rare.
Also one note about bug behaviour: if it occured once you will see it regulary
later (every secong click).

I will try to integrate new release into my application this week and see bug
occurance there.

I want to help you in debugging this on my side, but i'm not so skilled in
swing internals. I will try to do my best but not shure about result.
Maybe you can advise me some articles or tutorials about swing internals.

Regards,

Comment by kirillcool [ 05/Jun/09 ]

I'm not aware of any tutorials that go to that level (implementation of
lightweight / heavyweight popups).

Thanks
Kirill

Comment by xvik [ 12/Jun/09 ]

Hello Kirill,

I've done migration of my application to substance-* 5.2, flamingo 4.1 (and
also swingx 1.0). Also I've enabled new windows redering pipeline -
Dsun.java2d.d3d=true (the only reason to stay without it was bug in jfreechart
which is fixed now).

As a result, i see this bug again. And even worse: after enebling
sun.java2d.d3d=true the count of grey rect's instead of combobox popups grows a
lot.

But, thankfully you note that popups are heavyweight, so i put this code after
ribbon initialization:
ToolTipManager.sharedInstance().setLightWeightPopupEnabled(true);
JPopupMenu.setDefaultLightWeightPopupEnabled(true);

And this solves both problems!!!
What is the reason to leave popups heavyweight by default? (if i'm right, java
1.6 update 10 fixes lightweight popups bugs)

But there is enother bug in 4.1 release (i haven't seen it before):
when i switching from one popup to enother (in different grops on the same tab)
group highlighting is badly rendered: a kind of "grey rect" problem (see
attachments)

Regards,

Comment by xvik [ 12/Jun/09 ]

Created an attachment (id=25)
Switching from opened combobox on right group to combobox on left group causes not complete highlighting disabling from right group (there is also separator between comboboxes and checkboxes on right group))

Comment by xvik [ 12/Jun/09 ]

Created an attachment (id=26)
Switching back also causing not proper highlight disabling on left group

Comment by kirillcool [ 12/Jun/09 ]

In at least the near future the topic of mixing Flamingo and core Swing popups
will have to be deferred to the community. It does look like the entire custom
popup module in Flamingo needs to be revisited, and i simply don't have enough
resources to do this in the next few months.

Thanks
Kirill





[FLAMINGO-43] Ribbon application menu does not repaint properly if sun.awt.noerasebackground is set to true Created: 26/Apr/09  Updated: 26/Apr/09

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: flynnk Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File issue43.png     Java Source File Main.java     JPEG File screenshot.jpg    
Issuezilla Id: 43

 Description   

If the sun.awt.noerasebackground attribute is set to true, the ribbon
application menu will not repaint correctly the second time it is displayed.
Comes up okay the first time you click it, but does not appear the second time
it is selected. I'll attach a screenshot shortly showing the problem. The
screenshot shows the problem under Substance Raven, but I've verified the
behavior is the same under Metal.

The workaround is to not set this system property. We were formerly setting it
as legacy from pre-1.6 days where it was very helpful with gray rectangle issue.
Legacy applications upgrading to the ribbon may be setting this attribute, or
for applications that need to run on earlier platforms (i.e. 1.5, since I don't
think Flamingo officially supports before that). Given our paying customers all
have deployments upgraded to Java 6, I'm going to pull the property for our
applications.

As an aside, they need to update the OS choices. Windows Vista 64-bit is not in
the list; JDK 1.6.0_11 was used here as well.



 Comments   
Comment by flynnk [ 26/Apr/09 ]

Created an attachment (id=15)
Ugly screenshot showing the problem

Comment by flynnk [ 26/Apr/09 ]

Created an attachment (id=16)
Sample program to reproduce the problem

Comment by kirillcool [ 26/Apr/09 ]

Created an attachment (id=17)
Screenshot on my machine

Comment by kirillcool [ 26/Apr/09 ]

Attached screenshot of this test app on my machine. Windows Vista, JDK 6u10, no
hardware acceleration (embedded Intel graphics card).

What is your configuration? Can you try to disable the D3D acceleration with
-Dsun.java2d.d3d=false?

Thanks
Kirill

Comment by flynnk [ 26/Apr/09 ]

That's it. Turning off d3d with the argument fixes the problem also. I'm
running on dual NVidia cards, so that's probably part of it. This is probably
going to be a pain to fix if you cannot reproduce it locally.





[FLAMINGO-36] Support high DPI mode Created: 29/Jan/09  Updated: 30/Jan/09

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.1
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: dukke Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File issue36.png     Java Source File RibbonTest.java    
Issuezilla Id: 36

 Description   

When having three ribbon components vertically, the third one appears cut out.

(Will attach simple test program next)



 Comments   
Comment by dukke [ 29/Jan/09 ]

Created an attachment (id=12)
test program showing problem

Comment by kirillcool [ 29/Jan/09 ]

Created an attachment (id=14)
How it looks on my machine

Comment by kirillcool [ 29/Jan/09 ]

Attached screenshot of how it looks on my machine - Windows Vista SP1 + Java 6u10.

Note that the core components placed in ribbon bands should have small height -
otherwise they will indeed be cut, because there is only so much vertical space
there.

What is your OS / JVM configuration? Can you attach a screenshot that shows the
cut off pixels?

Thanks
Kirill

Comment by dukke [ 30/Jan/09 ]

Hi,

I remembered that I have my windows vista font PPP to a scale of 120. I thought
that might be the problem so I changed it back to the original size and it worked.

I was curious of how word2007 ribbon reacted to this change in font size, so i
run word2007 in both configurations and it actually makes the ribbon height
bigger to accommodate bigger fonts.

Thanks,
Pedro DV

Comment by kirillcool [ 30/Jan/09 ]

Support for high DPI mode will be postponed for the future releases. It will
have to span all the visuals of the ribbon and related components, and is quite
a big task.

Changing the summary and moving as ENHANCEMENT to version 4.1

Thanks
Kirill

Comment by kirillcool [ 30/Jan/09 ]

Changing the title.

Comment by dukke [ 30/Jan/09 ]

Ok thanks =)





[FLAMINGO-32] Exception in ribbon component Created: 15/Dec/08  Updated: 24/Dec/08

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mattnathan Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 32

 Description   

While playing with the new 'key tips' functionality from this demo:
https://substance-flamingo.dev.java.net/webstart/testRibbon.jnlp I noticed an
exception in the java console. I was unable to reproduce the issue reliably, it
seemed to be related to window focus and the java console but I can't be sure
about it.

Exception in thread "AWT-EventQueue-1" java.lang.IllegalStateException:
Substance delegate used when Substance is not the current LAF
at
org.jvnet.substance.utils.SubstanceColorSchemeUtilities.getColorScheme(SubstanceColorSchemeUtilities.java:298)
at
org.jvnet.substance.utils.SubstanceColorSchemeUtilities.getColorScheme(SubstanceColorSchemeUtilities.java:268)
at
org.jvnet.substance.utils.SubstanceColorUtilities.getDefaultBackgroundColor(SubstanceColorUtilities.java:817)
at
org.jvnet.substance.utils.SubstanceColorUtilities.getBackgroundFillColor(SubstanceColorUtilities.java:763)
at
org.jvnet.substance.painter.utils.SubstanceFillBackgroundDelegate.update(SubstanceFillBackgroundDelegate.java:148)
at
org.jvnet.substance.SubstancePanelUI._orgjvnetsubstanceSubstancePanelUI_update(SubstancePanelUI.java:89)
at
org.jvnet.substance.SubstancePanelUI._orgjvnetsubstanceSubstancePanelUIcontainer_update(SubstancePanelUI.java)
at org.jvnet.substance.SubstancePanelUI.update(SubstancePanelUI.java)
at javax.swing.JComponent.paintComponent(JComponent.java:763)
at javax.swing.JComponent.paint(JComponent.java:1027)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:564)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5122)
at
javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1472)
at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1403)
at
javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:293)
at javax.swing.RepaintManager.paint(RepaintManager.java:1217)
at javax.swing.JComponent._paintImmediately(JComponent.java:5070)
at javax.swing.JComponent.paintImmediately(JComponent.java:4880)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:803)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:714)
at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:694)
at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)



 Comments   
Comment by mattnathan [ 15/Dec/08 ]

I managed to reproduce the issue:

1) make sure the java console opens for webstart
2) open: https://substance-flamingo.dev.java.net/webstart/testRibbon.jnlp
3) move the windows so that both the console and the ribbon are visible
4) click on the console to give it focus (inside the window works for me)
5) click a drop down in the ribbon (the down arrow for cut works for me)
6) click the console again (again in the java bit)

Note that this is probably related to issue
https://flamingo.dev.java.net/issues/show_bug.cgi?id=31

Comment by kirillcool [ 16/Dec/08 ]

I can see this exception. Will need to add some more tracing code (when this
exception is thrown) to analyze the situation.

Thanks
Kirill

Comment by kirillcool [ 24/Dec/08 ]

I've added some tracing to the ribbon test app and Substance core library, but i
still don't know why this happens. This is a new trace:

Look-and-feel change from null to Metal
Look-and-feel change from Metal to Substance Business Blue Steel
Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException:
Substance delegate used when Substance is not the current LAF [component
JRibbonBand in window NewCheckRibbon:'Ribbon longer title to check contextual
tabs' under Windows]
at
org.jvnet.substance.utils.SubstanceCoreUtilities.traceSubstanceApiUsage(SubstanceCoreUtilities.java:2357)
at
org.jvnet.substance.utils.SubstanceColorSchemeUtilities.getColorScheme(SubstanceColorSchemeUtilities.java:299)
at
org.jvnet.substance.utils.SubstanceColorSchemeUtilities.getColorScheme(SubstanceColorSchemeUtilities.java:269)
at
org.jvnet.substance.flamingo.ribbon.ui.SubstanceRibbonBandUI.paintBandBackground(SubstanceRibbonBandUI.java:210)

As you can see, the UIManager starts under Metal and then gets switched to
Substance Blue Steel. However, at some point when i switch between the Java
console and the test app window, the current LAF is Windows - without it being
reported in the property change listener registered on the UIManager class.

This looks like an issue in the implementation of Java console, and i'll try to
create a standalone application to recreate this outside Flamingo / Substance
combination.

The same as above applies to issue 31 as well.

Thanks
Kirill





[FLAMINGO-31] NPE under substance with app menu (JNLP) Created: 15/Dec/08  Updated: 16/Dec/08

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: mattnathan Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 31

 Description   

The following exception is thrown under the following conditions:
Java Web Start 1.6.0_11
Using JRE version 1.6.0_11 Java HotSpot(TM) Server VM

1) Configure Java WebStart to always show the Java Console
2) Launch the ribbon JNLP app:
https://substance-flamingo.dev.java.net/webstart/testRibbon.jnlp
3) Click the app menu button
4) Click in the Java Console window

The following exception should be observed; I guess the problem is with the look
and feel of the second java window (the console) not being the same as the look
and feel of the window that is loosing the focus. There are probably other cases
where this can be reproduced in pure application code.

Exception in thread "AWT-EventQueue-1" java.lang.NullPointerException
at
org.jvnet.substance.utils.SubstanceTitlePane.paintComponent(SubstanceTitlePane.java:1147)
at
org.jvnet.substance.flamingo.ribbon.ui.SubstanceRibbonFrameTitlePane.paintComponent(SubstanceRibbonFrameTitlePane.java:587)
at javax.swing.JComponent.paint(JComponent.java:1027)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:564)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5122)
at
javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1472)
at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1403)
at
javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:293)
at javax.swing.RepaintManager.paint(RepaintManager.java:1217)
at javax.swing.JComponent._paintImmediately(JComponent.java:5070)
at javax.swing.JComponent.paintImmediately(JComponent.java:4880)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:803)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:714)
at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:694)
at
javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)



 Comments   
Comment by kirillcool [ 16/Dec/08 ]

Will try to reproduce it in the (debuggable) standalone mode.

Thanks
Kirill





[FLAMINGO-18] Bad comportments with dual screen Created: 17/Sep/08  Updated: 17/Sep/08

Status: Open
Project: flamingo
Component/s: base
Affects Version/s: 4.0
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: gervaisb Assignee: kirillcool
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Attachments: Zip Archive Screenshots.zip    
Issuezilla Id: 18

 Description   

Hi,

I have jus tried the lastest release of Flamingo from Pushing Pixels
testRibbon.jnlp (September 15, 2008).
I have a dual screen configuration and when the application start i can't move
it to the second screen. After changing the look and feel ro "Windows" I can
move the frame to the second screen but when I try to expand it, she don't pick
the correct size (more width and not enough height).

I'm using the jdk_1.6.0_10. I you want I have two screenshots to explain the
problem. You can contact me at gervais.b@gmail.com

Thanks



 Comments   
Comment by kirillcool [ 17/Sep/08 ]

Currently there is no built-in support for multi-monitor setup in Ribbon
component. How does Office 2007 behave in your setup? Can you maximize it to
both screens? What happens when two screens have different pixel dimensions?

Marking this as ENHANCEMENT for the next release with first step to understand
the required behavior of a frame with ribbon under multi-monitor environment.

Comment by gervaisb [ 17/Sep/08 ]

Created an attachment (id=6)
Screen1: When the app start. Screen2: Whne i have changed the l&f to Windows to move the frame and tried to expand it.

Comment by kirillcool [ 17/Sep/08 ]

Moving to version 4.0. Note that the official ribbon specification doesn't say
anything about the behavior under multiple monitor setup. I'll try playing with
Office 2007 on such a setup when i find time.





[FLAMINGO-88] Default constructors for swing components Created: 09/Feb/11  Updated: 09/Feb/11

Status: Open
Project: flamingo
Component/s: breadcrumb bar, common components, file viewer, ribbon, www
Affects Version/s: 4.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: fabiennisol Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all



 Description   

The components should declare a default constructor permitting flamingo components to be used in a modern UI design tool (like netbeans matisse)

Integrating flamingo into a matisse designed application is complicated.






[FLAMINGO-89] TitlePane Created: 11/Feb/12  Updated: 11/Feb/12

Status: Open
Project: flamingo
Component/s: ribbon
Affects Version/s: 5.0
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: anastasmenocal Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 6.0, Windows 7 Ultimate



 Description   

I can't use the class SubstanceRibbonFrameTitlePane and my application don't set the title of the frame at the center of the title's bar...






Generated at Tue Jul 28 08:40:06 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.