[jira] [Commented] (PIVOT-846) rework methods for modifying user-level child components of Container subclasses
[ https://issues.apache.org/jira/browse/PIVOT-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266490#comment-13266490 ] Noel Grandin commented on PIVOT-846: Hi No, I haven't worked on that yet. Regards, Noel. > rework methods for modifying user-level child components of Container > subclasses > > > Key: PIVOT-846 > URL: https://issues.apache.org/jira/browse/PIVOT-846 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Noel Grandin >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.2, 2.1 > > > For most sub-classes of Container, directly adding/removing child components > is not something the user usually wants to do. > This gets especially confusing when users do things like adding a child > component to a ScrollPane. > Also, the skin classes add extra components to the Container, potentially > making it even more confusing. > I plan to move access to a new method on Container#getChildComponentList(), > which will be clearly marked as being of mostly internal interest. > Then I will add convenience methods to the subclasses of Container where it > makes sense to treat the subclass as directly containing user-level child > components, eg. BoxPane, CardPane, FlowPane, StackPane -- 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-790) Add FillPane layout container that acts like a BoxPane with fill=true in both directions
[ https://issues.apache.org/jira/browse/PIVOT-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090118#comment-13090118 ] Noel Grandin commented on PIVOT-790: Arr. Sorry everybody, I've been thinking about this the wrong way. One of things about Pivot that keeps biting me is when widgets have similar names to the ones in Swing/AWT, but act differently. Pivot's BoxPane is most similar to Swing's FlowLayout. And Roger's FillPane is most similar to Swing's GridLayout, and is basically a simplified copy of Pivot's GridPane. Maybe I should just document this in the code, so I don't forget it. Roger, I withdraw my objection to your patch. Go ahead and commit. > Add FillPane layout container that acts like a BoxPane with fill=true in both > directions > > > Key: PIVOT-790 > URL: https://issues.apache.org/jira/browse/PIVOT-790 > Project: Pivot > Issue Type: New Feature > Components: wtk >Affects Versions: 2.0.1 >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.0.1 > > Attachments: fill.patch, fill_pane_horizontal.jpg, > fill_pane_vertical.jpg > > Original Estimate: 2h > Remaining Estimate: 2h > > Would like to have a FillPane that lays out its components to fill the > available space both horizontally and vertically. It does have an > orientation (like BoxPane) to specify the direction to lay things out but it > always allows its children to fill up the space. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-790) Add FillPane layout container that acts like a BoxPane with fill=true in both directions
[ https://issues.apache.org/jira/browse/PIVOT-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090101#comment-13090101 ] Noel Grandin commented on PIVOT-790: "Adding complexity" is not an argument against adding a new feature. All new features add complexity. The question is "is the complexity justified" and "is it the minimum necessary complexity" I think the complexity is justified and that it is minimised by adding the feature to BoxPane, since BoxPane already implements most of this logic - it really just needs some conditional checks to decide how much width/height to work with i.e. all of it, or just the minimum amount. StackPane lays things out on top of each other, so it's not appropriate for this case, and ScrollPane.. scrolls. -- Noel. > Add FillPane layout container that acts like a BoxPane with fill=true in both > directions > > > Key: PIVOT-790 > URL: https://issues.apache.org/jira/browse/PIVOT-790 > Project: Pivot > Issue Type: New Feature > Components: wtk >Affects Versions: 2.0.1 >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.0.1 > > Attachments: fill.patch, fill_pane_horizontal.jpg, > fill_pane_vertical.jpg > > Original Estimate: 2h > Remaining Estimate: 2h > > Would like to have a FillPane that lays out its components to fill the > available space both horizontally and vertically. It does have an > orientation (like BoxPane) to specify the direction to lay things out but it > always allows its children to fill up the space. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-790) Add FillPane layout container that acts like a BoxPane with fill=true in both directions
[ https://issues.apache.org/jira/browse/PIVOT-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089678#comment-13089678 ] Noel Grandin commented on PIVOT-790: I think we can keep backwards compatibility by making the new setFill(String) method parse "true" and "false". > Add FillPane layout container that acts like a BoxPane with fill=true in both > directions > > > Key: PIVOT-790 > URL: https://issues.apache.org/jira/browse/PIVOT-790 > Project: Pivot > Issue Type: New Feature > Components: wtk >Affects Versions: 2.0.1 >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.0.1 > > Attachments: fill.patch, fill_pane_horizontal.jpg, > fill_pane_vertical.jpg > > Original Estimate: 2h > Remaining Estimate: 2h > > Would like to have a FillPane that lays out its components to fill the > available space both horizontally and vertically. It does have an > orientation (like BoxPane) to specify the direction to lay things out but it > always allows its children to fill up the space. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-790) Add FillPane layout container that acts like a BoxPane with fill=true in both directions
[ https://issues.apache.org/jira/browse/PIVOT-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089384#comment-13089384 ] Noel Grandin commented on PIVOT-790: I'm not in favour of adding another component when we can easily make this a simple style addition to an existing component. Mostly because we end up duplicating a lot of code unnecessarily. > Add FillPane layout container that acts like a BoxPane with fill=true in both > directions > > > Key: PIVOT-790 > URL: https://issues.apache.org/jira/browse/PIVOT-790 > Project: Pivot > Issue Type: New Feature > Components: wtk >Affects Versions: 2.0.1 >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.0.1 > > Attachments: fill.patch, fill_pane_horizontal.jpg, > fill_pane_vertical.jpg > > Original Estimate: 2h > Remaining Estimate: 2h > > Would like to have a FillPane that lays out its components to fill the > available space both horizontally and vertically. It does have an > orientation (like BoxPane) to specify the direction to lay things out but it > always allows its children to fill up the space. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-790) Add FillPane layout container that acts like a BoxPane with fill=true in both directions
[ https://issues.apache.org/jira/browse/PIVOT-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088203#comment-13088203 ] Noel Grandin commented on PIVOT-790: It might simpler to add a new style to BoxPane that makes it fill the available space in the orientation direction. Not sure what to call such a property, though. Ideally, we should change "fill" to be an enum with values NONE, HORIZONTAL, VERTICAL, BOTH but that's an API change. > Add FillPane layout container that acts like a BoxPane with fill=true in both > directions > > > Key: PIVOT-790 > URL: https://issues.apache.org/jira/browse/PIVOT-790 > Project: Pivot > Issue Type: New Feature > Components: wtk >Affects Versions: 2.0.1 >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.0.1 > > Attachments: fill.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Would like to have a FillPane that lays out its components to fill the > available space both horizontally and vertically. It does have an > orientation (like BoxPane) to specify the direction to lay things out but it > always allows its children to fill up the space. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-780) Can't use BXMLSerializer from non-AWT threads makes background resource loading impossible
[ https://issues.apache.org/jira/browse/PIVOT-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-780. Resolution: Fixed Assignee: Noel Grandin Marking this as closed for now. Can be re-opened if there is some corner case we missed. > Can't use BXMLSerializer from non-AWT threads makes background resource > loading impossible > -- > > Key: PIVOT-780 > URL: https://issues.apache.org/jira/browse/PIVOT-780 > Project: Pivot > Issue Type: Bug > Components: core-beans, wtk >Affects Versions: 2.0.1 >Reporter: Piotr Kołaczkowski >Assignee: Noel Grandin > Labels: background, initialization, thread > Fix For: 2.0.1 > > > Calling bxmlSerializer.readObject from a non-AWT thread causes the following > exception: > An error occurred at line number 5 in file > /C:/Users/Piotr/Projekty/viungo/viungo-editor/target/scala_2.9.0/classes/com/viungo/editor/CircuitEditor.bxml: > org.apache.pivot.serialization.SerializationException: > java.lang.IllegalStateException: this method can only be called from the AWT > event dispatch thread > at > org.apache.pivot.beans.BXMLSerializer.processStartElement(BXMLSerializer.java:769) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:441) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:624) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:579) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:540) > at > com.viungo.editor.CircuitEditor$$anon$1.execute(CircuitEditor.scala:21) > at > com.viungo.editor.CircuitEditor$$anon$1.execute(CircuitEditor.scala:18) > at > org.apache.pivot.util.concurrent.Task$ExecuteCallback.run(Task.java:42) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.lang.IllegalStateException: this method can only be called > from the AWT event dispatch thread > at org.apache.pivot.wtk.Container$1.run(Container.java:864) > at > org.apache.pivot.wtk.Container.assertEventDispatchThread(Container.java:871) > at org.apache.pivot.wtk.WTKListenerList.add(WTKListenerList.java:36) > at > org.apache.pivot.wtk.skin.ComponentSkin.install(ComponentSkin.java:96) > at > org.apache.pivot.wtk.skin.ContainerSkin.install(ContainerSkin.java:129) > at org.apache.pivot.wtk.skin.WindowSkin.install(WindowSkin.java:66) > at org.apache.pivot.wtk.Component.setSkin(Component.java:749) > at org.apache.pivot.wtk.Component.installSkin(Component.java:812) > at org.apache.pivot.wtk.Window.(Window.java:453) > at org.apache.pivot.wtk.Window.(Window.java:448) > at com.viungo.editor.EditorWindow.(EditorWindow.scala:20) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at > org.apache.pivot.beans.BXMLSerializer.newTypedObject(BXMLSerializer.java:1556) > at > org.apache.pivot.beans.BXMLSerializer.processStartElement(BXMLSerializer.java:767) > ... 11 more > Loading objects in background is very important, so that the user can see > e.g. a progress indicator while the rest of the UI is deserialized. > Doing this in AWT thread, blocks what is currently displayed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-780) Can't use BXMLSerializer from non-AWT threads makes background resource loading impossible
[ https://issues.apache.org/jira/browse/PIVOT-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079359#comment-13079359 ] Noel Grandin commented on PIVOT-780: Checked in a fix in rev 1153866 > Can't use BXMLSerializer from non-AWT threads makes background resource > loading impossible > -- > > Key: PIVOT-780 > URL: https://issues.apache.org/jira/browse/PIVOT-780 > Project: Pivot > Issue Type: Bug > Components: core-beans, wtk >Affects Versions: 2.0.1 >Reporter: Piotr Kołaczkowski > Labels: background, initialization, thread > Fix For: 2.0.1 > > > Calling bxmlSerializer.readObject from a non-AWT thread causes the following > exception: > An error occurred at line number 5 in file > /C:/Users/Piotr/Projekty/viungo/viungo-editor/target/scala_2.9.0/classes/com/viungo/editor/CircuitEditor.bxml: > org.apache.pivot.serialization.SerializationException: > java.lang.IllegalStateException: this method can only be called from the AWT > event dispatch thread > at > org.apache.pivot.beans.BXMLSerializer.processStartElement(BXMLSerializer.java:769) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:441) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:624) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:579) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:540) > at > com.viungo.editor.CircuitEditor$$anon$1.execute(CircuitEditor.scala:21) > at > com.viungo.editor.CircuitEditor$$anon$1.execute(CircuitEditor.scala:18) > at > org.apache.pivot.util.concurrent.Task$ExecuteCallback.run(Task.java:42) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.lang.IllegalStateException: this method can only be called > from the AWT event dispatch thread > at org.apache.pivot.wtk.Container$1.run(Container.java:864) > at > org.apache.pivot.wtk.Container.assertEventDispatchThread(Container.java:871) > at org.apache.pivot.wtk.WTKListenerList.add(WTKListenerList.java:36) > at > org.apache.pivot.wtk.skin.ComponentSkin.install(ComponentSkin.java:96) > at > org.apache.pivot.wtk.skin.ContainerSkin.install(ContainerSkin.java:129) > at org.apache.pivot.wtk.skin.WindowSkin.install(WindowSkin.java:66) > at org.apache.pivot.wtk.Component.setSkin(Component.java:749) > at org.apache.pivot.wtk.Component.installSkin(Component.java:812) > at org.apache.pivot.wtk.Window.(Window.java:453) > at org.apache.pivot.wtk.Window.(Window.java:448) > at com.viungo.editor.EditorWindow.(EditorWindow.scala:20) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at > org.apache.pivot.beans.BXMLSerializer.newTypedObject(BXMLSerializer.java:1556) > at > org.apache.pivot.beans.BXMLSerializer.processStartElement(BXMLSerializer.java:767) > ... 11 more > Loading objects in background is very important, so that the user can see > e.g. a progress indicator while the rest of the UI is deserialized. > Doing this in AWT thread, blocks what is currently displayed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-696) TextArea support for entering tab characters and tab stops
[ https://issues.apache.org/jira/browse/PIVOT-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079357#comment-13079357 ] Noel Grandin commented on PIVOT-696: It's fine for light use - see the example code in org.apache.pivot.demos.text.TextPaneDemo but it depends on what you expect from a rich text editor. There is still lots off functionality that could be added. > TextArea 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 >Priority: Minor > Fix For: 2.0.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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-780) Can't use BXMLSerializer from non-AWT threads makes background resource loading impossible
[ https://issues.apache.org/jira/browse/PIVOT-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079354#comment-13079354 ] Noel Grandin commented on PIVOT-780: Modifying any WTK object from outside the event thread could lead to data-corruption, which tends to show up as weird errors far away from the misbehaving code. That is why we try to catch the offending code early on, to save ourselves from that debugging. You can already override the check - see Container#setEventDispatchThreadChecker() > Can't use BXMLSerializer from non-AWT threads makes background resource > loading impossible > -- > > Key: PIVOT-780 > URL: https://issues.apache.org/jira/browse/PIVOT-780 > Project: Pivot > Issue Type: Bug > Components: core-beans, wtk >Affects Versions: 2.0.1 >Reporter: Piotr Kołaczkowski > Labels: background, initialization, thread > Fix For: 2.0.1 > > > Calling bxmlSerializer.readObject from a non-AWT thread causes the following > exception: > An error occurred at line number 5 in file > /C:/Users/Piotr/Projekty/viungo/viungo-editor/target/scala_2.9.0/classes/com/viungo/editor/CircuitEditor.bxml: > org.apache.pivot.serialization.SerializationException: > java.lang.IllegalStateException: this method can only be called from the AWT > event dispatch thread > at > org.apache.pivot.beans.BXMLSerializer.processStartElement(BXMLSerializer.java:769) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:441) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:624) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:579) > at > org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:540) > at > com.viungo.editor.CircuitEditor$$anon$1.execute(CircuitEditor.scala:21) > at > com.viungo.editor.CircuitEditor$$anon$1.execute(CircuitEditor.scala:18) > at > org.apache.pivot.util.concurrent.Task$ExecuteCallback.run(Task.java:42) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.lang.IllegalStateException: this method can only be called > from the AWT event dispatch thread > at org.apache.pivot.wtk.Container$1.run(Container.java:864) > at > org.apache.pivot.wtk.Container.assertEventDispatchThread(Container.java:871) > at org.apache.pivot.wtk.WTKListenerList.add(WTKListenerList.java:36) > at > org.apache.pivot.wtk.skin.ComponentSkin.install(ComponentSkin.java:96) > at > org.apache.pivot.wtk.skin.ContainerSkin.install(ContainerSkin.java:129) > at org.apache.pivot.wtk.skin.WindowSkin.install(WindowSkin.java:66) > at org.apache.pivot.wtk.Component.setSkin(Component.java:749) > at org.apache.pivot.wtk.Component.installSkin(Component.java:812) > at org.apache.pivot.wtk.Window.(Window.java:453) > at org.apache.pivot.wtk.Window.(Window.java:448) > at com.viungo.editor.EditorWindow.(EditorWindow.scala:20) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at > org.apache.pivot.beans.BXMLSerializer.newTypedObject(BXMLSerializer.java:1556) > at > org.apache.pivot.beans.BXMLSerializer.processStartElement(BXMLSerializer.java:767) > ... 11 more > Loading objects in background is very important, so that the user can see > e.g. a progress indicator while the rest of the UI is deserialized. > Doing this in AWT thread, blocks what is currently displayed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-696) TextArea support for entering tab characters and tab stops
[ https://issues.apache.org/jira/browse/PIVOT-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078763#comment-13078763 ] Noel Grandin commented on PIVOT-696: I don't think this feature belongs in TextArea. TextArea is highly optimised for a very simple use-case. TextPane is where all of the fancy features belong. As a first step towards this, I have implemented support for CTRL-TAB in TextPane. > TextArea 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 >Priority: Minor > Fix For: 2.0.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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-774) Selection bug in TextArea
[ https://issues.apache.org/jira/browse/PIVOT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-774. Resolution: Fixed Fix Version/s: 2.0.1 Assignee: Noel Grandin Fixed in rev 1153480 > Selection bug in TextArea > - > > Key: PIVOT-774 > URL: https://issues.apache.org/jira/browse/PIVOT-774 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0 >Reporter: Edvin Syse >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: TextAreaSelectionFix.patch > > > If you start to select text in a TextArea and while selecting, move the > cursor over the bounds of the TextArea (north of it), the selection area is > not expanded. > This bug only appears to affect TextArea when the content has been scrolled > as far down or as far up as possible. While the text is being vertically > scrolled, selection works as expected. > A video showing the problem can be seen here: > https://edvin.viewscreencasts.com/c97422da51ed4cf1845e5a7610a8716f > This bug makes it hard to select text in a TextArea, because one often moves > the cursor further north than the TextArea when selecting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-709) Want a single-line text input component that wraps
[ https://issues.apache.org/jira/browse/PIVOT-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078613#comment-13078613 ] Noel Grandin commented on PIVOT-709: Just added an "acceptsEnter" skin property for TextArea. Bill, let me know how this works out for you. > Want a single-line text input component that wraps > -- > > Key: PIVOT-709 > URL: https://issues.apache.org/jira/browse/PIVOT-709 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Bill van Melle >Priority: Minor > > TextInput accepts a single line of text, but it also displays as only a > single line on the screen, with no provision for wrapping text instead of > clumsily horizontally scrolling. TextArea happily wraps text, but it also > accepts the Enter key to insert newlines into the content. > I would like a control that wraps its text, but also only accepts a single > line of input, i.e., it does not accept Enter to produce multiple lines, and > in fact allows Enter to be handled by its container (e.g., a Sheet). Whether > this means a wrapText attribute on a TextInput, or a multiLine or > acceptsEnter attribute on a TextArea makes little difference to me. A quick > glance at the TextAreaSkin suggests the latter would be straightforward. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-709) Want a single-line text input component that wraps
[ https://issues.apache.org/jira/browse/PIVOT-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078597#comment-13078597 ] Noel Grandin commented on PIVOT-709: OK, good point Bill. I think an "acceptEnter" skin property on TextArea would be pretty straightforward. Will look at it later. > Want a single-line text input component that wraps > -- > > Key: PIVOT-709 > URL: https://issues.apache.org/jira/browse/PIVOT-709 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Bill van Melle >Priority: Minor > > TextInput accepts a single line of text, but it also displays as only a > single line on the screen, with no provision for wrapping text instead of > clumsily horizontally scrolling. TextArea happily wraps text, but it also > accepts the Enter key to insert newlines into the content. > I would like a control that wraps its text, but also only accepts a single > line of input, i.e., it does not accept Enter to produce multiple lines, and > in fact allows Enter to be handled by its container (e.g., a Sheet). Whether > this means a wrapText attribute on a TextInput, or a multiLine or > acceptsEnter attribute on a TextArea makes little difference to me. A quick > glance at the TextAreaSkin suggests the latter would be straightforward. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-779) Resizing a TextPane wider leaves spurious lines of repeated text
[ https://issues.apache.org/jira/browse/PIVOT-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-779. Resolution: Fixed Assignee: Noel Grandin Nice bug submitting, Bill. Makes it a pleasure to fix :-) Fixed in rev 1153139. > Resizing a TextPane wider leaves spurious lines of repeated text > > > Key: PIVOT-779 > URL: https://issues.apache.org/jira/browse/PIVOT-779 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0.1 >Reporter: Bill van Melle >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > > If you resize a TextPane to be wider, so that its paragraphs in it require > fewer lines to display, it leaves behind one or more extra lines per > paragraph that repeat the text. The bug is most dramatic when the resize is > abrupt, such as when you maximize a window. Here's an example: >xmlns="org.apache.pivot.wtk"> > > > > > > > > > > > > > > > > > > This example fails in the current trunk, but works correctly in 2.0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-709) Want a single-line text input component that wraps
[ https://issues.apache.org/jira/browse/PIVOT-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13076209#comment-13076209 ] Noel Grandin commented on PIVOT-709: You could solve this by installing your own key event handler on a TextArea, which makes "enter" mean "commit the text". > Want a single-line text input component that wraps > -- > > Key: PIVOT-709 > URL: https://issues.apache.org/jira/browse/PIVOT-709 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Bill van Melle >Priority: Minor > > TextInput accepts a single line of text, but it also displays as only a > single line on the screen, with no provision for wrapping text instead of > clumsily horizontally scrolling. TextArea happily wraps text, but it also > accepts the Enter key to insert newlines into the content. > I would like a control that wraps its text, but also only accepts a single > line of input, i.e., it does not accept Enter to produce multiple lines, and > in fact allows Enter to be handled by its container (e.g., a Sheet). Whether > this means a wrapText attribute on a TextInput, or a multiLine or > acceptsEnter attribute on a TextArea makes little difference to me. A quick > glance at the TextAreaSkin suggests the latter would be straightforward. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-378) Add a "lineWidth" property to TextArea
[ https://issues.apache.org/jira/browse/PIVOT-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-378. Resolution: Fixed Fix Version/s: (was: 2.1) 2.0.1 Assignee: Noel Grandin Fixed in rev 1153116 > Add a "lineWidth" property to TextArea > -- > > Key: PIVOT-378 > URL: https://issues.apache.org/jira/browse/PIVOT-378 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Greg Brown >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > > This property would work like the "textSize" property of TextInput - it would > simply be used to drive the preferred width of the text area based on average > character width. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-780) Can't use BXMLSerializer from non-AWT threads makes background resource loading impossible
[
https://issues.apache.org/jira/browse/PIVOT-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073612#comment-13073612
]
Noel Grandin commented on PIVOT-780:
We could weaken the check so that it reads like this:
if (the component is attached to a Display
AND this thread is not the event dispatch thread)
{
throw exception
}
that would allow background loading, whilst still catching problems with
modifying currently "live" components from outside the EDT.
> Can't use BXMLSerializer from non-AWT threads makes background resource
> loading impossible
> --
>
> Key: PIVOT-780
> URL: https://issues.apache.org/jira/browse/PIVOT-780
> Project: Pivot
> Issue Type: Bug
> Components: core-beans, wtk
>Affects Versions: 2.0.1
>Reporter: Piotr Kołaczkowski
> Labels: background, initialization, thread
> Fix For: 2.0.1
>
>
> Calling bxmlSerializer.readObject from a non-AWT thread causes the following
> exception:
> An error occurred at line number 5 in file
> /C:/Users/Piotr/Projekty/viungo/viungo-editor/target/scala_2.9.0/classes/com/viungo/editor/CircuitEditor.bxml:
> org.apache.pivot.serialization.SerializationException:
> java.lang.IllegalStateException: this method can only be called from the AWT
> event dispatch thread
> at
> org.apache.pivot.beans.BXMLSerializer.processStartElement(BXMLSerializer.java:769)
> at
> org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:441)
> at
> org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:624)
> at
> org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:579)
> at
> org.apache.pivot.beans.BXMLSerializer.readObject(BXMLSerializer.java:540)
> at
> com.viungo.editor.CircuitEditor$$anon$1.execute(CircuitEditor.scala:21)
> at
> com.viungo.editor.CircuitEditor$$anon$1.execute(CircuitEditor.scala:18)
> at
> org.apache.pivot.util.concurrent.Task$ExecuteCallback.run(Task.java:42)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.IllegalStateException: this method can only be called
> from the AWT event dispatch thread
> at org.apache.pivot.wtk.Container$1.run(Container.java:864)
> at
> org.apache.pivot.wtk.Container.assertEventDispatchThread(Container.java:871)
> at org.apache.pivot.wtk.WTKListenerList.add(WTKListenerList.java:36)
> at
> org.apache.pivot.wtk.skin.ComponentSkin.install(ComponentSkin.java:96)
> at
> org.apache.pivot.wtk.skin.ContainerSkin.install(ContainerSkin.java:129)
> at org.apache.pivot.wtk.skin.WindowSkin.install(WindowSkin.java:66)
> at org.apache.pivot.wtk.Component.setSkin(Component.java:749)
> at org.apache.pivot.wtk.Component.installSkin(Component.java:812)
> at org.apache.pivot.wtk.Window.(Window.java:453)
> at org.apache.pivot.wtk.Window.(Window.java:448)
> at com.viungo.editor.EditorWindow.(EditorWindow.scala:20)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at
> org.apache.pivot.beans.BXMLSerializer.newTypedObject(BXMLSerializer.java:1556)
> at
> org.apache.pivot.beans.BXMLSerializer.processStartElement(BXMLSerializer.java:767)
> ... 11 more
> Loading objects in background is very important, so that the user can see
> e.g. a progress indicator while the rest of the UI is deserialized.
> Doing this in AWT thread, blocks what is currently displayed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-772) Exceptions thrown when calling getCharacterBounds of TextArea when incomplete lines exist
[ https://issues.apache.org/jira/browse/PIVOT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073579#comment-13073579 ] Noel Grandin commented on PIVOT-772: I've backed out my fix for now. Roger, the only solution that it available to you right now, is too push the scrollAreaToVisible() method call into a new Runnable, which is queued to be run after the TextArea modification. That will ensure that the component hierarchy is validated before scrollAreaToVisible() performs it's calculations. Long-term, I can't see any easy solution, other than documenting this requirement. > Exceptions thrown when calling getCharacterBounds of TextArea when incomplete > lines exist > - > > Key: PIVOT-772 > URL: https://issues.apache.org/jira/browse/PIVOT-772 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0.1 > Environment: Windows XP SP3, JRE 1.6_25 or JRE 1.7 (beta) >Reporter: Roger Whitcomb >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: Scroll.java, Scroll2.java, scroll.bxml, scroll.log, > scroll2.log > > Original Estimate: 48h > Remaining Estimate: 48h > > If partial lines are appended to a TextArea and then "getCharacterBounds" > followed by "scrollAreaToVisible" is called, Pivot throws > java.lang.IndexOutOfBoundsException from > TextAreaSkinParagraphView.getCharacterBounds: > java.lang.IndexOutOfBoundsException: ix = 38 > at sun.font.StandardGlyphVector.getGlyphLogicalBounds(Unknown Source) > at > org.apache.pivot.wtk.skin.TextAreaSkinParagraphView.getCharacterBounds(TextAreaSkinParagraphView.java:393) > at > org.apache.pivot.wtk.skin.TextAreaSkin.getCharacterBounds(TextAreaSkin.java:442) > at > org.apache.pivot.wtk.TextArea.getCharacterBounds(TextArea.java:1243) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-778) Optimise DisplayHost.paintBuffered and DisplayHost.paintVolatileBuffered
[
https://issues.apache.org/jira/browse/PIVOT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071762#comment-13071762
]
Noel Grandin commented on PIVOT-778:
We could always use a WeakReference to allow the GC to collect it if necessary.
But yes, it sounds like Piotr's application should be using partial repaints.
> Optimise DisplayHost.paintBuffered and DisplayHost.paintVolatileBuffered
>
>
> Key: PIVOT-778
> URL: https://issues.apache.org/jira/browse/PIVOT-778
> Project: Pivot
> Issue Type: Improvement
> Components: wtk
>Affects Versions: 2.0
>Reporter: Piotr Kołaczkowski
>Priority: Minor
> Labels: DisplayHost, caching, gc, paint, performance, repaint
> Fix For: 2.0.1
>
>
> We are writing sort of a game, which continually calls Component.repaint
> method, at 60 FPS. We noticed excessive CPU usage, although the actual amount
> of painting done by our component (actually in an overriden Panel.paint) is
> ridiculously small. The profiler pointed us to the paintVolatileBuffered
> method in the DisplayHost. What you are doing there is:
> 1. obtain a new, fresh BufferedImage of size equal to the actual clip region,
> let's say for a full screen game it can be about 1280x1024. This is 1.3 Mpix
> x 4 bytes/pixel = 5.2 MB of raw data, allocated from a probably cold memory
> region (not in the L2 cache)
> 2. then you call actual paint on that buffered image (this is touching at
> least 5.2 MB again)
> 3. then you copy that to the onscreen buffer (which means copying 5.2 MB for
> another time)
> 4. in case GC kicks in after 1 and 3. it has to move the BufferedImage in
> memory to compact young generation (= touching 5.2 MB fourth time)
> The whole process means allocating from cold memory 5.2 MB per each frame and
> touching about 20 MB per frame.
> For 60 FPS it makes up ~300 MB/s allocation rate and 1.2GB memory throughput.
> It also makes the GC go crazy.
> We have found that caching the buffer between the subsequent paint calls
> improves performance a lot:
>
> /** Stores the prepared offscreen buffer */
> private BufferedImage bufferedImage;
> /**
> * Attempts to paint the display using an offscreen buffer.
> *
> * @param graphics
> * The source graphics context.
> *
> * @return
> * true if the display was painted using the offscreen
> * buffer; false, otherwise.
> */
> private boolean paintBuffered(Graphics2D graphics) {
> boolean painted = false;
> // Paint the display into an offscreen buffer
> GraphicsConfiguration gc = graphics.getDeviceConfiguration();
> java.awt.Rectangle clipBounds = graphics.getClipBounds();
> if (bufferedImage == null ||
> bufferedImage.getWidth() < clipBounds.width ||
> bufferedImage.getHeight() < clipBounds.height)
> bufferedImage = gc.createCompatibleImage(clipBounds.width,
> clipBounds.height,
> Transparency.OPAQUE);
> if (bufferedImage != null) {
> Graphics2D bufferedImageGraphics =
> (Graphics2D)bufferedImage.getGraphics();
> bufferedImageGraphics.setClip(0, 0, clipBounds.width,
> ...
>
> Advantages:
> 1. it saves from costly allocation of a large object from possibly not-cached
> memory region
> 2. after a few repaints the GC moves this object to the tenured generation,
> so that the young generation collector is much more efficient (longer times
> between runs)
> 3. the image probably stays most of the time in the L2 or L3 cache, which
> saves on memory bandwidth and speeds up painting
> Disadvantages:
> 1. uses some memory that is probably not required all the time, when the app
> doesn't need to repaint anything large, however this is almost completely
> shadowed by the excessive GC overhead due to continuous recreation of the
> offscreen buffered image
> Anyway, we observed about 2-4x performance increase by this simple change -
> now when running at 60 FPS it uses only about 25% of CPU for painting, and
> the rest can be used by the application logic (AI, etc.). Previously 60 FPS
> was probably the most we could achieve from Core2Duo 2.2 GHz. Of course, this
> change won't affect any "business applications" that don't do animations etc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-772) Exceptions thrown when calling getCharacterBounds of TextArea when incomplete lines exist
[ https://issues.apache.org/jira/browse/PIVOT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-772. Resolution: Fixed Fixed in rev 1151471 Note that your code needs to change slightly: Bounds bounds = logTextArea.getCharacterBounds(textarea.getCharacterCount()); textarea.scrollAreaToVisible(bounds); Note the absence of the "-1" factor, since we actually want the position of the piece just past the end. > Exceptions thrown when calling getCharacterBounds of TextArea when incomplete > lines exist > - > > Key: PIVOT-772 > URL: https://issues.apache.org/jira/browse/PIVOT-772 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0.1 > Environment: Windows XP SP3, JRE 1.6_25 or JRE 1.7 (beta) >Reporter: Roger Whitcomb >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: Scroll.java, Scroll2.java, scroll.bxml, scroll.log, > scroll2.log > > Original Estimate: 48h > Remaining Estimate: 48h > > If partial lines are appended to a TextArea and then "getCharacterBounds" > followed by "scrollAreaToVisible" is called, Pivot throws > java.lang.IndexOutOfBoundsException from > TextAreaSkinParagraphView.getCharacterBounds: > java.lang.IndexOutOfBoundsException: ix = 38 > at sun.font.StandardGlyphVector.getGlyphLogicalBounds(Unknown Source) > at > org.apache.pivot.wtk.skin.TextAreaSkinParagraphView.getCharacterBounds(TextAreaSkinParagraphView.java:393) > at > org.apache.pivot.wtk.skin.TextAreaSkin.getCharacterBounds(TextAreaSkin.java:442) > at > org.apache.pivot.wtk.TextArea.getCharacterBounds(TextArea.java:1243) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-772) Exceptions thrown when calling getCharacterBounds of TextArea when incomplete lines exist
[ https://issues.apache.org/jira/browse/PIVOT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071132#comment-13071132 ] Noel Grandin commented on PIVOT-772: Roger, thanks for being so patient. Do you have way to make the example code show the error in a more pronounced way - I've tried running it in all 3 modes for quite a while, and I'm not seeing the problem show up? > Exceptions thrown when calling getCharacterBounds of TextArea when incomplete > lines exist > - > > Key: PIVOT-772 > URL: https://issues.apache.org/jira/browse/PIVOT-772 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0.1 > Environment: Windows XP SP3, JRE 1.6_25 or JRE 1.7 (beta) >Reporter: Roger Whitcomb >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: Scroll.java, scroll.bxml, scroll.log, scroll2.log > > Original Estimate: 48h > Remaining Estimate: 48h > > If partial lines are appended to a TextArea and then "getCharacterBounds" > followed by "scrollAreaToVisible" is called, Pivot throws > java.lang.IndexOutOfBoundsException from > TextAreaSkinParagraphView.getCharacterBounds: > java.lang.IndexOutOfBoundsException: ix = 38 > at sun.font.StandardGlyphVector.getGlyphLogicalBounds(Unknown Source) > at > org.apache.pivot.wtk.skin.TextAreaSkinParagraphView.getCharacterBounds(TextAreaSkinParagraphView.java:393) > at > org.apache.pivot.wtk.skin.TextAreaSkin.getCharacterBounds(TextAreaSkin.java:442) > at > org.apache.pivot.wtk.TextArea.getCharacterBounds(TextArea.java:1243) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-723) Better GrayscaleDecorator
[
https://issues.apache.org/jira/browse/PIVOT-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noel Grandin resolved PIVOT-723.
Resolution: Fixed
Fix Version/s: (was: 2.1)
2.0.1
Assignee: Noel Grandin
Fixed in rev 1150611
> Better GrayscaleDecorator
> -
>
> Key: PIVOT-723
> URL: https://issues.apache.org/jira/browse/PIVOT-723
> Project: Pivot
> Issue Type: Improvement
> Components: wtk-effects
>Affects Versions: 2.0
>Reporter: Bill van Melle
>Assignee: Noel Grandin
>Priority: Minor
> Fix For: 2.0.1
>
> Attachments: error-round.png
>
>
> The current GrayscaleDecorator doesn't work properly when the decorated
> component uses transparency -- it turns the transparent pixels black, which
> seems unlikely to be what you want. Here's a new version of
> GrayscaleDecorator#prepare that creates the BufferedImage in a
> transparency-aware way:
> public Graphics2D prepare(Component component, Graphics2D graphics) {
> this.graphics = graphics;
> int width = component.getWidth();
> int height = component.getHeight();
>
> // To convert to gray, we create a BufferedImage in the grayscale
> color space
> // into which the decorated component draws, and we output the
> resulting image.
> // The naive way to create the buffer is
> // new BufferedImage(width, height, BufferedImage.TYPE_BYTE_GRAY);
> // but that doesn't respect transparency. Hence the following more
> complicated method.
>
> if (bufferedImage == null
> || bufferedImage.getWidth() < width
> || bufferedImage.getHeight() < height) {
> ColorSpace gsColorSpace =
> ColorSpace.getInstance(ColorSpace.CS_GRAY);
> ComponentColorModel ccm = new ComponentColorModel(gsColorSpace,
> true, false,
>
> Transparency.TRANSLUCENT, DataBuffer.TYPE_BYTE);
> WritableRaster raster = ccm.createCompatibleWritableRaster(width,
> height);
> bufferedImage = new BufferedImage(ccm, raster,
> ccm.isAlphaPremultiplied(), null);
> }
> bufferedImageGraphics = bufferedImage.createGraphics();
> bufferedImageGraphics.setClip(graphics.getClip());
> return bufferedImageGraphics;
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-656) FileBrowserSheet seems frozen while browsing network folders
[ https://issues.apache.org/jira/browse/PIVOT-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070400#comment-13070400 ] Noel Grandin commented on PIVOT-656: This is an occasional problem when browsing windows network folders. There really isn't anything useful that can be done - I've seen the same thing numerous times with Windows Explorer, so it's not just a Pivot problem. What I do in one of my browsing widgets is to put a temporary "Loading..." node into the tree so at least the user knows that something is happening. > FileBrowserSheet seems frozen while browsing network folders > > > Key: PIVOT-656 > URL: https://issues.apache.org/jira/browse/PIVOT-656 > Project: Pivot > Issue Type: Improvement >Affects Versions: 1.5.1 >Reporter: A.J. > Fix For: 2.1 > > > Our customer complains about the FileBrowserSheet being unresponsive while > browsing network folders. > I haven't been able to reproduce this in my development environment but I saw > this in 'action' (or inaction in this case). > They click a folder then ... nothing happens, they wait, then wait. They are > free to try other folders (I guess this is asynchronous task) but nothing > happens. > I've asked them to navigate the same network path with the Windows explorer > which has no apparent problem (some slowdowns at worst). > So, it's hard to say where the problems is (no stack trace) but there is a > problem. > One first improvement that could be done would be to display an hourglass > (busy cursor) while the current I/O operation is pending. > Another one could be also to set a timer after which the I/O operation would > be canceled (or abandonned) and give back hand to the calling code. > That's all I'm thinking fo r now. > As soon as I can get some more info on the origin of the problem, I'll update > this issue. > Cheers, > A.J. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-772) Exceptions thrown when calling getCharacterBounds of TextArea when incomplete lines exist
[ https://issues.apache.org/jira/browse/PIVOT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-772. Resolution: Fixed Fixed in rev 1150603 > Exceptions thrown when calling getCharacterBounds of TextArea when incomplete > lines exist > - > > Key: PIVOT-772 > URL: https://issues.apache.org/jira/browse/PIVOT-772 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0.1 > Environment: Windows XP SP3, JRE 1.6_25 or JRE 1.7 (beta) >Reporter: Roger Whitcomb >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: Scroll.java, scroll.bxml, scroll.log, scroll2.log > > Original Estimate: 48h > Remaining Estimate: 48h > > If partial lines are appended to a TextArea and then "getCharacterBounds" > followed by "scrollAreaToVisible" is called, Pivot throws > java.lang.IndexOutOfBoundsException from > TextAreaSkinParagraphView.getCharacterBounds: > java.lang.IndexOutOfBoundsException: ix = 38 > at sun.font.StandardGlyphVector.getGlyphLogicalBounds(Unknown Source) > at > org.apache.pivot.wtk.skin.TextAreaSkinParagraphView.getCharacterBounds(TextAreaSkinParagraphView.java:393) > at > org.apache.pivot.wtk.skin.TextAreaSkin.getCharacterBounds(TextAreaSkin.java:442) > at > org.apache.pivot.wtk.TextArea.getCharacterBounds(TextArea.java:1243) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-757) ScrollPane paints over columnHeader if header has no background
[ https://issues.apache.org/jira/browse/PIVOT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069449#comment-13069449 ] Noel Grandin commented on PIVOT-757: Edvin, can you verify that this is still happening with the latest trunk source code? I can't repeat it here. If it is still happening for you: (*) what version of java are you using (*) what kind of graphics adapter do you have (*) what operating system and version are you running (*) is your graphics driver up to date? Thanks. > ScrollPane paints over columnHeader if header has no background > --- > > Key: PIVOT-757 > URL: https://issues.apache.org/jira/browse/PIVOT-757 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0 >Reporter: Edvin Syse > Fix For: 2.0.1 > > Attachments: headerbug.png, scrollpane-header-bug.zip > > > If the columnHeader of the ScrollPane doesn't have a background, and you > scroll the view down and then trigger a repaint, the background of the > columnHeader will actually be drawn on by the ScrollPane View. The following > code will trigger the problem if you make the surrounding Window small enough > to give you scrollbars, scroll down, and then resize the window, see attached > screenshot. > > http://pivot.apache.org/images/logo.png"/> > > > > > > > Workaround: Make sure the BoxPane has a background color set. > Will attach both a testcase and a screenshot. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-772) Exceptions thrown when calling getCharacterBounds of TextArea when incomplete lines exist
[ https://issues.apache.org/jira/browse/PIVOT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-772. Resolution: Fixed Assignee: Noel Grandin Fixed in rev 1149500 > Exceptions thrown when calling getCharacterBounds of TextArea when incomplete > lines exist > - > > Key: PIVOT-772 > URL: https://issues.apache.org/jira/browse/PIVOT-772 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0.1 > Environment: Windows XP SP3, JRE 1.6_25 or JRE 1.7 (beta) >Reporter: Roger Whitcomb >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: Scroll.java, scroll.bxml, scroll.log, scroll2.log > > Original Estimate: 48h > Remaining Estimate: 48h > > If partial lines are appended to a TextArea and then "getCharacterBounds" > followed by "scrollAreaToVisible" is called, Pivot throws > java.lang.IndexOutOfBoundsException from > TextAreaSkinParagraphView.getCharacterBounds: > java.lang.IndexOutOfBoundsException: ix = 38 > at sun.font.StandardGlyphVector.getGlyphLogicalBounds(Unknown Source) > at > org.apache.pivot.wtk.skin.TextAreaSkinParagraphView.getCharacterBounds(TextAreaSkinParagraphView.java:393) > at > org.apache.pivot.wtk.skin.TextAreaSkin.getCharacterBounds(TextAreaSkin.java:442) > at > org.apache.pivot.wtk.TextArea.getCharacterBounds(TextArea.java:1243) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-659) Scrollbar - The scrollbar's handle can't reach the right end in some cases.
[ https://issues.apache.org/jira/browse/PIVOT-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-659. Resolution: Fixed Assignee: Noel Grandin > Scrollbar - The scrollbar's handle can't reach the right end in some cases. > --- > > Key: PIVOT-659 > URL: https://issues.apache.org/jira/browse/PIVOT-659 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 1.5.1 >Reporter: Kamil Toszek >Assignee: Noel Grandin > Fix For: 2.0.1 > > > The scrollbar's handle can't reach the right end. > The same behavior is also in the tutorial > (http://pivot.apache.org/tutorials/scroll-bars.html). Try scrolling to the > right end and you will see a gap between scrollbar's handle and its "right" > button. > Link to thread: > http://apache-pivot-users.399431.n3.nabble.com/Scroll-Bars-td1746186.html#a1746186 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-768) Using TablePane.Filler to align cells in a TablePane can result in blocked mouse input when a Component's 'columnSpan' is > 1
[ https://issues.apache.org/jira/browse/PIVOT-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057708#comment-13057708 ] Noel Grandin commented on PIVOT-768: I can see two solutions to this (1) we make TablePane.Filler components "transparent" to mouse/keyboard events, so that it passes keyboard events to the component(s) below it (2) we add some kind of z-axis specification to the TablePane Container, so that the user can specify which z-order components should be displayed in. I think option (1) will fix Chris' immediate problem, but this is a general problem with any container component that is overloading the order of child components with two meanings: painting order and layout order. I'm in favour of implementing option (1) for version 2.0.1 and logging a separate issue to discuss and implement option (2) for version 2.1. > Using TablePane.Filler to align cells in a TablePane can result in blocked > mouse input when a Component's 'columnSpan' is > 1 > - > > Key: PIVOT-768 > URL: https://issues.apache.org/jira/browse/PIVOT-768 > Project: Pivot > Issue Type: Improvement > Components: wtk, wtk-terra >Affects Versions: 2.0 > Environment: n/a >Reporter: Chris Bartlett >Priority: Minor > Fix For: 2.1 > > Attachments: table_pane_filler_issue.bxml, table_pane_filler_issue.png > > > See attached BXML file and screenshot > A workaround is to make the 'filler' Component non-visible, whether it is an > actual TablePane.Filler or something else. > (A non-visible Label works exactly the same as a TablePane.Filler instance) > Perhaps TablePane.Filler should default to being non-visible to avoid this > problem? > I haven't investigated this in any way, so making the change may well have > ramifications elsewhere. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13044049#comment-13044049 ] Noel Grandin commented on PIVOT-685: Yeah, but sometimes the same variable is used in a context where it means that, and it is also used in a context where 0==A, 1==B, 2==C, etc. > 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 > Environment: n/a >Reporter: Chris Bartlett >Priority: Trivial > Fix For: 2.0.1 > > > 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 > def > > ghi' > Workaround by using the mouse, or SHIFT+LEFT & SHIFT+RIGHT -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13043378#comment-13043378 ] Noel Grandin commented on PIVOT-685: Greg, you are right. I'm not having much success tracking this one down, getting lost in the maze of when an index value points to the boundary between 2 characters, and when it points to the character itself. Makes me want to write some classes which wrap an int and explicitly specify which kind of index they are :-) Maybe next week my brain will be in better shape. > 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 > Environment: n/a >Reporter: Chris Bartlett >Priority: Trivial > Fix For: 2.0.1 > > > 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 > def > > ghi' > Workaround by using the mouse, or SHIFT+LEFT & SHIFT+RIGHT -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-748) ScaleTransition
[ https://issues.apache.org/jira/browse/PIVOT-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043241#comment-13043241 ] Noel Grandin commented on PIVOT-748: This is relatively common effect, so I'd say we should include it in the main project. > ScaleTransition > --- > > Key: PIVOT-748 > URL: https://issues.apache.org/jira/browse/PIVOT-748 > Project: Pivot > Issue Type: New Feature > Components: wtk-effects >Reporter: Edgar Merino >Priority: Minor > Fix For: 2.1 > > Attachments: ScaleTransition.java > > > This is a simple, yet useful, Transition which is able to scale the > component(s) attached to it for a given period of time, providing a "zoom" > effect. The code is attached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-729) TabPane corner component is hidden by tabs.
[ https://issues.apache.org/jira/browse/PIVOT-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-729. Resolution: Fixed Assignee: Noel Grandin Fixed in rev 1130432 > TabPane corner component is hidden by tabs. > --- > > Key: PIVOT-729 > URL: https://issues.apache.org/jira/browse/PIVOT-729 > Project: Pivot > Issue Type: Improvement > Components: wtk-terra >Affects Versions: 2.0 >Reporter: Raffaele Borrelli >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: TerraTabPaneSkin.diff > > > The width of the "corner" component of a TabPane is not respected and the > component gets hidden when a large number of tabs is opened. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-692) FileBrowserSheet's File column width is not adjustable
[ https://issues.apache.org/jira/browse/PIVOT-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042634#comment-13042634 ] Noel Grandin commented on PIVOT-692: This is awaiting a fix to PIVOT-609 > FileBrowserSheet's File column width is not adjustable > -- > > Key: PIVOT-692 > URL: https://issues.apache.org/jira/browse/PIVOT-692 > Project: Pivot > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Taro App >Priority: Minor > Fix For: 2.0.1 > > > Width of a File column in FileBrowserSheet is not adjustable, so users may > not be able to distinguish files such as > LongFileNameSalesRevenueDataFor201012.csv and > LongFileNameSalesRevenueDataFor201101.csv. Workaround is to make the width of > FileBrowserSheet bigger, but making column width adjustable is preferable > solution. > Reference: > http://mail-archives.apache.org/mod_mbox/pivot-user/201101.mbox/%3caanlktinkritxylet_k0qluatuwuh2y8xx0c1cuw5s...@mail.gmail.com%3E -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-647) IllegalArgumentException when attempting to show a tooltip set against a Display
[ https://issues.apache.org/jira/browse/PIVOT-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-647. Resolution: Fixed Assignee: Noel Grandin Resolved in rev 1130166 > IllegalArgumentException when attempting to show a tooltip set against a > Display > > > Key: PIVOT-647 > URL: https://issues.apache.org/jira/browse/PIVOT-647 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 1.5.1 > Environment: n/a >Reporter: Chris Bartlett >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: DisplayTooltip.java > > > Component#getWindow() returns null for a Display, which in turn causes the IAE > Note that the native frame title is also changed (blanked) while the tooltip > is being shown. > Perhaps the tooltip should have its title set to that of the host frame prior > to being shown, or DesktopApplicationContext#updateFrameTitleBar should treat > tooltips differently? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-695) TextInput should support editable property
[ https://issues.apache.org/jira/browse/PIVOT-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-695. Resolution: Fixed Assignee: Noel Grandin Fixed in 1130155 > TextInput should support editable property > -- > > Key: PIVOT-695 > URL: https://issues.apache.org/jira/browse/PIVOT-695 > Project: Pivot > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Taro App >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > > TextInput should support editable property as TextArea does. Setting > editable to false should make the TextInput read only. > Workaround may be to use a single line TextArea with editable="false" but the > pain part is that you can't scroll the TextArea horizontally with mouse drag. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13042161#comment-13042161 ] Noel Grandin commented on PIVOT-685: The problem here is that the way we have defined selection indexes, it is impossible to distinguish between the index that indicates before the first newline, and the index that indicates before the second newline. The obvious fix is to include the \n character in the calculation of indexes, but that will introduce a bunch of special cases elsewhere. > 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 > Environment: n/a >Reporter: Chris Bartlett >Priority: Trivial > Fix For: 2.0.1 > > > 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 > def > > ghi' > Workaround by using the mouse, or SHIFT+LEFT & SHIFT+RIGHT -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-747) pivot & blocking edt
[ https://issues.apache.org/jira/browse/PIVOT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041597#comment-13041597 ] Noel Grandin commented on PIVOT-747: No, you can substitute your own main method and do whatever you need to do there, before calling DesktopApplicationContext#main() > pivot & blocking edt > > > Key: PIVOT-747 > URL: https://issues.apache.org/jira/browse/PIVOT-747 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0 >Reporter: Andrei Pozolotin >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: Container.java, patch-001-exit.patch, > patch_2011-05-27_edt-name.patch, patch_2011-05-29_assert-runner.patch > > > Greg, hello; > in this thread: > http://mail-archives.apache.org/mod_mbox/pivot-user/201001.mbox/%3c4b5e581d.2080...@hms.harvard.edu%3E > your final word is: > "Sorry, it is not possible" > but I know that you know that it is possible :-) > the reason I need this is same as Martin here: > http://netbeans.org/bugzilla/show_bug.cgi?id=90590 > namely: do some cleanup after shutdown was requested and confirmed: > org.apache.pivot.wtk.Application > public boolean shutdown(boolean optional) throws Exception; > since you call shutdown(boolean optional) from EDT I need to block it, using > this approach: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > wich "almost works", except you have this check everywhere: > Container.assertEventDispatchThread(); > which fails, as described above: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > due to EventQueue.isDispatchThread() failing on the "T1 vs T1*" distinction > my request is this: > do you think you could make > Container.assertEventDispatchThread(); > less pedantic, and allow both "current and past/next" EDT threads to pass > which are created during EventQueue push() / pop() > thanks! > Andrei -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-747) pivot & blocking edt
[ https://issues.apache.org/jira/browse/PIVOT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041483#comment-13041483 ] Noel Grandin commented on PIVOT-747: Committed installable checker in rev 1129568 > pivot & blocking edt > > > Key: PIVOT-747 > URL: https://issues.apache.org/jira/browse/PIVOT-747 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0 >Reporter: Andrei Pozolotin >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: Container.java, patch-001-exit.patch, > patch_2011-05-27_edt-name.patch, patch_2011-05-29_assert-runner.patch > > > Greg, hello; > in this thread: > http://mail-archives.apache.org/mod_mbox/pivot-user/201001.mbox/%3c4b5e581d.2080...@hms.harvard.edu%3E > your final word is: > "Sorry, it is not possible" > but I know that you know that it is possible :-) > the reason I need this is same as Martin here: > http://netbeans.org/bugzilla/show_bug.cgi?id=90590 > namely: do some cleanup after shutdown was requested and confirmed: > org.apache.pivot.wtk.Application > public boolean shutdown(boolean optional) throws Exception; > since you call shutdown(boolean optional) from EDT I need to block it, using > this approach: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > wich "almost works", except you have this check everywhere: > Container.assertEventDispatchThread(); > which fails, as described above: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > due to EventQueue.isDispatchThread() failing on the "T1 vs T1*" distinction > my request is this: > do you think you could make > Container.assertEventDispatchThread(); > less pedantic, and allow both "current and past/next" EDT threads to pass > which are created during EventQueue push() / pop() > thanks! > Andrei -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-747) pivot & blocking edt
[ https://issues.apache.org/jira/browse/PIVOT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-747. Resolution: Fixed Fixed in rev 1129031 > pivot & blocking edt > > > Key: PIVOT-747 > URL: https://issues.apache.org/jira/browse/PIVOT-747 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0 >Reporter: Andrei Pozolotin >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: Container.java, patch-001-exit.patch, > patch_2011-05-27_edt-name.patch, patch_2011-05-29_assert-runner.patch > > > Greg, hello; > in this thread: > http://mail-archives.apache.org/mod_mbox/pivot-user/201001.mbox/%3c4b5e581d.2080...@hms.harvard.edu%3E > your final word is: > "Sorry, it is not possible" > but I know that you know that it is possible :-) > the reason I need this is same as Martin here: > http://netbeans.org/bugzilla/show_bug.cgi?id=90590 > namely: do some cleanup after shutdown was requested and confirmed: > org.apache.pivot.wtk.Application > public boolean shutdown(boolean optional) throws Exception; > since you call shutdown(boolean optional) from EDT I need to block it, using > this approach: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > wich "almost works", except you have this check everywhere: > Container.assertEventDispatchThread(); > which fails, as described above: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > due to EventQueue.isDispatchThread() failing on the "T1 vs T1*" distinction > my request is this: > do you think you could make > Container.assertEventDispatchThread(); > less pedantic, and allow both "current and past/next" EDT threads to pass > which are created during EventQueue push() / pop() > thanks! > Andrei -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-747) pivot & blocking edt
[ https://issues.apache.org/jira/browse/PIVOT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039143#comment-13039143 ] Noel Grandin commented on PIVOT-747: I'm in agreement with Greg, trying to fix Andrei's use-case is getting too complex. So yes, I think we should make it possible to turn it off with a system property. I think it's actually fairly robust in general - very few developers play the kind of EDT-switching tricks that Andrei does. For those developers not using such tricks, it provides early-on checking for a class of problems that is otherwise hard to debug. I also note from reading the bugs referenced by Andrei, that this particular problem is fixed in JDK7, so when that comes around, Andrei will not longer need to turn this off. > pivot & blocking edt > > > Key: PIVOT-747 > URL: https://issues.apache.org/jira/browse/PIVOT-747 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0 >Reporter: Andrei Pozolotin >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: Container.java, patch-001-exit.patch > > > Greg, hello; > in this thread: > http://mail-archives.apache.org/mod_mbox/pivot-user/201001.mbox/%3c4b5e581d.2080...@hms.harvard.edu%3E > your final word is: > "Sorry, it is not possible" > but I know that you know that it is possible :-) > the reason I need this is same as Martin here: > http://netbeans.org/bugzilla/show_bug.cgi?id=90590 > namely: do some cleanup after shutdown was requested and confirmed: > org.apache.pivot.wtk.Application > public boolean shutdown(boolean optional) throws Exception; > since you call shutdown(boolean optional) from EDT I need to block it, using > this approach: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > wich "almost works", except you have this check everywhere: > Container.assertEventDispatchThread(); > which fails, as described above: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > due to EventQueue.isDispatchThread() failing on the "T1 vs T1*" distinction > my request is this: > do you think you could make > Container.assertEventDispatchThread(); > less pedantic, and allow both "current and past/next" EDT threads to pass > which are created during EventQueue push() / pop() > thanks! > Andrei -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-747) pivot & blocking edt
[ https://issues.apache.org/jira/browse/PIVOT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038532#comment-13038532 ] Noel Grandin commented on PIVOT-747: Thanks for your analysis Andrei. There is not much I can do to fix EventQueue#isDispatchThread. But does it help your situation if you change the Container#assertEventDispatchThread method to be synchronized? That will force the VM to emit a memory barrier, which will at least enforce that it can see recent memory writes. > pivot & blocking edt > > > Key: PIVOT-747 > URL: https://issues.apache.org/jira/browse/PIVOT-747 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0 >Reporter: Andrei Pozolotin > Attachments: patch-001-exit.patch > > > Greg, hello; > in this thread: > http://mail-archives.apache.org/mod_mbox/pivot-user/201001.mbox/%3c4b5e581d.2080...@hms.harvard.edu%3E > your final word is: > "Sorry, it is not possible" > but I know that you know that it is possible :-) > the reason I need this is same as Martin here: > http://netbeans.org/bugzilla/show_bug.cgi?id=90590 > namely: do some cleanup after shutdown was requested and confirmed: > org.apache.pivot.wtk.Application > public boolean shutdown(boolean optional) throws Exception; > since you call shutdown(boolean optional) from EDT I need to block it, using > this approach: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > wich "almost works", except you have this check everywhere: > Container.assertEventDispatchThread(); > which fails, as described above: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > due to EventQueue.isDispatchThread() failing on the "T1 vs T1*" distinction > my request is this: > do you think you could make > Container.assertEventDispatchThread(); > less pedantic, and allow both "current and past/next" EDT threads to pass > which are created during EventQueue push() / pop() > thanks! > Andrei -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-747) pivot & blocking edt
[ https://issues.apache.org/jira/browse/PIVOT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037997#comment-13037997 ] Noel Grandin commented on PIVOT-747: Firstly, Container.assertEventDispatchThread() calls into EventQueue.isDispatchThread(), which correctly traverses the push()/pop() hierarchy, so there shouldn't be a problem there. Secondly, I don't understand why you need such a complicated solution. Why can you not simply call osgiShutdown() directly from your Application#shutdown(boolean) ? And why not simply call osgiStartup() from Application#startup ? > pivot & blocking edt > > > Key: PIVOT-747 > URL: https://issues.apache.org/jira/browse/PIVOT-747 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0 >Reporter: Andrei Pozolotin > > Greg, hello; > in this thread: > http://mail-archives.apache.org/mod_mbox/pivot-user/201001.mbox/%3c4b5e581d.2080...@hms.harvard.edu%3E > your final word is: > "Sorry, it is not possible" > but I know that you know that it is possible :-) > the reason I need this is same as Martin here: > http://netbeans.org/bugzilla/show_bug.cgi?id=90590 > namely: do some cleanup after shutdown was requested and confirmed: > org.apache.pivot.wtk.Application > public boolean shutdown(boolean optional) throws Exception; > since you call shutdown(boolean optional) from EDT I need to block it, using > this approach: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > wich "almost works", except you have this check everywhere: > Container.assertEventDispatchThread(); > which fails, as described above: > http://bugs.sun.com/view_bug.do?bug_id=6424157 > due to EventQueue.isDispatchThread() failing on the "T1 vs T1*" distinction > my request is this: > do you think you could make > Container.assertEventDispatchThread(); > less pedantic, and allow both "current and past/next" EDT threads to pass > which are created during EventQueue push() / pop() > thanks! > Andrei -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-735) Strange problem with textarea
[ https://issues.apache.org/jira/browse/PIVOT-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-735. Resolution: Fixed Assignee: Noel Grandin Fixed in rev 1097451 > Strange problem with textarea > -- > > Key: PIVOT-735 > URL: https://issues.apache.org/jira/browse/PIVOT-735 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0 > Environment: windows 7 x64 >Reporter: Olivier Dutrieux >Assignee: Noel Grandin > Labels: textarea > Fix For: 2.0.1 > > Attachments: sample.zip, screenshot-1.jpg > > > I have a textarea with scrollpane like this : > verticalScrollBarPolicy="fill_to_capacity" maximumHeight="100" > preferredWidth="350"> > > > If I hide a component on the my window page where there is this textarea, the > text of textarea change to be display under the scrollpane. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-730) NullPointerException when selecting across multiple text spans
[ https://issues.apache.org/jira/browse/PIVOT-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-730. Resolution: Fixed Assignee: Noel Grandin Fixed in rev 1094574 and rev 1094603 > NullPointerException when selecting across multiple text spans > -- > > Key: PIVOT-730 > URL: https://issues.apache.org/jira/browse/PIVOT-730 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0.1 >Reporter: Bill van Melle >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > > I'm getting frequent NullPointerException's related to selecting in a > TextPane. Here's a simple example: > http://pivot.apache.org/bxml"; > xmlns="org.apache.pivot.wtk"> > > > > Important: > I'm getting frequent NullPointerException's related to > selecting in a TextPane. This is a simple example. > (Today @ 12:31p) > > > > > Reshape the window small enough that some or all of the italicized text is on > at least the third line. Now try to select text from the plain part into the > italicized part. A typical backtrace in my debugger reads: > java.lang.NullPointerException > at > org.apache.pivot.wtk.skin.TextPaneSkin.updateSelection(TextPaneSkin.java:1138) > at > org.apache.pivot.wtk.skin.TextPaneSkin.selectionChanged(TextPaneSkin.java:1053) > at > org.apache.pivot.wtk.TextPane$TextPaneSelectionListenerList.selectionChanged(TextPane.java:190) > at org.apache.pivot.wtk.TextPane.setSelection(TextPane.java:734) > at > org.apache.pivot.wtk.skin.TextPaneSkin.mouseMove(TextPaneSkin.java:630) > at > org.apache.pivot.wtk.Component$ComponentMouseListenerList.mouseMove(Component.java:433) > at org.apache.pivot.wtk.Component.mouseMove(Component.java:2721) > at org.apache.pivot.wtk.Container.mouseMove(Container.java:673) > at > org.apache.pivot.wtk.ApplicationContext$DisplayHost.processMouseMotionEvent(ApplicationContext.java:1048) > at java.awt.Component.processEvent(Unknown Source) > at > org.apache.pivot.wtk.ApplicationContext$DisplayHost.processEvent(ApplicationContext.java:709) > at java.awt.Component.dispatchEventImpl(Unknown Source) > at java.awt.Component.dispatchEvent(Unknown Source) > at ... more awt stuff ... > Similar errors occur if you start with the window wide, select text spanning > the plain and italic parts, and then reshape the window narrower. > Related bug without a fault: with the window wide, select text spanning the > bold and plain parts. Reshape the window narrower. You'll get to widths > where more text appears selected than should be and/or some of the text is > blank. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-727) Text of different sizes in a TextPane should have aligned baselines
[ https://issues.apache.org/jira/browse/PIVOT-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-727. Resolution: Fixed Assignee: Noel Grandin > Text of different sizes in a TextPane should have aligned baselines > --- > > Key: PIVOT-727 > URL: https://issues.apache.org/jira/browse/PIVOT-727 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0 >Reporter: Bill van Melle >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > > When you have spans of different font sizes in a TextPane, it looks to me > like all the text is bottom-aligned, which generally looks bad. It would be > much nicer if the baselines were aligned. Here's a deliberately exaggerated > example: > http://pivot.apache.org/bxml"; > xmlns="org.apache.pivot.wtk"> > > > > > > > > > > > > > > > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PIVOT-728) TextPane: shift-cursor selection behaviour doesn't match other editors when moving backwards and forwards
TextPane: shift-cursor selection behaviour doesn't match other editors when moving backwards and forwards - Key: PIVOT-728 URL: https://issues.apache.org/jira/browse/PIVOT-728 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0 Reporter: Noel Grandin Priority: Minor Fix For: 2.1 1. Click somewhere in a paragraph. 2. Hold down the shift key. 3. Press right-arrow twice. Two characters are now selected. 4. Press left-arrow once. Now 3 characters are selected. The expected behaviour after step 4 is that only character is selected. The tricky part about this is that it requires us to keep track of where the selection process __began__, because we need to know if the user is moving forwards or backwards from the original selection position. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-726) Selection in a Paragraph with non-null background color displays incorrectly
[ https://issues.apache.org/jira/browse/PIVOT-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-726. Resolution: Fixed Fix Version/s: 2.0.1 Assignee: Noel Grandin Fixed in revision 1089425 > Selection in a Paragraph with non-null background color displays incorrectly > > > Key: PIVOT-726 > URL: https://issues.apache.org/jira/browse/PIVOT-726 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0, 2.0.1 > Environment: Windows XP, Mac OS X (at least) >Reporter: Bill van Melle >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > > If you try to select text in a Paragraph that has a background color, the > selection background is not painted, but the text is painted white, which > means that against a white or light background, the text is effectively > invisible. The problem doesn't happen when the Paragraph has the default > (null) background. > Simple example: >xmlns="org.apache.pivot.wtk"> > > > > > > > > > > > > Try making a selection that includes the second line of text, and notice that > you can't read the text. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PIVOT-724) Problem with TreeView and Comparator
[ https://issues.apache.org/jira/browse/PIVOT-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-724. Resolution: Fixed Assignee: Noel Grandin In revision 1089018 by making the indexOf() method in TreeBranch search for the node by hand. > Problem with TreeView and Comparator > > > Key: PIVOT-724 > URL: https://issues.apache.org/jira/browse/PIVOT-724 > Project: Pivot > Issue Type: Bug >Affects Versions: 2.0 > Environment: Fedora 12, NetBeans 8.9, java 1.6.0_18 >Reporter: Stefano Sancese >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > Attachments: Main.java > > > If two TreeNode have the same text AND a comparator is defined for the > TreeBranch they belong, then is impossible to select (by mouse o by arrow > key) one of them. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-724) Problem with TreeView and Comparator
[ https://issues.apache.org/jira/browse/PIVOT-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015903#comment-13015903 ] Noel Grandin commented on PIVOT-724: The problem here is as follows: TerraTreeViewSkin#mouseDown() calls TerraTreeViewSkin.NodeInfo#getPath() calls TreeBranch#indexOf calls ArrayList#indexOf which use the comparator to do a binary search, and comes up with the wrong answer because it considers the first 2 nodes to be the same. > Problem with TreeView and Comparator > > > Key: PIVOT-724 > URL: https://issues.apache.org/jira/browse/PIVOT-724 > Project: Pivot > Issue Type: Bug >Affects Versions: 2.0 > Environment: Fedora 12, NetBeans 8.9, java 1.6.0_18 >Reporter: Stefano Sancese >Priority: Minor > Fix For: 2.0.1 > > Attachments: Main.java > > > If two TreeNode have the same text AND a comparator is defined for the > TreeBranch they belong, then is impossible to select (by mouse o by arrow > key) one of them. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-697) Font looks different when text is selected across multiple lines in TextArea
[ https://issues.apache.org/jira/browse/PIVOT-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012448#comment-13012448 ] Noel Grandin commented on PIVOT-697: Nice work tracking that down Taro. Can you check the type of graphics driver you have, and the version of the graphics driver? And perhaps check if there is an updated driver? Sometimes the JDK manages to tickle interesting new bugs in graphics drivers. > Font looks different when text is selected across multiple lines in TextArea > > > Key: PIVOT-697 > URL: https://issues.apache.org/jira/browse/PIVOT-697 > Project: Pivot > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows XP SP3, JDK 1.6.0_18, Japanese >Reporter: Taro App >Priority: Minor > Fix For: 2.0.1 > > Attachments: NotePadComparison-MultipleLineSelectEnglish.png, > NotePadComparison-MultipleLineSelectJapanese.png, > Test1.SingleLineSelectEnglish.png, Test2.MultipleLineSelectEnglish.png, > Test3.SingleLineSelectJapanese.png, Test4.MultipleLineSelectJapanese.png, > TextAreaFontTestEnglish.java, TextAreaFontTestJapanese.java > > > Font looks different when text is selected across multiple lines in TextArea. > When the selection is within a single line, font looks the same. > For English text, this font change is subtle and can be ignored. > For Japanese text, this font change is obvious and looks weird. > I'm not sure if this is platform dependent or font dependent. > May have something to do with how Java2D renders fonts. > I will attach screen shots and test codes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-697) Font looks different when text is selected across multiple lines in TextArea
[ https://issues.apache.org/jira/browse/PIVOT-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012072#comment-13012072 ] Noel Grandin commented on PIVOT-697: Thanks Taro. Very very interesting. Both Pivot and Windows are doing anti-aliasing on the text, but they're doing it very differently. I'm really not sure what to make of this. > Font looks different when text is selected across multiple lines in TextArea > > > Key: PIVOT-697 > URL: https://issues.apache.org/jira/browse/PIVOT-697 > Project: Pivot > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows XP SP3, JDK 1.6.0_18, Japanese >Reporter: Taro App >Priority: Minor > Fix For: 2.0.1 > > Attachments: NotePadComparison-MultipleLineSelectEnglish.png, > NotePadComparison-MultipleLineSelectJapanese.png, > Test1.SingleLineSelectEnglish.png, Test2.MultipleLineSelectEnglish.png, > Test3.SingleLineSelectJapanese.png, Test4.MultipleLineSelectJapanese.png, > TextAreaFontTestEnglish.java, TextAreaFontTestJapanese.java > > > Font looks different when text is selected across multiple lines in TextArea. > When the selection is within a single line, font looks the same. > For English text, this font change is subtle and can be ignored. > For Japanese text, this font change is obvious and looks weird. > I'm not sure if this is platform dependent or font dependent. > May have something to do with how Java2D renders fonts. > I will attach screen shots and test codes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PIVOT-697) Font looks different when text is selected across multiple lines in TextArea
[ https://issues.apache.org/jira/browse/PIVOT-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010645#comment-13010645 ] Noel Grandin commented on PIVOT-697: @Taro, can you post 2 comparison screenshots of what this looks like in Pivot and in Notepad on your PC? So we can compare results. Thanks. > Font looks different when text is selected across multiple lines in TextArea > > > Key: PIVOT-697 > URL: https://issues.apache.org/jira/browse/PIVOT-697 > Project: Pivot > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows XP SP3, JDK 1.6.0_18, Japanese >Reporter: Taro App >Priority: Minor > Fix For: 2.0.1 > > Attachments: Test1.SingleLineSelectEnglish.png, > Test2.MultipleLineSelectEnglish.png, Test3.SingleLineSelectJapanese.png, > Test4.MultipleLineSelectJapanese.png, TextAreaFontTestEnglish.java, > TextAreaFontTestJapanese.java > > > Font looks different when text is selected across multiple lines in TextArea. > When the selection is within a single line, font looks the same. > For English text, this font change is subtle and can be ignored. > For Japanese text, this font change is obvious and looks weird. > I'm not sure if this is platform dependent or font dependent. > May have something to do with how Java2D renders fonts. > I will attach screen shots and test codes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PIVOT-716) Clearing a Document by removing all elements crashes
[ https://issues.apache.org/jira/browse/PIVOT-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-716. Resolution: Fixed Fix Version/s: 2.0.1 Assignee: Noel Grandin > Clearing a Document by removing all elements crashes > > > Key: PIVOT-716 > URL: https://issues.apache.org/jira/browse/PIVOT-716 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0.1 >Reporter: Bill van Melle >Assignee: Noel Grandin >Priority: Critical > Fix For: 2.0.1 > > > In version 2.0, I could clear a Document by doing >doc.remove(0, doc.getLength()); > In the current trunk, this causes a crash: > java.lang.IndexOutOfBoundsException: > offset+characterCount>this.characterCount offset=0 characterCount=38 > this.characterCount=0 > at org.apache.pivot.wtk.text.Element.getRange(Element.java:263) > at org.apache.pivot.wtk.text.Element.getRange(Element.java:39) > at > org.apache.pivot.wtk.TextPane$RangeRemovedEdit.(TextPane.java:122) > at org.apache.pivot.wtk.TextPane$2.rangeRemoved(TextPane.java:268) > at > org.apache.pivot.wtk.text.Node$NodeListenerList.rangeRemoved(Node.java:66) > at org.apache.pivot.wtk.text.Node.rangeRemoved(Node.java:217) > at org.apache.pivot.wtk.text.Element.remove(Element.java:454) > Example available on request, but you should be able to reproduce it by > taking the code from https://issues.apache.org/jira/browse/PIVOT-715, add a > suitable id to the Document node, and write code to do the remove call shown > above. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PIVOT-683) TextAreaSkin throws IndexOutOfBoundsException when the END key is pressed on the final line of a TextArea
[ https://issues.apache.org/jira/browse/PIVOT-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-683. Resolution: Fixed Fixed in revision 1081381 > TextAreaSkin throws IndexOutOfBoundsException when the END key is pressed on > the final line of a TextArea > - > > Key: PIVOT-683 > URL: https://issues.apache.org/jira/browse/PIVOT-683 > Project: Pivot > Issue Type: Bug > Components: wtk > Environment: n/a >Reporter: Chris Bartlett >Assignee: Greg Brown >Priority: Minor > Fix For: 2.0.1 > > > TextAreaSkin fails as follows when the END key is pressed on the final line > of a TextArea (ie, a line without a linebreak) > java.lang.IndexOutOfBoundsException > at org.apache.pivot.wtk.TextArea.getCharacterAt(TextArea.java:870) > at org.apache.pivot.wtk.skin.TextAreaSkin.keyPressed(TextAreaSkin.java:934) > at > org.apache.pivot.wtk.Component$ComponentKeyListenerList.keyPressed(Component.java:524) > at org.apache.pivot.wtk.Component.keyPressed(Component.java:2813) > at > org.apache.pivot.wtk.ApplicationContext$DisplayHost.processKeyEvent(ApplicationContext.java:1257) > at java.awt.Component.processEvent(Unknown Source) > at > org.apache.pivot.wtk.ApplicationContext$DisplayHost.processEvent(ApplicationContext.java:709) > ... > You can see this by simply pressing END with a freshly created TextArea with > no content. > If you add a second line, END will work on the first line, but will throw on > the last one. > (Using latest code from trunk) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PIVOT-684) Clicking on unused space following the last character in a TextArea should move the caret to after the last character
[ https://issues.apache.org/jira/browse/PIVOT-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-684. Resolution: Fixed Fixed in revision 1081377 > Clicking on unused space following the last character in a TextArea should > move the caret to after the last character > - > > Key: PIVOT-684 > URL: https://issues.apache.org/jira/browse/PIVOT-684 > Project: Pivot > Issue Type: Bug > Components: wtk > Environment: n/a >Reporter: Chris Bartlett >Assignee: Greg Brown >Priority: Minor > Fix For: 2.0.1 > > > Clicking in the unused space currently seems to have no effect. > The behaviour would mirrors the caret placement following the pressing of the > END key, so the END key can be used as a workaround. > See TextAreaSkin.getInsertionPoint(int, int) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (PIVOT-697) Font looks different when text is selected across multiple lines in TextArea
[ https://issues.apache.org/jira/browse/PIVOT-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006400#comment-13006400 ] Noel Grandin commented on PIVOT-697: This is just the standard Java anti-aliasing logic at work. I'm not sure that there is much we can do to fix it, without making other rendering look worse. You could try playing with these command-line switches and seeing if they help: http://stackoverflow.com/questions/1202040/specify-antialias-property-in-the-command-line > Font looks different when text is selected across multiple lines in TextArea > > > Key: PIVOT-697 > URL: https://issues.apache.org/jira/browse/PIVOT-697 > Project: Pivot > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows XP SP3, JDK 1.6.0_18, Japanese >Reporter: Taro App >Priority: Minor > Fix For: 2.0.1 > > Attachments: Test1.SingleLineSelectEnglish.png, > Test2.MultipleLineSelectEnglish.png, Test3.SingleLineSelectJapanese.png, > Test4.MultipleLineSelectJapanese.png, TextAreaFontTestEnglish.java, > TextAreaFontTestJapanese.java > > > Font looks different when text is selected across multiple lines in TextArea. > When the selection is within a single line, font looks the same. > For English text, this font change is subtle and can be ignored. > For Japanese text, this font change is obvious and looks weird. > I'm not sure if this is platform dependent or font dependent. > May have something to do with how Java2D renders fonts. > I will attach screen shots and test codes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PIVOT-693) Mouse drag in TextArea causes IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/PIVOT-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-693. Resolution: Fixed Assignee: Noel Grandin Fixed in revision 1081360. Please test because I can't confirm this myself. > Mouse drag in TextArea causes IndexOutOfBoundsException > --- > > Key: PIVOT-693 > URL: https://issues.apache.org/jira/browse/PIVOT-693 > Project: Pivot > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Taro App >Assignee: Noel Grandin > Fix For: 2.0.1 > > > Create a small TextArea filled with long text overflowing the TextArea, then > use your mouse to drag-select text and try to select out of the TextArea, > then IndexOutOfBoundsException is raised: > java.lang.IndexOutOfBoundsException: index 1 out of bounds. > at > org.apache.pivot.collections.ArrayList.verifyIndexBounds(ArrayList.java:577) > at org.apache.pivot.collections.ArrayList.get(ArrayList.java:346) > at > org.apache.pivot.wtk.skin.TextAreaSkinParagraphView.getRowInsertionPoint(TextAreaSkinParagraphView.java:313) > at > org.apache.pivot.wtk.skin.TextAreaSkinParagraphView.getInsertionPoint(TextAreaSkinParagraphView.java:288) > at > org.apache.pivot.wtk.skin.TextAreaSkin.getInsertionPoint(TextAreaSkin.java:322) > at > org.apache.pivot.wtk.skin.TextAreaSkin.mouseMove(TextAreaSkin.java:715) > at > org.apache.pivot.wtk.Component$ComponentMouseListenerList.mouseMove(Component.java:433) > at org.apache.pivot.wtk.Component.mouseMove(Component.java:2721) > at > org.apache.pivot.wtk.ApplicationContext$DisplayHost.processMouseMotionEvent(ApplicationContext.java:1048) > at java.awt.Component.processEvent(Component.java:6032) > at > org.apache.pivot.wtk.ApplicationContext$DisplayHost.processEvent(ApplicationContext.java:709) > at java.awt.Component.dispatchEventImpl(Component.java:4630) > at java.awt.Component.dispatchEvent(Component.java:4460) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4574) > at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4255) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168) > at java.awt.Container.dispatchEventImpl(Container.java:2085) > at java.awt.Window.dispatchEventImpl(Window.java:2478) > at java.awt.Component.dispatchEvent(Component.java:4460) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:599) > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) > This also happens for a TextArea inside ScrollPane. > This exception seems to occur only for some fonts. For my case, exception > didn't occur for my English font, but did occur for my Japanese font. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PIVOT-715) Background color not painted properly in TextPane
[ https://issues.apache.org/jira/browse/PIVOT-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-715. Resolution: Fixed Assignee: Noel Grandin Fixed in revision 1081353 > Background color not painted properly in TextPane > - > > Key: PIVOT-715 > URL: https://issues.apache.org/jira/browse/PIVOT-715 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0 >Reporter: Bill van Melle >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0.1 > > > The background color is not painted properly in a TextPane with multiple > spans. Here's a simple example: >xmlns:bxml="http://pivot.apache.org/bxml"; > xmlns="org.apache.pivot.wtk"> > > > > > > > > > > > If the window is wide enough, you'll see an extra splotch of yellow to the > right of the text, and part of the text will not be yellow. If you reshape > the window to be narrower than the text, you'll see many variations of blocks > of yellow showing outside the text, and parts of the next not having a yellow > background. > (The bold and italic styles make it interesting, but you can take them away > and still see the bug, just as long as the paragraph has multiple spans. And > the reshaping bug doesn't even require multiple spans.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (PIVOT-698) Support undo in TextPane
[ https://issues.apache.org/jira/browse/PIVOT-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-698. Resolution: Fixed Fix Version/s: 2.1 > Support undo in TextPane > > > Key: PIVOT-698 > URL: https://issues.apache.org/jira/browse/PIVOT-698 > Project: Pivot > Issue Type: New Feature > Components: wtk >Affects Versions: 2.1 >Reporter: Noel Grandin >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.1 > > > TextPane should support undo like TextArea does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PIVOT-698) Support undo in TextPane
Support undo in TextPane Key: PIVOT-698 URL: https://issues.apache.org/jira/browse/PIVOT-698 Project: Pivot Issue Type: New Feature Components: wtk Affects Versions: 2.1 Reporter: Noel Grandin Assignee: Noel Grandin Priority: Minor TextPane should support undo like TextArea does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-670) Generic types for listeners
[
https://issues.apache.org/jira/browse/PIVOT-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932652#action_12932652
]
Noel Grandin commented on PIVOT-670:
Plus it would be a major pain to implement because every single subclass of
wtk.Component would need to specify itself in the extends clause since Java
doesn't support self types.
And we'd have to override the listener methods in every subclass to specify the
correct return type.
And it would make certain types of generic programming, where you can define a
listener object that operates on many different Component subclasses, much
harder.
> Generic types for listeners
> ---
>
> Key: PIVOT-670
> URL: https://issues.apache.org/jira/browse/PIVOT-670
> Project: Pivot
> Issue Type: Improvement
> Environment: All
>Reporter: Frédéric VERGEZ
>Priority: Trivial
>
> Could listener interfaces have generic types ?
> This would allow to be type safe in methods, and avoid objects casting.
> For instance in a ComponentMouseListener:
> public interface ComponentMouseListener {
> /**
> * Component mouse button listener adapter.
> */
> public static class Adapter implements ComponentMouseListener {
> @Override
> public boolean mouseMove(T component, int x, int y) {
> return false;
> }
> @Override
> public void mouseOver(T component) {
> }
> @Override
> public void mouseOut(T component) {
> }
> }
> /**
> * Called when the mouse is moved over a component.
> *
> * @param component
> * @param x
> * @param y
> *
> * @return
> * true to consume the event; false to allow it to
> * propagate.
> */
> public boolean mouseMove(T component, int x, int y);
> /**
> * Called when the mouse enters a component.
> *
> * @param component
> */
> public void mouseOver(T component);
> /**
> * Called when the mouse exits a component.
> *
> * @param component
> */
> public void mouseOut(T component);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-487) Pivot doesn't start in turkish locale (and other locales)
[ https://issues.apache.org/jira/browse/PIVOT-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-487. Assignee: Noel Grandin Resolution: Fixed > Pivot doesn't start in turkish locale (and other locales) > - > > Key: PIVOT-487 > URL: https://issues.apache.org/jira/browse/PIVOT-487 > Project: Pivot > Issue Type: Bug >Affects Versions: 1.4, 1.5 >Reporter: Dirk Moebius >Assignee: Noel Grandin > Fix For: 2.0 > > > Run, for example, the StockTracker demo with turkish user locale, ie. with VM > options "-Duser.country=TR -Duser.language=tr". You get: > Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError > at org.apache.pivot.wtk.Component.installThemeSkin(Component.java:737) > at org.apache.pivot.wtk.Window.(Window.java:393) > at org.apache.pivot.wtk.Window.(Window.java:388) > at > org.apache.pivot.tutorials.stocktracker.StockTrackerWindow.(StockTrackerWindow.java:135) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at > org.apache.pivot.wtkx.WTKXSerializer.processStartElement(WTKXSerializer.java:623) > at > org.apache.pivot.wtkx.WTKXSerializer.readObject(WTKXSerializer.java:455) > at > org.apache.pivot.wtkx.WTKXSerializer.readObject(WTKXSerializer.java:411) > at > org.apache.pivot.wtkx.WTKXSerializer.readObject(WTKXSerializer.java:398) > at > org.apache.pivot.wtkx.WTKXSerializer.readObject(WTKXSerializer.java:379) > at > org.apache.pivot.tutorials.stocktracker.StockTracker.startup(StockTracker.java:45) > at > org.apache.pivot.wtk.DesktopApplicationContext$HostFrame.processWindowEvent(DesktopApplicationContext.java:94) > at java.awt.Window.processEvent(Window.java:1820) > at java.awt.Component.dispatchEventImpl(Component.java:4630) > at java.awt.Container.dispatchEventImpl(Container.java:2099) > at java.awt.Window.dispatchEventImpl(Window.java:2475) > at java.awt.Component.dispatchEvent(Component.java:4460) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:599) > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) > Caused by: java.lang.IllegalArgumentException: No enum const class > org.apache.pivot.wtk.MessageType.QUESTİON > at java.lang.Enum.valueOf(Enum.java:196) > at org.apache.pivot.wtk.MessageType.valueOf(MessageType.java:22) > at > org.apache.pivot.wtk.skin.terra.TerraTheme.loadMessageIcons(TerraTheme.java:229) > at org.apache.pivot.wtk.skin.terra.TerraTheme.load(TerraTheme.java:201) > at > org.apache.pivot.wtk.skin.terra.TerraTheme.(TerraTheme.java:171) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at org.apache.pivot.util.Service.getProvider(Service.java:96) > at org.apache.pivot.wtk.Theme.(Theme.java:73) > ... 29 more > The reason is the use of toUpperCase() and toLowerCase() in various parts of > Pivot. Those parts should be changed to toUpperCase(Locale.US) / > toLowerCase(Locale.US), as discussed in PIVOT-486. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-625) Enable item deselection in list based controls (ListView, TableView, TreeView)
[ https://issues.apache.org/jira/browse/PIVOT-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-625. Assignee: Noel Grandin Fix Version/s: 2.0 Resolution: Fixed > Enable item deselection in list based controls (ListView, TableView, TreeView) > -- > > Key: PIVOT-625 > URL: https://issues.apache.org/jira/browse/PIVOT-625 > Project: Pivot > Issue Type: New Feature >Affects Versions: 1.5.1 >Reporter: A.J. >Assignee: Noel Grandin > Fix For: 2.0 > > > Add the ability for a user to deselect an item in a list based control > (ListView, TableView, TreeView). > Many applications, platforms and OS implement this behavior. > CMD+Click (Apple) or CTRL+Click (win/linux) is the usual accelerator for this. > related to post > http://www.mail-archive.com/u...@pivot.apache.org/msg01621.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-592) Add a TabPane#getTabAt() method that delegates to the skin
[ https://issues.apache.org/jira/browse/PIVOT-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905907#action_12905907 ] Noel Grandin commented on PIVOT-592: What was the reason for this request? TabPane.getTabs().get(int) seems to be easy enough? > Add a TabPane#getTabAt() method that delegates to the skin > -- > > Key: PIVOT-592 > URL: https://issues.apache.org/jira/browse/PIVOT-592 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Greg Brown >Priority: Minor > Fix For: 2.1 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-559) use a PivotStyle annotation to help identify style properties on objects
[
https://issues.apache.org/jira/browse/PIVOT-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905905#action_12905905
]
Noel Grandin commented on PIVOT-559:
I can't see the point of most of this.
AffectsPainting and AffectsLayout is mostly irrelevant to most developers.
There would have to be more compelling reasons to justify adding the overhead
of something like this to the code.
You don't need to do anything clever to find the styles on a component, you
just call Component#getStyles()
For an example of how this is done dynamically, look at
org.apache.pivot.tutorials.explorer.tools.ComponentStyleInspectorSkin
> use a PivotStyle annotation to help identify style properties on objects
>
>
> Key: PIVOT-559
> URL: https://issues.apache.org/jira/browse/PIVOT-559
> Project: Pivot
> Issue Type: Improvement
> Components: wtk
>Reporter: Appddevvv
>Priority: Minor
>
> Benefits:
> a) You can write a scanner to find styles and list them. This helps you avoid
> having to filter direct bean properties on skins to list styles and identify
> the canonical style.
> b) Helps both clients as well as developers understand the impact of this
> style on layout and painting.
> c) Helps you implement style stacks and preferences so you can pull styles
> from a skin and save them in preferences without pulling extraneous
> information from the skin or having to do clever property filtering.
> I can include an annotation scanner that returns a list of style annotations
> from a class if that helps although its quite trivial.
> Prototype is below:
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to you under the Apache License,
> * Version 2.0 (the "License"); you may not use this file except in
> * compliance with the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package org.apache.pivot.wtk;
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Inherited;
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> import java.lang.annotation.Target;
> /**
> * Indicates that a property is a pivot style and provides
> * useful information for drawing optimization and discovery.
> *
> *
> * By convention, the annotation should annotate the setter and not
> * a field or the getter. Java bean conventions suggests that the
> * setter takes one parameter. If more than one method with a similar name
> * exists in a class, but has a different setter parameter,
> * choose the setter with the most specific parameter and that
> * does not require a conversion internal to the class to use
> * e.g. choose the setter with the {...@code Paint} parameter instead
> * of the setter with the string parameter that has to be parsed
> * to create a {...@code Paint} object. Or if the same method name
> * can also take a {...@code Color} object but you use a {...@code Paint}
> * object in the implementation, still select the {...@code Paint}
> * object. It would be up to an external processor to decide
> * if other methods with the same name but different parameters
> * should be used instead.
> *
> */
> @Inherited
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.METHOD)
> public @interface PivotStyle {
> /**
>* When true, indicates this style requires a component invalidation
>* to force layout because the style affects the layout e.g. the size
>* of something.
>*/
> boolean affectsLayout() default true;
> /**
>* When true, indicates this style requires a repaint
>* if it is set because it affects painting.
>*/
> boolean affectsPainting() default true;
> /**
>* A description of the style.
>*/
> String description() default "";
> /**
>* The category of the style such as "Colors" or "Animation".
>* A category groups similar style properties together for
>* browsing convenience.
>*/
> String category() default "";
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-612) TextInput validator problem when modifying selected text
[
https://issues.apache.org/jira/browse/PIVOT-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noel Grandin resolved PIVOT-612.
Fix Version/s: 2.0
Resolution: Fixed
> TextInput validator problem when modifying selected text
>
>
> Key: PIVOT-612
> URL: https://issues.apache.org/jira/browse/PIVOT-612
> Project: Pivot
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: A.J.
> Fix For: 2.0
>
>
> I have a validator on a textinput with strict validation set to true;
> The validator tries to match the text against a pattern.
> Everything is fine until i try to modify text that is selected (either
> partially or completely).
> And this because validation does not take into account that selected text
> should be replaced by typed characters;
> instead, it is trying to validate the concatenation of the new character and
> the actual text instead of replacing the selected part of the text.
> (lines 1059-1063 in class TerraTextInputSkin)
> I don't know if I'm clear.
> Consider this (pretty stupid) example that tries to accept only one digit in
> the text input :
> TextInput textInput = new TextInput();
> textInput.setMaximumLength(1);
> textInput.setStrictValidation(true);
> textInput.setValidator(new Validator() {
> @Override
> public boolean isValid(String text) {
> if (text.length() == 0)
> return true; // ok we accept empty field
> return text.length() == 1 &&
> Character.isDigit(text.charAt(0));
> }
> });
>
> BoxPane boxPane = new BoxPane(Orientation.HORIZONTAL);
> boxPane.add(textInput);
> boxPane.add(new PushButton("Test"));
> window.setContent(boxPane);
> Steps:
> 1. start app.
> 2. put focus in textinput (should be empty)
> 3. enter a digit, ex : '5'; ok this should work
> 4. move focus on button then move focus back on textinput
> 5. text is selected in textinput
> 6. try to replace the selected value ('5') by another digit by simply typing
> it
> ==> doesnt work (while it should)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-611) add a method hasListener() in ListenerList object
[
https://issues.apache.org/jira/browse/PIVOT-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902764#action_12902764
]
Noel Grandin commented on PIVOT-611:
public boolean contains(T t) {}
would be the appropriate method to add
> add a method hasListener() in ListenerList object
> -
>
> Key: PIVOT-611
> URL: https://issues.apache.org/jira/browse/PIVOT-611
> Project: Pivot
> Issue Type: Improvement
>Affects Versions: 1.5
>Reporter: A.J.
>Priority: Minor
>
> there is no easy way to determine wether a listener has already been added to
> a listener list (except by getting an iterator and traversing the list).
> it would be convenient to have 'hasListener' method in the ListenerList class
> that encapsulates this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-602) Create BeanInfo classes for WTK components
[ https://issues.apache.org/jira/browse/PIVOT-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901002#action_12901002 ] Noel Grandin commented on PIVOT-602: Or, since we're already building our own bean infrastructure code in org.apache.pivot.beans perhaps we should be building custom logic into BeanAdapter for this sort of stuff, in which case we can build custom logic for introspecting our listener design ?? > Create BeanInfo classes for WTK components > -- > > Key: PIVOT-602 > URL: https://issues.apache.org/jira/browse/PIVOT-602 > Project: Pivot > Issue Type: New Feature > Components: wtk >Affects Versions: 2.0 >Reporter: Noel Grandin >Priority: Minor > > Create BeanInfo classes for the UI components to add make it easier to build > design tools around Pivot. > For example, the BeanInfo classes would tell the design tool which values are > valid for certain methods e.g. the methods that take enumerated values also > never permit null. > Unfortunately, there will be some limitations - we cannot represent the Pivot > listener pattern in the BeanInfo classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PIVOT-602) Create BeanInfo classes for WTK components
Create BeanInfo classes for WTK components -- Key: PIVOT-602 URL: https://issues.apache.org/jira/browse/PIVOT-602 Project: Pivot Issue Type: New Feature Components: wtk Affects Versions: 2.0 Reporter: Noel Grandin Priority: Minor Create BeanInfo classes for the UI components to add make it easier to build design tools around Pivot. For example, the BeanInfo classes would tell the design tool which values are valid for certain methods e.g. the methods that take enumerated values also never permit null. Unfortunately, there will be some limitations - we cannot represent the Pivot listener pattern in the BeanInfo classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-595) Add data binding support to Button
[ https://issues.apache.org/jira/browse/PIVOT-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-595. Assignee: Noel Grandin Resolution: Fixed > Add data binding support to Button > -- > > Key: PIVOT-595 > URL: https://issues.apache.org/jira/browse/PIVOT-595 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Greg Brown >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0 > > > Add a "buttonDataKey" and a mapping interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-287) Inconsistency between TableView, ListView, and TreeView as to when to consume arrow key events
[ https://issues.apache.org/jira/browse/PIVOT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-287. Assignee: Noel Grandin Resolution: Fixed Went with majority rules, made TreeView consume UP and DOWN > Inconsistency between TableView, ListView, and TreeView as to when to consume > arrow key events > -- > > Key: PIVOT-287 > URL: https://issues.apache.org/jira/browse/PIVOT-287 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 1.3 >Reporter: Todd Volkert >Assignee: Noel Grandin >Priority: Trivial > Fix For: 2.0 > > > TreeView consumes UP and DOWN only if it actually changed the selected index. > TableView and ListView always consume UP and DOWN. The result is that once > you've reached the top of a tree view, the nearest scroll pane ancestor > begins scrolling up, but the same does not happen with a table view or list > view. > Which way is correct? Whatever is decided should apply to all three > components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-536) WTKXSerializer 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:comment-tabpanel&focusedCommentId=12898893#action_12898893 ] Noel Grandin commented on PIVOT-536: As near as I can tell, all you need is an API to access xmlStreamReader.getLocation() which will give you the position of the parser at the time of the error. Is this sufficient? > WTKXSerializer 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 > > 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. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-28) Add tick marks to Slider component
[ https://issues.apache.org/jira/browse/PIVOT-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-28. --- Assignee: Noel Grandin Fix Version/s: 2.0 (was: 2.1) Resolution: Fixed > Add tick marks to Slider component > -- > > Key: PIVOT-28 > URL: https://issues.apache.org/jira/browse/PIVOT-28 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Greg Brown >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-477) Window and DesktopApplicationContext should support java.awt.Window.setIconImages() to display multi-resolution icons
[ https://issues.apache.org/jira/browse/PIVOT-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-477. Assignee: Noel Grandin Resolution: Fixed > Window and DesktopApplicationContext should support > java.awt.Window.setIconImages() to display multi-resolution icons > - > > Key: PIVOT-477 > URL: https://issues.apache.org/jira/browse/PIVOT-477 > Project: Pivot > Issue Type: Wish > Components: wtk >Reporter: Dirk Moebius >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0 > > > DesktopApplicationContext currently sets the Window icon into the host frame > using java.awt.Window.setIconImage(Image). However, since Java6 there's a new > method called setIconImages(List icons) to set multi-resolution icons, > e.g. you can set a 16x16 icon for the window title bar, a 48x48 icon to be > shown in Microsoft Windows' task switcher, or a 64x64 icon to be shown in > Windows Vista/7 Aero task list. (It is up to the runtime implementation to > choose an appropriate icon from the list provided by setIconImages().) > Without the possibility to set multi-resolution icons the OS scales the image > either up or down to fit the current environment. This might lead to poor > results. > Suggestion: add a new method setIconImages(List) method to > pivot.wtk.Window and, if set, use it in DesktopApplicationContext. Or maybe > add setIconPictures(List) to get around the issue of downcasting to > Picture in updateFrameTitleBar(). > Thanks, > Dirk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-506) Menu item renderer not given enough space
[ https://issues.apache.org/jira/browse/PIVOT-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893565#action_12893565 ] Noel Grandin commented on PIVOT-506: Seems to working in Pivot 2.0, Windows 7, JDK 1.6.0_18 > Menu item renderer not given enough space > - > > Key: PIVOT-506 > URL: https://issues.apache.org/jira/browse/PIVOT-506 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 1.5 >Reporter: Todd Volkert >Priority: Minor > Fix For: 2.0 > > Attachments: ContextMenuTest.png > > > See attached screenshot, taken from ContextMenuTest. The "w" in "New" is cut > off my one pixel on the right. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-509) Possible infinite loop in Component Explorer
[ https://issues.apache.org/jira/browse/PIVOT-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893566#action_12893566 ] Noel Grandin commented on PIVOT-509: Seems to working in Pivot 2.0, Windows 7, JDK 1.6.0_18 > Possible infinite loop in Component Explorer > > > Key: PIVOT-509 > URL: https://issues.apache.org/jira/browse/PIVOT-509 > Project: Pivot > Issue Type: Bug > Components: tools >Affects Versions: 1.5 >Reporter: Todd Volkert >Priority: Minor > Fix For: 2.0 > > > Steps to reproduce: > 1) Run the component explorer > 2) Open the activity indicator > 3) Change its "color" style using the color chooser button > Result: > Exception in thread "AWT-EventQueue-4" java.lang.StackOverflowError > at org.apache.pivot.wtk.Component.repaint(Component.java:2006) > at org.apache.pivot.wtk.Component.repaint(Component.java:2006) > at org.apache.pivot.wtk.Component.repaint(Component.java:2006) > at org.apache.pivot.wtk.Component.repaint(Component.java:2006) > at org.apache.pivot.wtk.Viewport.repaint(Viewport.java:167) > at org.apache.pivot.wtk.Component.repaint(Component.java:2006) > at org.apache.pivot.wtk.Component.repaint(Component.java:2006) > at org.apache.pivot.wtk.Component.repaint(Component.java:2006) > at org.apache.pivot.wtk.Component.repaint(Component.java:2006) > at org.apache.pivot.wtk.Component.repaint(Component.java:1942) > at org.apache.pivot.wtk.Component.repaint(Component.java:1933) > at > org.apache.pivot.wtk.skin.ComponentSkin.invalidateComponent(ComponentSkin.java:335) > at > org.apache.pivot.wtk.skin.ButtonSkin.buttonDataChanged(ButtonSkin.java:88) > at > org.apache.pivot.wtk.Button$ButtonListenerList.buttonDataChanged(Button.java:116) > at org.apache.pivot.wtk.Button.setButtonData(Button.java:269) > at > org.apache.pivot.wtk.skin.ColorChooserButtonSkin.selectedColorChanged(ColorChooserButtonSkin.java:306) > at > org.apache.pivot.wtk.ColorChooserButton$ColorChooserButtonSelectionListenerList.selectedColorChanged(ColorChooserButton.java:41) > at > org.apache.pivot.wtk.ColorChooserButton.setSelectedColor(ColorChooserButton.java:160) > at > org.apache.pivot.tools.wtk.ComponentInspectorSkin.updateColorControl(ComponentInspectorSkin.java:1306) > at > org.apache.pivot.tools.wtk.ComponentInspectorSkin.updateControl(ComponentInspectorSkin.java:215) > at > org.apache.pivot.tools.wtk.ComponentStyleInspectorSkin$1.styleUpdated(ComponentStyleInspectorSkin.java:31) > at > org.apache.pivot.wtk.Component$ComponentListenerList.styleUpdated(Component.java:334) > at org.apache.pivot.wtk.Component$StyleDictionary.put(Component.java:73) > at org.apache.pivot.wtk.Component$StyleDictionary.put(Component.java:56) > at > org.apache.pivot.tools.wtk.ComponentInspectorSkin$26.selectedColorChanged(ComponentInspectorSkin.java:1290) > at > org.apache.pivot.wtk.ColorChooserButton$ColorChooserButtonSelectionListenerList.selectedColorChanged(ColorChooserButton.java:41) > at > org.apache.pivot.wtk.ColorChooserButton.setSelectedColor(ColorChooserButton.java:160) > at > org.apache.pivot.tools.wtk.ComponentInspectorSkin.updateColorControl(ComponentInspectorSkin.java:1306) > at > org.apache.pivot.tools.wtk.ComponentInspectorSkin.updateControl(ComponentInspectorSkin.java:215) > .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-550) Optimize org.apache.pivot.wtk.text.TextNode
[ https://issues.apache.org/jira/browse/PIVOT-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-550. Assignee: Noel Grandin Resolution: Fixed > Optimize org.apache.pivot.wtk.text.TextNode > --- > > Key: PIVOT-550 > URL: https://issues.apache.org/jira/browse/PIVOT-550 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Greg Brown >Assignee: Noel Grandin >Priority: Minor > Fix For: 2.0 > > > Currently, this class uses a StringBuilder internally to manage text updates. > While this is efficient for constructing strings, TextNode is not as > efficient at handling strings that are not being modified: TextNode#getText() > calls toString() on the internal StringBuilder, which generates a new String > instance each time it is called. Since paint operations (which call > getText()) are likely to occur more often than changes to the text, this is > most likely producing a number of unnecessary heap allocations. > TextInput was recently updated to use a StringBuilder to construct new > Strings when changes are made, but it uses a String instance internally to > store the text property value. A similar approach could be taken in TextNode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-582) IllegalArgumentException : width is negative when using Form Heading
[
https://issues.apache.org/jira/browse/PIVOT-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noel Grandin resolved PIVOT-582.
Fix Version/s: 2.0
Resolution: Fixed
> IllegalArgumentException : width is negative when using Form Heading
>
>
> Key: PIVOT-582
> URL: https://issues.apache.org/jira/browse/PIVOT-582
> Project: Pivot
> Issue Type: Bug
> Components: wtk-terra
>Affects Versions: 1.5
> Environment: mac os x 10.6, java 6
>Reporter: A.J.
>Assignee: Noel Grandin
> Fix For: 2.0
>
>
> Receiving an exception "java.lang.IllegalArgumentException: width is
> negative." message when trying to add a heading in a Form container embedded
> within a Border > TabPane > SplitPane container hierarchy.
> Bug can be reproduced with the following wtkx :
>xmlns:wtkx="http://pivot.apache.org/wtkx";
> xmlns="org.apache.pivot.wtk">
>
>
>
>
>
>TabPane.label="Left Part">
>
>text="Left content" />
>
>
>
>
>
>
>
>
>TabPane.label="Right Part">
>
>
>styles="{showFirstSectionHeading:true}">
>
>
>Form.label="Some item">
>text="Some text"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
> removing the heading or turning it off with the "showFirstSectionHeading"
> style fixes the problem but this means headings cannot be used in the form.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (PIVOT-582) IllegalArgumentException : width is negative when using Form Heading
[
https://issues.apache.org/jira/browse/PIVOT-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noel Grandin reassigned PIVOT-582:
--
Assignee: Noel Grandin
> IllegalArgumentException : width is negative when using Form Heading
>
>
> Key: PIVOT-582
> URL: https://issues.apache.org/jira/browse/PIVOT-582
> Project: Pivot
> Issue Type: Bug
> Components: wtk-terra
>Affects Versions: 1.5
> Environment: mac os x 10.6, java 6
>Reporter: A.J.
>Assignee: Noel Grandin
>
> Receiving an exception "java.lang.IllegalArgumentException: width is
> negative." message when trying to add a heading in a Form container embedded
> within a Border > TabPane > SplitPane container hierarchy.
> Bug can be reproduced with the following wtkx :
>xmlns:wtkx="http://pivot.apache.org/wtkx";
> xmlns="org.apache.pivot.wtk">
>
>
>
>
>
>TabPane.label="Left Part">
>
>text="Left content" />
>
>
>
>
>
>
>
>
>TabPane.label="Right Part">
>
>
>styles="{showFirstSectionHeading:true}">
>
>
>Form.label="Some item">
>text="Some text"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
> removing the heading or turning it off with the "showFirstSectionHeading"
> style fixes the problem but this means headings cannot be used in the form.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-561) The Form.Section Heading is not displaying for the first Section of a Form.
[
https://issues.apache.org/jira/browse/PIVOT-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885298#action_12885298
]
Noel Grandin commented on PIVOT-561:
I tend to agree with Graeme - it may be typographically more elegant, but it's
definitely surprising behaviour.
> The Form.Section Heading is not displaying for the first Section of a Form.
> ---
>
> Key: PIVOT-561
> URL: https://issues.apache.org/jira/browse/PIVOT-561
> Project: Pivot
> Issue Type: Bug
> Components: wtk
>Affects Versions: 1.5
> Environment: Java Version 6 Update 18, Windows Vista SP2, Chrome and
> Internet Explorer 8
>Reporter: Graeme Collis
>
> The Form.Section Heading is not displaying for the first Section of a Form.
> Below is the xml from the "Component Explorer Example" :
> http://pivot.apache.org/demos/component-explorer.html
> The Form has 4 Sections each with a heading.
> The first Section heading, "Personal Information", is not displaying.
>
> All the other Section Headings are displaying.
>
>
>
> Full "wtkx"
> http://pivot.apache.org/wtkx";
> xmlns="org.apache.pivot.wtk">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Form.flag="{messageType:'info', message:'We won\'t spam
> you!'}"/>
>
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-549) Storing to fields with data binding doesn't work
[ https://issues.apache.org/jira/browse/PIVOT-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884282#action_12884282 ] Noel Grandin commented on PIVOT-549: Hi According to www.json.org, the tilde is a valid identifier character. Which spec are you using? In fact, pretty much anything except doublequote and backslash are valid characters in an identifier. -- Noel Grandin > Storing to fields with data binding doesn't work > > > Key: PIVOT-549 > URL: https://issues.apache.org/jira/browse/PIVOT-549 > Project: Pivot > Issue Type: Bug > Components: core-beans >Affects Versions: 1.5 >Reporter: Michael Allman > Attachments: Field_Bug.tgz > > > Pivot allows you to prefix a textKey attribute value with a "~" to indicate > that that property should be accessed via the object's field. Currently, it > doesn't work. When I try to do it, I get an IllegalArgumentException: > Illegal identifier character. > I'm attaching a test case Eclipse project. Run FieldBug, put some stuff in > the fields or not, and press "Store". You should see the exception. Set a > breakpoint on the JSON.split method and rerun the app in the debugger. Step > through and you'll see where the exception is being thrown. > Cheers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-535) Add a @MessageListener annotation and an annotation processor for application context message listener
[ https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880607#action_12880607 ] Noel Grandin commented on PIVOT-535: See (some parts of) the earlier discussion we had about weak listeners here: http://www.mail-archive.com/pivot-...@incubator.apache.org/msg03847.html Bottom line is that weak listeners are a bad idea. > Add a @MessageListener annotation and an annotation processor for application > context message listener > -- > > Key: PIVOT-535 > URL: https://issues.apache.org/jira/browse/PIVOT-535 > Project: Pivot > Issue Type: Improvement >Reporter: Appddevvv > > Add a message listener annotation and a static method for annotation > processing to automatically enroll instance/methods in application message > handling. > I have the classes that I can submit as a starting point. They allow weak and > strong references as well as optional request-reply semantics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-515) org.apache.pivot.collections.ArrayList bounds checking issue
[
https://issues.apache.org/jira/browse/PIVOT-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noel Grandin resolved PIVOT-515.
Resolution: Fixed
> org.apache.pivot.collections.ArrayList bounds checking issue
>
>
> Key: PIVOT-515
> URL: https://issues.apache.org/jira/browse/PIVOT-515
> Project: Pivot
> Issue Type: Bug
> Components: core-collections
>Affects Versions: 1.5
> Environment: Java(TM) SE Runtime Environment (build 1.6.0_19-b04) MS
> Windows XP x64 SP2
>Reporter: Chris Bartlett
>Assignee: Noel Grandin
>Priority: Minor
> Fix For: 1.6
>
> Attachments: ListTest.zip
>
>
> Bounds checking on ArrayList fails under certain circumstances.
> Appears to happen when add() and/or insert() methods of ArrayList are used,
> and not when data is passed to a constructor
> jUnit test demonstrating the issue will be attached in a follow up post.
> public void simpleTest() {
> org.apache.pivot.collections.List pivot1 = new
> org.apache.pivot.collections.ArrayList("A", "B", "C");
> // Throws java.lang.IndexOutOfBoundsException
> pivot1.get(3);
> org.apache.pivot.collections.List pivot2 = new
> org.apache.pivot.collections.ArrayList();
> // Returns null
> System.out.println(pivot2.get(0));
> pivot2.add("A");
> pivot2.add("B");
> pivot2.add("C");
> // Returns null
> System.out.println(pivot2.get(3));
> java.util.List java = new java.util.ArrayList();
> // Throws java.lang.IndexOutOfBoundsException
> java.get(0);
> java.add("A");
> java.add("B");
> java.add("C");
> // Throws java.lang.IndexOutOfBoundsException
> java.get(3);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-512) Add support for line item tooltips in data-driven components
[ https://issues.apache.org/jira/browse/PIVOT-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875067#action_12875067 ] Noel Grandin commented on PIVOT-512: Aaah, I seem what you mean. Yes, that does sound better. However, I still think we're going to need a way of generating tooltip text that is separate from toString(Object), even if it falls back to toString(Object) in the default case. My tooltips are frequently quite a lot more verbose than the items that they are associated with. > Add support for line item tooltips in data-driven components > > > Key: PIVOT-512 > URL: https://issues.apache.org/jira/browse/PIVOT-512 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Greg Brown >Priority: Minor > Fix For: 1.6 > > > When enabled, the skin would use the toString() method of the renderer to > determine an appropriate tooltip for the item. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-512) Add support for line item tooltips in data-driven components
[ https://issues.apache.org/jira/browse/PIVOT-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874990#action_12874990 ] Noel Grandin commented on PIVOT-512: I find toString() tricky to use because it's not always possible to override the renderer's method, particularly if you're using someone else's renderer. I would prefer if we used some kind of function object to convert data items to strings for use in the tooltips. > Add support for line item tooltips in data-driven components > > > Key: PIVOT-512 > URL: https://issues.apache.org/jira/browse/PIVOT-512 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Greg Brown >Priority: Minor > Fix For: 1.6 > > > When enabled, the skin would use the toString() method of the renderer to > determine an appropriate tooltip for the item. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-500) JNLP demos that use signed JARs fail to launch
[ https://issues.apache.org/jira/browse/PIVOT-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869711#action_12869711 ] Noel Grandin commented on PIVOT-500: Are you using the JNLP compressor? I seem to remember there is some weird interaction between the two, which requires an extra step in the build process. I'll try and dig it out of my old project build files tomorrow. > JNLP demos that use signed JARs fail to launch > -- > > Key: PIVOT-500 > URL: https://issues.apache.org/jira/browse/PIVOT-500 > Project: Pivot > Issue Type: Bug > Components: demos >Reporter: Greg Brown >Priority: Minor > Fix For: 1.5 > > > The exception in the Web Start console doesn't offer much help: > java.lang.NullPointerException > at > java.util.jar.JarVerifier.mapSignersToCodeSource(JarVerifier.java:497) > at > java.util.jar.JarVerifier.mapSignersToCodeSources(JarVerifier.java:509) > at java.util.jar.JarVerifier.getCodeSources(JarVerifier.java:827) > at java.util.jar.JarFile.getCodeSources(JarFile.java:622) > at > java.util.jar.JavaUtilJarAccessImpl.getCodeSources(JavaUtilJarAccessImpl.java:25) > at > com.sun.deploy.cache.DeployCacheJarAccessImpl.getCodeSources(DeployCacheJarAccessImpl.java:60) > at > com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(SigningInfo.java:382) > at com.sun.javaws.security.SigningInfo.check(SigningInfo.java:291) > at > com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(LaunchDownload.java:1498) > at > com.sun.javaws.LaunchDownload.checkSignedResources(LaunchDownload.java:1268) > at com.sun.javaws.Launcher.prepareResources(Launcher.java:1222) > at com.sun.javaws.Launcher.prepareAllResources(Launcher.java:624) > at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:332) > at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:204) > at com.sun.javaws.Launcher.launch(Launcher.java:121) > at com.sun.javaws.Main.launchApp(Main.java:418) > at com.sun.javaws.Main.continueInSecureThread(Main.java:255) > at com.sun.javaws.Main$1.run(Main.java:115) > at java.lang.Thread.run(Thread.java:637) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-31) Add rich text support to TextArea
[ https://issues.apache.org/jira/browse/PIVOT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868682#action_12868682 ] Noel Grandin commented on PIVOT-31: --- Greg, that's fine by me. WRT the ComponentNode use-case you mentioned, that sounds potentially very useful, but it brings some interesting problems Problem 1 -- It means that the Document model is no longer share-able between multiple TextArea instances, because the Component will need to get inserted into the TextArea's containment hierarchy. I don't see it as a real problem, it's just something that will need to get noted in the docs and checked for (with nice exceptions) in the code. Problem 2 -- Keyboard/mouse/focus interaction is going to be "interesting" with editable documents and live components, and will likely lead to some surprising results when people stick Components into their documents. I'm inclined to say that we should enforce that we only support live components in documents in non-editable TextArea's. > Add rich text support to TextArea > - > > Key: PIVOT-31 > URL: https://issues.apache.org/jira/browse/PIVOT-31 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Greg Brown >Assignee: Greg Brown > Fix For: 1.6 > > Attachments: patch.txt, patch.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (PIVOT-31) Add rich text support to TextArea
[ https://issues.apache.org/jira/browse/PIVOT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin updated PIVOT-31: -- Attachment: patch.txt My patch now implements text fonts, foreground and background colors successfully. The next logical step would be to support the stuff from java.awt.font.TextAttribute like UNDERLINE, SUPERSCRIPT, etc. However, that would require some more drastic changes to our painting strategy i.e. we would have to either (a) figure out how to paint these things ourselves (b) delegate the painting to the java.awt.font.TextLayout class and drop our optimised font-glyph painting strategy. > Add rich text support to TextArea > - > > Key: PIVOT-31 > URL: https://issues.apache.org/jira/browse/PIVOT-31 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Greg Brown >Assignee: Greg Brown > Fix For: 1.6 > > Attachments: patch.txt, patch.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-31) Add rich text support to TextArea
[ https://issues.apache.org/jira/browse/PIVOT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868532#action_12868532 ] Noel Grandin commented on PIVOT-31: --- Thanks Greg, I have no pressing need for this functionality, just thought I'd see what would be involved in solving this issue. It seemed pertinent because we've had a number of requests for simple styled text on the mailing list lately, and this could resolve those requests. My solution would look something like this: (1) copy TextArea to RichTextArea (2) continue with making TextArea a simple, non-styled, optimised widget (3) add styling features gradually to RichTextArea, as they become necessary I'm convinced that we can hit a sweet spot of functionality with only a small amount of effort - although people keep saying they want an HTML rendering widget, or a really fancy rich-text widget, in my experience, fonts and colours alone will cover 99% of the use cases out there. > Add rich text support to TextArea > - > > Key: PIVOT-31 > URL: https://issues.apache.org/jira/browse/PIVOT-31 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Greg Brown >Assignee: Greg Brown > Attachments: patch.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (PIVOT-31) Add rich text support to TextArea
[ https://issues.apache.org/jira/browse/PIVOT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin updated PIVOT-31: -- Attachment: patch.txt Proof-of-concept patch. Implemented the most simple thing I could think of - adding a Font property to the Element class. Seems to work OK. > Add rich text support to TextArea > - > > Key: PIVOT-31 > URL: https://issues.apache.org/jira/browse/PIVOT-31 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Greg Brown >Assignee: Greg Brown > Attachments: patch.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-31) Add rich text support to TextArea
[ https://issues.apache.org/jira/browse/PIVOT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868294#action_12868294 ] Noel Grandin commented on PIVOT-31: --- What would constitute a good beginning for rich-text support? i.e.what features would be the minimum set that would be useful? I'm asking because i'm looking through the text code, and it doesn't look hard to add some basic stuff like different fonts and background/foreground colors. Obviously tables, etc. are a whole different ball of wax, but I think we could deliver something reasonably useful without much effort, given how good the existing TextArea infra-structure is. > Add rich text support to TextArea > - > > Key: PIVOT-31 > URL: https://issues.apache.org/jira/browse/PIVOT-31 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Greg Brown >Assignee: Greg Brown > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-380) Effects \ Blur doesn't take all image pixels
[ https://issues.apache.org/jira/browse/PIVOT-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864324#action_12864324 ] Noel Grandin commented on PIVOT-380: This appears to be a limitation of java.awt.image.ConvolveOp, since it does not apply the Kernel at the edges. It could probably be worked around by creating a temporary image with a 1-pixel border, running blur on the input image into the temporary image, and then clipping the temp image before writing to the output. > Effects \ Blur doesn't take all image pixels > > > Key: PIVOT-380 > URL: https://issues.apache.org/jira/browse/PIVOT-380 > Project: Pivot > Issue Type: Bug > Components: wtk-effects >Affects Versions: 1.4 >Reporter: Sandro Martini >Priority: Minor > Fix For: 2.1 > > > Effects \ Blur doesn't take all image pixels, leaving a 1 pixel border > without effect at any image, probably this is a little defect. > To show this, look at the Tutorial page that uses this effect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-371) Support word navigation in TextInput and TextArea
[ https://issues.apache.org/jira/browse/PIVOT-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-371. Fix Version/s: 1.5 (was: 1.5.1) Resolution: Fixed Only updated TextArea, since TextInput is already has this logic > Support word navigation in TextInput and TextArea > - > > Key: PIVOT-371 > URL: https://issues.apache.org/jira/browse/PIVOT-371 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Greg Brown >Assignee: Noel Grandin >Priority: Minor > Fix For: 1.5 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (PIVOT-371) Support word navigation in TextInput and TextArea
[ https://issues.apache.org/jira/browse/PIVOT-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin reassigned PIVOT-371: -- Assignee: Noel Grandin > Support word navigation in TextInput and TextArea > - > > Key: PIVOT-371 > URL: https://issues.apache.org/jira/browse/PIVOT-371 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Greg Brown >Assignee: Noel Grandin >Priority: Minor > Fix For: 1.5.1 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (PIVOT-419) Add Ability to Add tooltipText for Tabs in a TabPane.
[ https://issues.apache.org/jira/browse/PIVOT-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin reassigned PIVOT-419: -- Assignee: Noel Grandin > Add Ability to Add tooltipText for Tabs in a TabPane. > - > > Key: PIVOT-419 > URL: https://issues.apache.org/jira/browse/PIVOT-419 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Scott Baxter >Assignee: Noel Grandin >Priority: Minor > Fix For: 1.5 > > > It is requested that the ability to set tooltipText (just like icons and > labels) be added for each tab in a TabPane. This would be most useful in > space constrained interfaces where there is only enough room on each tab to > display an icon (or a minimal label), but further explanation of what is on > the tab would be useful to the user in order to know which tab to select. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-419) Add Ability to Add tooltipText for Tabs in a TabPane.
[ https://issues.apache.org/jira/browse/PIVOT-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin resolved PIVOT-419. Fix Version/s: 1.5 (was: 2.0) Resolution: Fixed > Add Ability to Add tooltipText for Tabs in a TabPane. > - > > Key: PIVOT-419 > URL: https://issues.apache.org/jira/browse/PIVOT-419 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Scott Baxter >Assignee: Noel Grandin >Priority: Minor > Fix For: 1.5 > > > It is requested that the ability to set tooltipText (just like icons and > labels) be added for each tab in a TabPane. This would be most useful in > space constrained interfaces where there is only enough room on each tab to > display an icon (or a minimal label), but further explanation of what is on > the tab would be useful to the user in order to know which tab to select. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-331) Form's vertical spacing should be baseline-aware
[ https://issues.apache.org/jira/browse/PIVOT-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864295#action_12864295 ] Noel Grandin commented on PIVOT-331: Looking at this again, I can see some very elegant solutions. But perhaps, given that this use-case is not going to be that common, we can simply support the brute-force approach of allowing the designer to set a verticalSpacing style on each individual Form.Field? Then the designer would be free to apply the necessary corrections to only those fields that needed it. Perhaps not the most elegant solution, but it has the benefit of simplicity :-) > Form's vertical spacing should be baseline-aware > > > Key: PIVOT-331 > URL: https://issues.apache.org/jira/browse/PIVOT-331 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Todd Volkert >Priority: Minor > Fix For: 2.0 > > Attachments: form-layout-mockup.png, screenshot-before-and-after.png > > > Graphic designers often want to lay out forms such that the vertical spacing > between the baselines of the form elements is predictable. Though Pivot's > Form can now align the baselines of its fields with their labels, it provides > no way to coordinate the vertical spacing of the baselines. Take, for > example, the following WTKX: > xmlns:wtkx="http://pivot.apache.org/wtkx"; > xmlns="org.apache.pivot.wtk"> > > > > > > > > > > > > > > > > It produces the attached screenshot, where the vertical spacing between the > baselines is unpredictable, even though the form's "verticalSpacing" style is > evenly applied. Contrast this with the attached mockup provided by a graphic > designer, where they clearly specify the layout in terms of spacing between > baselines. > It's not clear how best to achieve this feature from an architectural point > of view. Ideas are welcome in this ticket. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-473) Add support for true size limits, rather than preferred size limits
[ https://issues.apache.org/jira/browse/PIVOT-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864291#action_12864291 ] Noel Grandin commented on PIVOT-473: See also PIVOT-433. This is going to have similar problems where the true-size limits will conflict with relative-sizing type layouts. We should define one consistent approach to resolving these conflicts so we have one set of rules for handling the conflicts everywhere. > Add support for true size limits, rather than preferred size limits > --- > > Key: PIVOT-473 > URL: https://issues.apache.org/jira/browse/PIVOT-473 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Greg Brown > Fix For: 2.0 > > > Preferred size limits don't take constraints into account. Replace them with > true size limits that will be respected by containers that are capable of > doing so. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (PIVOT-381) Handle Home and End keys in TextArea, as in TextInput
[ https://issues.apache.org/jira/browse/PIVOT-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noel Grandin reassigned PIVOT-381: -- Assignee: Noel Grandin > Handle Home and End keys in TextArea, as in TextInput > - > > Key: PIVOT-381 > URL: https://issues.apache.org/jira/browse/PIVOT-381 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 1.4 >Reporter: Sandro Martini >Assignee: Noel Grandin >Priority: Minor > Fix For: 1.5 > > > In TextArea, handle Home and End keys and maybe also Home and > End ... as currently done in TextInput. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
