[jira] [Commented] (PIVOT-860) CPU Usage at 100% when displaying an Expander
[ https://issues.apache.org/jira/browse/PIVOT-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424100#comment-13424100 ] Roger Whitcomb commented on PIVOT-860: -- So, the infinite loop is in the TerraExpanderSkin.paint method where it sets the title bar color, which sets the Label color style, which causes a repaint, which goes around and around. I'm working on a fix, so assigning the issue to myself. CPU Usage at 100% when displaying an Expander - Key: PIVOT-860 URL: https://issues.apache.org/jira/browse/PIVOT-860 Project: Pivot Issue Type: Bug Affects Versions: 2.0.2 Environment: Windows XP, reproduced on Java 6 (various versions) and Java 7 Reporter: Guillaume Deshors Assignee: Sandro Martini Labels: performance Fix For: 2.0.3 Attachments: pivot_kitchensink_expanders_profile_test_0.png, pivot_kitchensink_expanders_profile_test_1.png, pivot_kitchensink_expanders_profile_test_2.png When displaying an Expander component, the CPU usage immediately goes up and stays at 100% as long as the component is displayed (even if the window is background, reduced or whatever). To be precise, I really had 50% because I have a dual core : one of the core was 100%. Reproduced on 3 different computers, all Windows XP, with Java 6 and 7. Reproduced in applet and in standalone application shape. Steps to reproduce : 1/ go to http://pivot.apache.org/tutorials/sample-application.html - CPU is normal, say 5% 2/ click on navigation to see the expander - CPU is at 100%, at least one of the cores. Alternative : just go to http://pivot.apache.org/tutorials/expanders.html and expect the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-860) CPU Usage at 100% when displaying an Expander
[ https://issues.apache.org/jira/browse/PIVOT-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-860. -- Resolution: Fixed Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraExpanderSkin.java Transmitting file data . Committed revision 1366521. CPU Usage at 100% when displaying an Expander - Key: PIVOT-860 URL: https://issues.apache.org/jira/browse/PIVOT-860 Project: Pivot Issue Type: Bug Affects Versions: 2.0.2 Environment: Windows XP, reproduced on Java 6 (various versions) and Java 7 Reporter: Guillaume Deshors Assignee: Roger Whitcomb Labels: performance Fix For: 2.0.3 Attachments: pivot_kitchensink_expanders_profile_test_0.png, pivot_kitchensink_expanders_profile_test_1.png, pivot_kitchensink_expanders_profile_test_2.png When displaying an Expander component, the CPU usage immediately goes up and stays at 100% as long as the component is displayed (even if the window is background, reduced or whatever). To be precise, I really had 50% because I have a dual core : one of the core was 100%. Reproduced on 3 different computers, all Windows XP, with Java 6 and 7. Reproduced in applet and in standalone application shape. Steps to reproduce : 1/ go to http://pivot.apache.org/tutorials/sample-application.html - CPU is normal, say 5% 2/ click on navigation to see the expander - CPU is at 100%, at least one of the cores. Alternative : just go to http://pivot.apache.org/tutorials/expanders.html and expect the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-860) CPU Usage at 100% when displaying an Expander
[ https://issues.apache.org/jira/browse/PIVOT-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424120#comment-13424120 ] Roger Whitcomb commented on PIVOT-860: -- Merged to 2.0.x branch also: Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraExpanderSkin.java Transmitting file data . Committed revision 1366523. CPU Usage at 100% when displaying an Expander - Key: PIVOT-860 URL: https://issues.apache.org/jira/browse/PIVOT-860 Project: Pivot Issue Type: Bug Affects Versions: 2.0.2 Environment: Windows XP, reproduced on Java 6 (various versions) and Java 7 Reporter: Guillaume Deshors Assignee: Roger Whitcomb Labels: performance Fix For: 2.0.3 Attachments: pivot_kitchensink_expanders_profile_test_0.png, pivot_kitchensink_expanders_profile_test_1.png, pivot_kitchensink_expanders_profile_test_2.png When displaying an Expander component, the CPU usage immediately goes up and stays at 100% as long as the component is displayed (even if the window is background, reduced or whatever). To be precise, I really had 50% because I have a dual core : one of the core was 100%. Reproduced on 3 different computers, all Windows XP, with Java 6 and 7. Reproduced in applet and in standalone application shape. Steps to reproduce : 1/ go to http://pivot.apache.org/tutorials/sample-application.html - CPU is normal, say 5% 2/ click on navigation to see the expander - CPU is at 100%, at least one of the cores. Alternative : just go to http://pivot.apache.org/tutorials/expanders.html and expect the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-655) FileBrowserSheet save dialog appends the saveas field content to the selected folders/file
[ https://issues.apache.org/jira/browse/PIVOT-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424131#comment-13424131 ] Roger Whitcomb commented on PIVOT-655: -- This is fixed as part of the fix for Pivot-865. This will be available in the 2.0.3 release, or you can pull trunk from SVN and try it. FileBrowserSheet save dialog appends the saveas field content to the selected folders/file -- Key: PIVOT-655 URL: https://issues.apache.org/jira/browse/PIVOT-655 Project: Pivot Issue Type: Bug Components: wtk-terra Affects Versions: 1.5.1 Reporter: A.J. Fix For: 2.1 If you copy/paste or type an absolute path to the save as text input field, the result 'selectedFile' is the concatenation of the selected path and the path in the text input. So you may end up with a File object pointing to something like : C:\toto\D:\myotherdirectory\file which is obviously incorrect. we can (should) check the result from the dialog but handling this case should, imho, be done by the FileBrowserSheet component. What do you think ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-655) FileBrowserSheet save dialog appends the saveas field content to the selected folders/file
[ https://issues.apache.org/jira/browse/PIVOT-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-655. -- Resolution: Fixed Resolved by revisions 1366521 and 1366523 (for trunk and 2.0.x branch respectively). FileBrowserSheet save dialog appends the saveas field content to the selected folders/file -- Key: PIVOT-655 URL: https://issues.apache.org/jira/browse/PIVOT-655 Project: Pivot Issue Type: Bug Components: wtk-terra Affects Versions: 1.5.1 Reporter: A.J. Fix For: 2.1 If you copy/paste or type an absolute path to the save as text input field, the result 'selectedFile' is the concatenation of the selected path and the path in the text input. So you may end up with a File object pointing to something like : C:\toto\D:\myotherdirectory\file which is obviously incorrect. we can (should) check the result from the dialog but handling this case should, imho, be done by the FileBrowserSheet component. What do you think ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-658) FileBrowser directory entry
[ https://issues.apache.org/jira/browse/PIVOT-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424133#comment-13424133 ] Roger Whitcomb commented on PIVOT-658: -- If the FileBrowser is set to SAVE_AS mode this feature is available (fix for Pivot-865). Still thinking about adding to the other modes (that don't currently display the input field). FileBrowser directory entry --- Key: PIVOT-658 URL: https://issues.apache.org/jira/browse/PIVOT-658 Project: Pivot Issue Type: Wish Components: wtk-terra Reporter: LG Fix For: 2.1 It could be insteresting to have an address bar to type full directory instead to have to browse all directory by clicking through all folders. For example, enter a full directory path c:/DIRECTORY1/DIRECTORY2/ in the textinput then hit enter and it calls the setRootDirectory with the path. Actually it could be great if it acts like in Windows Explorer, if I type a folder directory it selects the folder (setRootDirectory) and if I type a filename it selects the file and close the FileBrowser. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PIVOT-566) Add button in FileBrowsers to allow the creation of new directories
[ https://issues.apache.org/jira/browse/PIVOT-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-566: Assignee: Roger Whitcomb Add button in FileBrowsers to allow the creation of new directories --- Key: PIVOT-566 URL: https://issues.apache.org/jira/browse/PIVOT-566 Project: Pivot Issue Type: Improvement Components: wtk Reporter: André Thieme Assignee: Roger Whitcomb Fix For: 2.1 When a user wants to save a file it is possible that the target directory does not exist yet, and the user only finds out about this when he is already in the FileBrowser. A button for creating new dirs would be helpful. Also a right-click with the mouse on a file or folder could offer a popup menu that allows the user to select options such as open, delete and properties, where 'properties' would show some general information about the file, such as the full path, size in bytes, creation date and such. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PIVOT-658) FileBrowser directory entry
[ https://issues.apache.org/jira/browse/PIVOT-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-658: Assignee: Roger Whitcomb FileBrowser directory entry --- Key: PIVOT-658 URL: https://issues.apache.org/jira/browse/PIVOT-658 Project: Pivot Issue Type: Wish Components: wtk-terra Reporter: LG Assignee: Roger Whitcomb Fix For: 2.1 It could be insteresting to have an address bar to type full directory instead to have to browse all directory by clicking through all folders. For example, enter a full directory path c:/DIRECTORY1/DIRECTORY2/ in the textinput then hit enter and it calls the setRootDirectory with the path. Actually it could be great if it acts like in Windows Explorer, if I type a folder directory it selects the folder (setRootDirectory) and if I type a filename it selects the file and close the FileBrowser. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PIVOT-492) Unable to select a file and/or a directory in FileBrowserSheet
[ https://issues.apache.org/jira/browse/PIVOT-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-492: Assignee: Roger Whitcomb Unable to select a file and/or a directory in FileBrowserSheet -- Key: PIVOT-492 URL: https://issues.apache.org/jira/browse/PIVOT-492 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 1.4 Reporter: David Gao Assignee: Roger Whitcomb Labels: Directory, FileBrowser, FileBrowserSheet Fix For: 2.1 Attachments: FileBrowserSheet.diff, TerraFileBrowserSheetSkin.diff, src.java.zip Hi, I'm writing a file chooser now with FileBrowserSheet. I found that I can only select a file when the mode is SAVE_AS and a directory when the mode is SAVE_TO. I would like a mode in which I can select either a file or a directory. I find no way to realize this. Please help. The function shoule be something like what Swing JFileChoose does below: JFileChooser chooser = new JFileChooser(); ... chooser.setFileSelectionMode(JFileChooser.FILES_AND_DIRECTORIES); int returnVal = chooser.showOpenDialog(this); My use case is like this. I am writing a tool which can do some conversion tasks for files. If user selects a file via FileBrowserSheet, the tool will just deal with the selected file. However, if the user selects a folder, the tool will scan and convert all files or filtered files under this folder recursively. This will make the tool look smarter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PIVOT-679) TableViewImageCellRenderer should render disabled rows with an opacity of 0.5f
[ https://issues.apache.org/jira/browse/PIVOT-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-679: Assignee: Roger Whitcomb (was: Chris Bartlett) TableViewImageCellRenderer should render disabled rows with an opacity of 0.5f -- Key: PIVOT-679 URL: https://issues.apache.org/jira/browse/PIVOT-679 Project: Pivot Issue Type: Improvement Components: wtk Environment: n/a Reporter: Chris Bartlett Assignee: Roger Whitcomb Priority: Trivial Fix For: 2.1 All of the following renderers set the ImageView's opacity to 0.5f when the relevant item is disabled. TableViewImageCellRenderer should do the same for consistency. ButtonDataRenderer LinkButtonDataRenderer ListViewItemRenderer MenuBarItemDataRenderer MenuItemDataRenderer TableViewHeaderDataRenderer TreeViewNodeRenderer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-679) TableViewImageCellRenderer should render disabled rows with an opacity of 0.5f
[ https://issues.apache.org/jira/browse/PIVOT-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424170#comment-13424170 ] Roger Whitcomb commented on PIVOT-679: -- The default TableViewCellRenderer definitely uses the disabled color for the text if the row is disabled. And this includes the classes derived from it (Date, FileSize, Number) which don't override the render method. The TableViewTextAreaCellRenderer uses a similar methodology, so it also uses the disabled color. The checkbox renderer sets the enabled state of its checkbox, so that should work too. So, it looks like this renderer is the only holdout. Assigning this issue to me -- I have the code almost ready. TableViewImageCellRenderer should render disabled rows with an opacity of 0.5f -- Key: PIVOT-679 URL: https://issues.apache.org/jira/browse/PIVOT-679 Project: Pivot Issue Type: Improvement Components: wtk Environment: n/a Reporter: Chris Bartlett Assignee: Chris Bartlett Priority: Trivial Fix For: 2.1 All of the following renderers set the ImageView's opacity to 0.5f when the relevant item is disabled. TableViewImageCellRenderer should do the same for consistency. ButtonDataRenderer LinkButtonDataRenderer ListViewItemRenderer MenuBarItemDataRenderer MenuItemDataRenderer TableViewHeaderDataRenderer TreeViewNodeRenderer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-679) TableViewImageCellRenderer should render disabled rows with an opacity of 0.5f
[ https://issues.apache.org/jira/browse/PIVOT-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-679. -- Resolution: Fixed Fix Version/s: (was: 2.1) 2.0.3 trunk: Sending wtk/src/org/apache/pivot/wtk/content/TableViewImageCellRenderer.java Transmitting file data . Committed revision 1366553. 2.0.x: Sending wtk/src/org/apache/pivot/wtk/content/TableViewImageCellRenderer.java Transmitting file data . Committed revision 1366556. TableViewImageCellRenderer should render disabled rows with an opacity of 0.5f -- Key: PIVOT-679 URL: https://issues.apache.org/jira/browse/PIVOT-679 Project: Pivot Issue Type: Improvement Components: wtk Environment: n/a Reporter: Chris Bartlett Assignee: Roger Whitcomb Priority: Trivial Fix For: 2.0.3 All of the following renderers set the ImageView's opacity to 0.5f when the relevant item is disabled. TableViewImageCellRenderer should do the same for consistency. ButtonDataRenderer LinkButtonDataRenderer ListViewItemRenderer MenuBarItemDataRenderer MenuItemDataRenderer TableViewHeaderDataRenderer TreeViewNodeRenderer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-783) Calling setScale on scaleDecorator doesn't update the display
[
https://issues.apache.org/jira/browse/PIVOT-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424194#comment-13424194
]
Roger Whitcomb commented on PIVOT-783:
--
A very easy workaround is simply to call repaint() on the component after
changing the decorator scale value:
Window title=Scale change maximized=true
xmlns:bxml=http://pivot.apache.org/bxml;
xmlns:effects=org.apache.pivot.wtk.effects
xmlns=org.apache.pivot.wtk
BoxPane orientation=vertical preferredWidth=300
PushButton buttonData=Change
buttonPressListeners
function buttonPressed(button) {
scaleDecorator.setScale(2.0);
scaledLabel.repaint();
}
/buttonPressListeners
/PushButton
Label bxml:id=scaledLabel text=This text should get twice as big when I
push the button
decorators
effects:ScaleDecorator bxml:id=scaleDecorator
horizontalAlignment=left verticalAlignment=top /
/decorators
/Label
/BoxPane
/Window
Seems like we could simply document this for potential users rather than change
all the infrastructure around Decorators. (Tested this code and it works as it
should.)
Because, as you say: Decorators can be applied to many different components, so
we would have to implement a list of Components inside Decorator and do all the
listeners and notifications, etc. which seems overkill for this one issue.
Generally decorators don't change their values anyway once they are
instantiated.
So, another solution is just to remove the decorator and add it again after
changing scale, which also works:
Window title=Scale change maximized=true
xmlns:bxml=http://pivot.apache.org/bxml;
xmlns:effects=org.apache.pivot.wtk.effects
xmlns=org.apache.pivot.wtk
BoxPane orientation=vertical preferredWidth=300
PushButton buttonData=Change
buttonPressListeners
function buttonPressed(button) {
scaledLabel.getDecorators().remove(scaleDecorator);
scaleDecorator.setScale(2.0);
scaledLabel.getDecorators().add(scaleDecorator);
}
/buttonPressListeners
/PushButton
Label bxml:id=scaledLabel text=This text should get twice as big when I
push the button
decorators
effects:ScaleDecorator bxml:id=scaleDecorator
horizontalAlignment=left verticalAlignment=top /
/decorators
/Label
/BoxPane
/Window
So, generally I would say this is a non-issue, except that it could be
documented what to do for ScaleDecorator to force a repaint when changing scale.
Calling setScale on scaleDecorator doesn't update the display
-
Key: PIVOT-783
URL: https://issues.apache.org/jira/browse/PIVOT-783
Project: Pivot
Issue Type: Improvement
Components: wtk
Affects Versions: 2.0
Reporter: Bill van Melle
Priority: Minor
Fix For: 2.1
When you call setScale on a scaleDecorator that's already in the display
tree, the display does not update. You can't see the effect of the change
until something else causes a repaint.
Looking at the code, isn't this an issue for decorators in general? I don't
see any mechanism for decorators to notify the component (or components?)
that they are attached to that they've changed. If you're not going to
notify, then shouldn't decorators be immutable objects? (Of course, that
would break a lot of code.)
FWIW, a demonstration:
Window title=Scale change maximized=true
xmlns:bxml=http://pivot.apache.org/bxml;
xmlns:effects=org.apache.pivot.wtk.effects
xmlns=org.apache.pivot.wtk
BoxPane orientation=vertical preferredWidth=300
PushButton buttonData=Change
buttonPressListeners
function buttonPressed(button) {
scaleDecorator.setScale(2.0);
}
/buttonPressListeners
/PushButton
Label text=This text should get twice as big when I push the button
decorators
effects:ScaleDecorator bxml:id=scaleDecorator
horizontalAlignment=left verticalAlignment=top /
/decorators
/Label
/BoxPane
/Window
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (PIVOT-783) Calling setScale on scaleDecorator doesn't update the display
[
https://issues.apache.org/jira/browse/PIVOT-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Whitcomb closed PIVOT-783.
Resolution: Not A Problem
Fix Version/s: (was: 2.1)
2.0.3
Close it for now with a doc change.
Calling setScale on scaleDecorator doesn't update the display
-
Key: PIVOT-783
URL: https://issues.apache.org/jira/browse/PIVOT-783
Project: Pivot
Issue Type: Improvement
Components: wtk
Affects Versions: 2.0
Reporter: Bill van Melle
Priority: Minor
Fix For: 2.0.3
When you call setScale on a scaleDecorator that's already in the display
tree, the display does not update. You can't see the effect of the change
until something else causes a repaint.
Looking at the code, isn't this an issue for decorators in general? I don't
see any mechanism for decorators to notify the component (or components?)
that they are attached to that they've changed. If you're not going to
notify, then shouldn't decorators be immutable objects? (Of course, that
would break a lot of code.)
FWIW, a demonstration:
Window title=Scale change maximized=true
xmlns:bxml=http://pivot.apache.org/bxml;
xmlns:effects=org.apache.pivot.wtk.effects
xmlns=org.apache.pivot.wtk
BoxPane orientation=vertical preferredWidth=300
PushButton buttonData=Change
buttonPressListeners
function buttonPressed(button) {
scaleDecorator.setScale(2.0);
}
/buttonPressListeners
/PushButton
Label text=This text should get twice as big when I push the button
decorators
effects:ScaleDecorator bxml:id=scaleDecorator
horizontalAlignment=left verticalAlignment=top /
/decorators
/Label
/BoxPane
/Window
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-685) SHIFT+DOWN keystroke within TextArea do not expand the selection past an empty line
[ https://issues.apache.org/jira/browse/PIVOT-685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-685: - Priority: Minor (was: Trivial) SHIFT+DOWN keystroke within TextArea do not expand the selection past an empty line --- Key: PIVOT-685 URL: https://issues.apache.org/jira/browse/PIVOT-685 Project: Pivot Issue Type: Bug Components: wtk, wtk-terra Affects Versions: 2.0 Environment: n/a Reporter: Chris Bartlett Assignee: Noel Grandin Priority: Minor Fix For: 2.0.3 SHIFT+UP SHIFT+DOWN keystrokes can be used to expand the selection to the previous or next line respectively. However SHIFT+DOWN fails to extend the selection past an empty line. SHIFT+UP appears to work as expected Given the following text, and the caret positioned at the start of the TextArea, the first press of SHIFT+DOWN will select 'abc', the second will also select 'def', but third and subsequent presses will have no effect due to an empty 3rd line. 'abc newline def newline empty line ghi' Workaround by using the mouse, or SHIFT+LEFT SHIFT+RIGHT -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-721) ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style
[ https://issues.apache.org/jira/browse/PIVOT-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428254#comment-13428254 ] Roger Whitcomb commented on PIVOT-721: -- Sounds like we just need some doc on the restriction. That is, if you call setFillIcon you can't set a preferred height unless you don't want it to scale up. Something like that. To me it doesn't sound like a bug (except for the fix you already put in). ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style - Key: PIVOT-721 URL: https://issues.apache.org/jira/browse/PIVOT-721 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0 Reporter: Bill van Melle Assignee: Sandro Martini Priority: Minor Fix For: 2.0.3 Attachments: pivot721_imageview_only_for_debug_DO_NOT_COMMIT.patch ButtonDataRenderer has a setFillIcon method, which supposedly should allow the button's image to be scaled to fit the button. However, it has no effect, because the renderer is a BoxPane with the default fill=false. Fix: In the ButtonDataRenderer constructor, add getStyles().put(fill, true); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PIVOT-863) FileBrowser/FileBrowserSheet Improvements
[ https://issues.apache.org/jira/browse/PIVOT-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-863: Assignee: Roger Whitcomb (was: Sandro Martini) FileBrowser/FileBrowserSheet Improvements - Key: PIVOT-863 URL: https://issues.apache.org/jira/browse/PIVOT-863 Project: Pivot Issue Type: Improvement Components: wtk, wtk-terra Reporter: Sandro Martini Assignee: Roger Whitcomb Priority: Minor Fix For: 2.1 Some usability improvements for FileBrowser/FileBrowserSheet: - when in SAVE_TO mode, even files are displayed but should be better to not display them (it's a folder selection) ... or maybe add a style property to handle this show/hide status -- as default value in this case what do you prefer, the current (2.0.x) behavior, or the new (for 2.1) ? - verify if it's possible to handle selection using keyboard letters, like in ListView, maybe add a style property to enable/disable (like now) this -- as default value in this case what do you prefer, off, or on ? If someone has other suggestions (but not tracked by other issues) please post here, or link other issues if already existing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-863) FileBrowser/FileBrowserSheet Improvements
[ https://issues.apache.org/jira/browse/PIVOT-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13431430#comment-13431430 ] Roger Whitcomb commented on PIVOT-863: -- We use SAVE_TO mode for a Save,As dialog, so in this case (some cases) displaying file names is appropriate. So, I would suggest another style to only display directories in this mode. Might apply to other modes too (so you could use it as an input directory chooser too). Applicable to FileBrowser and FileBrowserSheet, so we'll have to see how to coordinate the two with the new style(s). FileBrowser/FileBrowserSheet Improvements - Key: PIVOT-863 URL: https://issues.apache.org/jira/browse/PIVOT-863 Project: Pivot Issue Type: Improvement Components: wtk, wtk-terra Reporter: Sandro Martini Assignee: Roger Whitcomb Priority: Minor Fix For: 2.1 Some usability improvements for FileBrowser/FileBrowserSheet: - when in SAVE_TO mode, even files are displayed but should be better to not display them (it's a folder selection) ... or maybe add a style property to handle this show/hide status -- as default value in this case what do you prefer, the current (2.0.x) behavior, or the new (for 2.1) ? - verify if it's possible to handle selection using keyboard letters, like in ListView, maybe add a style property to enable/disable (like now) this -- as default value in this case what do you prefer, off, or on ? If someone has other suggestions (but not tracked by other issues) please post here, or link other issues if already existing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-864) Add a pluggable file system architecture to FileBrowser so remote browsing can be done
[ https://issues.apache.org/jira/browse/PIVOT-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13432095#comment-13432095 ] Roger Whitcomb commented on PIVOT-864: -- Looking into Apache Commons VFS as the basis for this -- supports FTP, WebDAV, HTTP, etc. as file systems (see http://commons.apache.org/vfs/filesystems.html), and it subsumes Apache Commons-Net. Add a pluggable file system architecture to FileBrowser so remote browsing can be done -- Key: PIVOT-864 URL: https://issues.apache.org/jira/browse/PIVOT-864 Project: Pivot Issue Type: New Feature Components: wtk Affects Versions: 2.0.2 Environment: Windows, Linux, OSX Reporter: Roger Whitcomb Assignee: Roger Whitcomb Labels: filebrowser Fix For: 2.1 Original Estimate: 336h Remaining Estimate: 336h Our application requires the ability to be able to browse (for instance) a Linux machine from the Windows desktop. For this I would like to add (somehow) a pluggable file system architecture so that I could (for instance) implement an FTP protocol underneath the FileBrowser so that I can browse through directories and files on something other than the local machine. We would also need to be able to type in a host name or TCP/IP address to start browsing the remote machine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PIVOT-869) Add style to Form to adjust spacing between labels and fields
Roger Whitcomb created PIVOT-869: Summary: Add style to Form to adjust spacing between labels and fields Key: PIVOT-869 URL: https://issues.apache.org/jira/browse/PIVOT-869 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Currently the space between the longest form label and the fields is not controllable. We would like to be able to adjust this spacing. Suggest adding a new style to TerraFormSkin to control this spacing. Default would be 0 to match the current look. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-817) Implement borderThickness style for TerraPushButtonSkin
[ https://issues.apache.org/jira/browse/PIVOT-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-817: - Due Date: (was: 31/Jul/12) The idea was to be able to make buttons look more like Windows buttons (the default button look), but the timeframe was unrealistic. Implement borderThickness style for TerraPushButtonSkin - Key: PIVOT-817 URL: https://issues.apache.org/jira/browse/PIVOT-817 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.1 Environment: Windows XP SP3, JDK 1.6.0_16 Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: pushbutton,, thickness Fix For: 2.1 Attachments: thick.patch Original Estimate: 168h Remaining Estimate: 168h In order to somewhat simulate the appearance of the default button on Windows, which has a thicker border, it would be nice to be able to set the border thickness of a PushButton to something bigger than one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-850) Fail to take input characters other than English in Mac Lion
[ https://issues.apache.org/jira/browse/PIVOT-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453228#comment-13453228 ] Roger Whitcomb commented on PIVOT-850: -- I have done some poking around in the Pivot code. It seems like what is happening is that we recognize keys by the keydown event, but the Character Viewer on OSX is sending just a complete character event (not keydown, keyup) and so we completely miss them. Still trying to verify that this is the problem. Then we would have to figure some way of recognizing and accepting the input in this case. Fail to take input characters other than English in Mac Lion Key: PIVOT-850 URL: https://issues.apache.org/jira/browse/PIVOT-850 Project: Pivot Issue Type: Bug Components: wtk, wtk-terra Affects Versions: 2.0.1, 2.0.2 Environment: Mac Lion Reporter: Brendan Assignee: Roger Whitcomb Fix For: 2.0.3 Attachments: ASF.LICENSE.NOT.GRANTED--Input to Mac Lion of Chinese Character show nothing.jpg, ASF.LICENSE.NOT.GRANTED--Window 7 and Text Area to show Chinese Input as Box.jpg, inputProblem.png, WebStartInput.png In Mac Lion, no Chinese and Korean character can appear in TextInput and TextArea thru the input method. However, these components can take the character thru copy and paste. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-867) Ability to selectively enable/disable a Tree node
[ https://issues.apache.org/jira/browse/PIVOT-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453295#comment-13453295 ] Roger Whitcomb commented on PIVOT-867: -- Based on my conversations with the user, I'm inclined to say that we shouldn't change anything -- there is already enough functionality provided to be able to do this if desired, especially given this is marked as an Improvement. Ability to selectively enable/disable a Tree node - Key: PIVOT-867 URL: https://issues.apache.org/jira/browse/PIVOT-867 Project: Pivot Issue Type: Improvement Components: wtk, wtk-terra Reporter: J R Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 http://apache-pivot-users.399431.n3.nabble.com/How-to-block-UI-input-to-a-disabled-busy-TreeNode-tt4022018.html The above link has detailed explanation of the problem and some pseudo code that I'm using right now to mimic this functionality. thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-867) Ability to selectively enable/disable a Tree node
[ https://issues.apache.org/jira/browse/PIVOT-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-867. -- Resolution: Won't Fix Others -- feel free to reopen if you think there really should be something added/changed in Pivot. Ability to selectively enable/disable a Tree node - Key: PIVOT-867 URL: https://issues.apache.org/jira/browse/PIVOT-867 Project: Pivot Issue Type: Improvement Components: wtk, wtk-terra Reporter: J R Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 http://apache-pivot-users.399431.n3.nabble.com/How-to-block-UI-input-to-a-disabled-busy-TreeNode-tt4022018.html The above link has detailed explanation of the problem and some pseudo code that I'm using right now to mimic this functionality. thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-873) Provide a style for TableVIew that allows one click to start row editing
[ https://issues.apache.org/jira/browse/PIVOT-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-873: - Issue Type: Improvement (was: Bug) Provide a style for TableVIew that allows one click to start row editing Key: PIVOT-873 URL: https://issues.apache.org/jira/browse/PIVOT-873 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Trivial Labels: tableview Fix For: 2.0.3 Normally, a double click is required in a TableView row to initiate editing of the row. Our users would like to start editing right away. The proposal is to add a new style (implemented in TerraTableViewSkin) called editOnMouseDown that would allow the first click to begin editing. The default behavior would remain the same (edit is started on double click). It is not clear if I can implement it such that the first click would not only initiate editing but also toggle checkboxes or select radio buttons if there are any in the row editor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PIVOT-873) Provide a style for TableVIew that allows one click to start row editing
Roger Whitcomb created PIVOT-873: Summary: Provide a style for TableVIew that allows one click to start row editing Key: PIVOT-873 URL: https://issues.apache.org/jira/browse/PIVOT-873 Project: Pivot Issue Type: Bug Components: wtk-terra Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Trivial Fix For: 2.0.3 Normally, a double click is required in a TableView row to initiate editing of the row. Our users would like to start editing right away. The proposal is to add a new style (implemented in TerraTableViewSkin) called editOnMouseDown that would allow the first click to begin editing. The default behavior would remain the same (edit is started on double click). It is not clear if I can implement it such that the first click would not only initiate editing but also toggle checkboxes or select radio buttons if there are any in the row editor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-873) Provide a style for TableVIew that allows one click to start row editing
[ https://issues.apache.org/jira/browse/PIVOT-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459993#comment-13459993 ] Roger Whitcomb commented on PIVOT-873: -- Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTableViewSkin.java Transmitting file data . Committed revision 1388236. First phase which is to implement the style and see that it works. I still would like to get the mouse click propagated to child fields in the editor (if possible). Provide a style for TableVIew that allows one click to start row editing Key: PIVOT-873 URL: https://issues.apache.org/jira/browse/PIVOT-873 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Trivial Labels: tableview Fix For: 2.0.3 Normally, a double click is required in a TableView row to initiate editing of the row. Our users would like to start editing right away. The proposal is to add a new style (implemented in TerraTableViewSkin) called editOnMouseDown that would allow the first click to begin editing. The default behavior would remain the same (edit is started on double click). It is not clear if I can implement it such that the first click would not only initiate editing but also toggle checkboxes or select radio buttons if there are any in the row editor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-873) Provide a style for TableVIew that allows one click to start row editing
[ https://issues.apache.org/jira/browse/PIVOT-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460665#comment-13460665 ] Roger Whitcomb commented on PIVOT-873: -- Hi Sandro, just want to see if I can get the click propagated to the children still. So, not quite resolved. Provide a style for TableVIew that allows one click to start row editing Key: PIVOT-873 URL: https://issues.apache.org/jira/browse/PIVOT-873 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Trivial Labels: tableview Fix For: 2.0.3 Normally, a double click is required in a TableView row to initiate editing of the row. Our users would like to start editing right away. The proposal is to add a new style (implemented in TerraTableViewSkin) called editOnMouseDown that would allow the first click to begin editing. The default behavior would remain the same (edit is started on double click). It is not clear if I can implement it such that the first click would not only initiate editing but also toggle checkboxes or select radio buttons if there are any in the row editor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (PIVOT-721) ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style
[ https://issues.apache.org/jira/browse/PIVOT-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reopened PIVOT-721: -- Assignee: Roger Whitcomb (was: Sandro Martini) Reopening this issue because setting the fill:true has actually messed up a number of buttons in our application. Rethinking this fix. The default ButtonDataRenderer shouldn't have fill:true, but maybe setting a fill icon should set this style Trying that ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style - Key: PIVOT-721 URL: https://issues.apache.org/jira/browse/PIVOT-721 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0 Reporter: Bill van Melle Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: pivot721_imageview_only_for_debug_DO_NOT_COMMIT.patch ButtonDataRenderer has a setFillIcon method, which supposedly should allow the button's image to be scaled to fit the button. However, it has no effect, because the renderer is a BoxPane with the default fill=false. Fix: In the ButtonDataRenderer constructor, add getStyles().put(fill, true); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-721) ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style
[ https://issues.apache.org/jira/browse/PIVOT-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-721: - Attachment: 721.diff Here's my proposed fix. The default behavior remains as it was before the last fix (i.e., fill is false normally). If setFillIcon(true) is called, then the fill is set to true and in this case the render method will then set the image size to the button size, allowing the image to both scale up and down to fit the button. ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style - Key: PIVOT-721 URL: https://issues.apache.org/jira/browse/PIVOT-721 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0 Reporter: Bill van Melle Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: 721.diff, pivot721_imageview_only_for_debug_DO_NOT_COMMIT.patch ButtonDataRenderer has a setFillIcon method, which supposedly should allow the button's image to be scaled to fit the button. However, it has no effect, because the renderer is a BoxPane with the default fill=false. Fix: In the ButtonDataRenderer constructor, add getStyles().put(fill, true); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-721) ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style
[ https://issues.apache.org/jira/browse/PIVOT-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-721. -- Resolution: Fixed Sendingtests\src\org\apache\pivot\tests\issues\Pivot721.java Sendingwtk\src\org\apache\pivot\wtk\content\ButtonDataRenderer.java Transmitting file data .. Committed revision 1391496. ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style - Key: PIVOT-721 URL: https://issues.apache.org/jira/browse/PIVOT-721 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0 Reporter: Bill van Melle Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: 721.diff, pivot721_imageview_only_for_debug_DO_NOT_COMMIT.patch ButtonDataRenderer has a setFillIcon method, which supposedly should allow the button's image to be scaled to fit the button. However, it has no effect, because the renderer is a BoxPane with the default fill=false. Fix: In the ButtonDataRenderer constructor, add getStyles().put(fill, true); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-721) ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style
[ https://issues.apache.org/jira/browse/PIVOT-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465676#comment-13465676 ] Roger Whitcomb commented on PIVOT-721: -- In trunk ... Sending. Sendingtests\src\org\apache\pivot\tests\issues\Pivot721.java Sendingwtk\src\org\apache\pivot\wtk\content\ButtonDataRenderer.java Transmitting file data .. Committed revision 1391504. ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style - Key: PIVOT-721 URL: https://issues.apache.org/jira/browse/PIVOT-721 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0 Reporter: Bill van Melle Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: 721.diff, pivot721_imageview_only_for_debug_DO_NOT_COMMIT.patch ButtonDataRenderer has a setFillIcon method, which supposedly should allow the button's image to be scaled to fit the button. However, it has no effect, because the renderer is a BoxPane with the default fill=false. Fix: In the ButtonDataRenderer constructor, add getStyles().put(fill, true); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-721) ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style
[ https://issues.apache.org/jira/browse/PIVOT-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465711#comment-13465711 ] Roger Whitcomb commented on PIVOT-721: -- Checked for setFillIcon in other examples and tutorials and none were found except Pivot721.java. Checked this fix in our applications and everything appears fine. Pivot721 works great. Even the 200x200 case with the renderer with setFillIcon(true) works correctly and the image is scaled to fill the button. Bill, can you take the latest 2.0.3 code and check to make sure? ButtonDataRenderer#setFillIcon has no effect, because its BoxPane doesn't have fill style - Key: PIVOT-721 URL: https://issues.apache.org/jira/browse/PIVOT-721 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0 Reporter: Bill van Melle Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: 721.diff, pivot721_imageview_only_for_debug_DO_NOT_COMMIT.patch ButtonDataRenderer has a setFillIcon method, which supposedly should allow the button's image to be scaled to fit the button. However, it has no effect, because the renderer is a BoxPane with the default fill=false. Fix: In the ButtonDataRenderer constructor, add getStyles().put(fill, true); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-874) StockTracker: removing multiple symbols may remove unselected ones too
[ https://issues.apache.org/jira/browse/PIVOT-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466370#comment-13466370 ] Roger Whitcomb commented on PIVOT-874: -- Thank you for the patch. I will apply it and commit once I verify it. StockTracker: removing multiple symbols may remove unselected ones too -- Key: PIVOT-874 URL: https://issues.apache.org/jira/browse/PIVOT-874 Project: Pivot Issue Type: Bug Components: tutorials Affects Versions: 2.0.2 Reporter: Jiri Locker Priority: Minor Attachments: 0001-Remove-multiple-symbols-in-StockTracker-correctly.patch When multiple symbols are selected and remove button is clicked, the complete range from first to last selected symbol is removed. However there may be unselected symbols in that range, which are (unexpectedly) removed too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-874) StockTracker: removing multiple symbols may remove unselected ones too
[ https://issues.apache.org/jira/browse/PIVOT-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13467123#comment-13467123 ] Roger Whitcomb commented on PIVOT-874: -- 2.0.3 branch: Sending 2.0.x/tutorials/src/org/apache/pivot/tutorials/stocktracker/StockTrackerWindow.java Transmitting file data . Committed revision 1392533. StockTracker: removing multiple symbols may remove unselected ones too -- Key: PIVOT-874 URL: https://issues.apache.org/jira/browse/PIVOT-874 Project: Pivot Issue Type: Bug Components: tutorials Affects Versions: 2.0.2 Reporter: Jiri Locker Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: 0001-Remove-multiple-symbols-in-StockTracker-correctly.patch When multiple symbols are selected and remove button is clicked, the complete range from first to last selected symbol is removed. However there may be unselected symbols in that range, which are (unexpectedly) removed too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-874) StockTracker: removing multiple symbols may remove unselected ones too
[ https://issues.apache.org/jira/browse/PIVOT-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-874. -- Resolution: Fixed [trunk] Sending. Sending tutorials\src\org\apache\pivot\tutorials\stocktracker\StockTrackerWindow.java Transmitting file data . Committed revision 1392539. StockTracker: removing multiple symbols may remove unselected ones too -- Key: PIVOT-874 URL: https://issues.apache.org/jira/browse/PIVOT-874 Project: Pivot Issue Type: Bug Components: tutorials Affects Versions: 2.0.2 Reporter: Jiri Locker Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: 0001-Remove-multiple-symbols-in-StockTracker-correctly.patch When multiple symbols are selected and remove button is clicked, the complete range from first to last selected symbol is removed. However there may be unselected symbols in that range, which are (unexpectedly) removed too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PIVOT-875) JSON should support using pivot.collections.Map directly
Roger Whitcomb created PIVOT-875: Summary: JSON should support using pivot.collections.Map directly Key: PIVOT-875 URL: https://issues.apache.org/jira/browse/PIVOT-875 Project: Pivot Issue Type: Improvement Components: core-json Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Priority: Trivial Fix For: 2.0.3 When supplying a pivot.collections.Map as the data object for a TableView, the data is fetched for each row using JSON.get(...). However, this method will default to using the BeanAdapter for anything other than a java.util.Map, which results in values like class, capacity, count and comparator fetching the values for the Map object instead of using the get method of the actual map to get the values. This fix will likely speed things up (a bit) because the first if in the chain will now succeed for Pivot Map-based objects, instead of having to fail and do three other tests before getting to the dictionary.get for these objects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-875) JSON should support using pivot.collections.Map directly
[ https://issues.apache.org/jira/browse/PIVOT-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-875. -- Resolution: Fixed [trunk] Sendingcore\src\org\apache\pivot\json\JSON.java Transmitting file data . Committed revision 1394847. [branches/2.0.x] Sending. Sendingcore\src\org\apache\pivot\json\JSON.java Transmitting file data . Committed revision 1394855. JSON should support using pivot.collections.Map directly Key: PIVOT-875 URL: https://issues.apache.org/jira/browse/PIVOT-875 Project: Pivot Issue Type: Improvement Components: core-json Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Priority: Trivial Labels: JSON Fix For: 2.0.3 When supplying a pivot.collections.Map as the data object for a TableView, the data is fetched for each row using JSON.get(...). However, this method will default to using the BeanAdapter for anything other than a java.util.Map, which results in values like class, capacity, count and comparator fetching the values for the Map object instead of using the get method of the actual map to get the values. This fix will likely speed things up (a bit) because the first if in the chain will now succeed for Pivot Map-based objects, instead of having to fail and do three other tests before getting to the dictionary.get for these objects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-875) JSON should support using pivot.collections.Map directly
[ https://issues.apache.org/jira/browse/PIVOT-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470782#comment-13470782 ] Roger Whitcomb commented on PIVOT-875: -- Also had to fix the JSONSerializerTest because it was relying on the old (IMHO broken) behavior and checking the value of count from a serialized JSON map. ant test now runs clean again. [trunk] Sendingcore\test\org\apache\pivot\json\test\JSONSerializerTest.java Transmitting file data . Committed revision 1394858. [branches/2.0.x] Sending. Sendingcore\test\org\apache\pivot\json\test\JSONSerializerTest.java Transmitting file data . Committed revision 1394859. JSON should support using pivot.collections.Map directly Key: PIVOT-875 URL: https://issues.apache.org/jira/browse/PIVOT-875 Project: Pivot Issue Type: Improvement Components: core-json Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Priority: Trivial Labels: JSON Fix For: 2.0.3 When supplying a pivot.collections.Map as the data object for a TableView, the data is fetched for each row using JSON.get(...). However, this method will default to using the BeanAdapter for anything other than a java.util.Map, which results in values like class, capacity, count and comparator fetching the values for the Map object instead of using the get method of the actual map to get the values. This fix will likely speed things up (a bit) because the first if in the chain will now succeed for Pivot Map-based objects, instead of having to fail and do three other tests before getting to the dictionary.get for these objects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-878) Show FileBrowserSheet while Initializing
[ https://issues.apache.org/jira/browse/PIVOT-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476232#comment-13476232 ] Roger Whitcomb commented on PIVOT-878: -- @Ronald -- can you test this with the current (pre-release) 2.0.3 code? I made some changes in this area, but I don't remember if the work was done before 2.0.2 or after. Thanks. Show FileBrowserSheet while Initializing Key: PIVOT-878 URL: https://issues.apache.org/jira/browse/PIVOT-878 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All (Mostly Windows) Reporter: Ronald Thomas Assignee: Roger Whitcomb Priority: Minor Labels: Browsing, File, FileBrowserSheet, performance, responsiveness, wtk, wtk-terra Fix For: 2.1 If the list of file roots returned by http://docs.oracle.com/javase/1.4.2/docs/api/java/io/File.html#listRoots() includes more than a few network drives (primarily on windows where each mapped drive is its own file system root), or if the initial path on the FileBrowserSheet maps to a device that takes a while to spin up, the FileBrowserSheet may not appear on the screen for several seconds making the Pivot app appear unresponsive. It would help if there were some indication of activity immediately after the call to the FileBrowserSheet.open() method. The FileBrowserSheet could be displayed in a loading mode and then switched to its normal display mode once the potentially long-running initialization has completed. In this case, the long running code is around line 936-947 of the 2.0.2 release source file at wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraFileBrowserSkin.java Steps to reproduce: # Create a Pivot application that opens a FileBrowserSheet using a button. # Map about 6 network drives or connect external hard drives to drive letters on a machine running windows # Wait enough time for the power-management spin down on some or all of the mapped or connected drives # Run the Pivot application and click the button that opens the FileBrowserSheet # *Nothing appears to be happening for several seconds* (far too long) while the JVM collects the results of File.listRoots() to populate the driveListButton listData. # Finally after several seconds, the FileBrowserSheet appears. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-879) Need access to Displays list in order to support multiple host windows
[ https://issues.apache.org/jira/browse/PIVOT-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-879: - Attachment: 879.patch This patch implements the needed access. Need access to Displays list in order to support multiple host windows -- Key: PIVOT-879 URL: https://issues.apache.org/jira/browse/PIVOT-879 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: 879.patch We are using multiple host windows using code from the pivot-contrib area, and observed various small painting problems, for instance a rollup would not actuall expand in a new host window until the mouse was moved. The resolution is to allow a newly hosted Display to add itself to the ApplicationContext list of Displays so the repaint and other logic will work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-879) Need access to Displays list in order to support multiple host windows
[ https://issues.apache.org/jira/browse/PIVOT-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-879: - Description: We are using multiple host windows using code from the pivot-contrib area, and observed various small painting problems, for instance a rollup would not actually expand in a new host window until the mouse was moved. The resolution is to allow a newly hosted Display to add itself to the ApplicationContext list of Displays so the repaint and other logic will work. (was: We are using multiple host windows using code from the pivot-contrib area, and observed various small painting problems, for instance a rollup would not actuall expand in a new host window until the mouse was moved. The resolution is to allow a newly hosted Display to add itself to the ApplicationContext list of Displays so the repaint and other logic will work.) Need access to Displays list in order to support multiple host windows -- Key: PIVOT-879 URL: https://issues.apache.org/jira/browse/PIVOT-879 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: 879.patch We are using multiple host windows using code from the pivot-contrib area, and observed various small painting problems, for instance a rollup would not actually expand in a new host window until the mouse was moved. The resolution is to allow a newly hosted Display to add itself to the ApplicationContext list of Displays so the repaint and other logic will work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-879) Need access to Displays list in order to support multiple host windows
[ https://issues.apache.org/jira/browse/PIVOT-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-879. -- Resolution: Fixed Need access to Displays list in order to support multiple host windows -- Key: PIVOT-879 URL: https://issues.apache.org/jira/browse/PIVOT-879 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: 879.patch We are using multiple host windows using code from the pivot-contrib area, and observed various small painting problems, for instance a rollup would not actually expand in a new host window until the mouse was moved. The resolution is to allow a newly hosted Display to add itself to the ApplicationContext list of Displays so the repaint and other logic will work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-879) Need access to Displays list in order to support multiple host windows
[ https://issues.apache.org/jira/browse/PIVOT-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476442#comment-13476442 ] Roger Whitcomb commented on PIVOT-879: -- [trunk]: Sendingwtk\src\org\apache\pivot\wtk\ApplicationContext.java Transmitting file data . Committed revision 1398511. [branches/2.0.x]: Sending. Sendingwtk\src\org\apache\pivot\wtk\ApplicationContext.java Transmitting file data . Committed revision 1398512. Need access to Displays list in order to support multiple host windows -- Key: PIVOT-879 URL: https://issues.apache.org/jira/browse/PIVOT-879 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: 879.patch We are using multiple host windows using code from the pivot-contrib area, and observed various small painting problems, for instance a rollup would not actually expand in a new host window until the mouse was moved. The resolution is to allow a newly hosted Display to add itself to the ApplicationContext list of Displays so the repaint and other logic will work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PIVOT-558) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string
[ https://issues.apache.org/jira/browse/PIVOT-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-558: Assignee: Roger Whitcomb (was: Sandro Martini) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string Key: PIVOT-558 URL: https://issues.apache.org/jira/browse/PIVOT-558 Project: Pivot Issue Type: Improvement Components: core-beans Reporter: Appddevvv Assignee: Roger Whitcomb Priority: Minor Fix For: 2.1 Attachments: bean.patch API: public void putAll(MapString, ? values) public boolean putAll(MapString, ? values, boolean ignoreErrors) where ignore errors indicates that any errors/exceptions thrown should be caught. If any are thrown or errors occur, true is returned, otherwise false. I'll submit a patch if you accept this improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-558) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string
[ https://issues.apache.org/jira/browse/PIVOT-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-558: - Attachment: bean.patch I am persuaded that there is sufficient utility for the amount of code that we might as well add it. But, for now I want to just put it into BeanAdapter instead of adding to the Map interface or adding a new Map.Util class. The attached patch file shows the implementation (and it is just as easy as Greg indicated). BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string Key: PIVOT-558 URL: https://issues.apache.org/jira/browse/PIVOT-558 Project: Pivot Issue Type: Improvement Components: core-beans Reporter: Appddevvv Assignee: Sandro Martini Priority: Minor Fix For: 2.1 Attachments: bean.patch API: public void putAll(MapString, ? values) public boolean putAll(MapString, ? values, boolean ignoreErrors) where ignore errors indicates that any errors/exceptions thrown should be caught. If any are thrown or errors occur, true is returned, otherwise false. I'll submit a patch if you accept this improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-558) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string
[ https://issues.apache.org/jira/browse/PIVOT-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-558: - Attachment: (was: bean.patch) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string Key: PIVOT-558 URL: https://issues.apache.org/jira/browse/PIVOT-558 Project: Pivot Issue Type: Improvement Components: core-beans Reporter: Appddevvv Assignee: Roger Whitcomb Priority: Minor Fix For: 2.1, 2.0.3 Attachments: bean.patch API: public void putAll(MapString, ? values) public boolean putAll(MapString, ? values, boolean ignoreErrors) where ignore errors indicates that any errors/exceptions thrown should be caught. If any are thrown or errors occur, true is returned, otherwise false. I'll submit a patch if you accept this improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-558) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string
[ https://issues.apache.org/jira/browse/PIVOT-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-558: - Attachment: bean.patch Updated the patch (should have named the methods putAll -- was setAll the first time). BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string Key: PIVOT-558 URL: https://issues.apache.org/jira/browse/PIVOT-558 Project: Pivot Issue Type: Improvement Components: core-beans Reporter: Appddevvv Assignee: Roger Whitcomb Priority: Minor Fix For: 2.1, 2.0.3 Attachments: bean.patch API: public void putAll(MapString, ? values) public boolean putAll(MapString, ? values, boolean ignoreErrors) where ignore errors indicates that any errors/exceptions thrown should be caught. If any are thrown or errors occur, true is returned, otherwise false. I'll submit a patch if you accept this improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-558) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string
[ https://issues.apache.org/jira/browse/PIVOT-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13478016#comment-13478016 ] Roger Whitcomb commented on PIVOT-558: -- [trunk]: Sendingcore\src\org\apache\pivot\beans\BeanAdapter.java Transmitting file data . Committed revision 1399331. [branches/2.0.x]: Sending. Sendingcore\src\org\apache\pivot\beans\BeanAdapter.java Transmitting file data . Committed revision 1399334. BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string Key: PIVOT-558 URL: https://issues.apache.org/jira/browse/PIVOT-558 Project: Pivot Issue Type: Improvement Components: core-beans Reporter: Appddevvv Assignee: Roger Whitcomb Priority: Minor Fix For: 2.1, 2.0.3 Attachments: bean.patch API: public void putAll(MapString, ? values) public boolean putAll(MapString, ? values, boolean ignoreErrors) where ignore errors indicates that any errors/exceptions thrown should be caught. If any are thrown or errors occur, true is returned, otherwise false. I'll submit a patch if you accept this improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-878) Show FileBrowserSheet while Initializing
[ https://issues.apache.org/jira/browse/PIVOT-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13478683#comment-13478683 ] Roger Whitcomb commented on PIVOT-878: -- @ronald: I believe your thought that the bulk of time is spent in the rootDirectoryChanged() method is correct. That would end up calling TerraFileBrowserSkin.rootDirectoryChanged() method (from the listener list in FileBrowser) which in turn would (the first time) do a File.getRoots() call, which would end up connecting to each network drive in turn. I will look at your profiler screen shot. There were some improvements suggested on another issue with sample code (for 2.0, which I would have to update for 2.0.3 now) that perhaps could speed this up. I just haven't had time to go through the patch code yet. Thank you very much for the analysis and the test case. I will commit the example code to the appropriate section of the source and see what we can do to speed this up. Show FileBrowserSheet while Initializing Key: PIVOT-878 URL: https://issues.apache.org/jira/browse/PIVOT-878 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All (Mostly Windows) Reporter: Ronald Thomas Assignee: Roger Whitcomb Priority: Minor Labels: Browsing, File, FileBrowserSheet, performance, responsiveness, wtk, wtk-terra Fix For: 2.1 Attachments: PIVOT-878_example_src.zip, tptp_profiler_exec_call_tree_screenshot.png If the list of file roots returned by http://docs.oracle.com/javase/1.4.2/docs/api/java/io/File.html#listRoots() includes more than a few network drives (primarily on windows where each mapped drive is its own file system root), or if the initial path on the FileBrowserSheet maps to a device that takes a while to spin up, the FileBrowserSheet may not appear on the screen for several seconds making the Pivot app appear unresponsive. It would help if there were some indication of activity immediately after the call to the FileBrowserSheet.open() method. The FileBrowserSheet could be displayed in a loading mode and then switched to its normal display mode once the potentially long-running initialization has completed. In this case, the long running code is around line 936-947 of the 2.0.2 release source file at wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraFileBrowserSkin.java Steps to reproduce: # Create a Pivot application that opens a FileBrowserSheet using a button. # Map about 6 network drives or connect external hard drives to drive letters on a machine running windows # Wait enough time for the power-management spin down on some or all of the mapped or connected drives # Run the Pivot application and click the button that opens the FileBrowserSheet # *Nothing appears to be happening for several seconds* (far too long) while the JVM collects the results of File.listRoots() to populate the driveListButton listData. # Finally after several seconds, the FileBrowserSheet appears. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-558) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string
[ https://issues.apache.org/jira/browse/PIVOT-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13479059#comment-13479059 ] Roger Whitcomb commented on PIVOT-558: -- I still wanted to investigate moving this into Map (or Map.Util) for 2.1 --- so not sure how to do that? Maybe make a new issue for 2.1 and reference this one? Or leave this open still and mark for 2.1?? What do you think? BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string Key: PIVOT-558 URL: https://issues.apache.org/jira/browse/PIVOT-558 Project: Pivot Issue Type: Improvement Components: core-beans Reporter: Appddevvv Assignee: Roger Whitcomb Priority: Minor Fix For: 2.1, 2.0.3 Attachments: bean.patch API: public void putAll(MapString, ? values) public boolean putAll(MapString, ? values, boolean ignoreErrors) where ignore errors indicates that any errors/exceptions thrown should be caught. If any are thrown or errors occur, true is returned, otherwise false. I'll submit a patch if you accept this improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-558) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string
[ https://issues.apache.org/jira/browse/PIVOT-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-558: - Fix Version/s: (was: 2.1) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string Key: PIVOT-558 URL: https://issues.apache.org/jira/browse/PIVOT-558 Project: Pivot Issue Type: Improvement Components: core-beans Reporter: Appddevvv Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: bean.patch API: public void putAll(MapString, ? values) public boolean putAll(MapString, ? values, boolean ignoreErrors) where ignore errors indicates that any errors/exceptions thrown should be caught. If any are thrown or errors occur, true is returned, otherwise false. I'll submit a patch if you accept this improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-558) BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string
[ https://issues.apache.org/jira/browse/PIVOT-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-558. -- Resolution: Fixed Resolved. Going to add another issue for 2.1. BeanAdapter should have a putAll method to allow multiple property set in one method call...especially useful when setting properties from a JSON string Key: PIVOT-558 URL: https://issues.apache.org/jira/browse/PIVOT-558 Project: Pivot Issue Type: Improvement Components: core-beans Reporter: Appddevvv Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Attachments: bean.patch API: public void putAll(MapString, ? values) public boolean putAll(MapString, ? values, boolean ignoreErrors) where ignore errors indicates that any errors/exceptions thrown should be caught. If any are thrown or errors occur, true is returned, otherwise false. I'll submit a patch if you accept this improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-834) Form.getSection(Component) to return the section for nested components
[ https://issues.apache.org/jira/browse/PIVOT-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482513#comment-13482513 ] Roger Whitcomb commented on PIVOT-834: -- In looking into this change, there are some subtle implications to changing the existing method: 1) TerraFormSkin uses Form.getSection() in conjunction with section.indexOf() in the labelChanged method. This probably would break badly with the proposed change, and the follow-on changes to getIndex and etc. would quickly get to be very confusing. 2) As someone noted this is easy enough to implement in an application by following the parent chain. So, I would propose adding another method: Form.getEnclosingSection(Component) that would do what is requested for when it is needed, but leave the existing method alone. Form.getSection(Component) to return the section for nested components -- Key: PIVOT-834 URL: https://issues.apache.org/jira/browse/PIVOT-834 Project: Pivot Issue Type: New Feature Components: wtk Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3 Reporter: David Keen Assignee: Sandro Martini Priority: Minor Fix For: 2.0.4 Form.getSection returns the Form.Section of the given component. However, it currently only works for top-level components and returns null for components nested inside other components. This request is for the method to return the correct form section for all components of a form, regardless of whether they are nested or not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-834) Form.getSection(Component) to return the section for nested components
[ https://issues.apache.org/jira/browse/PIVOT-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-834: - Attachment: pivot-834.patch The pivot-834.patch file implements my suggestion (no change to getSection, add a new getEnclosingSection method). Adds Javadoc to explain what each does. Form.getSection(Component) to return the section for nested components -- Key: PIVOT-834 URL: https://issues.apache.org/jira/browse/PIVOT-834 Project: Pivot Issue Type: New Feature Components: wtk Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3 Reporter: David Keen Assignee: Sandro Martini Priority: Minor Fix For: 2.0.4 Attachments: pivot-834.patch Form.getSection returns the Form.Section of the given component. However, it currently only works for top-level components and returns null for components nested inside other components. This request is for the method to return the correct form section for all components of a form, regardless of whether they are nested or not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-878) Show FileBrowserSheet while Initializing
[ https://issues.apache.org/jira/browse/PIVOT-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482576#comment-13482576 ] Roger Whitcomb commented on PIVOT-878: -- Actually this is pretty much the same issue as Pivot-796. There is code there that I will try to implement in the current trunk to improve the user experience. Show FileBrowserSheet while Initializing Key: PIVOT-878 URL: https://issues.apache.org/jira/browse/PIVOT-878 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All (Mostly Windows) Reporter: Ronald Thomas Assignee: Roger Whitcomb Priority: Minor Labels: Browsing, File, FileBrowserSheet, performance, responsiveness, wtk, wtk-terra Fix For: 2.1, 2.0.3 Attachments: PIVOT-878_example_src.zip, tptp_profiler_exec_call_tree_screenshot.png If the list of file roots returned by http://docs.oracle.com/javase/1.4.2/docs/api/java/io/File.html#listRoots() includes more than a few network drives (primarily on windows where each mapped drive is its own file system root), or if the initial path on the FileBrowserSheet maps to a device that takes a while to spin up, the FileBrowserSheet may not appear on the screen for several seconds making the Pivot app appear unresponsive. It would help if there were some indication of activity immediately after the call to the FileBrowserSheet.open() method. The FileBrowserSheet could be displayed in a loading mode and then switched to its normal display mode once the potentially long-running initialization has completed. In this case, the long running code is around line 936-947 of the 2.0.2 release source file at wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraFileBrowserSkin.java Steps to reproduce: # Create a Pivot application that opens a FileBrowserSheet using a button. # Map about 6 network drives or connect external hard drives to drive letters on a machine running windows # Wait enough time for the power-management spin down on some or all of the mapped or connected drives # Run the Pivot application and click the button that opens the FileBrowserSheet # *Nothing appears to be happening for several seconds* (far too long) while the JVM collects the results of File.listRoots() to populate the driveListButton listData. # Finally after several seconds, the FileBrowserSheet appears. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (PIVOT-878) Show FileBrowserSheet while Initializing
[ https://issues.apache.org/jira/browse/PIVOT-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482576#comment-13482576 ] Roger Whitcomb edited comment on PIVOT-878 at 10/23/12 7:05 PM: Actually this is pretty much the same issue as PIVOT-796. There is code there that I will try to implement in the current trunk to improve the user experience. was (Author: rwhitcomb): Actually this is pretty much the same issue as Pivot-796. There is code there that I will try to implement in the current trunk to improve the user experience. Show FileBrowserSheet while Initializing Key: PIVOT-878 URL: https://issues.apache.org/jira/browse/PIVOT-878 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All (Mostly Windows) Reporter: Ronald Thomas Assignee: Roger Whitcomb Priority: Minor Labels: Browsing, File, FileBrowserSheet, performance, responsiveness, wtk, wtk-terra Fix For: 2.1, 2.0.3 Attachments: PIVOT-878_example_src.zip, tptp_profiler_exec_call_tree_screenshot.png If the list of file roots returned by http://docs.oracle.com/javase/1.4.2/docs/api/java/io/File.html#listRoots() includes more than a few network drives (primarily on windows where each mapped drive is its own file system root), or if the initial path on the FileBrowserSheet maps to a device that takes a while to spin up, the FileBrowserSheet may not appear on the screen for several seconds making the Pivot app appear unresponsive. It would help if there were some indication of activity immediately after the call to the FileBrowserSheet.open() method. The FileBrowserSheet could be displayed in a loading mode and then switched to its normal display mode once the potentially long-running initialization has completed. In this case, the long running code is around line 936-947 of the 2.0.2 release source file at wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraFileBrowserSkin.java Steps to reproduce: # Create a Pivot application that opens a FileBrowserSheet using a button. # Map about 6 network drives or connect external hard drives to drive letters on a machine running windows # Wait enough time for the power-management spin down on some or all of the mapped or connected drives # Run the Pivot application and click the button that opens the FileBrowserSheet # *Nothing appears to be happening for several seconds* (far too long) while the JVM collects the results of File.listRoots() to populate the driveListButton listData. # Finally after several seconds, the FileBrowserSheet appears. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-731) Ignore Flag for controls within a Rollup Heading
[ https://issues.apache.org/jira/browse/PIVOT-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-731. -- Resolution: Not A Problem Fix Version/s: (was: 2.0.4) 2.0.2 Already implemented as the headingToggles style. Ignore Flag for controls within a Rollup Heading Key: PIVOT-731 URL: https://issues.apache.org/jira/browse/PIVOT-731 Project: Pivot Issue Type: New Feature Components: wtk Affects Versions: 2.0 Environment: Windows 7 Professional 64bit Java(TM) SE Runtime Environment (build 1.6.0_21-b06) Reporter: Daniel Kuschny Assignee: Sandro Martini Priority: Minor Labels: collapse, expanded, header, rollup Fix For: 2.0.2 If you place any control which requires a focus into a Rollup Header you can't click on it without collapsing the rollup. I tried to place a ListButton within a Rollup Header: Rollup expanded=true heading BoxPane orientation=horizontal Label text=Choose: / ListButton listData=['Option 1', 'Option 2'] / /BoxPane /heading ... If I click on the ListButton, the rollup expands/collapses. Please add a shared property which allows preventing the collapse behaviour on specific controls: Rollup expanded=true heading BoxPane orientation=horizontal Label text=Choose: / ListButton listData=['Option 1', 'Option 2'] Rollup.ignore=true / /BoxPane /heading ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-731) Ignore Flag for controls within a Rollup Heading
[
https://issues.apache.org/jira/browse/PIVOT-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13484281#comment-13484281
]
Roger Whitcomb commented on PIVOT-731:
--
There is an existing style for Rollup that will do what you want:
headingToggles, so for your example, you would do:
Rollup expanded=true styles={headingToggles:false}
heading
BoxPane orientation=horizontal
Label text=Choose:/
ListButton listData=['Option 1', 'Option 2']/
/BoxPane
/heading
...
The result is that only clicking on the rollup button would do the rollup
action, and not clicking on the header component(s).
So, I'm going to close this issue as already implemented. But, feel free to
reopen if you feel there is still a problem in your application doing it this
way.
Ignore Flag for controls within a Rollup Heading
Key: PIVOT-731
URL: https://issues.apache.org/jira/browse/PIVOT-731
Project: Pivot
Issue Type: New Feature
Components: wtk
Affects Versions: 2.0
Environment: Windows 7 Professional 64bit
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Reporter: Daniel Kuschny
Assignee: Sandro Martini
Priority: Minor
Labels: collapse, expanded, header, rollup
Fix For: 2.0.2
If you place any control which requires a focus into a Rollup Header you
can't click on it without collapsing the rollup.
I tried to place a ListButton within a Rollup Header:
Rollup expanded=true
heading
BoxPane orientation=horizontal
Label text=Choose: /
ListButton listData=['Option 1', 'Option 2'] /
/BoxPane
/heading
...
If I click on the ListButton, the rollup expands/collapses. Please add a
shared property which allows preventing the collapse behaviour on specific
controls:
Rollup expanded=true
heading
BoxPane orientation=horizontal
Label text=Choose: /
ListButton listData=['Option 1', 'Option 2']
Rollup.ignore=true /
/BoxPane
/heading
...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PIVOT-276) Add a GridView component
[ https://issues.apache.org/jira/browse/PIVOT-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-276: Assignee: Edvin Syse Add a GridView component Key: PIVOT-276 URL: https://issues.apache.org/jira/browse/PIVOT-276 Project: Pivot Issue Type: New Feature Components: wtk Reporter: Greg Brown Assignee: Edvin Syse Fix For: 2.1 Attachments: grid_view_component_explorer.patch, grid_view_component_explorer.png, GridView.patch GridView would be a data-driven component like ListView or TableView, but would arrange items in a 2-dimensional grid instead of in rows (similar to icon view in Windows Explorer or Mac OS X Finder). It would provide an orientation property that would dictate which way items would be laid out: a horizontal grid view would arrange items left to right, and a vertical grid view would arrange them top to bottom. GridView would assume a fixed renderer size, and would report preferred size based on orientation: e.g. the preferred size of a horizontal grid view would be (n * renderer width) x (renderer height). Constraining the preferred width of a horizontal grid view would cause the items to wrap at the end of each row; constraining the preferred height of a grid view would cause items to wrap at the end of each column. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (PIVOT-749) Transitions bug
[ https://issues.apache.org/jira/browse/PIVOT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-749. Looks like the patch has been applied, and verified. So I am closing the issue. Transitions bug --- Key: PIVOT-749 URL: https://issues.apache.org/jira/browse/PIVOT-749 Project: Pivot Issue Type: Bug Components: wtk-effects Affects Versions: 2.0 Environment: OS: Arch64 JVM: HotSpot 1.6.0_25 Reporter: Edgar Merino Priority: Minor Fix For: 2.0.1 Attachments: PIVOT-749.patch, TestTransition.java, Transition2.patch, Transition.diff Working with Transitions and ComponentMouseListeners, seems like reversing is not keeping up when mouse events happen too quickly. Attached is a test case where the bug can be reproduced: Hover the mouse quickly twice (mouseOver-mouseOut-mouseOver-mouseOut) over the component to see the bug. I've made some tests and it seems Transition#getPercentCompleted() reports a wrong value which is causing this behaviour, but I haven't been able to tackle the exact cause of the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-864) Add a pluggable file system architecture to FileBrowser so remote browsing can be done
[ https://issues.apache.org/jira/browse/PIVOT-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-864: - Due Date: 31/Dec/12 (was: 28/Sep/12) Add a pluggable file system architecture to FileBrowser so remote browsing can be done -- Key: PIVOT-864 URL: https://issues.apache.org/jira/browse/PIVOT-864 Project: Pivot Issue Type: New Feature Components: wtk Affects Versions: 2.0.2 Environment: Windows, Linux, OSX Reporter: Roger Whitcomb Assignee: Roger Whitcomb Labels: filebrowser Fix For: 2.1 Original Estimate: 336h Remaining Estimate: 336h Our application requires the ability to be able to browse (for instance) a Linux machine from the Windows desktop. For this I would like to add (somehow) a pluggable file system architecture so that I could (for instance) implement an FTP protocol underneath the FileBrowser so that I can browse through directories and files on something other than the local machine. We would also need to be able to type in a host name or TCP/IP address to start browsing the remote machine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (PIVOT-536) BXMLSerializer should provide a structure error object when a serializer error occurs
[ https://issues.apache.org/jira/browse/PIVOT-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-536. Resolution: Not A Problem Fix Version/s: (was: 2.1) 2.0.3 Closing as the feature is already available, so not a problem. BXMLSerializer should provide a structure error object when a serializer error occurs - Key: PIVOT-536 URL: https://issues.apache.org/jira/browse/PIVOT-536 Project: Pivot Issue Type: Improvement Components: wtk Reporter: Appddevvv Priority: Trivial Fix For: 2.0.3 When an error occurs in the serializer, logException() is typically called. The error message, line number and other information is typically not available for use by tooling. WTKXSerializer should provide a structured object with the error information in it e.g. the line number. I don't have a patch for this but I think a simple error object and a property accessor would be all that's needed. The error object could be accessed as part of exception handling. I came across when writing pivotpad (xamlpad like tool) and wanted to highlight the error in the bxml text. This improvement is targeted towards tooling support and has no other apparent use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (PIVOT-536) BXMLSerializer should provide a structure error object when a serializer error occurs
[ https://issues.apache.org/jira/browse/PIVOT-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reopened PIVOT-536: -- Assignee: Roger Whitcomb I'm going to reopen it myself to add (as Noel suggested) a method to return the location of the xmlStreamReader, which could be called at any time, but in the event of some other error. BXMLSerializer should provide a structure error object when a serializer error occurs - Key: PIVOT-536 URL: https://issues.apache.org/jira/browse/PIVOT-536 Project: Pivot Issue Type: Improvement Components: wtk Reporter: Appddevvv Assignee: Roger Whitcomb Priority: Trivial Fix For: 2.0.3 When an error occurs in the serializer, logException() is typically called. The error message, line number and other information is typically not available for use by tooling. WTKXSerializer should provide a structured object with the error information in it e.g. the line number. I don't have a patch for this but I think a simple error object and a property accessor would be all that's needed. The error object could be accessed as part of exception handling. I came across when writing pivotpad (xamlpad like tool) and wanted to highlight the error in the bxml text. This improvement is targeted towards tooling support and has no other apparent use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-536) BXMLSerializer should provide a structure error object when a serializer error occurs
[ https://issues.apache.org/jira/browse/PIVOT-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-536. -- Resolution: Fixed [trunk] Sendingcore\src\org\apache\pivot\beans\BXMLSerializer.java Transmitting file data . Committed revision 1405882. [branches/2.0.x] Sending. Sendingcore\src\org\apache\pivot\beans\BXMLSerializer.java Transmitting file data . Committed revision 1405883. BXMLSerializer should provide a structure error object when a serializer error occurs - Key: PIVOT-536 URL: https://issues.apache.org/jira/browse/PIVOT-536 Project: Pivot Issue Type: Improvement Components: wtk Reporter: Appddevvv Assignee: Roger Whitcomb Priority: Trivial Fix For: 2.0.3 When an error occurs in the serializer, logException() is typically called. The error message, line number and other information is typically not available for use by tooling. WTKXSerializer should provide a structured object with the error information in it e.g. the line number. I don't have a patch for this but I think a simple error object and a property accessor would be all that's needed. The error object could be accessed as part of exception handling. I came across when writing pivotpad (xamlpad like tool) and wanted to highlight the error in the bxml text. This improvement is targeted towards tooling support and has no other apparent use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-880) NPE when calling FileBrowser.setRootDirectory using a UNC path
[
https://issues.apache.org/jira/browse/PIVOT-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Whitcomb resolved PIVOT-880.
--
Resolution: Fixed
Fix Version/s: 2.0.3
[trunk]
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraFileBrowserSkin.java
Transmitting file data .
Committed revision 1407585.
[branches/2.0.x]
Sending.
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraFileBrowserSkin.java
Transmitting file data .
Committed revision 1407586.
NPE when calling FileBrowser.setRootDirectory using a UNC path
--
Key: PIVOT-880
URL: https://issues.apache.org/jira/browse/PIVOT-880
Project: Pivot
Issue Type: Bug
Components: wtk-terra
Affects Versions: 2.0.1
Environment: Windows XP with network shares
Reporter: Steven Swor
Assignee: Roger Whitcomb
Priority: Minor
Fix For: 2.1, 2.0.3
I'm using Pivot as the user interface to an enterprise application. I want
my users to be able to control applicaiton settings through the UI, such as
where to save output files. In this particular case, the users want to use a
network share accessed via a UNC path (\\server\share).
In testing, I discovered a NPE was being logged when I ran the following code:
{code}
FileBrowser browser = ... //assume the browser is shown
String path = ... //UNC path, such as \\server\share (escape slashes
removed for legibility)
java.io.File directory = new java.io.File(path);
if (directory.exists()) {
browser.setRootDirectory(directory);
}
{code}
The exception stack trace is:
{quote}
java.lang.NullPointerException
at
org.apache.pivot.wtk.skin.terra.TerraFileBrowserSkin$2.selectedItemChanged(TerraFileBrowserSkin.java:610)
at
org.apache.pivot.wtk.ListButton$ListButtonSelectionListenerList.selectedItemChanged(ListButton.java:131)
at org.apache.pivot.wtk.ListButton.setSelectedIndex(ListButton.java:514)
at org.apache.pivot.wtk.ListButton.setSelectedItem(ListButton.java:532)
at
org.apache.pivot.wtk.skin.terra.TerraFileBrowserSkin.rootDirectoryChanged(TerraFileBrowserSkin.java:955)
at
org.apache.pivot.wtk.FileBrowser$FileBrowserListenerList.rootDirectoryChanged(FileBrowser.java:44)
at
org.apache.pivot.wtk.FileBrowser.setRootDirectory(FileBrowser.java:127)
{quote}
Stepping through the code, it appears as though TerraFileBrowserSkin tries to
select the drive by looking for path separators (slash characters), but it
gets thrown off by the leading slashes in the UNC path.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-880) NPE when calling FileBrowser.setRootDirectory using a UNC path
[
https://issues.apache.org/jira/browse/PIVOT-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494203#comment-13494203
]
Roger Whitcomb commented on PIVOT-880:
--
@Steven: can you build the latest 2.0.x code and verify that this is fixed for
you? I was able to reproduce it and verified that this change fixed the
problem for me. Thanks.
NPE when calling FileBrowser.setRootDirectory using a UNC path
--
Key: PIVOT-880
URL: https://issues.apache.org/jira/browse/PIVOT-880
Project: Pivot
Issue Type: Bug
Components: wtk-terra
Affects Versions: 2.0.1
Environment: Windows XP with network shares
Reporter: Steven Swor
Assignee: Roger Whitcomb
Priority: Minor
Fix For: 2.1, 2.0.3
I'm using Pivot as the user interface to an enterprise application. I want
my users to be able to control applicaiton settings through the UI, such as
where to save output files. In this particular case, the users want to use a
network share accessed via a UNC path (\\server\share).
In testing, I discovered a NPE was being logged when I ran the following code:
{code}
FileBrowser browser = ... //assume the browser is shown
String path = ... //UNC path, such as \\server\share (escape slashes
removed for legibility)
java.io.File directory = new java.io.File(path);
if (directory.exists()) {
browser.setRootDirectory(directory);
}
{code}
The exception stack trace is:
{quote}
java.lang.NullPointerException
at
org.apache.pivot.wtk.skin.terra.TerraFileBrowserSkin$2.selectedItemChanged(TerraFileBrowserSkin.java:610)
at
org.apache.pivot.wtk.ListButton$ListButtonSelectionListenerList.selectedItemChanged(ListButton.java:131)
at org.apache.pivot.wtk.ListButton.setSelectedIndex(ListButton.java:514)
at org.apache.pivot.wtk.ListButton.setSelectedItem(ListButton.java:532)
at
org.apache.pivot.wtk.skin.terra.TerraFileBrowserSkin.rootDirectoryChanged(TerraFileBrowserSkin.java:955)
at
org.apache.pivot.wtk.FileBrowser$FileBrowserListenerList.rootDirectoryChanged(FileBrowser.java:44)
at
org.apache.pivot.wtk.FileBrowser.setRootDirectory(FileBrowser.java:127)
{quote}
Stepping through the code, it appears as though TerraFileBrowserSkin tries to
select the drive by looking for path separators (slash characters), but it
gets thrown off by the leading slashes in the UNC path.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-696) TextPane support for entering tab characters and tab stops
[ https://issues.apache.org/jira/browse/PIVOT-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13499016#comment-13499016 ] Roger Whitcomb commented on PIVOT-696: -- Committed this small change to TextArea: [trunk]: Sendingwtk\src\org\apache\pivot\wtk\TextArea.java Sendingwtk\src\org\apache\pivot\wtk\skin\TextAreaSkin.java Transmitting file data .. Committed revision 1410536. [branches/2.0.x]: Sending. Sendingwtk\src\org\apache\pivot\wtk\TextArea.java Sendingwtk\src\org\apache\pivot\wtk\skin\TextAreaSkin.java Transmitting file data .. Committed revision 1410537. TextPane support for entering tab characters and tab stops -- Key: PIVOT-696 URL: https://issues.apache.org/jira/browse/PIVOT-696 Project: Pivot Issue Type: Improvement Affects Versions: 2.0 Reporter: Taro App Assignee: Noel Grandin Priority: Minor Fix For: 2.1 Currently, if you press Ctrl+Tab in a TextArea, series of space characters entered. (The number of space characters can be specified with tabWidth property.) Text containing tabs can be set by TextArea.setText, but then tab characters are not displayed. It is desirable that TextArea supports tab stops so users can enter and see tab characters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-696) TextPane support for entering tab characters and tab stops
[ https://issues.apache.org/jira/browse/PIVOT-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13499116#comment-13499116 ] Roger Whitcomb commented on PIVOT-696: -- Extended the support of converting tabs to appropriate number of spaces to insertText also (which means paste also works): [trunk]: Sendingwtk\src\org\apache\pivot\wtk\TextArea.java Transmitting file data . Committed revision 1410555. [branches/2.0.x]: Sending. Sendingwtk\src\org\apache\pivot\wtk\TextArea.java Transmitting file data . Committed revision 1410556. TextPane support for entering tab characters and tab stops -- Key: PIVOT-696 URL: https://issues.apache.org/jira/browse/PIVOT-696 Project: Pivot Issue Type: Improvement Affects Versions: 2.0 Reporter: Taro App Assignee: Noel Grandin Priority: Minor Fix For: 2.1 Currently, if you press Ctrl+Tab in a TextArea, series of space characters entered. (The number of space characters can be specified with tabWidth property.) Text containing tabs can be set by TextArea.setText, but then tab characters are not displayed. It is desirable that TextArea supports tab stops so users can enter and see tab characters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PIVOT-883) Update Javadoc for ComponentStateListener method arguments
[ https://issues.apache.org/jira/browse/PIVOT-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-883: Assignee: Roger Whitcomb Update Javadoc for ComponentStateListener method arguments -- Key: PIVOT-883 URL: https://issues.apache.org/jira/browse/PIVOT-883 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 2.0, 2.0.1, 2.0.2 Reporter: Steven Swor Assignee: Roger Whitcomb Priority: Minor Labels: documentation,, javadoc Fix For: 2.0.3 Original Estimate: 1m Remaining Estimate: 1m The org.apache.pivot.wtk.ComponentStateListener interface has two methods, enabledChanged(Component) and focusedChanged(Component, Component). While it should be pretty intuitive that the single argument of enabledChanged is the component whose enabled state has changed, the javadoc for the focusedChanged method is a bit vague as to what each argument represents. I'm assuming that the component argument is the one which lost focus and obverseComponent is the one that gained focus, but I could have that backwards :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-883) Update Javadoc for ComponentStateListener method arguments
[ https://issues.apache.org/jira/browse/PIVOT-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-883. -- Resolution: Fixed Added more explanation of both methods (including the parameters) of the ComponentStateListener interface. [trunk] Sendingwtk\src\org\apache\pivot\wtk\ComponentStateListener.java Transmitting file data . Committed revision 1417081. [branches/2.0.x] Sending. Sendingwtk\src\org\apache\pivot\wtk\ComponentStateListener.java Transmitting file data . Committed revision 1417088. Update Javadoc for ComponentStateListener method arguments -- Key: PIVOT-883 URL: https://issues.apache.org/jira/browse/PIVOT-883 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 2.0, 2.0.1, 2.0.2 Reporter: Steven Swor Assignee: Roger Whitcomb Priority: Minor Labels: documentation,, javadoc Fix For: 2.0.3 Original Estimate: 1m Remaining Estimate: 1m The org.apache.pivot.wtk.ComponentStateListener interface has two methods, enabledChanged(Component) and focusedChanged(Component, Component). While it should be pretty intuitive that the single argument of enabledChanged is the component whose enabled state has changed, the javadoc for the focusedChanged method is a bit vague as to what each argument represents. I'm assuming that the component argument is the one which lost focus and obverseComponent is the one that gained focus, but I could have that backwards :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-696) TextPane support for entering tab characters and tab stops
[ https://issues.apache.org/jira/browse/PIVOT-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510205#comment-13510205 ] Roger Whitcomb commented on PIVOT-696: -- I added a new property to TextArea called expandTabs which is set to false by default, and which controls whether this tab expansion happens during setText and insertText. The default behavior (now) will be the same as it was in version 2.0.2, but by setting this property true the new behavior is enabled. [trunk]: Sendingwtk\src\org\apache\pivot\wtk\TextArea.java Transmitting file data . Committed revision 1417258. [branches/2.0.x]: Sending. Sendingwtk\src\org\apache\pivot\wtk\TextArea.java Transmitting file data . Committed revision 1417259. TextPane support for entering tab characters and tab stops -- Key: PIVOT-696 URL: https://issues.apache.org/jira/browse/PIVOT-696 Project: Pivot Issue Type: Improvement Affects Versions: 2.0 Reporter: Taro App Assignee: Noel Grandin Priority: Minor Fix For: 2.1 Currently, if you press Ctrl+Tab in a TextArea, series of space characters entered. (The number of space characters can be specified with tabWidth property.) Text containing tabs can be set by TextArea.setText, but then tab characters are not displayed. It is desirable that TextArea supports tab stops so users can enter and see tab characters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-884) Add support for dynamic construction of ListenerListCustomListener
[ https://issues.apache.org/jira/browse/PIVOT-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-884: - Summary: Add support for dynamic construction of ListenerListCustomListener (was: Add support for dynamic construction of ListerListCustomListener) Add support for dynamic construction of ListenerListCustomListener Key: PIVOT-884 URL: https://issues.apache.org/jira/browse/PIVOT-884 Project: Pivot Issue Type: New Feature Components: core-beans Affects Versions: 2.1, 2.0.3 Reporter: Karel Hübl Priority: Minor Fix For: 2.1 Attachments: Pivot-sample.zip As a Pivot application developer I would like to have option to dynamically create ListenerList implementation to support my custom Listener interface. I do not want to implement for each application Listener interface event dispatching logic. I use custom Listener interfaces to enable property binding between my application model classes and Pivot components in BXML. I implemented prototype of org.apache.pivot.util.listener.DynaListenerList class, which accepts Listener interface in constructor and provides event dispatcher in getEventDispatcher() method. Source will be attached, please consider this functionality in next Pivot release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PIVOT-887) Tutorial example code for NumericSpinnerData doesn't work as shown
Roger Whitcomb created PIVOT-887: Summary: Tutorial example code for NumericSpinnerData doesn't work as shown Key: PIVOT-887 URL: https://issues.apache.org/jira/browse/PIVOT-887 Project: Pivot Issue Type: Bug Components: tutorials Affects Versions: 2.0.2, 2.0.3 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 See mailing list archive for complete explanation: http://apache-pivot-users.399431.n3.nabble.com/Problem-using-wtk-content-NumericSpinnerData-td4022316.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-887) Tutorial example code for NumericSpinnerData doesn't work as shown
[ https://issues.apache.org/jira/browse/PIVOT-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542429#comment-13542429 ] Roger Whitcomb commented on PIVOT-887: -- Update the source for the tutorial: [trunk]: Sendingtutorials\www\spinners.xml Transmitting file data . Committed revision 1428056. [branches/2.0.x]: Sending. Sendingtutorials\www\spinners.xml Transmitting file data . Committed revision 1428058. Still want to think about these possibilities to make this better: a) Remove the DefaultProperty(spinnerData) in Spinner.java so that spinnerData would be required in BXML (not entirely ideal for convenience). b) Change the default value of spinnerData in the no-arg constructor to something that is not a Sequence so that BXMLSerializer will do the right thing (not sure if it is possible). c) Change the behavior of BXMLSerializer not to do what it does in this case (this obviously has much wider implications and would have to be done VERY carefully). Tutorial example code for NumericSpinnerData doesn't work as shown -- Key: PIVOT-887 URL: https://issues.apache.org/jira/browse/PIVOT-887 Project: Pivot Issue Type: Bug Components: tutorials Affects Versions: 2.0.2, 2.0.3 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: spinner Fix For: 2.0.3 See mailing list archive for complete explanation: http://apache-pivot-users.399431.n3.nabble.com/Problem-using-wtk-content-NumericSpinnerData-td4022316.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-887) Tutorial example code for NumericSpinnerData doesn't work as shown
[ https://issues.apache.org/jira/browse/PIVOT-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13543295#comment-13543295 ] Roger Whitcomb commented on PIVOT-887: -- So, here is a possible solution (a combination of b) and c) above, but which is pretty safe, I think): 1) In the default constructor for Spinner, wrap the empty ArrayList in an ImmutableList (which throws an exception if you try to add something to it). 2) In BXMLSerializer, when trying to do a sequence.add(element.value) trap the UnsupportedOperationException and just do the beanAdapter.put(element.value) instead if the exception is thrown. I think this is pretty safe because this should be the only time the exception would be thrown. Thoughts? Comments? Thanks. Tutorial example code for NumericSpinnerData doesn't work as shown -- Key: PIVOT-887 URL: https://issues.apache.org/jira/browse/PIVOT-887 Project: Pivot Issue Type: Bug Components: tutorials Affects Versions: 2.0.2, 2.0.3 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: spinner Fix For: 2.0.3 See mailing list archive for complete explanation: http://apache-pivot-users.399431.n3.nabble.com/Problem-using-wtk-content-NumericSpinnerData-td4022316.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-887) Tutorial example code for NumericSpinnerData doesn't work as shown
[ https://issues.apache.org/jira/browse/PIVOT-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13543339#comment-13543339 ] Roger Whitcomb commented on PIVOT-887: -- Thanks, Sandro, for updating the live web page -- I verified that it is good now. I have tested my trial solution to the problem and it is working where my test case was failing before. And it still works the way the tutorial shows it (now). And my tests with our application show no other places where this exception is thrown during BXML serialization, so I'm confident that the fix affects just this one case. Tutorial example code for NumericSpinnerData doesn't work as shown -- Key: PIVOT-887 URL: https://issues.apache.org/jira/browse/PIVOT-887 Project: Pivot Issue Type: Bug Components: tutorials Affects Versions: 2.0.2, 2.0.3 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: spinner Fix For: 2.0.3 See mailing list archive for complete explanation: http://apache-pivot-users.399431.n3.nabble.com/Problem-using-wtk-content-NumericSpinnerData-td4022316.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-887) Tutorial example code for NumericSpinnerData doesn't work as shown
[ https://issues.apache.org/jira/browse/PIVOT-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-887: - Attachment: 887.patch Attaching my proposed patch to Spinner.java and BXMLSerializer.java. Tutorial example code for NumericSpinnerData doesn't work as shown -- Key: PIVOT-887 URL: https://issues.apache.org/jira/browse/PIVOT-887 Project: Pivot Issue Type: Bug Components: tutorials Affects Versions: 2.0.2, 2.0.3 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: spinner Fix For: 2.0.3 Attachments: 887.patch See mailing list archive for complete explanation: http://apache-pivot-users.399431.n3.nabble.com/Problem-using-wtk-content-NumericSpinnerData-td4022316.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-887) Tutorial example code for NumericSpinnerData doesn't work as shown
[ https://issues.apache.org/jira/browse/PIVOT-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-887. -- Resolution: Fixed [trunk]: C:\Projects\Pivot\pivot\trunk\wtk\src\org\apache\pivot\wtk\Spinner.java C:\Projects\Pivot\pivot\trunk\core\src\org\apache\pivot\beans\BXMLSerializer.java At revision: 1428650 [branches\2.0.x]: Sending content: C:\Projects\Pivot\pivot\branches\2.0.x\wtk\src\org\apache\pivot\wtk\Spinner.java Sending content: C:\Projects\Pivot\pivot\branches\2.0.x\core\src\org\apache\pivot\beans\BXMLSerializer.java Completed: At revision: 1428652 Tutorial example code for NumericSpinnerData doesn't work as shown -- Key: PIVOT-887 URL: https://issues.apache.org/jira/browse/PIVOT-887 Project: Pivot Issue Type: Bug Components: tutorials Affects Versions: 2.0.2, 2.0.3 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: spinner Fix For: 2.0.3 Attachments: 887.patch See mailing list archive for complete explanation: http://apache-pivot-users.399431.n3.nabble.com/Problem-using-wtk-content-NumericSpinnerData-td4022316.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-888) Nullpointer Exception while editing TextArea with text property two-way bounded
[
https://issues.apache.org/jira/browse/PIVOT-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553033#comment-13553033
]
Roger Whitcomb commented on PIVOT-888:
--
Do you have the stack trace when the NPE does happen? That would help us track
it down. Thanks.
Nullpointer Exception while editing TextArea with text property two-way
bounded
---
Key: PIVOT-888
URL: https://issues.apache.org/jira/browse/PIVOT-888
Project: Pivot
Issue Type: Bug
Components: wtk
Affects Versions: 2.0.2
Reporter: Karel Hübl
Priority: Trivial
I am getting NullPointer exception trace printed to System.out when I edit
TextArea, which text property is two-way data bounded.
The issue is fixed when I extend TextArea and override the setText mehtod to
do nothing, if the text equals to current text value:
Fixed class:
public class TwoWayBindableTextArea extends TextArea {
public void setText(String text) {
if (text != null text.equals(this.getText())) {
return;
}
super.setText(text);
}
}
Problematic bxml:
Form styles={padding:5}
xmlns=org.apache.pivot.wtk
xmlns:view=com.dirigent.gui.component
xmlns:bxml=http://pivot.apache.org/bxml; width=300 height=200
Form.Section
TextInput bxml:id=textInput text=${textArea.text}/
Border
FillPane minimumWidth=300 minimumHeight=100
!--view:TwoWayBindableTextArea bxml:id=textArea
text=${textInput.text}/--
TextArea bxml:id=textArea text=${textInput.text}/
/FillPane
/Border
/Form.Section
/Form
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PIVOT-888) Nullpointer Exception while editing TextArea with text property two-way bounded
[
https://issues.apache.org/jira/browse/PIVOT-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Whitcomb reassigned PIVOT-888:
Assignee: Roger Whitcomb
Nullpointer Exception while editing TextArea with text property two-way
bounded
---
Key: PIVOT-888
URL: https://issues.apache.org/jira/browse/PIVOT-888
Project: Pivot
Issue Type: Bug
Components: wtk
Affects Versions: 2.0.2
Reporter: Karel Hübl
Assignee: Roger Whitcomb
Priority: Trivial
I am getting NullPointer exception trace printed to System.out when I edit
TextArea, which text property is two-way data bounded.
The issue is fixed when I extend TextArea and override the setText mehtod to
do nothing, if the text equals to current text value:
Fixed class:
public class TwoWayBindableTextArea extends TextArea {
public void setText(String text) {
if (text != null text.equals(this.getText())) {
return;
}
super.setText(text);
}
}
Problematic bxml:
Form styles={padding:5}
xmlns=org.apache.pivot.wtk
xmlns:view=com.dirigent.gui.component
xmlns:bxml=http://pivot.apache.org/bxml; width=300 height=200
Form.Section
TextInput bxml:id=textInput text=${textArea.text}/
Border
FillPane minimumWidth=300 minimumHeight=100
!--view:TwoWayBindableTextArea bxml:id=textArea
text=${textInput.text}/--
TextArea bxml:id=textArea text=${textInput.text}/
/FillPane
/Border
/Form.Section
/Form
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-888) Nullpointer Exception while editing TextArea with text property two-way bounded
[
https://issues.apache.org/jira/browse/PIVOT-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13554034#comment-13554034
]
Roger Whitcomb commented on PIVOT-888:
--
Hi Karel,
This trace doesn't look like it corresponds to the 2.0.x source code, so which
version are you using? Can you build from source and try it with either the
current trunk or branches/2.0.x code? If not, let me know and I'll try to
track it down another way. Thanks.
Nullpointer Exception while editing TextArea with text property two-way
bounded
---
Key: PIVOT-888
URL: https://issues.apache.org/jira/browse/PIVOT-888
Project: Pivot
Issue Type: Bug
Components: wtk
Affects Versions: 2.0.2
Reporter: Karel Hübl
Assignee: Roger Whitcomb
Priority: Trivial
Fix For: 2.0.3
I am getting NullPointer exception trace printed to System.out when I edit
TextArea, which text property is two-way data bounded.
The issue is fixed when I extend TextArea and override the setText mehtod to
do nothing, if the text equals to current text value:
Fixed class:
public class TwoWayBindableTextArea extends TextArea {
public void setText(String text) {
if (text != null text.equals(this.getText())) {
return;
}
super.setText(text);
}
}
Problematic bxml:
Form styles={padding:5}
xmlns=org.apache.pivot.wtk
xmlns:view=com.dirigent.gui.component
xmlns:bxml=http://pivot.apache.org/bxml; width=300 height=200
Form.Section
TextInput bxml:id=textInput text=${textArea.text}/
Border
FillPane minimumWidth=300 minimumHeight=100
!--view:TwoWayBindableTextArea bxml:id=textArea
text=${textInput.text}/--
TextArea bxml:id=textArea text=${textInput.text}/
/FillPane
/Border
/Form.Section
/Form
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PIVOT-889) Allow newline to do hard break in Label text when wrapping
Roger Whitcomb created PIVOT-889: Summary: Allow newline to do hard break in Label text when wrapping Key: PIVOT-889 URL: https://issues.apache.org/jira/browse/PIVOT-889 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 In a Label with wrapText set true, it would be good for newline characters to do a hard line break. I considered adding a new style to the LabelSkin for this, but I think it should be fine (even for backward compatibility) to just do it (if wrapText is set to true). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-889) Allow newline to do hard break in Label text when wrapping
[ https://issues.apache.org/jira/browse/PIVOT-889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557623#comment-13557623 ] Roger Whitcomb commented on PIVOT-889: -- Committed this change: [trunk] Sendingwtk\src\org\apache\pivot\wtk\skin\LabelSkin.java Transmitting file data . Committed revision 1435351. [branches/2.0.x} Sending. Sendingwtk\src\org\apache\pivot\wtk\skin\LabelSkin.java Transmitting file data . Committed revision 1435352. Allow newline to do hard break in Label text when wrapping -- Key: PIVOT-889 URL: https://issues.apache.org/jira/browse/PIVOT-889 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: label Fix For: 2.0.3 Attachments: label.patch In a Label with wrapText set true, it would be good for newline characters to do a hard line break. I considered adding a new style to the LabelSkin for this, but I think it should be fine (even for backward compatibility) to just do it (if wrapText is set to true). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-889) Allow newline to do hard break in Label text when wrapping
[ https://issues.apache.org/jira/browse/PIVOT-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb resolved PIVOT-889. -- Resolution: Fixed More testing in our application and all the Label displays look good, and the newlines are working as expected now to do a hard line break. Allow newline to do hard break in Label text when wrapping -- Key: PIVOT-889 URL: https://issues.apache.org/jira/browse/PIVOT-889 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: label Fix For: 2.0.3 Attachments: label.patch In a Label with wrapText set true, it would be good for newline characters to do a hard line break. I considered adding a new style to the LabelSkin for this, but I think it should be fine (even for backward compatibility) to just do it (if wrapText is set to true). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-889) Allow newline to do hard break in Label text when wrapping
[ https://issues.apache.org/jira/browse/PIVOT-889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559259#comment-13559259 ] Roger Whitcomb commented on PIVOT-889: -- Made a trivial change to the LabelTest.java program to test/demonstrate this change: [trunk]: Sendingtests\src\org\apache\pivot\tests\LabelTest.java Transmitting file data . Committed revision 1436707. [branches/2.0.x]: Sending. Sendingtests\src\org\apache\pivot\tests\LabelTest.java Transmitting file data . Committed revision 1436708. Allow newline to do hard break in Label text when wrapping -- Key: PIVOT-889 URL: https://issues.apache.org/jira/browse/PIVOT-889 Project: Pivot Issue Type: Improvement Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: label Fix For: 2.0.3 Attachments: label.patch In a Label with wrapText set true, it would be good for newline characters to do a hard line break. I considered adding a new style to the LabelSkin for this, but I think it should be fine (even for backward compatibility) to just do it (if wrapText is set to true). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PIVOT-891) Fixes to selection logic in TextArea and TextPane
Roger Whitcomb created PIVOT-891: Summary: Fixes to selection logic in TextArea and TextPane Key: PIVOT-891 URL: https://issues.apache.org/jira/browse/PIVOT-891 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Fix For: 2.0.3 Currently (in TextArea at least) if you type Shift-Down and select a line or two, then do Shift-Up it will extend the beginning of the area, instead of reducing the end that you just extended. This is not how any other editor works. Also would like to have double-click select the word the mouse is pointing to, as other editors do. We'd like TextArea and TextPane (at least, maybe TextInput also) do the same things. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-892) DoubleValidator and FloatValidator do not allow exponents to be entered
[ https://issues.apache.org/jira/browse/PIVOT-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-892: - Attachment: 892.patch The 892.patch file is what I've come up with to resolve this issue. Basically the only way to instantiate a NumberFormat object to recognize scientific notation is to use a pattern. This code appears to work correctly in all my tests to recognize general decimal and scientific notation for input. DoubleValidator and FloatValidator do not allow exponents to be entered --- Key: PIVOT-892 URL: https://issues.apache.org/jira/browse/PIVOT-892 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: validation Fix For: 2.0.3 Attachments: 892.patch Original Estimate: 1h Remaining Estimate: 1h The DoubleValidator and FloatValidator classes rely on a default NumberFormat instance to do parsing, however, a DecimalFormat is necessary in order to recognize floating values entered with exponents. As a result, using one of these validators currently will fail to validate a valid floating-point number such as 3.0e20. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-892) DoubleValidator and FloatValidator do not allow exponents to be entered
[ https://issues.apache.org/jira/browse/PIVOT-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13574886#comment-13574886 ] Roger Whitcomb commented on PIVOT-892: -- in trunk: Sendingwtk\src\org\apache\pivot\wtk\validation\DoubleValidator.java Sendingwtk\src\org\apache\pivot\wtk\validation\FloatValidator.java Sendingwtk\src\org\apache\pivot\wtk\validation\FormattedValidator.java Transmitting file data ... Committed revision 1444260. in branches/2.0.x: Sending. Sendingwtk\src\org\apache\pivot\wtk\validation\DoubleValidator.java Sendingwtk\src\org\apache\pivot\wtk\validation\FloatValidator.java Sendingwtk\src\org\apache\pivot\wtk\validation\FormattedValidator.java Transmitting file data ... Committed revision 1444261. DoubleValidator and FloatValidator do not allow exponents to be entered --- Key: PIVOT-892 URL: https://issues.apache.org/jira/browse/PIVOT-892 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: validation Fix For: 2.0.3 Attachments: 892.patch Original Estimate: 1h Remaining Estimate: 1h The DoubleValidator and FloatValidator classes rely on a default NumberFormat instance to do parsing, however, a DecimalFormat is necessary in order to recognize floating values entered with exponents. As a result, using one of these validators currently will fail to validate a valid floating-point number such as 3.0e20. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PIVOT-892) DoubleValidator and FloatValidator do not allow exponents to be entered
[ https://issues.apache.org/jira/browse/PIVOT-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-892: - Attachment: num.patch The attached num.patch (which goes in after my previous change) now works with all the cases I have tried, including integers and integer ranges, and fixes some more float range cases. I have also updated the TextInputValidator test program. DoubleValidator and FloatValidator do not allow exponents to be entered --- Key: PIVOT-892 URL: https://issues.apache.org/jira/browse/PIVOT-892 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: validation Fix For: 2.0.3 Attachments: 892.patch, num.patch Original Estimate: 1h Remaining Estimate: 1h The DoubleValidator and FloatValidator classes rely on a default NumberFormat instance to do parsing, however, a DecimalFormat is necessary in order to recognize floating values entered with exponents. As a result, using one of these validators currently will fail to validate a valid floating-point number such as 3.0e20. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-892) DoubleValidator and FloatValidator do not allow exponents to be entered
[ https://issues.apache.org/jira/browse/PIVOT-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13575946#comment-13575946 ] Roger Whitcomb commented on PIVOT-892: -- trunk: Sendingtests\src\org\apache\pivot\tests\TextInputValidatorTest.java Sendingtests\src\org\apache\pivot\tests\text_input_validator_test.bxml Sendingwtk\src\org\apache\pivot\wtk\validation\DecimalValidator.java Sendingwtk\src\org\apache\pivot\wtk\validation\DoubleValidator.java Sendingwtk\src\org\apache\pivot\wtk\validation\FloatValidator.java Sendingwtk\src\org\apache\pivot\wtk\validation\FormattedValidator.java Transmitting file data .. Committed revision 1444910. branches/2.0.x: Sending. Sendingtests\src\org\apache\pivot\tests\TextInputValidatorTest.java Sendingtests\src\org\apache\pivot\tests\text_input_validator_test.bxml Sendingwtk\src\org\apache\pivot\wtk\validation\DecimalValidator.java Sendingwtk\src\org\apache\pivot\wtk\validation\DoubleValidator.java Sendingwtk\src\org\apache\pivot\wtk\validation\FloatValidator.java Sendingwtk\src\org\apache\pivot\wtk\validation\FormattedValidator.java Transmitting file data .. Committed revision 1444912. DoubleValidator and FloatValidator do not allow exponents to be entered --- Key: PIVOT-892 URL: https://issues.apache.org/jira/browse/PIVOT-892 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: validation Fix For: 2.0.3 Attachments: 892.patch, num.patch Original Estimate: 1h Remaining Estimate: 1h The DoubleValidator and FloatValidator classes rely on a default NumberFormat instance to do parsing, however, a DecimalFormat is necessary in order to recognize floating values entered with exponents. As a result, using one of these validators currently will fail to validate a valid floating-point number such as 3.0e20. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-891) Fixes to selection logic in TextArea and TextPane
[ https://issues.apache.org/jira/browse/PIVOT-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13578530#comment-13578530 ] Roger Whitcomb commented on PIVOT-891: -- First round of changes to implement double- and triple-click selection of word/line. Fix Shift-LEFT and -RIGHT to do the right thing to reduce selection after changing directions. UP/DOWN not fixed yet though. Also, implement Ctrl-HOME and END to move to beginning / end of the document and Shift-Ctrl-HOME to select from here to there. Only done in TextArea for now, also, so more changes coming. [branches/2.0.x]: Sendingwtk\src\org\apache\pivot\wtk\skin\TextAreaSkin.java Transmitting file data . Committed revision 1446283. Fixes to selection logic in TextArea and TextPane - Key: PIVOT-891 URL: https://issues.apache.org/jira/browse/PIVOT-891 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Labels: text-selection Fix For: 2.0.3 Currently (in TextArea at least) if you type Shift-Down and select a line or two, then do Shift-Up it will extend the beginning of the area, instead of reducing the end that you just extended. This is not how any other editor works. Also would like to have double-click select the word the mouse is pointing to, as other editors do. We'd like TextArea and TextPane (at least, maybe TextInput also) do the same things. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-873) Provide a style for TableVIew that allows one click to start row editing
[ https://issues.apache.org/jira/browse/PIVOT-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13579514#comment-13579514 ] Roger Whitcomb commented on PIVOT-873: -- Made another fix for SelectMode.NONE: [branches/2.0.x]: Sending wtk-terra/src/org/apache/pivot/wtk/skin/terra/TerraTableViewSkin.java Transmitting file data . Committed revision 1446780. Provide a style for TableVIew that allows one click to start row editing Key: PIVOT-873 URL: https://issues.apache.org/jira/browse/PIVOT-873 Project: Pivot Issue Type: Improvement Components: wtk-terra Affects Versions: 2.0.2 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Trivial Labels: tableview Fix For: 2.0.3 Normally, a double click is required in a TableView row to initiate editing of the row. Our users would like to start editing right away. The proposal is to add a new style (implemented in TerraTableViewSkin) called editOnMouseDown that would allow the first click to begin editing. The default behavior would remain the same (edit is started on double click). It is not clear if I can implement it such that the first click would not only initiate editing but also toggle checkboxes or select radio buttons if there are any in the row editor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-861) Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection
[ https://issues.apache.org/jira/browse/PIVOT-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13579640#comment-13579640 ] Roger Whitcomb commented on PIVOT-861: -- I'm now getting these errors periodically (sent to System.err): Nonexistent listener org.apache.pivot.wtk.skin.ImageViewSkin$1@99504b removed from org.apache.pivot.wtk.media.Image$ImageListenerList@1669e7f I'm not sure yet under what circumstances, but it seems this fix isn't quite right yet. Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection - Key: PIVOT-861 URL: https://issues.apache.org/jira/browse/PIVOT-861 Project: Pivot Issue Type: Bug Components: wtk, wtk-media Affects Versions: 2.0.2 Environment: Windows XP, Java 1.7.0_05 Reporter: David Keen Assignee: Sandro Martini Fix For: 2.0.3 Attachments: leaktest.zip, Pivot861.launch, PivotSample.zip When a window or dialog is opened which has an icon, after it is closed it cannot be garbage collected because a reference is retained to it through the icon. Removing the icon resolves the issue. As far as I've investigated, the issue appears to the in the ImageListenerList which each Image contains. I've done a heapdump of my application and used the IBM HeapAnalyzer which shows this list containing a reference to the window/dialog through the ImageViewSkin, but I don't know the Pivot internals well enough to see where or how it should be released. I'll attach a simple test application to show the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-861) Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection
[ https://issues.apache.org/jira/browse/PIVOT-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581526#comment-13581526 ] Roger Whitcomb commented on PIVOT-861: -- After debugging through the new fail case, I don't see that clearing the image listener list inside ButtonData is going to help at all. I will change this locally and see if I can come up with a better solution. Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection - Key: PIVOT-861 URL: https://issues.apache.org/jira/browse/PIVOT-861 Project: Pivot Issue Type: Bug Components: wtk, wtk-media Affects Versions: 2.0.2 Environment: Windows XP, Java 1.7.0_05 Reporter: David Keen Assignee: Sandro Martini Fix For: 2.0.3 Attachments: leaktest.zip, Pivot861.launch, PivotSample.zip When a window or dialog is opened which has an icon, after it is closed it cannot be garbage collected because a reference is retained to it through the icon. Removing the icon resolves the issue. As far as I've investigated, the issue appears to the in the ImageListenerList which each Image contains. I've done a heapdump of my application and used the IBM HeapAnalyzer which shows this list containing a reference to the window/dialog through the ImageViewSkin, but I don't know the Pivot internals well enough to see where or how it should be released. I'll attach a simple test application to show the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-861) Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection
[ https://issues.apache.org/jira/browse/PIVOT-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581792#comment-13581792 ] Roger Whitcomb commented on PIVOT-861: -- Part of PIVOT-861: Lingering memory leak of ListenerList$Node objects when continuosly creating and destroying windows or buttons (from BXMLSerializer). It seemed like the basic problem was every time you use a ButtonRenderer, there is a call to ImageView.setIcon which takes the old image out of the ImageViewSkin listener list and puts the new one in, ending up creating a huge number of ListenerList$Node objects for every add to these lists. So, I rewrote the whole of ListenerList to use a small array for these lists instead of a real linked list. Empirically the lists don't usually grow very big, so the default size of 5 works well except for a handful of cases, and then the largest seen was 25. The result is that I don't see any long-term memory leak at all in the test applications and the overall memory thrashing seems less because we're creating far fewer of these little Node objects (just to add and remove a reference in a small list). Also reverted the last changes to ButtonData.java and Image.java to take out the earlier workaround that wasn't quite working. Sendingcore\src\org\apache\pivot\util\ListenerList.java Sendingwtk\src\org\apache\pivot\wtk\content\ButtonData.java Sendingwtk\src\org\apache\pivot\wtk\media\Image.java Transmitting file data ... Committed revision 1447977. Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection - Key: PIVOT-861 URL: https://issues.apache.org/jira/browse/PIVOT-861 Project: Pivot Issue Type: Bug Components: wtk, wtk-media Affects Versions: 2.0.2 Environment: Windows XP, Java 1.7.0_05 Reporter: David Keen Assignee: Sandro Martini Fix For: 2.0.3 Attachments: leaktest.zip, Pivot861.launch, PivotSample.zip When a window or dialog is opened which has an icon, after it is closed it cannot be garbage collected because a reference is retained to it through the icon. Removing the icon resolves the issue. As far as I've investigated, the issue appears to the in the ImageListenerList which each Image contains. I've done a heapdump of my application and used the IBM HeapAnalyzer which shows this list containing a reference to the window/dialog through the ImageViewSkin, but I don't know the Pivot internals well enough to see where or how it should be released. I'll attach a simple test application to show the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (PIVOT-861) Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection
[ https://issues.apache.org/jira/browse/PIVOT-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581792#comment-13581792 ] Roger Whitcomb edited comment on PIVOT-861 at 2/20/13 12:17 AM: Part of PIVOT-861: Lingering memory leak of ListenerList$Node objects when continuosly creating and destroying windows or buttons (from BXMLSerializer). It seemed like the basic problem was every time you use a ButtonRenderer, there is a call to ImageView.setIcon which takes the old image out of the ImageViewSkin listener list and puts the new one in, ending up creating a huge number of ListenerList$Node objects for every add to these lists. So, I rewrote the whole of ListenerList to use a small array for these lists instead of a real linked list. Empirically the lists don't usually grow very big, so the default size of 5 works well except for a handful of cases, and then the largest seen was 25. The result is that I don't see any long-term memory leak at all in the test applications and the overall memory thrashing seems less because we're creating far fewer of these little Node objects (just to add and remove a reference in a small list). Also reverted the last changes to ButtonData.java and Image.java to take out the earlier workaround that wasn't quite working. [branches/2.0.x]: Sendingcore\src\org\apache\pivot\util\ListenerList.java Sendingwtk\src\org\apache\pivot\wtk\content\ButtonData.java Sendingwtk\src\org\apache\pivot\wtk\media\Image.java Transmitting file data ... Committed revision 1447977. [trunk]: Sending. Sendingcore\src\org\apache\pivot\util\ListenerList.java Sendingwtk\src\org\apache\pivot\wtk\content\ButtonData.java Sendingwtk\src\org\apache\pivot\wtk\media\Image.java Transmitting file data ... Committed revision 1447978. was (Author: rwhitcomb): Part of PIVOT-861: Lingering memory leak of ListenerList$Node objects when continuosly creating and destroying windows or buttons (from BXMLSerializer). It seemed like the basic problem was every time you use a ButtonRenderer, there is a call to ImageView.setIcon which takes the old image out of the ImageViewSkin listener list and puts the new one in, ending up creating a huge number of ListenerList$Node objects for every add to these lists. So, I rewrote the whole of ListenerList to use a small array for these lists instead of a real linked list. Empirically the lists don't usually grow very big, so the default size of 5 works well except for a handful of cases, and then the largest seen was 25. The result is that I don't see any long-term memory leak at all in the test applications and the overall memory thrashing seems less because we're creating far fewer of these little Node objects (just to add and remove a reference in a small list). Also reverted the last changes to ButtonData.java and Image.java to take out the earlier workaround that wasn't quite working. Sendingcore\src\org\apache\pivot\util\ListenerList.java Sendingwtk\src\org\apache\pivot\wtk\content\ButtonData.java Sendingwtk\src\org\apache\pivot\wtk\media\Image.java Transmitting file data ... Committed revision 1447977. Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection - Key: PIVOT-861 URL: https://issues.apache.org/jira/browse/PIVOT-861 Project: Pivot Issue Type: Bug Components: wtk, wtk-media Affects Versions: 2.0.2 Environment: Windows XP, Java 1.7.0_05 Reporter: David Keen Assignee: Sandro Martini Fix For: 2.0.3 Attachments: leaktest.zip, Pivot861.launch, PivotSample.zip When a window or dialog is opened which has an icon, after it is closed it cannot be garbage collected because a reference is retained to it through the icon. Removing the icon resolves the issue. As far as I've investigated, the issue appears to the in the ImageListenerList which each Image contains. I've done a heapdump of my application and used the IBM HeapAnalyzer which shows this list containing a reference to the window/dialog through the ImageViewSkin, but I don't know the Pivot internals well enough to see where or how it should be released. I'll attach a simple test application to show the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-861) Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection
[ https://issues.apache.org/jira/browse/PIVOT-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13581828#comment-13581828 ] Roger Whitcomb commented on PIVOT-861: -- So, after using this new code and debugging through the PivotApp861.java program, there are several things I see here: 1) Each time you load the btn_grid.xml it creates 9 new ButtonDataRenderer objects, each with a new ImageView. 2) So, even though the same image is loaded from the Application's resource cache, there is a new ImageViewSkin that is added to the Image's ListenerList for each button. 3) If I remove the (nine) dataRenderer ... /dataRenderer blocks from the btn_grid.xml file then there is no longer a memory leak. 4) The real problem, then, is two-fold: a) The example is creating ButtonDataRenderer objects that it doesn't need to. b) There needs to be a way for a Renderer not to participate in the listener list for ImageView because it is not necessary (because the image is transient by definition, being set by every call to render). This will need some thought as to how to make ImageView work with transient images. Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection - Key: PIVOT-861 URL: https://issues.apache.org/jira/browse/PIVOT-861 Project: Pivot Issue Type: Bug Components: wtk, wtk-media Affects Versions: 2.0.2 Environment: Windows XP, Java 1.7.0_05 Reporter: David Keen Assignee: Sandro Martini Fix For: 2.0.3 Attachments: leaktest.zip, Pivot861.launch, PivotSample.zip When a window or dialog is opened which has an icon, after it is closed it cannot be garbage collected because a reference is retained to it through the icon. Removing the icon resolves the issue. As far as I've investigated, the issue appears to the in the ImageListenerList which each Image contains. I've done a heapdump of my application and used the IBM HeapAnalyzer which shows this list containing a reference to the window/dialog through the ImageViewSkin, but I don't know the Pivot internals well enough to see where or how it should be released. I'll attach a simple test application to show the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-861) Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection
[ https://issues.apache.org/jira/browse/PIVOT-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582320#comment-13582320 ] Roger Whitcomb commented on PIVOT-861: -- Hi Sandro, Noel suggested privately just making ListenerListT use java.lang.ArrayListT as a base, and save even more code. So, I'm thinking about that. Using this code and your workaround #2, I was getting the error a lot, and I guess I didn't see the leak with the btn_grid test, but I didn't think that your workaround was actually getting to the root of the problem (plus getting the error messages). :) I guess I don't mind making a method to do the whole dance of the get from cache, then if not found, load the image and put into cache into a helper method. That seems fine as you suggest. But I don't think it is necessary to put the cache.put inside the try / catch since it doesn't throw any exceptions that would be caught . I will respond to the other part of the problem in PIVOT-894. But, I think I have a solution for that. Memory leak: Window icon ImageListenerList retains reference to closed windows, preventing garbage collection - Key: PIVOT-861 URL: https://issues.apache.org/jira/browse/PIVOT-861 Project: Pivot Issue Type: Bug Components: wtk, wtk-media Affects Versions: 2.0.2 Environment: Windows XP, Java 1.7.0_05 Reporter: David Keen Assignee: Sandro Martini Labels: cache, image, leak, listener, memory Fix For: 2.0.3 Attachments: leaktest.zip, Pivot861.launch, PivotSample.zip When a window or dialog is opened which has an icon, after it is closed it cannot be garbage collected because a reference is retained to it through the icon. Removing the icon resolves the issue. As far as I've investigated, the issue appears to the in the ImageListenerList which each Image contains. I've done a heapdump of my application and used the IBM HeapAnalyzer which shows this list containing a reference to the window/dialog through the ImageViewSkin, but I don't know the Pivot internals well enough to see where or how it should be released. I'll attach a simple test application to show the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-894) Memory leak when using dataRenderer blocks in bxml files
[ https://issues.apache.org/jira/browse/PIVOT-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13582340#comment-13582340 ] Roger Whitcomb commented on PIVOT-894: -- Oh, and one other thing: if the renderer interface had some way of knowing when it was done with the Image object, and so could take it out of the listener lists, that would also help. But, I don't think there is any way of knowing this either. Memory leak when using dataRenderer blocks in bxml files Key: PIVOT-894 URL: https://issues.apache.org/jira/browse/PIVOT-894 Project: Pivot Issue Type: Bug Components: wtk, wtk-media Affects Versions: 2.0.2 Reporter: Sandro Martini Assignee: Roger Whitcomb Labels: cache, image, leak, listener, memory Fix For: 2.1, 2.0.3 This is the second part of PIVOT-861, moved here (and so even the related test case). For a full solution of this maybe we need some incompatible change (so in this case it will be moved to 2.1), and maybe even some changes to the test case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
