[jira] [Commented] (PIVOT-1007) Allow Ctrl-Tab and Ctrl-Shift-Tab to switch among panes of TabPane container
[ https://issues.apache.org/jira/browse/PIVOT-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16188964#comment-16188964 ] Roger Whitcomb commented on PIVOT-1007: --- Okay, implemented this feature, along with some updates to EnumSet and Keyboard to add supporting code: Sendingcore\src\org\apache\pivot\collections\EnumSet.java Sendingwtk\src\org\apache\pivot\wtk\Keyboard.java Sendingwtk\src\org\apache\pivot\wtk\skin\ComponentSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTabPaneSkin.java Transmitting file data done Committing transaction... Committed revision 1810613. Diff is attached as 1007.patch. > Allow Ctrl-Tab and Ctrl-Shift-Tab to switch among panes of TabPane container > > > Key: PIVOT-1007 > URL: https://issues.apache.org/jira/browse/PIVOT-1007 > Project: Pivot > Issue Type: Improvement > Components: wtk-terra >Affects Versions: 2.1, 2.0.5 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > Many "MDI-style" components (like TabPane) allow Ctrl/Cmd-Tab and Shift-Tab > to select among the components. This would be easy to do in TabPane as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-971) Add the ability to have tri-state checkboxes in ListView
[ https://issues.apache.org/jira/browse/PIVOT-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159091#comment-16159091 ] Roger Whitcomb commented on PIVOT-971: -- Need a test/demo application for this before closing the issue. > Add the ability to have tri-state checkboxes in ListView > > > Key: PIVOT-971 > URL: https://issues.apache.org/jira/browse/PIVOT-971 > Project: Pivot > Issue Type: New Feature > Components: wtk, wtk-terra >Affects Versions: 2.0.4 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Labels: listview > Fix For: 2.1 > > Attachments: listview.diffs, tri-state listview.png > > > For one place in our application, a ListView is used along with checkboxes, > but it seems like it would be good to be able to use tri-state checkboxes > here, such that a mixed state could be indicated for some entries. But, then > the question becomes: if the checkbox is mixed, is it checked or not? Two > thoughts on that: > 1. Add a method to get the checkbox state for all items, so you can check > yourself if they are checked, unchecked or mixed. > 2. Add a property "mixedAreChecked", which if set true (default false) would > make the mixed state entries show up as checked. > Also, how do you set the "mixed" state for an item? Not sure about that yet. > Altogether: lots of implications throughout the code to support this feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-995) Second "open" of Prompt or Alert will not display the message type icon.
[ https://issues.apache.org/jira/browse/PIVOT-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-995. > Second "open" of Prompt or Alert will not display the message type icon. > - > > Key: PIVOT-995 > URL: https://issues.apache.org/jira/browse/PIVOT-995 > Project: Pivot > Issue Type: Bug > Components: wtk-terra >Affects Versions: 2.0.4, 2.1 >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1, 2.0.5 > > Attachments: prompt.patch > > > Define a Prompt (as in a "bxml:define" block in a BXML file), then invoke it > twice from within an application but without reloading it. The second and > subsequent times the Prompt is displayed the message type icon will not be > displayed; only the first time. > The reason is the "sheetClosed" listener is clearing the "typeImageView" but > it is not reloaded again for the second "open()" call. > The attached "prompt.patch" fixes this issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-993) Apache Pivot does not work with Oracle JDK8u131
[
https://issues.apache.org/jira/browse/PIVOT-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Whitcomb closed PIVOT-993.
> Apache Pivot does not work with Oracle JDK8u131
> ---
>
> Key: PIVOT-993
> URL: https://issues.apache.org/jira/browse/PIVOT-993
> Project: Pivot
> Issue Type: Bug
> Components: all
>Affects Versions: 2.0.4
> Environment: java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>Reporter: Andres Almiray
>Assignee: Roger Whitcomb
>Priority: Critical
> Fix For: 2.1, 2.0.5
>
>
> Attempting to run a Pivot application with Oracle JDK8u131 results in the
> following stacktrace
> {code}
> Caused by: java.lang.NumberFormatException: Value out of range. Value:"131"
> Radix:10
> at java.lang.Byte.parseByte(Byte.java:151)
> at java.lang.Byte.parseByte(Byte.java:175)
> at org.apache.pivot.util.Version.decode(Version.java:150)
> at
> org.apache.pivot.wtk.ApplicationContext.(ApplicationContext.java:1697)
> ... 15 more
> {code}
> The problem is located in the `Version` class. This class parses version
> numbers using Byte. 131 is clearly out of range. Should use `Short` or
> `Integer` instead.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (PIVOT-821) Add support for Shift-Ins to do a Paste on Windows
[ https://issues.apache.org/jira/browse/PIVOT-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-821. > Add support for Shift-Ins to do a Paste on Windows > -- > > Key: PIVOT-821 > URL: https://issues.apache.org/jira/browse/PIVOT-821 > Project: Pivot > Issue Type: Improvement > Components: wtk-terra >Affects Versions: 2.0.1 > Environment: Windows XP SP3, JDK 1.6.0_16 >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Trivial > Labels: paste > Fix For: 2.0.1 > > Attachments: insert.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Standard Windows OS conventions allow Shift-INS to do a Paste operation (as > well as Ctrl-V). Windows users expect to be able to use this keyboard > shortcut and consider it a bug if it does not work. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PIVOT-1005) TextPane Cut and Paste always add a trailing newline to the text
[ https://issues.apache.org/jira/browse/PIVOT-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-1005: -- Description: If you select some text in a TextPane and Cut it, then paste into another text editor you will see that the text has a trailing newline, regardless of whether the selected text included the end of line or not. Similarly, select some random text in another application and Paste into a TextPane and a new paragraph will always be entered, regardless of whether the original text had a newline or not. This is due to PlainTextSerializer (used for all these operations) always creates a Document, which always has the text enclosed in a Paragraph (which implicitly contains a newline at the end). Note: Copy does not have the same problem (any more). was: If you select some text in a TextPane and Cut or Copy it, then paste into another text editor you will see that the text has a trailing newline, regardless of whether the selected text included the end of line or not. Similarly, select some random text in another application and Paste into a TextPane and a new paragraph will always be entered, regardless of whether the original text had a newline or not. This is due to PlainTextSerializer (used for all these operations) always creates a Document, which always has the text enclosed in a Paragraph (which implicitly contains a newline at the end). Summary: TextPane Cut and Paste always add a trailing newline to the text (was: TextPane Cut, Copy and Paste always add a trailing newline to the text) > TextPane Cut and Paste always add a trailing newline to the text > > > Key: PIVOT-1005 > URL: https://issues.apache.org/jira/browse/PIVOT-1005 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.1, 2.0.5 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > > If you select some text in a TextPane and Cut it, then paste into another > text editor you will see that the text has a trailing newline, regardless of > whether the selected text included the end of line or not. Similarly, select > some random text in another application and Paste into a TextPane and a new > paragraph will always be entered, regardless of whether the original text had > a newline or not. > This is due to PlainTextSerializer (used for all these operations) always > creates a Document, which always has the text enclosed in a Paragraph (which > implicitly contains a newline at the end). > Note: Copy does not have the same problem (any more). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-996) Unable to run with SAP JVM
[ https://issues.apache.org/jira/browse/PIVOT-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-996. Assignee: Roger Whitcomb (was: Sandro Martini) > Unable to run with SAP JVM > -- > > Key: PIVOT-996 > URL: https://issues.apache.org/jira/browse/PIVOT-996 > Project: Pivot > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Sandro Martini >Assignee: Roger Whitcomb > Fix For: 2.0.5, 2.1.0 > > > As reported in our Dev mailing list, the check on JVM version that we do > doesn't work with JVM different than Oracle Java. > For example the SAP JVM with version "8.1.028 25.51-b14" generates the > problem, which is blocking. > The discussion thread is visible for example > [here](http://apache-pivot-developers.417237.n3.nabble.com/Issue-in-Version-decode-with-SAPJVM-td4027425.html). > We should check if log a warning and continue the execution, or parse > anything after he major.minor.patch as a string ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PIVOT-1005) TextPane Cut, Copy and Paste always add a trailing newline to the text
Roger Whitcomb created PIVOT-1005: - Summary: TextPane Cut, Copy and Paste always add a trailing newline to the text Key: PIVOT-1005 URL: https://issues.apache.org/jira/browse/PIVOT-1005 Project: Pivot Issue Type: Bug Components: wtk Affects Versions: 2.0.5, 2.1 Environment: All Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor If you select some text in a TextPane and Cut or Copy it, then paste into another text editor you will see that the text has a trailing newline, regardless of whether the selected text included the end of line or not. Similarly, select some random text in another application and Paste into a TextPane and a new paragraph will always be entered, regardless of whether the original text had a newline or not. This is due to PlainTextSerializer (used for all these operations) always creates a Document, which always has the text enclosed in a Paragraph (which implicitly contains a newline at the end). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1005) TextPane Cut, Copy and Paste always add a trailing newline to the text
[ https://issues.apache.org/jira/browse/PIVOT-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159160#comment-16159160 ] Roger Whitcomb commented on PIVOT-1005: --- Related to PIVOT-992 which is a similar issue for "getSelectedText()". > TextPane Cut, Copy and Paste always add a trailing newline to the text > -- > > Key: PIVOT-1005 > URL: https://issues.apache.org/jira/browse/PIVOT-1005 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.1, 2.0.5 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > > If you select some text in a TextPane and Cut or Copy it, then paste into > another text editor you will see that the text has a trailing newline, > regardless of whether the selected text included the end of line or not. > Similarly, select some random text in another application and Paste into a > TextPane and a new paragraph will always be entered, regardless of whether > the original text had a newline or not. > This is due to PlainTextSerializer (used for all these operations) always > creates a Document, which always has the text enclosed in a Paragraph (which > implicitly contains a newline at the end). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-960) Implement simple macro system in JSONSerializer
[ https://issues.apache.org/jira/browse/PIVOT-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-960. Resolution: Fixed > Implement simple macro system in JSONSerializer > --- > > Key: PIVOT-960 > URL: https://issues.apache.org/jira/browse/PIVOT-960 > Project: Pivot > Issue Type: Improvement > Components: core-json >Affects Versions: 2.0.4 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > Attachments: 960.patch > > > It occurred to me since we are using JSON style sheets to style our > application, and it is getting quite big, that a macro system (maybe similar > to C/C++ with #define or something similar) would be useful, especially for > repeated colors, and other constants (like padding values, fonts, etc.) This > would enable using custom values consistently while avoiding inconsistencies > due to typos or changes introduced one place and not others. > I was thinking of a simple > #define NAME value > as in C/C++, and then using $(NAME) as the substitution token. This is > easily implemented in JSONSerializer. > I'm open to suggestions for the syntax, but I believe the feature will be > very useful, especially for the JSON stylesheet. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1005) TextPane Cut and Paste always add a trailing newline to the text
[ https://issues.apache.org/jira/browse/PIVOT-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159549#comment-16159549 ] Roger Whitcomb commented on PIVOT-1005: --- For components or images none of this is going to work! > TextPane Cut and Paste always add a trailing newline to the text > > > Key: PIVOT-1005 > URL: https://issues.apache.org/jira/browse/PIVOT-1005 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.1, 2.0.5 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > > If you select some text in a TextPane and Cut it, then paste into another > text editor you will see that the text has a trailing newline, regardless of > whether the selected text included the end of line or not. Similarly, select > some random text in another application and Paste into a TextPane and a new > paragraph will always be entered, regardless of whether the original text had > a newline or not. > This is due to PlainTextSerializer (used for all these operations) always > creates a Document, which always has the text enclosed in a Paragraph (which > implicitly contains a newline at the end). > Note: Copy does not have the same problem (any more). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1005) TextPane Cut and Paste always add a trailing newline to the text
[ https://issues.apache.org/jira/browse/PIVOT-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163137#comment-16163137 ] Roger Whitcomb commented on PIVOT-1005: --- Fix the deletion of paragraph terminator, although other problems remain: Sendingwtk\src\org\apache\pivot\wtk\TextPane.java Transmitting file data .done Committing transaction... Committed revision 1808126. > TextPane Cut and Paste always add a trailing newline to the text > > > Key: PIVOT-1005 > URL: https://issues.apache.org/jira/browse/PIVOT-1005 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.1, 2.0.5 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > > If you select some text in a TextPane and Cut it, then paste into another > text editor you will see that the text has a trailing newline, regardless of > whether the selected text included the end of line or not. Similarly, select > some random text in another application and Paste into a TextPane and a new > paragraph will always be entered, regardless of whether the original text had > a newline or not. > This is due to PlainTextSerializer (used for all these operations) always > creates a Document, which always has the text enclosed in a Paragraph (which > implicitly contains a newline at the end). > Note: Copy does not have the same problem (any more). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PIVOT-610) Accordion & TabPane keyboard navigation using COMMAND+n only works if the current Pane/Tab contains a focusable Component
[ https://issues.apache.org/jira/browse/PIVOT-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-610: Assignee: Roger Whitcomb (was: Chris Bartlett) > Accordion & TabPane keyboard navigation using COMMAND+n only works if the > current Pane/Tab contains a focusable Component > - > > Key: PIVOT-610 > URL: https://issues.apache.org/jira/browse/PIVOT-610 > Project: Pivot > Issue Type: Bug > Components: wtk, wtk-terra >Affects Versions: 1.5.1 > Environment: n/a >Reporter: Chris Bartlett >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.5 > > > Users can navigate around the panes/tabs of Accordion and TabPane by pressing > the system specific command modifer key plus a number from 1 to 9. > On MS Windows this would mean CTRL+1 to CTRL+9 selecting the 1st to 9th > pane/tab respectively. > These keypresses are only processed if a child component of the container has > focus. > A TabPane might have 2 Tabs > Tab 1 - contains an enabled TextInput > Tab 2 - contains an enabled Label > If the TextInput on Tab 1 has focus, it is possible to change to Tab 2 by > pressing CTRL+2, but once there, it is not possible to get back to the Tab 1 > by pressing CTRL+1. > This is because Labels are not focusable, and by default Pivot Containers are > not focusable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (PIVOT-990) MenuPopup can overflow off the top of the window
[ https://issues.apache.org/jira/browse/PIVOT-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reopened PIVOT-990: -- > MenuPopup can overflow off the top of the window > > > Key: PIVOT-990 > URL: https://issues.apache.org/jira/browse/PIVOT-990 > Project: Pivot > Issue Type: Bug > Components: wtk-terra >Affects Versions: 2.0.4, 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1, 2.0.5 > > Attachments: 990.patch, menu_popup_cut_off.png, menu_popup_fixed.png > > > If the window / display size is small (either height [usually] or width), a > tall or wide MenuPopup will be positioned either off the top or off the left > of the window and you cannot see the top/left of the menu. This is > particularly a problem with the height because you cannot see the menu items > that are positioned outside the window, and so you cannot properly select > them. > The solution is to limit the border size in these cases, so that the Panorama > that surrounds the menu list will automatically come into play and allow the > menu to be scrolled into view. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PIVOT-990) MenuPopup can overflow off the top of the window
[ https://issues.apache.org/jira/browse/PIVOT-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-990: - Attachment: menu2.png Example of a long menu where y + height is greater than window height, so the menu goes too high up and is cut off. > MenuPopup can overflow off the top of the window > > > Key: PIVOT-990 > URL: https://issues.apache.org/jira/browse/PIVOT-990 > Project: Pivot > Issue Type: Bug > Components: wtk-terra >Affects Versions: 2.0.4, 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1, 2.0.5 > > Attachments: 990.patch, menu2.png, menu_popup_cut_off.png, > menu_popup_fixed.png > > > If the window / display size is small (either height [usually] or width), a > tall or wide MenuPopup will be positioned either off the top or off the left > of the window and you cannot see the top/left of the menu. This is > particularly a problem with the height because you cannot see the menu items > that are positioned outside the window, and so you cannot properly select > them. > The solution is to limit the border size in these cases, so that the Panorama > that surrounds the menu list will automatically come into play and allow the > menu to be scrolled into view. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-990) MenuPopup can overflow off the top of the window
[ https://issues.apache.org/jira/browse/PIVOT-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16188431#comment-16188431 ] Roger Whitcomb commented on PIVOT-990: -- Still an issue with (probably) the second code path. See attached "menu2.png". > MenuPopup can overflow off the top of the window > > > Key: PIVOT-990 > URL: https://issues.apache.org/jira/browse/PIVOT-990 > Project: Pivot > Issue Type: Bug > Components: wtk-terra >Affects Versions: 2.0.4, 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1, 2.0.5 > > Attachments: 990.patch, menu_popup_cut_off.png, menu_popup_fixed.png > > > If the window / display size is small (either height [usually] or width), a > tall or wide MenuPopup will be positioned either off the top or off the left > of the window and you cannot see the top/left of the menu. This is > particularly a problem with the height because you cannot see the menu items > that are positioned outside the window, and so you cannot properly select > them. > The solution is to limit the border size in these cases, so that the Panorama > that surrounds the menu list will automatically come into play and allow the > menu to be scrolled into view. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (PIVOT-990) MenuPopup can overflow off the top of the window
[
https://issues.apache.org/jira/browse/PIVOT-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16188435#comment-16188435
]
Roger Whitcomb edited comment on PIVOT-990 at 10/2/17 5:24 PM:
---
Example ("menu2.png") of a long menu where y + height is greater than window
height, so the menu goes too high up and is cut off.
was (Author: rwhitcomb):
Example of a long menu where y + height is greater than window height, so the
menu goes too high up and is cut off.
> MenuPopup can overflow off the top of the window
>
>
> Key: PIVOT-990
> URL: https://issues.apache.org/jira/browse/PIVOT-990
> Project: Pivot
> Issue Type: Bug
> Components: wtk-terra
>Affects Versions: 2.0.4, 2.1
> Environment: All
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1, 2.0.5
>
> Attachments: 990.patch, menu2.png, menu_popup_cut_off.png,
> menu_popup_fixed.png
>
>
> If the window / display size is small (either height [usually] or width), a
> tall or wide MenuPopup will be positioned either off the top or off the left
> of the window and you cannot see the top/left of the menu. This is
> particularly a problem with the height because you cannot see the menu items
> that are positioned outside the window, and so you cannot properly select
> them.
> The solution is to limit the border size in these cases, so that the Panorama
> that surrounds the menu list will automatically come into play and allow the
> menu to be scrolled into view.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PIVOT-1008) Allow enum values as Automation IDs
[ https://issues.apache.org/jira/browse/PIVOT-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-1008: -- Summary: Allow enum values as Automation IDs (was: Allow enum values to Automation IDs) > Allow enum values as Automation IDs > --- > > Key: PIVOT-1008 > URL: https://issues.apache.org/jira/browse/PIVOT-1008 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > It would be convenient in some instances to be able to use enum constants as > automation IDs in order to provide compile-time checking of the ID values (to > ensure consistency). So, to facilitate this, we could add "get", "add" and > "remove" methods in Automation that accept enum values. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PIVOT-1014) Specify skin default styles in JSON file so they can be easily changed
Roger Whitcomb created PIVOT-1014:
-
Summary: Specify skin default styles in JSON file so they can be
easily changed
Key: PIVOT-1014
URL: https://issues.apache.org/jira/browse/PIVOT-1014
Project: Pivot
Issue Type: Improvement
Components: wtk-terra
Reporter: Roger Whitcomb
Assignee: Roger Whitcomb
Priority: Minor
Fix For: 2.1
I have noticed some inconsistencies in the way default styles (things like
colors, fonts, padding/margins, etc.) are set in the constructors of the
Terra*Skin classes, such as:
* Color values set directly from the theme vs. set through the setter methods.
* Missing color setter methods using the theme color index.
* Derived colors being set in two different places, potentially leading to
inconsistencies because of the duplication.
* Possible inconsistencies between controls in the theme colors used (such as
for backgrounds, borders, etc.) -- this has not been verified, because it will
require a lot of research.
* Since these defaults are all set in code, even though (for instance) the
theme colors themselves are set in the "TerraTheme_default.json" file, changing
the overall look-and-feel is difficult at present.
So, for all these reasons I propose to use a new "terra_theme_defaults.json"
file, which can be overridden by a new setting in the "TerraTheme*.json"
file(s) which will set all the defaults for all the Terra*Skin classes similar
to this (taken from TerraExpanderSkin):
Previously:
{code:java}
setBackgroundColor(theme.getColor(4));
titleBarBackgroundColor = theme.getColor(10);
titleBarBorderColor = theme.getColor(7);
titleBarColor = theme.getColor(12);
shadeButtonColor = theme.getColor(12);
disabledShadeButtonColor = theme.getColor(7);
borderColor = theme.getColor(7);
padding = new Insets(4);
{code}
New:
{code:java}
TerraExpanderSkin : {
backgroundColor : 4,
titleBarBackgroundColor : 10,
titleBarBorderColor : 7,
titleBarColor : 12,
shadeButtonColor : 12,
disabledShadeButtonColor : 7,
borderColor : 7,
padding : 4
},
{code}
Note: this approach also fits well with the overall Pivot philosophy of doing
things in a "declarative" fashion (via BXML / JSON files) rather than in code,
where possible.
I have prototyped this in a couple of classes and it seems to work well, AND it
has revealed a number of the color properties that were missing the "setXXX(int
index)" methods.
Note: there is potential for slowdown during control construction since we're
executing a LOT more code to set these defaults (including expensive reflection
operations inside BeanAdapter), but I have not yet been able to measure the
speed differential to see if it will be of concern.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (PIVOT-850) Fail to take input characters other than English in Mac Lion
[ https://issues.apache.org/jira/browse/PIVOT-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16271900#comment-16271900 ] Roger Whitcomb edited comment on PIVOT-850 at 11/30/17 12:36 AM: - I believe this last issue is resolved by the fix for PIVOT-1006. So, the only (known) problem is TextArea has no IME support yet; TextInput and TextPane are done. Other than the Emoji problem on OSX noted above. was (Author: rwhitcomb): I believe this last issue is resolved by the fix for PIVOT-1006. So, the only (known) problem is TextArea has no IME support yet; TextInput and TextPane are done. > Fail to take input characters other than English in Mac Lion > > > Key: PIVOT-850 > URL: https://issues.apache.org/jira/browse/PIVOT-850 > Project: Pivot > Issue Type: Bug > Components: wtk, wtk-terra >Affects Versions: 2.0.1, 2.0.2, 2.0.3 > Environment: Mac Lion >Reporter: Brendan >Assignee: Roger Whitcomb > Labels: jre, mac > Fix For: 2.5 > > Attachments: ASF.LICENSE.NOT.GRANTED--Input to Mac Lion of Chinese > Character show nothing.jpg, ASF.LICENSE.NOT.GRANTED--Window 7 and Text Area > to show Chinese Input as Box.jpg, Screen Shot 2013-03-11 at 10.56.51 AM.png, > Screen Shot 2013-03-11 at 10.59.23 AM.png, Screen Shot 2013-03-11 at 11.00.14 > AM.png, WebStartInput.png, inputProblem.png > > > In Mac Lion, no Chinese and Korean character can appear in TextInput and > TextArea thru the input method. > However, these components can take the character thru copy and paste. > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-850) Fail to take input characters other than English in Mac Lion
[ https://issues.apache.org/jira/browse/PIVOT-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16271900#comment-16271900 ] Roger Whitcomb commented on PIVOT-850: -- I believe this last issue is resolved by the fix for PIVOT-1006. So, the only (known) problem is TextArea has no IME support yet; TextInput and TextPane are done. > Fail to take input characters other than English in Mac Lion > > > Key: PIVOT-850 > URL: https://issues.apache.org/jira/browse/PIVOT-850 > Project: Pivot > Issue Type: Bug > Components: wtk, wtk-terra >Affects Versions: 2.0.1, 2.0.2, 2.0.3 > Environment: Mac Lion >Reporter: Brendan >Assignee: Roger Whitcomb > Labels: jre, mac > Fix For: 2.5 > > Attachments: ASF.LICENSE.NOT.GRANTED--Input to Mac Lion of Chinese > Character show nothing.jpg, ASF.LICENSE.NOT.GRANTED--Window 7 and Text Area > to show Chinese Input as Box.jpg, Screen Shot 2013-03-11 at 10.56.51 AM.png, > Screen Shot 2013-03-11 at 10.59.23 AM.png, Screen Shot 2013-03-11 at 11.00.14 > AM.png, WebStartInput.png, inputProblem.png > > > In Mac Lion, no Chinese and Korean character can appear in TextInput and > TextArea thru the input method. > However, these components can take the character thru copy and paste. > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-984) Support CSS3/X11 color names
[ https://issues.apache.org/jira/browse/PIVOT-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16271867#comment-16271867 ] Roger Whitcomb commented on PIVOT-984: -- Somewhat related change: support "null" as a valid Color that returns a null Color value. Add a test: Sendingwtk\src\org\apache\pivot\wtk\GraphicsUtilities.java Sendingwtk\test\org\apache\pivot\wtk\test\ColorUtilitiesTest.java Transmitting file data ..done Committing transaction... Committed revision 1816663. > Support CSS3/X11 color names > > > Key: PIVOT-984 > URL: https://issues.apache.org/jira/browse/PIVOT-984 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0.4, 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The current set of color names is determined by the Java AWT color names, > which are basically the base 16 colors, plus a few. The latest web standards > build in the X11 colors names, which are a much larger list (see > https://en.wikipedia.org/wiki/X11_color_names, and note the differences > between CSS3 and X11). > I would propose implementing the W3C standards since these are what current > web applications will be using. > The changes are easy enough (except for the "gray" vs. "grey" spellings and > possibly the X11/CSS3 differences) that I would consider changing it for > 2.0.5 except that this is a spec change that doesn't belong in a bug fix > release (unless someone could make a good case for it). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1014) Specify skin default styles in JSON file so they can be easily changed
[
https://issues.apache.org/jira/browse/PIVOT-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273205#comment-16273205
]
Roger Whitcomb commented on PIVOT-1014:
---
First POC submission made, with the framework and two classes now using it:
Sendingcore\src\org\apache\pivot\beans\BXMLSerializer.java
Sendingcore\src\org\apache\pivot\beans\BeanAdapter.java
Sendingcore\src\org\apache\pivot\collections\Dictionary.java
Sendingcore\src\org\apache\pivot\json\JSONSerializer.java
Sendingwtk\src\org\apache\pivot\wtk\MessageType.java
Sendingwtk\src\org\apache\pivot\wtk\Theme.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraExpanderSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraRollupSkin.java
Sendingwtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTheme.java
Adding
wtk-terra\src\org\apache\pivot\wtk\skin\terra\terra_theme_defaults.json
Transmitting file data ..done
Committing transaction...
Committed revision 1816747.
PIVOT-1014: Create the starting framework for loading default styles
from a JSON file. Do a couple of Terra*Skin classes as a test.
1. In the Theme interface, add a new interface method: "setDefaultStyles".
2. In TerraTheme, add the loading of the new "terra_theme_defaults.json"
file as part of the constructor, saving the loaded map. Then implement
the "setDefaultStyles" method using the initially loaded map.
3. To help with debugging problems of missing setter methods, add the key
or property name being set to the "BeanAdapter.coerce(...)"" method and
add this new parameter to all the callers.
4. Also add a default "putAll" method to Dictionary, and slightly modify
the parameters of the existing method of this name in BeanAdapter so
it can override this new default method.
5. Move the style initialization in both TerraExpanderSkin and
TerraRollupSkin into the new .json file. This involves several other
changes:
a. The style initialization has to be moved into the "install()" method
in order for the component to be set (which is needed for the
"getStyles()"
call in there).
b. A number of new "set*Color(int)" methods had to be added for
TerraExpanderSkin because they were now being invoked to set the defaults
but were missing (and thus the need for identifying the property name in
the "BeanAdapter.coerce()"" method).
c. Also remove some of the now unnecessary derived color calculations in
these
two constructors, since they are done in the setter methods.
6. Do some other minor code simplification in TerraTheme, which also involved:
a. Make a new "fromString(...)" method in "MessageType" to hide some of the
repeated work being done in TerraTheme to load the icons.
Note: this is more-or-less a Proof-Of-Concept for this issue, which seems to be
reasonable, and fulfilling my objectives for it. There are still 51 other
classes
to be done/changed, and the slowdown implications have not yet been measured.
> Specify skin default styles in JSON file so they can be easily changed
> --
>
> Key: PIVOT-1014
> URL: https://issues.apache.org/jira/browse/PIVOT-1014
> Project: Pivot
> Issue Type: Improvement
> Components: wtk-terra
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
>
> I have noticed some inconsistencies in the way default styles (things like
> colors, fonts, padding/margins, etc.) are set in the constructors of the
> Terra*Skin classes, such as:
> * Color values set directly from the theme vs. set through the setter methods.
> * Missing color setter methods using the theme color index.
> * Derived colors being set in two different places, potentially leading to
> inconsistencies because of the duplication.
> * Possible inconsistencies between controls in the theme colors used (such as
> for backgrounds, borders, etc.) -- this has not been verified, because it
> will require a lot of research.
> * Since these defaults are all set in code, even though (for instance) the
> theme colors themselves are set in the "TerraTheme_default.json" file,
> changing the overall look-and-feel is difficult at present.
> So, for all these reasons I propose to use a new "terra_theme_defaults.json"
> file, which can be overridden by a new setting in the "TerraTheme*.json"
> file(s) which will set all the defaults for all the Terra*Skin classes
> similar to this (taken from TerraExpanderSkin):
> Previously:
> {code:java}
>setBackgroundColor(theme.getColor(4));
>titleBarBackgroundColor = theme.getColor(10);
>titleBarBorderColor = theme.getColor(7);
>titleBarColor = theme.getColor(12);
>
[jira] [Commented] (PIVOT-1014) Specify skin default styles in JSON file so they can be easily changed
[
https://issues.apache.org/jira/browse/PIVOT-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273335#comment-16273335
]
Roger Whitcomb commented on PIVOT-1014:
---
New changes to make both this new "terra_theme_defaults.json" and the
preexisting "terra_theme_styles.json" file names overridable in the
TerraTheme*.json file(s). The "_defaults" file lists these default names. So,
now a user application can specify a different theme definition file (such as
the examples "TerraTheme_osx.json", etc.) which could now also include
different styles defaults and named styles. This opens the way for full
customization of the TerraTheme by users.
Sendingwtk\src\org\apache\pivot\wtk\Theme.java
Sendingwtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTheme.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTheme_default.json
Transmitting file data ...done
Committing transaction...
Committed revision 1816752.
> Specify skin default styles in JSON file so they can be easily changed
> --
>
> Key: PIVOT-1014
> URL: https://issues.apache.org/jira/browse/PIVOT-1014
> Project: Pivot
> Issue Type: Improvement
> Components: wtk-terra
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
>
> I have noticed some inconsistencies in the way default styles (things like
> colors, fonts, padding/margins, etc.) are set in the constructors of the
> Terra*Skin classes, such as:
> * Color values set directly from the theme vs. set through the setter methods.
> * Missing color setter methods using the theme color index.
> * Derived colors being set in two different places, potentially leading to
> inconsistencies because of the duplication.
> * Possible inconsistencies between controls in the theme colors used (such as
> for backgrounds, borders, etc.) -- this has not been verified, because it
> will require a lot of research.
> * Since these defaults are all set in code, even though (for instance) the
> theme colors themselves are set in the "TerraTheme_default.json" file,
> changing the overall look-and-feel is difficult at present.
> So, for all these reasons I propose to use a new "terra_theme_defaults.json"
> file, which can be overridden by a new setting in the "TerraTheme*.json"
> file(s) which will set all the defaults for all the Terra*Skin classes
> similar to this (taken from TerraExpanderSkin):
> Previously:
> {code:java}
>setBackgroundColor(theme.getColor(4));
>titleBarBackgroundColor = theme.getColor(10);
>titleBarBorderColor = theme.getColor(7);
>titleBarColor = theme.getColor(12);
>shadeButtonColor = theme.getColor(12);
>disabledShadeButtonColor = theme.getColor(7);
>borderColor = theme.getColor(7);
>padding = new Insets(4);
> {code}
> New:
> {code:java}
> TerraExpanderSkin : {
> backgroundColor : 4,
> titleBarBackgroundColor : 10,
> titleBarBorderColor : 7,
> titleBarColor : 12,
> shadeButtonColor : 12,
> disabledShadeButtonColor : 7,
> borderColor : 7,
> padding : 4
> },
> {code}
> Note: this approach also fits well with the overall Pivot philosophy of doing
> things in a "declarative" fashion (via BXML / JSON files) rather than in
> code, where possible.
> I have prototyped this in a couple of classes and it seems to work well, AND
> it has revealed a number of the color properties that were missing the
> "setXXX(int index)" methods.
> Note: there is potential for slowdown during control construction since we're
> executing a LOT more code to set these defaults (including expensive
> reflection operations inside BeanAdapter), but I have not yet been able to
> measure the speed differential to see if it will be of concern.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (PIVOT-984) Support CSS3/X11 color names
[
https://issues.apache.org/jira/browse/PIVOT-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Whitcomb closed PIVOT-984.
Resolution: Fixed
More work was done on this issue, actually as part of PIVOT-985 There is
now a separate CSSColor enum that has the complete list, including the
American/British spelling variants ("gray" and "grey", etc.) and support has
been added to ColorItem also (new "allCSSColors" method).
Closing this as finished.
> Support CSS3/X11 color names
>
>
> Key: PIVOT-984
> URL: https://issues.apache.org/jira/browse/PIVOT-984
> Project: Pivot
> Issue Type: Improvement
> Components: wtk
>Affects Versions: 2.0.4, 2.1
> Environment: All
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
>
> The current set of color names is determined by the Java AWT color names,
> which are basically the base 16 colors, plus a few. The latest web standards
> build in the X11 colors names, which are a much larger list (see
> https://en.wikipedia.org/wiki/X11_color_names, and note the differences
> between CSS3 and X11).
> I would propose implementing the W3C standards since these are what current
> web applications will be using.
> The changes are easy enough (except for the "gray" vs. "grey" spellings and
> possibly the X11/CSS3 differences) that I would consider changing it for
> 2.0.5 except that this is a spec change that doesn't belong in a bug fix
> release (unless someone could make a good case for it).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PIVOT-1006) Composed text from Input Method Editor doesn't show up sometimes
[ https://issues.apache.org/jira/browse/PIVOT-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16271898#comment-16271898 ] Roger Whitcomb commented on PIVOT-1006: --- The main issue is PIVOT-850. > Composed text from Input Method Editor doesn't show up sometimes > > > Key: PIVOT-1006 > URL: https://issues.apache.org/jira/browse/PIVOT-1006 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb > Fix For: 2.1 > > > When the composed text from the IME is at the end of a paragraph, but there > is a TextSpan that contains the last text in the paragraph (that is, the > parent of the TextNode is a TextSpan, whose parent is then the Paragraph) > then the composed text is not painted, even though the caret moves the > correct amount. If there is no intervening TextSpan (that is, the TextNode > is the direct descendant of the Paragraph) then the composed text is painted > correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-994) BXMLExplorer is getting a null display for a visible owner window.
[ https://issues.apache.org/jira/browse/PIVOT-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293487#comment-16293487 ] Roger Whitcomb commented on PIVOT-994: -- Note: running the "alert_prompt_test.bxml" file using ScriptApplication does not have this problem. So, likely this has to do with the specific code/environment in BXMLExplorer. > BXMLExplorer is getting a null display for a visible owner window. > -- > > Key: PIVOT-994 > URL: https://issues.apache.org/jira/browse/PIVOT-994 > Project: Pivot > Issue Type: Bug > Components: core-beans >Affects Versions: 2.0.4, 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > Run the BXML Explorer Tutorial application. Open up the > "org/apache/pivot/tests/alert_prompt_test.bxml" file and try to bring up any > of the alerts or prompts. There will be an IllegalArgumentException that > "display is null." > The stack trace (for 2.0.x) shows this: > java.lang.IllegalArgumentException: display is null. > at org.apache.pivot.wtk.Window.open(Window.java:630) > at org.apache.pivot.wtk.Dialog.open(Dialog.java:186) > at org.apache.pivot.wtk.Alert.alert(Alert.java:359) > at org.apache.pivot.wtk.Alert.alert(Alert.java:331) > at jdk.nashorn.internal.scripts.Script$3$\^eval\_.:program(:1) > at > jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637) > at > jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494) > at > jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) > at > jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449) > at > jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406) > at > jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402) > at > jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155) > at javax.script.AbstractScriptEngine.eval(Unknown Source) > at > org.apache.pivot.beans.BXMLSerializer$AttributeInvocationHandler.invoke(BXMLSerializer.java:156) > This sequence shows that "owner.getDisplay()" is returning null at > Alert.open() time, even though the owner window is clearly visible at the > time. > This could possibly be due to Nashorn scripting issues with Java 8, since the > "window" variable would be set in the JS namespace, but this doesn't really > explain why the "display" value is null, and not the "window" value itself. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-994) BXMLExplorer is getting a null display for a visible owner window.
[ https://issues.apache.org/jira/browse/PIVOT-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-994. Resolution: Not A Problem The more I look at this, the more I am convinced this is not a problem. Running the script via "ScriptApplication" where the window is clearly "open"ed in its own display, everything is fine. Inside BXMLExplorer, the window is displayed, but the code substitutes a "FakeWindow" component that does not have the real "Window" as a child, so the "getDisplay" method will never find the Display ancestor of that FakeWindow, and thus the error. And, the BXMLExplorer application is not meant to actually run the examples anyway, only to explore the BXML hierarchy and the components' styles and attributes. > BXMLExplorer is getting a null display for a visible owner window. > -- > > Key: PIVOT-994 > URL: https://issues.apache.org/jira/browse/PIVOT-994 > Project: Pivot > Issue Type: Bug > Components: core-beans >Affects Versions: 2.0.4, 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > Run the BXML Explorer Tutorial application. Open up the > "org/apache/pivot/tests/alert_prompt_test.bxml" file and try to bring up any > of the alerts or prompts. There will be an IllegalArgumentException that > "display is null." > The stack trace (for 2.0.x) shows this: > java.lang.IllegalArgumentException: display is null. > at org.apache.pivot.wtk.Window.open(Window.java:630) > at org.apache.pivot.wtk.Dialog.open(Dialog.java:186) > at org.apache.pivot.wtk.Alert.alert(Alert.java:359) > at org.apache.pivot.wtk.Alert.alert(Alert.java:331) > at jdk.nashorn.internal.scripts.Script$3$\^eval\_.:program(:1) > at > jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637) > at > jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494) > at > jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) > at > jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449) > at > jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406) > at > jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402) > at > jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155) > at javax.script.AbstractScriptEngine.eval(Unknown Source) > at > org.apache.pivot.beans.BXMLSerializer$AttributeInvocationHandler.invoke(BXMLSerializer.java:156) > This sequence shows that "owner.getDisplay()" is returning null at > Alert.open() time, even though the owner window is clearly visible at the > time. > This could possibly be due to Nashorn scripting issues with Java 8, since the > "window" variable would be set in the JS namespace, but this doesn't really > explain why the "display" value is null, and not the "window" value itself. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291661#comment-16291661 ] Roger Whitcomb commented on PIVOT-1017: --- More enhancements to the RulerSkin: * Add "majorDivision" and "minorDivision" styles (default to 4 and 2 respectively) at which intervals to draw the major and minor markers. * Allow either of these to be 0, which is to not make the distinction. * Make the minor markers a bit longer so they are bit easier to distinguish. * Add some Javadoc that was previously missing for some of the styles. * Correct the Javadoc in a couple of places in GraphicsUtilities. Sendingwtk\src\org\apache\pivot\wtk\GraphicsUtilities.java Sendingwtk\src\org\apache\pivot\wtk\skin\RulerSkin.java Transmitting file data ..done Committing transaction... Committed revision 1818219. > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-1016) Error parsing Java 9 version string
[ https://issues.apache.org/jira/browse/PIVOT-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-1016. - Resolution: Fixed Considering this finished, unless anyone else sees further problems. > Error parsing Java 9 version string > --- > > Key: PIVOT-1016 > URL: https://issues.apache.org/jira/browse/PIVOT-1016 > Project: Pivot > Issue Type: Bug > Components: core-util > Environment: java version "9.0.1" > Java(TM) SE Runtime Environment (build 9.0.1+11) > Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode) >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > > Starting up any application will give the following error when run with this > Java 9 version:Error decoding version string "9.0.1+11": For input string: > "1+11" > Note: since the changes to Version.java for 1.8.0_131 this is not a fatal > error any longer, but the parsing should be updated to allow for the new Java > 9 version strings (see: > https://blogs.oracle.com/java-platform-group/a-new-jdk-9-version-string-scheme). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1016) Error parsing Java 9 version string
[ https://issues.apache.org/jira/browse/PIVOT-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16287932#comment-16287932 ] Roger Whitcomb commented on PIVOT-1016: --- Added some more possible version strings from the JEP-223 document, which required some further parsing changes to "Version.decode()" to handle: Sendingcore\src\org\apache\pivot\util\Version.java Sendingcore\test\org\apache\pivot\util\test\VersionTest.java Transmitting file data ..done Committing transaction... Committed revision 1817937. > Error parsing Java 9 version string > --- > > Key: PIVOT-1016 > URL: https://issues.apache.org/jira/browse/PIVOT-1016 > Project: Pivot > Issue Type: Bug > Components: core-util > Environment: java version "9.0.1" > Java(TM) SE Runtime Environment (build 9.0.1+11) > Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode) >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > > Starting up any application will give the following error when run with this > Java 9 version:Error decoding version string "9.0.1+11": For input string: > "1+11" > Note: since the changes to Version.java for 1.8.0_131 this is not a fatal > error any longer, but the parsing should be updated to allow for the new Java > 9 version strings (see: > https://blogs.oracle.com/java-platform-group/a-new-jdk-9-version-string-scheme). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1016) Error parsing Java 9 version string
[ https://issues.apache.org/jira/browse/PIVOT-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16287949#comment-16287949 ] Roger Whitcomb commented on PIVOT-1016: --- And added all the potential new Java version strings found in the JEP-223 paper, as a final check: Sendingcore\test\org\apache\pivot\util\test\VersionTest.java Transmitting file data .done Committing transaction... Committed revision 1817938. > Error parsing Java 9 version string > --- > > Key: PIVOT-1016 > URL: https://issues.apache.org/jira/browse/PIVOT-1016 > Project: Pivot > Issue Type: Bug > Components: core-util > Environment: java version "9.0.1" > Java(TM) SE Runtime Environment (build 9.0.1+11) > Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode) >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > > Starting up any application will give the following error when run with this > Java 9 version:Error decoding version string "9.0.1+11": For input string: > "1+11" > Note: since the changes to Version.java for 1.8.0_131 this is not a fatal > error any longer, but the parsing should be updated to allow for the new Java > 9 version strings (see: > https://blogs.oracle.com/java-platform-group/a-new-jdk-9-version-string-scheme). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
Roger Whitcomb created PIVOT-1017: - Summary: Move the tutorial "Ruler" class into the mainline code for use by others Key: PIVOT-1017 URL: https://issues.apache.org/jira/browse/PIVOT-1017 Project: Pivot Issue Type: Improvement Components: wtk Environment: All Reporter: Roger Whitcomb Priority: Minor Fix For: 2.1 The "Ruler" class (and associated Skin and Listener classes) already exists in two places in the tutorials branch, so it should go into the main "wtk" code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291179#comment-16291179 ] Roger Whitcomb commented on PIVOT-1017: --- Deleting tutorials\src\org\apache\pivot\tutorials\explorer\Ruler.java Deleting tutorials\src\org\apache\pivot\tutorials\explorer\RulerListener.java Deleting tutorials\src\org\apache\pivot\tutorials\explorer\RulerSkin.java Sending tutorials\src\org\apache\pivot\tutorials\explorer\scroll_pane.bxml Deleting tutorials\src\org\apache\pivot\tutorials\navigation\Ruler.java Deleting tutorials\src\org\apache\pivot\tutorials\navigation\RulerListener.java Deleting tutorials\src\org\apache\pivot\tutorials\navigation\RulerSkin.java Sending tutorials\src\org\apache\pivot\tutorials\navigation\scroll_panes.bxml Adding wtk\src\org\apache\pivot\wtk\Ruler.java Adding wtk\src\org\apache\pivot\wtk\RulerListener.java Adding wtk\src\org\apache\pivot\wtk\RulerSkin.java Transmitting file data .done Committing transaction... Committed revision 1818168. > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-1017: - Assignee: Roger Whitcomb > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-984) Support CSS3/X11 color names
[ https://issues.apache.org/jira/browse/PIVOT-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291136#comment-16291136 ] Roger Whitcomb commented on PIVOT-984: -- Adding a tiny demo of this: change the "RulerSkin" class to use the CSSColor.LightYellow since that's what the hard-coded color value that was there translates to: Sendingtutorials\src\org\apache\pivot\tutorials\explorer\RulerSkin.java Sending tutorials\src\org\apache\pivot\tutorials\navigation\RulerSkin.java Transmitting file data ..done Committing transaction... Committed revision 1818163. > Support CSS3/X11 color names > > > Key: PIVOT-984 > URL: https://issues.apache.org/jira/browse/PIVOT-984 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0.4, 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The current set of color names is determined by the Java AWT color names, > which are basically the base 16 colors, plus a few. The latest web standards > build in the X11 colors names, which are a much larger list (see > https://en.wikipedia.org/wiki/X11_color_names, and note the differences > between CSS3 and X11). > I would propose implementing the W3C standards since these are what current > web applications will be using. > The changes are easy enough (except for the "gray" vs. "grey" spellings and > possibly the X11/CSS3 differences) that I would consider changing it for > 2.0.5 except that this is a spec change that doesn't belong in a bug fix > release (unless someone could make a good case for it). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-850) Fail to take input characters other than English in Mac Lion
[ https://issues.apache.org/jira/browse/PIVOT-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291541#comment-16291541 ] Roger Whitcomb commented on PIVOT-850: -- Correct a tiny text positioning problem in TextPane: Sendingwtk\src\org\apache\pivot\wtk\skin\TextPaneSkinTextNodeView.java Transmitting file data .done Committing transaction... Committed revision 1818207. > Fail to take input characters other than English in Mac Lion > > > Key: PIVOT-850 > URL: https://issues.apache.org/jira/browse/PIVOT-850 > Project: Pivot > Issue Type: Bug > Components: wtk, wtk-terra >Affects Versions: 2.0.1, 2.0.2, 2.0.3 > Environment: Mac Lion >Reporter: Brendan >Assignee: Roger Whitcomb > Labels: jre, mac > Fix For: 2.5 > > Attachments: ASF.LICENSE.NOT.GRANTED--Input to Mac Lion of Chinese > Character show nothing.jpg, ASF.LICENSE.NOT.GRANTED--Window 7 and Text Area > to show Chinese Input as Box.jpg, Screen Shot 2013-03-11 at 10.56.51 AM.png, > Screen Shot 2013-03-11 at 10.59.23 AM.png, Screen Shot 2013-03-11 at 11.00.14 > AM.png, WebStartInput.png, inputProblem.png > > > In Mac Lion, no Chinese and Korean character can appear in TextInput and > TextArea thru the input method. > However, these components can take the character thru copy and paste. > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291244#comment-16291244 ] Roger Whitcomb commented on PIVOT-1017: --- Made the colors and marker spacing into styles of the skin, move the skin to the right class, and make it part of the Theme skin map, update one of the tutorials to test the styles, move the listener list into the listener itself: Sending tutorials\src\org\apache\pivot\tutorials\navigation\scroll_panes.bxml Sendingwtk\src\org\apache\pivot\wtk\Ruler.java Sendingwtk\src\org\apache\pivot\wtk\RulerListener.java Deleting wtk\src\org\apache\pivot\wtk\RulerSkin.java Sendingwtk\src\org\apache\pivot\wtk\Theme.java Adding wtk\src\org\apache\pivot\wtk\skin\RulerSkin.java Transmitting file data .done Committing transaction... Committed revision 1818171. > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291766#comment-16291766 ] Roger Whitcomb edited comment on PIVOT-1017 at 12/14/17 11:09 PM: -- Enhance the border drawing for RulerSkin: * Add the remaining choices to Borders for all the two and three border cases. * Move the border drawing into GraphicsUtilities.drawBorders and out of RulerSkin. Sendingwtk\src\org\apache\pivot\wtk\Borders.java Sendingwtk\src\org\apache\pivot\wtk\GraphicsUtilities.java Sendingwtk\src\org\apache\pivot\wtk\skin\RulerSkin.java Transmitting file data ...done Committing transaction... Committed revision 1818221. was (Author: rwhitcomb): Enhance the border drawing for RulerSkin: * Add the remaining choices to Borders for all the two and three border cases. * Move the border drawing into GraphicsUtilities.drawBorders and out of RulerSkin. Sendingwtk\src\org\apache\pivot\wtk\Borders.java Sendingwtk\src\org\apache\pivot\wtk\GraphicsUtilities.java Sendingwtk\src\org\apache\pivot\wtk\skin\RulerSkin.java Transmitting file data ...done Committing transaction... Committed revision 1818221. > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291766#comment-16291766 ] Roger Whitcomb commented on PIVOT-1017: --- Enhance the border drawing for RulerSkin: * Add the remaining choices to Borders for all the two and three border cases. * Move the border drawing into GraphicsUtilities.drawBorders and out of RulerSkin. Sendingwtk\src\org\apache\pivot\wtk\Borders.java Sendingwtk\src\org\apache\pivot\wtk\GraphicsUtilities.java Sendingwtk\src\org\apache\pivot\wtk\skin\RulerSkin.java Transmitting file data ...done Committing transaction... Committed revision 1818221. > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PIVOT-1019) Add a NumberRuler heading component for use with scrolling TextArea or TextPane
Roger Whitcomb created PIVOT-1019: - Summary: Add a NumberRuler heading component for use with scrolling TextArea or TextPane Key: PIVOT-1019 URL: https://issues.apache.org/jira/browse/PIVOT-1019 Project: Pivot Issue Type: New Feature Components: wtk Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Fix For: 2.1 Similiar to the Ruler component from PIVOT-1017, this would size itself and display line numbers or column counts when used as a row or column heading object for a ScrollPane around a TextArea or TextPane (when used with pure text). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1019) Add a NumberRuler heading component for use with scrolling TextArea or TextPane
[ https://issues.apache.org/jira/browse/PIVOT-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296961#comment-16296961 ] Roger Whitcomb commented on PIVOT-1019: --- Adding wtk\src\org\apache\pivot\wtk\NumberRuler.java Adding wtk\src\org\apache\pivot\wtk\NumberRulerListener.java Sendingwtk\src\org\apache\pivot\wtk\Theme.java Adding wtk\src\org\apache\pivot\wtk\skin\NumberRulerSkin.java Transmitting file data done Committing transaction... Committed revision 1818680. > Add a NumberRuler heading component for use with scrolling TextArea or > TextPane > --- > > Key: PIVOT-1019 > URL: https://issues.apache.org/jira/browse/PIVOT-1019 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > Similiar to the Ruler component from PIVOT-1017, this would size itself and > display line numbers or column counts when used as a row or column heading > object for a ScrollPane around a TextArea or TextPane (when used with pure > text). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1011) Move ListenerList implementations of interfaces into the interface itself
[ https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296987#comment-16296987 ] Roger Whitcomb commented on PIVOT-1011: --- For the new NumberRuler: Sendingwtk\src\org\apache\pivot\wtk\NumberRuler.java Sendingwtk\src\org\apache\pivot\wtk\NumberRulerListener.java Transmitting file data ..done Committing transaction... Committed revision 1818686. > Move ListenerList implementations of interfaces into the interface itself > - > > Key: PIVOT-1011 > URL: https://issues.apache.org/jira/browse/PIVOT-1011 > Project: Pivot > Issue Type: Improvement > Components: core-collections, core-util, web, wtk, wtk-terra > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Attachments: 1011.diffs > > > A universal paradigm in Pivot is to have a "listener" interface for a class > or data structure that is used to notify listeners of changes in the > class/data. There is then an "Adapter" static class in the interface file > that implements the interface with default implementations. Then there is a > very separate enclosed static class that implements the "ListenerList" > interface of that listener interface. And usually (or always) this "listener > list" class is defined/used only in the class that needs to notify the > listeners. However, this class must be very parallel to not only the > interface itself, but also the "Adapter" class, and yet it is in a different > place. > So, it seems somewhat reasonable to move all these "listener list" classes > into the interfaces themselves, so all three related things are located in > the same file. A preliminary POC of this concept was done with "Query.java", > and "QueryListener.java" and it looks good. > This doesn't seem to require changes to client code, because the accessor > methods only refer to "ListenerList<>" and not to the listener list class > itself (in order to be more general, of course), but which helps us to hide > the implementing class away inside the interface. > I will attach the diff of the POC, to hopefully make this more clear. It may > seem a somewhat nebulous concept, but the idea is to keep "like things" > together for clarity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1019) Add a NumberRuler heading component for use with scrolling TextArea or TextPane
[ https://issues.apache.org/jira/browse/PIVOT-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16296988#comment-16296988 ] Roger Whitcomb commented on PIVOT-1019: --- Also for PIVOT-1011, move the listener list into the interface: Sendingwtk\src\org\apache\pivot\wtk\NumberRuler.java Sendingwtk\src\org\apache\pivot\wtk\NumberRulerListener.java Transmitting file data ..done Committing transaction... Committed revision 1818686. > Add a NumberRuler heading component for use with scrolling TextArea or > TextPane > --- > > Key: PIVOT-1019 > URL: https://issues.apache.org/jira/browse/PIVOT-1019 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > Similiar to the Ruler component from PIVOT-1017, this would size itself and > display line numbers or column counts when used as a row or column heading > object for a ScrollPane around a TextArea or TextPane (when used with pure > text). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291938#comment-16291938 ] Roger Whitcomb commented on PIVOT-1017: --- Add more override methods to set the "markerInsets" style in RulerSkin, in order to support all the possible ways of setting this style in BXML (modeled after other "Insets" styles). Mark all the "set" methods as "public final" as in other skin classes. Sendingwtk\src\org\apache\pivot\wtk\skin\RulerSkin.java Transmitting file data .done Committing transaction... Committed revision 1818224. > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PIVOT-1018) ScrollPane corners do not paint the correct background color
Roger Whitcomb created PIVOT-1018: - Summary: ScrollPane corners do not paint the correct background color Key: PIVOT-1018 URL: https://issues.apache.org/jira/browse/PIVOT-1018 Project: Pivot Issue Type: Bug Components: wtk Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor Fix For: 2.1 With column and row headers on a ScrollPane, there are leftover spaces filled in with "Corner" components, but these always paint with theme color 11 (almost white), no matter what the background color of the ScrollPane is supposed to be. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-1017. - Resolution: Fixed This satisfies all my requirements. Marking it closed. But feel free to reopen if anything shows up wrong. > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1018) ScrollPane corners do not paint the correct background color
[ https://issues.apache.org/jira/browse/PIVOT-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293304#comment-16293304 ] Roger Whitcomb commented on PIVOT-1018: --- r1818230 | rwhitcomb | 2017-12-14 18:59:50 -0800 (Thu, 14 Dec 2017) | 4 lines Changed paths: M /pivot/trunk/wtk/src/org/apache/pivot/wtk/skin/ScrollPaneSkin.java PIVOT-1018: Propagate the scroll pane background color to the default corner components when they get made visible so the correct background is painted. > ScrollPane corners do not paint the correct background color > > > Key: PIVOT-1018 > URL: https://issues.apache.org/jira/browse/PIVOT-1018 > Project: Pivot > Issue Type: Bug > Components: wtk >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > With column and row headers on a ScrollPane, there are leftover spaces filled > in with "Corner" components, but these always paint with theme color 11 > (almost white), no matter what the background color of the ScrollPane is > supposed to be. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-1018) ScrollPane corners do not paint the correct background color
[ https://issues.apache.org/jira/browse/PIVOT-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-1018. - Resolution: Fixed > ScrollPane corners do not paint the correct background color > > > Key: PIVOT-1018 > URL: https://issues.apache.org/jira/browse/PIVOT-1018 > Project: Pivot > Issue Type: Bug > Components: wtk >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > With column and row headers on a ScrollPane, there are leftover spaces filled > in with "Corner" components, but these always paint with theme color 11 > (almost white), no matter what the background color of the ScrollPane is > supposed to be. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1010) Update CalendarDate and Time classes to interact with new java.time classes
[ https://issues.apache.org/jira/browse/PIVOT-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293306#comment-16293306 ] Roger Whitcomb commented on PIVOT-1010: --- Not sure what else to do with this issue. Any suggestions?? > Update CalendarDate and Time classes to interact with new java.time classes > --- > > Key: PIVOT-1010 > URL: https://issues.apache.org/jira/browse/PIVOT-1010 > Project: Pivot > Issue Type: Improvement > Components: core-util >Affects Versions: 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Labels: datetime > Fix For: 2.1 > > > In Java 8 there are new classes in the "java.time" package that are much > better and easier to use than some of the old date/time classes. Now, our > CalendarDate and Time classes are reasonably good, and using > GregorianCalendar is still robust, but it would make sense (at least) to be > able to construct instances of our classes from LocalDate, LocalTime and > LocalDateTime, and to construct instances of these new classes from our > classes to facilitate interaction with new applications using these Java 8 > features. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1009) Improve Task to be able to tell what the background Thread that was used to execute it
[
https://issues.apache.org/jira/browse/PIVOT-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293308#comment-16293308
]
Roger Whitcomb commented on PIVOT-1009:
---
Not sure what else to do for this issue. Suggestions?
> Improve Task to be able to tell what the background Thread that was used to
> execute it
> --
>
> Key: PIVOT-1009
> URL: https://issues.apache.org/jira/browse/PIVOT-1009
> Project: Pivot
> Issue Type: Improvement
> Components: core-beans, wtk
> Environment: All
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
> Attachments: 1009.patch
>
>
> The idea is that Tasks are generally run on a background thread, but we don't
> usually know what that thread was. There should be a field inside the Task
> class that keeps a weak reference to the thread ("weak" so it doesn't hold up
> garbage collection). That way any errors caught during the task execution
> can actually report the thread that was used.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PIVOT-997) Deprecate (and eventually remove) the WTKListenerList class, which is currently empty
[ https://issues.apache.org/jira/browse/PIVOT-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb updated PIVOT-997: - Fix Version/s: 2.1 2.5 > Deprecate (and eventually remove) the WTKListenerList class, which is > currently empty > - > > Key: PIVOT-997 > URL: https://issues.apache.org/jira/browse/PIVOT-997 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.5, 2.1 > > > The WTKListenerList class was originally added as a subclass of ListenerList, > but with thread-safety checks in it (basically checking that all the > operations were performed on the Event Dispatch Thread (EDT) or "main" during > startup). All these checks were removed some time ago, so that component > hierarchies could be built "offline", that is in a background thread, either > by BXMLSerializer, or programmatically. This left WTKListenerList as an > empty class, but with comments to the effect that it was used to provide > thread safety checks This is confusing, and unnecessary. So, I propose > to deprecate the class in version 2.1, replacing all the internal references > with just "ListenerList", and so the class can be removed at some point after > that. > Note: deprecating it in the 2.0.x branch is not really an option, since it > means the build gets 100s of warnings about the deprecation, which is not > good for a release branch. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293242#comment-16293242 ] Roger Whitcomb commented on PIVOT-1017: --- Added styles and drawing to enable numbers on the major and minor markers if desired: Sending tutorials\src\org\apache\pivot\tutorials\navigation\scroll_panes.bxml Sendingwtk\src\org\apache\pivot\wtk\skin\RulerSkin.java Transmitting file data ..done Committing transaction... Committed revision 1818338. > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293275#comment-16293275 ] Roger Whitcomb commented on PIVOT-1017: --- Changed the number font size: Sendingwtk\src\org\apache\pivot\wtk\skin\RulerSkin.java Transmitting file data .done Committing transaction... Committed revision 1818345. > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-965) Java 8 BXML scripting security issues in Apache Pivot RIAs
[ https://issues.apache.org/jira/browse/PIVOT-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16288341#comment-16288341 ] Roger Whitcomb commented on PIVOT-965: -- Okay, resolved this latest problem by getting a new engine for each element callback: Sendingcore\src\org\apache\pivot\beans\BXMLSerializer.java Transmitting file data .done Committing transaction... Committed revision 1817960. > Java 8 BXML scripting security issues in Apache Pivot RIAs > -- > > Key: PIVOT-965 > URL: https://issues.apache.org/jira/browse/PIVOT-965 > Project: Pivot > Issue Type: Bug > Components: core-serialization >Affects Versions: 2.0.4 > Environment: Windows, Sun JRE 64-bit 1.8.0_31b13 >Reporter: Karel Hübl >Assignee: Roger Whitcomb > Labels: java8, jdk8 > Fix For: 2.1 > > Attachments: 965.diffs, BXMLSerializer.patch, jnlpScripting.war > > > We encounter security issues in our pivot application after upgrading to JRE > 1.8. The application is deployed as RIA using Java Web Start. > I found out, that the problem is connected with nashorn script engine which > replaced rhino script engine from previous java version. BXMLSerializer is > using ScriptEngine to evaluate scripts in BXML files. It seems, that all > calls initiated from BXML scripts, are considered untrusted in JRE 1.8 RIA > Environment - this means security dialogs and exceptions are thrown, when > trying execute privileged actions (network communication, reflection ...). > Currently, I am not sure, if this is Pivot or Nashorn bug, but it is problem > for current Apache Pivot RIAs. To investigate the srcipting behaviour in > RIAs, I created testing non Pivot project > https://github.com/kaja78/jnlpScripting The project contains testing > application, which is deployed as JWS. When you execute the java web start > app in JRE 1.8, the security dialog is displayed when testing method is > executed from nashorn script engine (if you press cancel button on security > dialog, you get SecurityException). When you uncomment 2 lines in > Webcontent/jnlpScripting.jnlp file, rhino script engine is used instead of > nashorn and no security dialog is displayed. This fix works also for our > Pivot RIAs. > I believe, Pivot should work in JRE 1.8 RIA Environment without security > issues by default, so it should be fixed somehow in Pivot - may be, by > correct ScriptEngine configuration in BXMLSerializer or by including Rhino > libraries in Pivot distribution. Any idea how to "correctly" fix this issue? > Btw.: I found this bug: http://bugs.java.com/view_bug.do?bug_id=8045075 I am > not sure, if it is the same problem. But anyway, it should be fixed in > 1.8.25.b01 and we are encountering above issues in latest 1.8.0.31.b13. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1017) Move the tutorial "Ruler" class into the mainline code for use by others
[ https://issues.apache.org/jira/browse/PIVOT-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297302#comment-16297302 ] Roger Whitcomb commented on PIVOT-1017: --- Tweak the horizontal ruler text positioning and do a little code cleanup. Also port a lot of the horizontal code into the new NumberRulerSkin (for PIVOT-1019): Sendingwtk\src\org\apache\pivot\wtk\skin\NumberRulerSkin.java Sendingwtk\src\org\apache\pivot\wtk\skin\RulerSkin.java Transmitting file data ..done Committing transaction... Committed revision 1818707. > Move the tutorial "Ruler" class into the mainline code for use by others > > > Key: PIVOT-1017 > URL: https://issues.apache.org/jira/browse/PIVOT-1017 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > The "Ruler" class (and associated Skin and Listener classes) already exists > in two places in the tutorials branch, so it should go into the main "wtk" > code so it can be used by others who might find it useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1019) Add a NumberRuler heading component for use with scrolling TextArea or TextPane
[ https://issues.apache.org/jira/browse/PIVOT-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297338#comment-16297338 ] Roger Whitcomb commented on PIVOT-1019: --- Take into account the top marker inset when drawing vertical number rulers. Add NumberRuler as both row and column headings in the ComponentExplorer "BXMLSource" tab (as a demonstration): Sending tutorials\src\org\apache\pivot\tutorials\explorer\component_explorer_window.bxml Sendingwtk\src\org\apache\pivot\wtk\skin\NumberRulerSkin.java Transmitting file data ..done Committing transaction... Committed revision 1818710. > Add a NumberRuler heading component for use with scrolling TextArea or > TextPane > --- > > Key: PIVOT-1019 > URL: https://issues.apache.org/jira/browse/PIVOT-1019 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > Similiar to the Ruler component from PIVOT-1017, this would size itself and > display line numbers or column counts when used as a row or column heading > object for a ScrollPane around a TextArea or TextPane (when used with pure > text). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1019) Add a NumberRuler heading component for use with scrolling TextArea or TextPane
[ https://issues.apache.org/jira/browse/PIVOT-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297298#comment-16297298 ] Roger Whitcomb commented on PIVOT-1019: --- Finished the horizontal drawing code borrowing code/concepts from RulerSkin. Tweak the code in both places to adjust positioning a little and clean up code. Sendingwtk\src\org\apache\pivot\wtk\skin\NumberRulerSkin.java Sendingwtk\src\org\apache\pivot\wtk\skin\RulerSkin.java Transmitting file data ..done Committing transaction... Committed revision 1818707. > Add a NumberRuler heading component for use with scrolling TextArea or > TextPane > --- > > Key: PIVOT-1019 > URL: https://issues.apache.org/jira/browse/PIVOT-1019 > Project: Pivot > Issue Type: New Feature > Components: wtk >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1 > > > Similiar to the Ruler component from PIVOT-1017, this would size itself and > display line numbers or column counts when used as a row or column heading > object for a ScrollPane around a TextArea or TextPane (when used with pure > text). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1012) Many places throw IllegalArgumentException during parameter validation, but some are inconsistent
[
https://issues.apache.org/jira/browse/PIVOT-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250550#comment-16250550
]
Roger Whitcomb commented on PIVOT-1012:
---
More cleanup:
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSpinnerSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSplitPaneSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSuggestionPopupSkin.java
Transmitting file data ...done
Committing transaction...
Committed revision 1815161.
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraScrollBarSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraScrollPaneCornerSkin.java
Sendingwtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSheetSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSliderSkin.java
Transmitting file data done
Committing transaction...
Committed revision 1815163.
Sendingwtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraMeterSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraPaletteSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraPanoramaSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraPromptSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraPushButtonSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraRadioButtonSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraRollupSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTabPaneSkin.java
Transmitting file data done
Committing transaction...
Committed revision 1815164.
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraCheckboxSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraColorChooserButtonSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraExpanderSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraLinkButtonSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraListButtonSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraMenuBarSkin.java
Sendingwtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraMenuSkin.java
Transmitting file data ...done
Committing transaction...
Committed revision 1815165.
> Many places throw IllegalArgumentException during parameter validation, but
> some are inconsistent
> -
>
> Key: PIVOT-1012
> URL: https://issues.apache.org/jira/browse/PIVOT-1012
> Project: Pivot
> Issue Type: Improvement
> Components: core, wtk, wtk-terra
> Environment: All
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
>
> Primarily the code looks like this currently:
> {code:java}
> if (param == null)
> throw new IllegalArgumentException(param + " is null");
> {code}
> But not all places have the message in the exception, and not all places
> check the parameters as they should, and not all places have the same message.
> So, regularize this checking everywhere by making common "core" methods to do
> this null check (or other checks, such as <= 0, etc.) so that the checking
> and messaging are common. This also simplifies the code, and with JIT
> compiling shouldn't affect runtime speed either, as this common method should
> get compiled and/or inlined as appropriate.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PIVOT-1012) Many places throw IllegalArgumentException during parameter validation, but some are inconsistent
[
https://issues.apache.org/jira/browse/PIVOT-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250541#comment-16250541
]
Roger Whitcomb commented on PIVOT-1012:
---
Some cleanup in this area:
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTableViewHeaderSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTableViewSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTextInputSkin.java
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTreeViewSkin.java
Transmitting file data done
Committing transaction...
Committed revision 1815160.
> Many places throw IllegalArgumentException during parameter validation, but
> some are inconsistent
> -
>
> Key: PIVOT-1012
> URL: https://issues.apache.org/jira/browse/PIVOT-1012
> Project: Pivot
> Issue Type: Improvement
> Components: core, wtk, wtk-terra
> Environment: All
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
>
> Primarily the code looks like this currently:
> {code:java}
> if (param == null)
> throw new IllegalArgumentException(param + " is null");
> {code}
> But not all places have the message in the exception, and not all places
> check the parameters as they should, and not all places have the same message.
> So, regularize this checking everywhere by making common "core" methods to do
> this null check (or other checks, such as <= 0, etc.) so that the checking
> and messaging are common. This also simplifies the code, and with JIT
> compiling shouldn't affect runtime speed either, as this common method should
> get compiled and/or inlined as appropriate.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PIVOT-1012) Many places throw IllegalArgumentException during parameter validation, but some are inconsistent
[
https://issues.apache.org/jira/browse/PIVOT-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250553#comment-16250553
]
Roger Whitcomb commented on PIVOT-1012:
---
Further cleanup:
Sendingwtk\src\org\apache\pivot\wtk\text\NumberedList.java
Sendingwtk\src\org\apache\pivot\wtk\text\TextNode.java
Transmitting file data ..done
Committing transaction...
Committed revision 1815166.
> Many places throw IllegalArgumentException during parameter validation, but
> some are inconsistent
> -
>
> Key: PIVOT-1012
> URL: https://issues.apache.org/jira/browse/PIVOT-1012
> Project: Pivot
> Issue Type: Improvement
> Components: core, wtk, wtk-terra
> Environment: All
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
>
> Primarily the code looks like this currently:
> {code:java}
> if (param == null)
> throw new IllegalArgumentException(param + " is null");
> {code}
> But not all places have the message in the exception, and not all places
> check the parameters as they should, and not all places have the same message.
> So, regularize this checking everywhere by making common "core" methods to do
> this null check (or other checks, such as <= 0, etc.) so that the checking
> and messaging are common. This also simplifies the code, and with JIT
> compiling shouldn't affect runtime speed either, as this common method should
> get compiled and/or inlined as appropriate.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PIVOT-1012) Many places throw IllegalArgumentException during parameter validation, but some are inconsistent
[
https://issues.apache.org/jira/browse/PIVOT-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250584#comment-16250584
]
Roger Whitcomb commented on PIVOT-1012:
---
Misc. cleanup here:
Sendingtutorials\src\org\apache\pivot\tutorials\explorer\Ruler.java
Sendingtutorials\src\org\apache\pivot\tutorials\navigation\Ruler.java
Transmitting file data ..done
Committing transaction...
Committed revision 1815168.
Sendingwtk\src\org\apache\pivot\wtk\effects\ScaleDecorator.java
Transmitting file data .done
Committing transaction...
Committed revision 1815169.
Sendingwtk\src\org\apache\pivot\wtk\BrowserApplicationContext.java
Sendingwtk\src\org\apache\pivot\wtk\Component.java
Transmitting file data ..done
Committing transaction...
Committed revision 1815170.
Finally here:
Sendingdemos\src\org\apache\pivot\demos\itunes\SearchDemo.java
Sendingdemos\src\org\apache\pivot\demos\xml\NodeRenderer.java
Sendingtests\src\org\apache\pivot\tests\JavascriptConsoleTest.java
Sendingtests\src\org\apache\pivot\tests\issues\Pivot694.java
Sending
tutorials\src\org\apache\pivot\tutorials\bxmlexplorer\FakeWindowSkin.java
Sending
tutorials\src\org\apache\pivot\tutorials\webqueries\AmountBindMapping.java
Transmitting file data ..done
Committing transaction...
Committed revision 1815171.
> Many places throw IllegalArgumentException during parameter validation, but
> some are inconsistent
> -
>
> Key: PIVOT-1012
> URL: https://issues.apache.org/jira/browse/PIVOT-1012
> Project: Pivot
> Issue Type: Improvement
> Components: core, wtk, wtk-terra
> Environment: All
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
>
> Primarily the code looks like this currently:
> {code:java}
> if (param == null)
> throw new IllegalArgumentException(param + " is null");
> {code}
> But not all places have the message in the exception, and not all places
> check the parameters as they should, and not all places have the same message.
> So, regularize this checking everywhere by making common "core" methods to do
> this null check (or other checks, such as <= 0, etc.) so that the checking
> and messaging are common. This also simplifies the code, and with JIT
> compiling shouldn't affect runtime speed either, as this common method should
> get compiled and/or inlined as appropriate.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PIVOT-1011) Move ListenerList implementations of interfaces into the interface itself
[ https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249693#comment-16249693 ] Roger Whitcomb commented on PIVOT-1011: --- Changes to Action and BoxPane and their respective listeners, plus misc. changes for PIVOT-1011 and PIVOT-999: Sendingwtk\src\org\apache\pivot\wtk\Action.java Sendingwtk\src\org\apache\pivot\wtk\ActionClassListener.java Sendingwtk\src\org\apache\pivot\wtk\ActionListener.java Sendingwtk\src\org\apache\pivot\wtk\BoxPane.java Sendingwtk\src\org\apache\pivot\wtk\BoxPaneListener.java Transmitting file data .done Committing transaction... Committed revision 1815112. > Move ListenerList implementations of interfaces into the interface itself > - > > Key: PIVOT-1011 > URL: https://issues.apache.org/jira/browse/PIVOT-1011 > Project: Pivot > Issue Type: Improvement > Components: core-collections, core-util, web, wtk, wtk-terra > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Attachments: 1011.diffs > > > A universal paradigm in Pivot is to have a "listener" interface for a class > or data structure that is used to notify listeners of changes in the > class/data. There is then an "Adapter" static class in the interface file > that implements the interface with default implementations. Then there is a > very separate enclosed static class that implements the "ListenerList" > interface of that listener interface. And usually (or always) this "listener > list" class is defined/used only in the class that needs to notify the > listeners. However, this class must be very parallel to not only the > interface itself, but also the "Adapter" class, and yet it is in a different > place. > So, it seems somewhat reasonable to move all these "listener list" classes > into the interfaces themselves, so all three related things are located in > the same file. A preliminary POC of this concept was done with "Query.java", > and "QueryListener.java" and it looks good. > This doesn't seem to require changes to client code, because the accessor > methods only refer to "ListenerList<>" and not to the listener list class > itself (in order to be more general, of course), but which helps us to hide > the implementing class away inside the interface. > I will attach the diff of the POC, to hopefully make this more clear. It may > seem a somewhat nebulous concept, but the idea is to keep "like things" > together for clarity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PIVOT-1013) Allow button presses to queue the action to be performed instead of doing it directly.
Roger Whitcomb created PIVOT-1013: - Summary: Allow button presses to queue the action to be performed instead of doing it directly. Key: PIVOT-1013 URL: https://issues.apache.org/jira/browse/PIVOT-1013 Project: Pivot Issue Type: Improvement Components: wtk Reporter: Roger Whitcomb Assignee: Roger Whitcomb Priority: Minor In some applications if an action is performed, it will invoke a dialog or open another window. If that action has been triggered from a MenuPopup (so in this case the button will be a MenuButton subclass of Button) the focus will be stolen from the invoked dialog back to the main window by the closing of the MenuPopup. The result is that the user must click another time on the dialog. So, one solution to this dilemma is to queue the action to be performed "later" on the event queue. This allows the menu popup window to close before the action is invoked and therefore the focus can be shifted properly. So, add a property to Button, which will be set by MenuButton to queue the action instead of performing it directly inside "Button.press()". This is a Proof-Of-Concept since I haven't yet figured out how to get this to work properly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-998) Update "trunk" to require Java 8
[ https://issues.apache.org/jira/browse/PIVOT-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251787#comment-16251787 ] Roger Whitcomb commented on PIVOT-998: -- I think that's really it. I have been building with Java 8 for months now, including Jenkins builds. There are now Java 8 features being used in the source, so there is really no turning back now (see PIVOT-999). > Update "trunk" to require Java 8 > > > Key: PIVOT-998 > URL: https://issues.apache.org/jira/browse/PIVOT-998 > Project: Pivot > Issue Type: New Feature > Components: all >Affects Versions: 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb > Fix For: 2.1.0 > > > Since "trunk" is unreleased as of yet, and Java 8 is quite mature, and Java 9 > is due out later this year, and there are features of Java 8 (such as > lambdas) that we would like to take advantage of for new development, it > seems wise to require Java 8 going forward for the "trunk", while leaving the > 2.0.x maintenance branch at Java 6. Previously we had upgraded to requiring > Java 7 for "trunk", but that version is stabilized and no longer being > updated... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-998) Update "trunk" to require Java 8
[ https://issues.apache.org/jira/browse/PIVOT-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-998. Resolution: Fixed > Update "trunk" to require Java 8 > > > Key: PIVOT-998 > URL: https://issues.apache.org/jira/browse/PIVOT-998 > Project: Pivot > Issue Type: New Feature > Components: all >Affects Versions: 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb > Fix For: 2.1.0 > > > Since "trunk" is unreleased as of yet, and Java 8 is quite mature, and Java 9 > is due out later this year, and there are features of Java 8 (such as > lambdas) that we would like to take advantage of for new development, it > seems wise to require Java 8 going forward for the "trunk", while leaving the > 2.0.x maintenance branch at Java 6. Previously we had upgraded to requiring > Java 7 for "trunk", but that version is stabilized and no longer being > updated... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1011) Move ListenerList implementations of interfaces into the interface itself
[ https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282745#comment-16282745 ] Roger Whitcomb commented on PIVOT-1011: --- Update everything done so far with the new convention: Sendingweb\src\org\apache\pivot\web\Query.java Sendingweb\src\org\apache\pivot\web\QueryListener.java Sendingwtk\src\org\apache\pivot\wtk\Action.java Sendingwtk\src\org\apache\pivot\wtk\ActionClassListener.java Sendingwtk\src\org\apache\pivot\wtk\ActionListener.java Sendingwtk\src\org\apache\pivot\wtk\BoxPane.java Sendingwtk\src\org\apache\pivot\wtk\BoxPaneListener.java Sendingwtk\src\org\apache\pivot\wtk\ButtonGroup.java Sendingwtk\src\org\apache\pivot\wtk\ButtonGroupListener.java Sendingwtk\src\org\apache\pivot\wtk\ColorChooser.java Sendingwtk\src\org\apache\pivot\wtk\ColorChooserBindingListener.java Sendingwtk\src\org\apache\pivot\wtk\ColorChooserButton.java Sending wtk\src\org\apache\pivot\wtk\ColorChooserButtonBindingListener.java Sending wtk\src\org\apache\pivot\wtk\ColorChooserButtonSelectionListener.java Sendingwtk\src\org\apache\pivot\wtk\ColorChooserSelectionListener.java Sendingwtk\src\org\apache\pivot\wtk\ScrollPane.java Sendingwtk\src\org\apache\pivot\wtk\ScrollPaneListener.java Sendingwtk\src\org\apache\pivot\wtk\TextInput.java Sendingwtk\src\org\apache\pivot\wtk\TextInputBindingListener.java Sendingwtk\src\org\apache\pivot\wtk\TextInputContentListener.java Sendingwtk\src\org\apache\pivot\wtk\TextInputListener.java Sendingwtk\src\org\apache\pivot\wtk\TextInputSelectionListener.java Transmitting file data ..done Committing transaction... Committed revision 1817442. > Move ListenerList implementations of interfaces into the interface itself > - > > Key: PIVOT-1011 > URL: https://issues.apache.org/jira/browse/PIVOT-1011 > Project: Pivot > Issue Type: Improvement > Components: core-collections, core-util, web, wtk, wtk-terra > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Attachments: 1011.diffs > > > A universal paradigm in Pivot is to have a "listener" interface for a class > or data structure that is used to notify listeners of changes in the > class/data. There is then an "Adapter" static class in the interface file > that implements the interface with default implementations. Then there is a > very separate enclosed static class that implements the "ListenerList" > interface of that listener interface. And usually (or always) this "listener > list" class is defined/used only in the class that needs to notify the > listeners. However, this class must be very parallel to not only the > interface itself, but also the "Adapter" class, and yet it is in a different > place. > So, it seems somewhat reasonable to move all these "listener list" classes > into the interfaces themselves, so all three related things are located in > the same file. A preliminary POC of this concept was done with "Query.java", > and "QueryListener.java" and it looks good. > This doesn't seem to require changes to client code, because the accessor > methods only refer to "ListenerList<>" and not to the listener list class > itself (in order to be more general, of course), but which helps us to hide > the implementing class away inside the interface. > I will attach the diff of the POC, to hopefully make this more clear. It may > seem a somewhat nebulous concept, but the idea is to keep "like things" > together for clarity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-498) Revisit use of Executors.newCachedThreadPool() in Task class
[ https://issues.apache.org/jira/browse/PIVOT-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282244#comment-16282244 ] Roger Whitcomb commented on PIVOT-498: -- Move the "DefaultExecutorService" out of "Task.java" into its own class: "SimpleExecutorService" and change the default for Task, etc. to be "Executors.newCachedThreadPool()". Tests run fine, our (large) application runs fine, and the workaround can still be applied if necessary using this new/old class. Adding core\src\org\apache\pivot\util\concurrent\SimpleExecutorService.java Sendingcore\src\org\apache\pivot\util\concurrent\Task.java Transmitting file data ..done Committing transaction... Committed revision 1817402. > Revisit use of Executors.newCachedThreadPool() in Task class > > > Key: PIVOT-498 > URL: https://issues.apache.org/jira/browse/PIVOT-498 > Project: Pivot > Issue Type: Task > Components: core-util >Reporter: Greg Brown >Assignee: Roger Whitcomb > Fix For: 2.5 > > > There appears to be an issue with Executors.newCachedThreadPool() when > running as an applet. IllegalThreadStateExceptions are thrown periodically > and seemingly unpredictably. The current workaround uses a custom > ExecutorService that simply dispatches requests to new threads as they are > received. However, this is not optimal and a better solution should be found, > if possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-891) Fixes to selection logic in TextArea and TextPane
[ https://issues.apache.org/jira/browse/PIVOT-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282816#comment-16282816 ] Roger Whitcomb commented on PIVOT-891: -- Oops! Correct the Javadoc in SelectDirection that was obsolete even before checking it in... Sendingwtk\src\org\apache\pivot\wtk\SelectDirection.java Transmitting file data .done Committing transaction... Committed revision 1817445. > Fixes to selection logic in TextArea and TextPane > - > > Key: PIVOT-891 > URL: https://issues.apache.org/jira/browse/PIVOT-891 > Project: Pivot > Issue Type: Improvement > Components: wtk-terra >Affects Versions: 2.0.2, 2.0.4 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Labels: text-selection > Fix For: 2.0.3, 2.1 > > > Currently (in TextArea at least) if you type Shift-Down and select a line or > two, then do Shift-Up it will extend the beginning of the area, instead of > reducing the end that you just extended. This is not how any other editor > works. > Also would like to have double-click select the "word" the mouse is pointing > to, as other editors do. > We'd like TextArea and TextPane (at least, maybe TextInput also) do the same > things. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-891) Fixes to selection logic in TextArea and TextPane
[ https://issues.apache.org/jira/browse/PIVOT-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282809#comment-16282809 ] Roger Whitcomb commented on PIVOT-891: -- Revisited TextInput with a new "SelectDirection" enum being used (in preparation for TextArea and TextPane): Adding wtk\src\org\apache\pivot\wtk\SelectDirection.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTextInputSkin.java Transmitting file data ..done Committing transaction... Committed revision 1817444. Note: there may be a slight bug when starting left from end of text, then back right to the end again... > Fixes to selection logic in TextArea and TextPane > - > > Key: PIVOT-891 > URL: https://issues.apache.org/jira/browse/PIVOT-891 > Project: Pivot > Issue Type: Improvement > Components: wtk-terra >Affects Versions: 2.0.2, 2.0.4 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Labels: text-selection > Fix For: 2.0.3, 2.1 > > > Currently (in TextArea at least) if you type Shift-Down and select a line or > two, then do Shift-Up it will extend the beginning of the area, instead of > reducing the end that you just extended. This is not how any other editor > works. > Also would like to have double-click select the "word" the mouse is pointing > to, as other editors do. > We'd like TextArea and TextPane (at least, maybe TextInput also) do the same > things. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1012) Many places throw IllegalArgumentException during parameter validation, but some are inconsistent
[
https://issues.apache.org/jira/browse/PIVOT-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16284130#comment-16284130
]
Roger Whitcomb commented on PIVOT-1012:
---
Changes to Separator and skin classes (plus changes for PIVOT-999, PIVOT-1011,
and PIVOT-1014):
Sending wtk\src\org\apache\pivot\wtk\Separator.java
Sending wtk\src\org\apache\pivot\wtk\SeparatorListener.java
Sending wtk\src\org\apache\pivot\wtk\skin\SeparatorSkin.java
Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSeparatorSkin.java
Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\terra_theme_defaults.json
Transmitting file data .done
Committing transaction...
Committed revision 1817553.
> Many places throw IllegalArgumentException during parameter validation, but
> some are inconsistent
> -
>
> Key: PIVOT-1012
> URL: https://issues.apache.org/jira/browse/PIVOT-1012
> Project: Pivot
> Issue Type: Improvement
> Components: core, wtk, wtk-terra
> Environment: All
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
>
> Primarily the code looks like this currently:
> {code:java}
> if (param == null)
> throw new IllegalArgumentException(param + " is null");
> {code}
> But not all places have the message in the exception, and not all places
> check the parameters as they should, and not all places have the same message.
> So, regularize this checking everywhere by making common "core" methods to do
> this null check (or other checks, such as <= 0, etc.) so that the checking
> and messaging are common. This also simplifies the code, and with JIT
> compiling shouldn't affect runtime speed either, as this common method should
> get compiled and/or inlined as appropriate.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (PIVOT-999) Update code to take advantage of Java 8 features
[ https://issues.apache.org/jira/browse/PIVOT-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16284125#comment-16284125 ] Roger Whitcomb edited comment on PIVOT-999 at 12/8/17 7:50 PM: --- Changes to Separator and skin classes (plus changes for PIVOT-1011, PIVOT-1012, and PIVOT-1014): Sendingwtk\src\org\apache\pivot\wtk\Separator.java Sendingwtk\src\org\apache\pivot\wtk\SeparatorListener.java Sendingwtk\src\org\apache\pivot\wtk\skin\SeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\terra_theme_defaults.json Transmitting file data .done Committing transaction... Committed revision 1817553. was (Author: rwhitcomb): Changes to Separator and skin classes (plus changes for PIVOT-1011, PIVOT-1012, and Pivot-1014): Sendingwtk\src\org\apache\pivot\wtk\Separator.java Sendingwtk\src\org\apache\pivot\wtk\SeparatorListener.java Sendingwtk\src\org\apache\pivot\wtk\skin\SeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\terra_theme_defaults.json Transmitting file data .done Committing transaction... Committed revision 1817553. > Update code to take advantage of Java 8 features > > > Key: PIVOT-999 > URL: https://issues.apache.org/jira/browse/PIVOT-999 > Project: Pivot > Issue Type: New Feature > Components: all >Affects Versions: 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb > Fix For: 2.1 > > > Some features that we could potentially use include: > * default methods in interfaces to extend features while maintaining backward > compatibility > * lambdas for such things as callbacks > * really use functional interfaces (already kind of present, but not really > used) > * "forEach" in many places for Iterable collections -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-999) Update code to take advantage of Java 8 features
[ https://issues.apache.org/jira/browse/PIVOT-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16284125#comment-16284125 ] Roger Whitcomb commented on PIVOT-999: -- Changes to Separator and skin classes (plus changes for PIVOT-1011, PIVOT-1012, and Pivot-1014): Sendingwtk\src\org\apache\pivot\wtk\Separator.java Sendingwtk\src\org\apache\pivot\wtk\SeparatorListener.java Sendingwtk\src\org\apache\pivot\wtk\skin\SeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\terra_theme_defaults.json Transmitting file data .done Committing transaction... Committed revision 1817553. > Update code to take advantage of Java 8 features > > > Key: PIVOT-999 > URL: https://issues.apache.org/jira/browse/PIVOT-999 > Project: Pivot > Issue Type: New Feature > Components: all >Affects Versions: 2.1 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb > Fix For: 2.1 > > > Some features that we could potentially use include: > * default methods in interfaces to extend features while maintaining backward > compatibility > * lambdas for such things as callbacks > * really use functional interfaces (already kind of present, but not really > used) > * "forEach" in many places for Iterable collections -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1011) Move ListenerList implementations of interfaces into the interface itself
[ https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16284127#comment-16284127 ] Roger Whitcomb commented on PIVOT-1011: --- Changes to Separator and skin classes (plus changes for PIVOT-999, PIVOT-1012, and Pivot-1014): Sending wtk\src\org\apache\pivot\wtk\Separator.java Sending wtk\src\org\apache\pivot\wtk\SeparatorListener.java Sending wtk\src\org\apache\pivot\wtk\skin\SeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\terra_theme_defaults.json Transmitting file data .done Committing transaction... Committed revision 1817553. > Move ListenerList implementations of interfaces into the interface itself > - > > Key: PIVOT-1011 > URL: https://issues.apache.org/jira/browse/PIVOT-1011 > Project: Pivot > Issue Type: Improvement > Components: core-collections, core-util, web, wtk, wtk-terra > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Attachments: 1011.diffs > > > A universal paradigm in Pivot is to have a "listener" interface for a class > or data structure that is used to notify listeners of changes in the > class/data. There is then an "Adapter" static class in the interface file > that implements the interface with default implementations. Then there is a > very separate enclosed static class that implements the "ListenerList" > interface of that listener interface. And usually (or always) this "listener > list" class is defined/used only in the class that needs to notify the > listeners. However, this class must be very parallel to not only the > interface itself, but also the "Adapter" class, and yet it is in a different > place. > So, it seems somewhat reasonable to move all these "listener list" classes > into the interfaces themselves, so all three related things are located in > the same file. A preliminary POC of this concept was done with "Query.java", > and "QueryListener.java" and it looks good. > This doesn't seem to require changes to client code, because the accessor > methods only refer to "ListenerList<>" and not to the listener list class > itself (in order to be more general, of course), but which helps us to hide > the implementing class away inside the interface. > I will attach the diff of the POC, to hopefully make this more clear. It may > seem a somewhat nebulous concept, but the idea is to keep "like things" > together for clarity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (PIVOT-1011) Move ListenerList implementations of interfaces into the interface itself
[ https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16284127#comment-16284127 ] Roger Whitcomb edited comment on PIVOT-1011 at 12/8/17 7:49 PM: Changes to Separator and skin classes (plus changes for PIVOT-999, PIVOT-1012, and PIVOT-1014): Sending wtk\src\org\apache\pivot\wtk\Separator.java Sending wtk\src\org\apache\pivot\wtk\SeparatorListener.java Sending wtk\src\org\apache\pivot\wtk\skin\SeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\terra_theme_defaults.json Transmitting file data .done Committing transaction... Committed revision 1817553. was (Author: rwhitcomb): Changes to Separator and skin classes (plus changes for PIVOT-999, PIVOT-1012, and Pivot-1014): Sending wtk\src\org\apache\pivot\wtk\Separator.java Sending wtk\src\org\apache\pivot\wtk\SeparatorListener.java Sending wtk\src\org\apache\pivot\wtk\skin\SeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSeparatorSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\terra_theme_defaults.json Transmitting file data .done Committing transaction... Committed revision 1817553. > Move ListenerList implementations of interfaces into the interface itself > - > > Key: PIVOT-1011 > URL: https://issues.apache.org/jira/browse/PIVOT-1011 > Project: Pivot > Issue Type: Improvement > Components: core-collections, core-util, web, wtk, wtk-terra > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Attachments: 1011.diffs > > > A universal paradigm in Pivot is to have a "listener" interface for a class > or data structure that is used to notify listeners of changes in the > class/data. There is then an "Adapter" static class in the interface file > that implements the interface with default implementations. Then there is a > very separate enclosed static class that implements the "ListenerList" > interface of that listener interface. And usually (or always) this "listener > list" class is defined/used only in the class that needs to notify the > listeners. However, this class must be very parallel to not only the > interface itself, but also the "Adapter" class, and yet it is in a different > place. > So, it seems somewhat reasonable to move all these "listener list" classes > into the interfaces themselves, so all three related things are located in > the same file. A preliminary POC of this concept was done with "Query.java", > and "QueryListener.java" and it looks good. > This doesn't seem to require changes to client code, because the accessor > methods only refer to "ListenerList<>" and not to the listener list class > itself (in order to be more general, of course), but which helps us to hide > the implementing class away inside the interface. > I will attach the diff of the POC, to hopefully make this more clear. It may > seem a somewhat nebulous concept, but the idea is to keep "like things" > together for clarity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1014) Specify skin default styles in JSON file so they can be easily changed
[
https://issues.apache.org/jira/browse/PIVOT-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16284131#comment-16284131
]
Roger Whitcomb commented on PIVOT-1014:
---
Changes to Separator and skin classes (plus changes for PIVOT-999, PIVOT-1011,
and PIVOT-1012):
Sending wtk\src\org\apache\pivot\wtk\Separator.java
Sending wtk\src\org\apache\pivot\wtk\SeparatorListener.java
Sending wtk\src\org\apache\pivot\wtk\skin\SeparatorSkin.java
Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraSeparatorSkin.java
Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\terra_theme_defaults.json
Transmitting file data .done
Committing transaction...
Committed revision 1817553.
> Specify skin default styles in JSON file so they can be easily changed
> --
>
> Key: PIVOT-1014
> URL: https://issues.apache.org/jira/browse/PIVOT-1014
> Project: Pivot
> Issue Type: Improvement
> Components: wtk-terra
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
>
> I have noticed some inconsistencies in the way default styles (things like
> colors, fonts, padding/margins, etc.) are set in the constructors of the
> Terra*Skin classes, such as:
> * Color values set directly from the theme vs. set through the setter methods.
> * Missing color setter methods using the theme color index.
> * Derived colors being set in two different places, potentially leading to
> inconsistencies because of the duplication.
> * Possible inconsistencies between controls in the theme colors used (such as
> for backgrounds, borders, etc.) -- this has not been verified, because it
> will require a lot of research.
> * Since these defaults are all set in code, even though (for instance) the
> theme colors themselves are set in the "TerraTheme_default.json" file,
> changing the overall look-and-feel is difficult at present.
> So, for all these reasons I propose to use a new "terra_theme_defaults.json"
> file, which can be overridden by a new setting in the "TerraTheme*.json"
> file(s) which will set all the defaults for all the Terra*Skin classes
> similar to this (taken from TerraExpanderSkin):
> Previously:
> {code:java}
>setBackgroundColor(theme.getColor(4));
>titleBarBackgroundColor = theme.getColor(10);
>titleBarBorderColor = theme.getColor(7);
>titleBarColor = theme.getColor(12);
>shadeButtonColor = theme.getColor(12);
>disabledShadeButtonColor = theme.getColor(7);
>borderColor = theme.getColor(7);
>padding = new Insets(4);
> {code}
> New:
> {code:java}
> TerraExpanderSkin : {
> backgroundColor : 4,
> titleBarBackgroundColor : 10,
> titleBarBorderColor : 7,
> titleBarColor : 12,
> shadeButtonColor : 12,
> disabledShadeButtonColor : 7,
> borderColor : 7,
> padding : 4
> },
> {code}
> Note: this approach also fits well with the overall Pivot philosophy of doing
> things in a "declarative" fashion (via BXML / JSON files) rather than in
> code, where possible.
> I have prototyped this in a couple of classes and it seems to work well, AND
> it has revealed a number of the color properties that were missing the
> "setXXX(int index)" methods.
> Note: there is potential for slowdown during control construction since we're
> executing a LOT more code to set these defaults (including expensive
> reflection operations inside BeanAdapter), but I have not yet been able to
> measure the speed differential to see if it will be of concern.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (PIVOT-777) Antialias on Labels, configure the desired mode (overriding defaults)
[ https://issues.apache.org/jira/browse/PIVOT-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-777: Assignee: Roger Whitcomb > Antialias on Labels, configure the desired mode (overriding defaults) > - > > Key: PIVOT-777 > URL: https://issues.apache.org/jira/browse/PIVOT-777 > Project: Pivot > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Sandro Martini >Assignee: Roger Whitcomb >Priority: Minor > Labels: alias, antialias, label, text > Fix For: 2.5 > > > To change the default value of antialias on Labels, verify if add to the > Platform class, a setFontRenderContext() method, so applications can control > this value. > Some reference here: > http://apache-pivot-users.399431.n3.nabble.com/Anti-Aliased-Labels-td3195802.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PIVOT-900) Allow Query responses for HTTP methods other than GET
[ https://issues.apache.org/jira/browse/PIVOT-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-900: Assignee: Roger Whitcomb (was: Sandro Martini) > Allow Query responses for HTTP methods other than GET > - > > Key: PIVOT-900 > URL: https://issues.apache.org/jira/browse/PIVOT-900 > Project: Pivot > Issue Type: Improvement > Components: web >Reporter: Steven Swor >Assignee: Roger Whitcomb > Fix For: 2.2 > > Attachments: GetQuery.patch, PostQueryWithResult.java, Query.patch > > > Currently, > org.apache.pivot.web.Query.execute(org.apache.pivot.web.Query.Method, Object) > is hard-coded to only deserialize an object from the response body if the > method used is GET. However, there are situations where other methods such > as POST are used and the server will still return a response instead of a > redirect (such as non-RESTful web services or workarounds for large query > strings). > This issue is complicated because the method directly accesses several > private-scoped variables (such as status, bytesSent, bytesReceived, and > bytesExpected), which makes it difficult to override this method. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1011) Move ListenerList implementations of interfaces into the interface itself
[ https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279479#comment-16279479 ] Roger Whitcomb commented on PIVOT-1011: --- Did this for TextInput: Sendingwtk\src\org\apache\pivot\wtk\TextInput.java Sendingwtk\src\org\apache\pivot\wtk\TextInputBindingListener.java Sendingwtk\src\org\apache\pivot\wtk\TextInputContentListener.java Sendingwtk\src\org\apache\pivot\wtk\TextInputListener.java Sendingwtk\src\org\apache\pivot\wtk\TextInputSelectionListener.java Transmitting file data .done Committing transaction... Committed revision 1817255. > Move ListenerList implementations of interfaces into the interface itself > - > > Key: PIVOT-1011 > URL: https://issues.apache.org/jira/browse/PIVOT-1011 > Project: Pivot > Issue Type: Improvement > Components: core-collections, core-util, web, wtk, wtk-terra > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Attachments: 1011.diffs > > > A universal paradigm in Pivot is to have a "listener" interface for a class > or data structure that is used to notify listeners of changes in the > class/data. There is then an "Adapter" static class in the interface file > that implements the interface with default implementations. Then there is a > very separate enclosed static class that implements the "ListenerList" > interface of that listener interface. And usually (or always) this "listener > list" class is defined/used only in the class that needs to notify the > listeners. However, this class must be very parallel to not only the > interface itself, but also the "Adapter" class, and yet it is in a different > place. > So, it seems somewhat reasonable to move all these "listener list" classes > into the interfaces themselves, so all three related things are located in > the same file. A preliminary POC of this concept was done with "Query.java", > and "QueryListener.java" and it looks good. > This doesn't seem to require changes to client code, because the accessor > methods only refer to "ListenerList<>" and not to the listener list class > itself (in order to be more general, of course), but which helps us to hide > the implementing class away inside the interface. > I will attach the diff of the POC, to hopefully make this more clear. It may > seem a somewhat nebulous concept, but the idea is to keep "like things" > together for clarity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-939) Unable to Build in Jenkins with Java 8
[ https://issues.apache.org/jira/browse/PIVOT-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-939. Resolution: Fixed Jenkins builds on Java 8 are working fine now for quite a while. > Unable to Build in Jenkins with Java 8 > -- > > Key: PIVOT-939 > URL: https://issues.apache.org/jira/browse/PIVOT-939 > Project: Pivot > Issue Type: Improvement > Components: wtk > Environment: OpenJDK 8 >Reporter: Sandro Martini >Assignee: Sandro Martini > Fix For: 2.1 > > > Jenkins Job for building trunk with Java 8 (using OpenJDK 8 on Ubuntu): > https://builds.apache.org/job/Pivot-trunk%20on%20Java%208/ > generate a compile error, see: > https://builds.apache.org/job/Pivot-trunk%20on%20Java%208/1/console > or even here: > http://apache-pivot-developers.417237.n3.nabble.com/Build-failed-in-Jenkins-Pivot-trunk-on-Java-8-1-td4026511.html > This is the error: > [javac] /x1/jenkins/jenkins-slave/workspace/Pivot-trunk on Java > 8/pivot_trunk/wtk/src/org/apache/pivot/wtk/BrowserApplicationContext.java:395: > error: cannot find symbol > [javac] JSObject window = > JSObject.getWindow(applicationHostApplet); > [javac] ^ > [javac] symbol: method getWindow(HostApplet) > [javac] location: class JSObject > Check if this happens even with Oracle JDK 8. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-891) Fixes to selection logic in TextArea and TextPane
[
https://issues.apache.org/jira/browse/PIVOT-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279388#comment-16279388
]
Roger Whitcomb commented on PIVOT-891:
--
Double- and triple-click support in TextInput ("trunk"):
Sending
wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraTextInputSkin.java
Transmitting file data .done
Committing transaction...
Committed revision 1817251.
> Fixes to selection logic in TextArea and TextPane
> -
>
> Key: PIVOT-891
> URL: https://issues.apache.org/jira/browse/PIVOT-891
> Project: Pivot
> Issue Type: Improvement
> Components: wtk-terra
>Affects Versions: 2.0.2, 2.0.4
> Environment: All
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Labels: text-selection
> Fix For: 2.0.3, 2.1
>
>
> Currently (in TextArea at least) if you type Shift-Down and select a line or
> two, then do Shift-Up it will extend the beginning of the area, instead of
> reducing the end that you just extended. This is not how any other editor
> works.
> Also would like to have double-click select the "word" the mouse is pointing
> to, as other editors do.
> We'd like TextArea and TextPane (at least, maybe TextInput also) do the same
> things.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PIVOT-1011) Move ListenerList implementations of interfaces into the interface itself
[ https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279708#comment-16279708 ] Roger Whitcomb commented on PIVOT-1011: --- And ColorChooser, ColorChooserButton: Sendingwtk\src\org\apache\pivot\wtk\ColorChooser.java Sendingwtk\src\org\apache\pivot\wtk\ColorChooserBindingListener.java Sendingwtk\src\org\apache\pivot\wtk\ColorChooserButton.java Sending wtk\src\org\apache\pivot\wtk\ColorChooserButtonBindingListener.java Sending wtk\src\org\apache\pivot\wtk\ColorChooserButtonSelectionListener.java Sendingwtk\src\org\apache\pivot\wtk\ColorChooserSelectionListener.java Transmitting file data ..done Committing transaction... Committed revision 1817268. > Move ListenerList implementations of interfaces into the interface itself > - > > Key: PIVOT-1011 > URL: https://issues.apache.org/jira/browse/PIVOT-1011 > Project: Pivot > Issue Type: Improvement > Components: core-collections, core-util, web, wtk, wtk-terra > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Attachments: 1011.diffs > > > A universal paradigm in Pivot is to have a "listener" interface for a class > or data structure that is used to notify listeners of changes in the > class/data. There is then an "Adapter" static class in the interface file > that implements the interface with default implementations. Then there is a > very separate enclosed static class that implements the "ListenerList" > interface of that listener interface. And usually (or always) this "listener > list" class is defined/used only in the class that needs to notify the > listeners. However, this class must be very parallel to not only the > interface itself, but also the "Adapter" class, and yet it is in a different > place. > So, it seems somewhat reasonable to move all these "listener list" classes > into the interfaces themselves, so all three related things are located in > the same file. A preliminary POC of this concept was done with "Query.java", > and "QueryListener.java" and it looks good. > This doesn't seem to require changes to client code, because the accessor > methods only refer to "ListenerList<>" and not to the listener list class > itself (in order to be more general, of course), but which helps us to hide > the implementing class away inside the interface. > I will attach the diff of the POC, to hopefully make this more clear. It may > seem a somewhat nebulous concept, but the idea is to keep "like things" > together for clarity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1011) Move ListenerList implementations of interfaces into the interface itself
[ https://issues.apache.org/jira/browse/PIVOT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279702#comment-16279702 ] Roger Whitcomb commented on PIVOT-1011: --- ScrollPane (in "trunk"): Sendingwtk\src\org\apache\pivot\wtk\ScrollPane.java Sendingwtk\src\org\apache\pivot\wtk\ScrollPaneListener.java Sendingwtk\src\org\apache\pivot\wtk\skin\ScrollPaneSkin.java Transmitting file data ...done Committing transaction... Committed revision 1817267. > Move ListenerList implementations of interfaces into the interface itself > - > > Key: PIVOT-1011 > URL: https://issues.apache.org/jira/browse/PIVOT-1011 > Project: Pivot > Issue Type: Improvement > Components: core-collections, core-util, web, wtk, wtk-terra > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Attachments: 1011.diffs > > > A universal paradigm in Pivot is to have a "listener" interface for a class > or data structure that is used to notify listeners of changes in the > class/data. There is then an "Adapter" static class in the interface file > that implements the interface with default implementations. Then there is a > very separate enclosed static class that implements the "ListenerList" > interface of that listener interface. And usually (or always) this "listener > list" class is defined/used only in the class that needs to notify the > listeners. However, this class must be very parallel to not only the > interface itself, but also the "Adapter" class, and yet it is in a different > place. > So, it seems somewhat reasonable to move all these "listener list" classes > into the interfaces themselves, so all three related things are located in > the same file. A preliminary POC of this concept was done with "Query.java", > and "QueryListener.java" and it looks good. > This doesn't seem to require changes to client code, because the accessor > methods only refer to "ListenerList<>" and not to the listener list class > itself (in order to be more general, of course), but which helps us to hide > the implementing class away inside the interface. > I will attach the diff of the POC, to hopefully make this more clear. It may > seem a somewhat nebulous concept, but the idea is to keep "like things" > together for clarity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PIVOT-886) Make BXMLSerializer more extendable
[
https://issues.apache.org/jira/browse/PIVOT-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Whitcomb reassigned PIVOT-886:
Assignee: Roger Whitcomb (was: Sandro Martini)
> Make BXMLSerializer more extendable
> ---
>
> Key: PIVOT-886
> URL: https://issues.apache.org/jira/browse/PIVOT-886
> Project: Pivot
> Issue Type: Improvement
>Reporter: Karel Hübl
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.5
>
>
> If I want to extend BXMLSerializer, I need also to change static MimeTypes
> map on BXMLSerializer:
> For example:
> public class InjectingSerializer extends BXMLSerializer {
> static {
> BXMLSerializer.getMimeTypes().put(MIME_TYPE,
> InjectingSerializer.class);
> }
> ...
> May be the MimeTypes map should be instance variable and implicit mapping of
> MIME_TYPE should be this.getClass(), so one does not need to change mapping
> of MimeTypes when extending BXMLSerializer.
> May be implementation of AbstractFactory pattern for Pivot serializer should
> be considered.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (PIVOT-37) Additional calendar features
[ https://issues.apache.org/jira/browse/PIVOT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-37: --- Assignee: Roger Whitcomb > Additional calendar features > > > Key: PIVOT-37 > URL: https://issues.apache.org/jira/browse/PIVOT-37 > Project: Pivot > Issue Type: Improvement > Components: wtk >Reporter: Greg Brown >Assignee: Roger Whitcomb > Fix For: 2.5 > > > Add support for multiple selection and bounded selection ranges (from/to). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PIVOT-838) TextArea - removed text event, unable to retrieve removed text
[ https://issues.apache.org/jira/browse/PIVOT-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-838: Assignee: Roger Whitcomb > TextArea - removed text event, unable to retrieve removed text > -- > > Key: PIVOT-838 > URL: https://issues.apache.org/jira/browse/PIVOT-838 > Project: Pivot > Issue Type: Bug > Components: wtk >Affects Versions: 2.0.1, 2.0.2 >Reporter: Imbue Lab >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.5 > > > There is no possibility to get information about text removed from TextArea > component. In the ParagraphListener there are two methods: > - void textInserted(Paragraph paragraph, int index, int count) - this one is > OK, information about inserted text can be retrieved from the paragraph's > CharSequence (using getCharacters() method), there is everything what is > needed: index and count > - void textRemoved(Paragraph paragraph, int index, int count) - here the > problem begins, paragraph received as parameter has no text that was removed > because it has been already removed. > Of course one can make a deep copy of paragraph's characters (every time it > changed) and search for removed text using previously created copy, but is it > really too expensive. > I checked the source and in the TextArea.Paragraph class in the method void > removeText(int index, int count) there is a line where real text removal > operation takes place: characters.delete(index, index + count), but removed > text is not stored or passed to any of the listeners. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PIVOT-884) Add support for dynamic construction of ListenerList
[ https://issues.apache.org/jira/browse/PIVOT-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-884: Assignee: Roger Whitcomb (was: Sandro Martini) > Add support for dynamic construction of ListenerList > > > Key: PIVOT-884 > URL: https://issues.apache.org/jira/browse/PIVOT-884 > Project: Pivot > Issue Type: New Feature > Components: core-beans >Reporter: Karel Hübl >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.5 > > Attachments: Pivot-sample.zip > > > As a Pivot application developer I would like to have option to dynamically > create ListenerList implementation to support my custom Listener interface. I > do not want to implement for each application Listener interface event > dispatching logic. I use custom Listener interfaces to enable property > binding between my application model classes and Pivot components in BXML. > I implemented prototype of org.apache.pivot.util.listener.DynaListenerList > class, which accepts Listener interface in constructor and provides event > dispatcher in getEventDispatcher() method. Source will be attached, please > consider this functionality in next Pivot release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PIVOT-868) Improvement in clear() and clearSelection() methods in Buttons
[ https://issues.apache.org/jira/browse/PIVOT-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-868: Assignee: Roger Whitcomb (was: Sandro Martini) > Improvement in clear() and clearSelection() methods in Buttons > -- > > Key: PIVOT-868 > URL: https://issues.apache.org/jira/browse/PIVOT-868 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3 >Reporter: Sandro Martini >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.5 > > > Enhance clear and clearSelection even in Buttons (all other components should > be Ok now). > Use the Pivot694.java test application to test all missing components for > this enhancement. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PIVOT-841) TextArea - ParagraphListener - textInserted method problem - count is equal 0
[
https://issues.apache.org/jira/browse/PIVOT-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Whitcomb reassigned PIVOT-841:
Assignee: Roger Whitcomb
> TextArea - ParagraphListener - textInserted method problem - count is equal 0
> -
>
> Key: PIVOT-841
> URL: https://issues.apache.org/jira/browse/PIVOT-841
> Project: Pivot
> Issue Type: Bug
> Components: wtk
>Affects Versions: 2.0.1, 2.0.2
> Environment: Windows 7, Java 1.7.0_01
>Reporter: Imbue Lab
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.5
>
>
> I use TextArea and want to listen to the inserted text (simply by using
> keyboard). I do it using ParagraphListener. Every time new character is typed
> a listener's method textInserted(Paragraph paragraph, int index, int count)
> is invoked. Everything works fine till I press ENTER. In that case
> textInserted method is invoked with "count" parameter set to 0. Does it make
> any sense?
> I've prepared the simplest example I could imagine, it looks ugly, but it's
> simple and works :-)
> Please take a look on the code below and description after it:
> import org.apache.pivot.collections.Map;
> import org.apache.pivot.wtk.Application;
> import org.apache.pivot.wtk.DesktopApplicationContext;
> import org.apache.pivot.wtk.Display;
> import org.apache.pivot.wtk.TextArea;
> import org.apache.pivot.wtk.TextArea.Paragraph;
> import org.apache.pivot.wtk.TextArea.ParagraphListener;
> import org.apache.pivot.wtk.TextAreaContentListener;
> import org.apache.pivot.wtk.Window;
> public class TextAreaListenersExample extends Application.Adapter {
> @Override
> public void startup(Display display, Map properties) throws
> Exception {
> TextArea textArea = new TextArea();
> textArea.setText("abcxyz");
> //---
> final ParagraphListener paragraphListener = new
> ParagraphListener.Adapter() {
> @Override
> public void textInserted(Paragraph paragraph, int index, int count) {
> System.out.println("Text inserted\n\tparagraph content: '" +
> paragraph.getCharacters() + "" + "'\n\tindex: " + index + "\n\tcount: " +
> count);
> }
> @Override
> public void textRemoved(Paragraph paragraph, int index, int count) {
> System.out.println("Text removed\n\tparagraph content: '" +
> paragraph.getCharacters() + "'\n\tindex: " + index + "\n\tcount: " + count);
> }
> };
>
>
> textArea.getParagraphs().get(0).getParagraphListeners().add(paragraphListener);
>
> textArea.getTextAreaContentListeners().add(new
> TextAreaContentListener.Adapter() {
> @Override
> public void paragraphInserted(TextArea textArea, int index) {
> Paragraph paragraph = textArea.getParagraphs().get(index);
>
> System.out.println("Paragraph inserted\n\tparagraph content: '" +
> paragraph.getCharacters() + "'\n\tindex: " + index);
>
> paragraph.getParagraphListeners().add(paragraphListener);
> }
> });
>
> Window window = new Window(textArea);
>
> window.open(display);
> }
> public static void main(String[] args) throws Exception {
> DesktopApplicationContext.main(TextAreaListenersExample.class, new
> String[0]);
> }
> }
> When you place carret after the "c" character in the TextArea and press
> ENTER, you get following output:
> Text removed
> paragraph content: 'abc' <- text 'xyz' was removed from the first
> paragraph 'abcxyz'
> index: 3
> count: 3
> Text inserted
> paragraph content: 'abc' <- first paragraph insertion, probably it was
> ENTER
> index: 3
> count: 0 <- count is 0!!!
> Paragraph inserted
> paragraph content: 'xyz' <- new paragraph is inserted together with the
> content
> index: 1
> Text inserted
> paragraph content: 'xyz' <- I don't know why insertion happens here
> index: 0
> count: 0 <- again, count is 0!!!
> One more thing, maybe it would be better to have paragraph insertion without
> any content (not like it is now), and after that text insertion with the all
> content of the new created paragraph, it would be more intuitive and easier
> to handle, I really struggle with that now. Can you consider that?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (PIVOT-666) JVM Crash
[ https://issues.apache.org/jira/browse/PIVOT-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-666. > JVM Crash > - > > Key: PIVOT-666 > URL: https://issues.apache.org/jira/browse/PIVOT-666 > Project: Pivot > Issue Type: Bug >Affects Versions: 1.5.1 > Environment: Windows XP >Reporter: LG >Priority: Blocker > > The customer complains about frequent and random JVM crash when using our > application. > The JVM crash log tells that the crash occured in the awt.dll > This occured with the JRE 6.0_17 version and I tried to update to the latest > version but the crash happens again > Here is the dump of the JVM crash > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d0f0f1d, pid=3492, > tid=2688 > # > # JRE version: 6.0_17-b04 > # Java VM: Java HotSpot(TM) Client VM (14.3-b01 mixed mode windows-x86 ) > # Problematic frame: > # C [awt.dll+0x40f1d] > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > --- T H R E A D --- > Current thread (0x4732a400): JavaThread "AWT-Windows" daemon > [_thread_in_native, id=2688, stack(0x4782,0x4787)] > siginfo: ExceptionCode=0xc005, writing address 0xe2073380 > Registers: > EAX=0x02d03b94, EBX=0x0040, ECX=0x0010, EDX=0xe2073380 > ESP=0x4786f294, EBP=0x0040, ESI=0x02d03b94, EDI=0xe2073380 > EIP=0x6d0f0f1d, EFLAGS=0x00010212 > Top of Stack: (sp=0x4786f294) > 0x4786f294: 4786f2f0 0010 4786f374 0010 > 0x4786f2a4: 6d15aa27 0040 0400 0010 > 0x4786f2b4: 0010 4786f4f0 4786f2f0 > 0x4786f2c4: 0010 4741eb70 0100 > 0x4786f2d4: 00114d40 0400 e2073380 > 0x4786f2e4: 0010 0010 > 0x4786f2f4: 0010 0010 > 0x4786f304: 0004 0400 > Instructions: (pc=0x6d0f0f1d) > 0x6d0f0f0d: 00 00 00 8b 4c 24 14 8b e9 c1 e9 02 8b f0 8b fa > 0x6d0f0f1d: f3 a5 8b cd 83 e1 03 f3 a4 8b 74 24 18 8b 4c 24 > Stack: [0x4782,0x4787], sp=0x4786f294, free space=316k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [awt.dll+0x40f1d] > [error occurred during error reporting (printing native stack), id 0xc005] > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j sun.awt.windows.WToolkit.eventLoop()V+0 > j sun.awt.windows.WToolkit.run()V+69 > j java.lang.Thread.run()V+11 > v ~StubRoutines::call_stub > --- P R O C E S S --- > Java Threads: ( => current thread ) > 0x47246800 JavaThread "Store com.csi.domain.Offer Spool Thread" daemon > [_thread_blocked, id=2160, stack(0x48c3,0x48c8)] > 0x47541400 JavaThread "Store com.csi.domain.Scenario Spool Thread" daemon > [_thread_blocked, id=3296, stack(0x48c9,0x48ce)] > 0x476fb400 JavaThread "Store org.hibernate.cache.StandardQueryCache Spool > Thread" daemon [_thread_blocked, id=3016, stack(0x4822,0x4827)] > 0x483c7800 JavaThread "Store org.hibernate.cache.UpdateTimestampsCache > Spool Thread" daemon [_thread_blocked, id=3524, stack(0x4818,0x481d)] > 0x48418800 JavaThread "H2 Log Writer CSI.DB" daemon [_thread_blocked, > id=948, stack(0x481d,0x4822)] > 0x47378800 JavaThread "H2 File Lock Watchdog > D:\CSI\V0.92\db\csi.db.lock.db" daemon [_thread_blocked, id=2036, > stack(0x4813,0x4818)] > 0x475ff000 JavaThread "D3D Screen Updater" daemon [_thread_blocked, > id=2552, stack(0x47d9,0x47de)] > 0x47432800 JavaThread "Timer-0" [_thread_blocked, id=2752, > stack(0x4792,0x4797)] > 0x00397800 JavaThread "DestroyJavaVM" [_thread_blocked, id=4048, > stack(0x003b,0x0040)] > 0x47407400 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=2132, > stack(0x478d,0x4792)] > =>0x4732a400 JavaThread "AWT-Windows" daemon [_thread_in_native, id=2688, > stack(0x4782,0x4787)] > 0x473d9400 JavaThread "AWT-Shutdown" [_thread_blocked, id=2380, > stack(0x477d,0x4782)] > 0x47404400 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=228, > stack(0x4778,0x477d)] > 0x46e41800 JavaThread "Low Memory Detector" daemon [_thread_blocked, > id=2388, stack(0x4709,0x470e)] > 0x46e3b800 JavaThread "CompilerThread0" daemon [_thread_blocked, id=2836, > stack(0x4704,0x4709)] > 0x46e3a000 JavaThread "Attach Listener" daemon [_thread_blocked, id=576, > stack(0x46ff,0x4704)] > 0x46e38c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2476, > stack(0x46fa,0x46ff)]
[jira] [Closed] (PIVOT-498) Revisit use of Executors.newCachedThreadPool() in Task class
[ https://issues.apache.org/jira/browse/PIVOT-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-498. Resolution: Fixed Fix Version/s: (was: 2.5) 2.1 Closing this issue now with the caveat that the old workaround can still be applied if necessary if anyone is still using applets and sees a problem. > Revisit use of Executors.newCachedThreadPool() in Task class > > > Key: PIVOT-498 > URL: https://issues.apache.org/jira/browse/PIVOT-498 > Project: Pivot > Issue Type: Task > Components: core-util >Reporter: Greg Brown >Assignee: Roger Whitcomb > Fix For: 2.1 > > > There appears to be an issue with Executors.newCachedThreadPool() when > running as an applet. IllegalThreadStateExceptions are thrown periodically > and seemingly unpredictably. The current workaround uses a custom > ExecutorService that simply dispatches requests to new threads as they are > received. However, this is not optimal and a better solution should be found, > if possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (PIVOT-498) Revisit use of Executors.newCachedThreadPool() in Task class
[ https://issues.apache.org/jira/browse/PIVOT-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb reassigned PIVOT-498: Assignee: Roger Whitcomb > Revisit use of Executors.newCachedThreadPool() in Task class > > > Key: PIVOT-498 > URL: https://issues.apache.org/jira/browse/PIVOT-498 > Project: Pivot > Issue Type: Task > Components: core-util >Reporter: Greg Brown >Assignee: Roger Whitcomb > Fix For: 2.5 > > > There appears to be an issue with Executors.newCachedThreadPool() when > running as an applet. IllegalThreadStateExceptions are thrown periodically > and seemingly unpredictably. The current workaround uses a custom > ExecutorService that simply dispatches requests to new threads as they are > received. However, this is not optimal and a better solution should be found, > if possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-498) Revisit use of Executors.newCachedThreadPool() in Task class
[ https://issues.apache.org/jira/browse/PIVOT-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282218#comment-16282218 ] Roger Whitcomb commented on PIVOT-498: -- I'm going to take a chance that: a) Since applets are mostly obsolete now that we won't ever see this problem going forward (if it still exists); and b) The problem is most likely fixed in Java 8/9 now anyway. So, I propose to do this: 1) Move the default (simple) executor service out of Task into a separate class somewhere; and 2) Change the default in Task to be an "Executors.newCachedThreadPool()" as it should be; finally 3) Retain the ability to still specify an executor service in Task, TaskSequence and TaskGroup constructors in case there are problems. > Revisit use of Executors.newCachedThreadPool() in Task class > > > Key: PIVOT-498 > URL: https://issues.apache.org/jira/browse/PIVOT-498 > Project: Pivot > Issue Type: Task > Components: core-util >Reporter: Greg Brown >Assignee: Roger Whitcomb > Fix For: 2.5 > > > There appears to be an issue with Executors.newCachedThreadPool() when > running as an applet. IllegalThreadStateExceptions are thrown periodically > and seemingly unpredictably. The current workaround uses a custom > ExecutorService that simply dispatches requests to new threads as they are > received. However, this is not optimal and a better solution should be found, > if possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-1014) Specify skin default styles in JSON file so they can be easily changed
[
https://issues.apache.org/jira/browse/PIVOT-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282273#comment-16282273
]
Roger Whitcomb commented on PIVOT-1014:
---
Make tiny changes to one of the test theme files, with "updated" default styles
and named styles files:
Sendingtests\src\org\apache\pivot\tests\TerraTheme_test.json
Adding tests\src\org\apache\pivot\tests\terra_theme_defaults_test.json
Adding tests\src\org\apache\pivot\tests\terra_theme_styles_test.json
Transmitting file data ...done
Committing transaction...
Committed revision 1817403.
> Specify skin default styles in JSON file so they can be easily changed
> --
>
> Key: PIVOT-1014
> URL: https://issues.apache.org/jira/browse/PIVOT-1014
> Project: Pivot
> Issue Type: Improvement
> Components: wtk-terra
>Reporter: Roger Whitcomb
>Assignee: Roger Whitcomb
>Priority: Minor
> Fix For: 2.1
>
>
> I have noticed some inconsistencies in the way default styles (things like
> colors, fonts, padding/margins, etc.) are set in the constructors of the
> Terra*Skin classes, such as:
> * Color values set directly from the theme vs. set through the setter methods.
> * Missing color setter methods using the theme color index.
> * Derived colors being set in two different places, potentially leading to
> inconsistencies because of the duplication.
> * Possible inconsistencies between controls in the theme colors used (such as
> for backgrounds, borders, etc.) -- this has not been verified, because it
> will require a lot of research.
> * Since these defaults are all set in code, even though (for instance) the
> theme colors themselves are set in the "TerraTheme_default.json" file,
> changing the overall look-and-feel is difficult at present.
> So, for all these reasons I propose to use a new "terra_theme_defaults.json"
> file, which can be overridden by a new setting in the "TerraTheme*.json"
> file(s) which will set all the defaults for all the Terra*Skin classes
> similar to this (taken from TerraExpanderSkin):
> Previously:
> {code:java}
>setBackgroundColor(theme.getColor(4));
>titleBarBackgroundColor = theme.getColor(10);
>titleBarBorderColor = theme.getColor(7);
>titleBarColor = theme.getColor(12);
>shadeButtonColor = theme.getColor(12);
>disabledShadeButtonColor = theme.getColor(7);
>borderColor = theme.getColor(7);
>padding = new Insets(4);
> {code}
> New:
> {code:java}
> TerraExpanderSkin : {
> backgroundColor : 4,
> titleBarBackgroundColor : 10,
> titleBarBorderColor : 7,
> titleBarColor : 12,
> shadeButtonColor : 12,
> disabledShadeButtonColor : 7,
> borderColor : 7,
> padding : 4
> },
> {code}
> Note: this approach also fits well with the overall Pivot philosophy of doing
> things in a "declarative" fashion (via BXML / JSON files) rather than in
> code, where possible.
> I have prototyped this in a couple of classes and it seems to work well, AND
> it has revealed a number of the color properties that were missing the
> "setXXX(int index)" methods.
> Note: there is potential for slowdown during control construction since we're
> executing a LOT more code to set these defaults (including expensive
> reflection operations inside BeanAdapter), but I have not yet been able to
> measure the speed differential to see if it will be of concern.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PIVOT-978) Possible to get calendar dates in year 10000 and beyond
[ https://issues.apache.org/jira/browse/PIVOT-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286432#comment-16286432 ] Roger Whitcomb commented on PIVOT-978: -- Fixed a new problem introduced with changes to PIVOT-999 that also tried to address this issue (by setting a Spinner data list that has the defined Gregorian calendar limits to it): Sendingcore\src\org\apache\pivot\beans\BXMLSerializer.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraCalendarButtonSkin.java Sending wtk-terra\src\org\apache\pivot\wtk\skin\terra\TerraCalendarSkin.java Transmitting file data ...done Committing transaction... Committed revision 1817805. > Possible to get calendar dates in year 1 and beyond > --- > > Key: PIVOT-978 > URL: https://issues.apache.org/jira/browse/PIVOT-978 > Project: Pivot > Issue Type: Bug > Components: wtk-terra >Affects Versions: 2.0.4, 2.1 > Environment: ALL >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Fix For: 2.1, 2.0.5 > > > Summary of the steps to reproduce (from QA tester of our application): > 1. click into the year field - it seems not possible to change the year, > however: > 2. press 1 and a date of 1 is entered > 3. press 2 and it's 2 > 4. press 3 and it's 3 (if you press 3 first, it could be 3000 and so it > would be valid) > 5. you get a error message e.g. Invalid year: 1 > 6. nevertheless you can change the year with the arrow keys/buttons but for > every change you get the error message. > You also get the error message if you go to the upper and lower bounds of the > calender, which is the year 1582 and 1 (both exclusive) by means of arrow > keys / arrow buttons. You can change the year into the wrong direction if you > are willing to confirm the error message on every keypress. And if you want > to change the year back to some meaningful value, you have to confirm the > error message again, until you hit a valid year. If in such a invalid year > (e.g 1580), you can click on a day and the date will change to that date in > 1583. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-798) Components should paint using their "disabled" style if they or any ancestor is disabled
[ https://issues.apache.org/jira/browse/PIVOT-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286587#comment-16286587 ] Roger Whitcomb commented on PIVOT-798: -- Right now in trunk, with Java 8 the "Enable Magic" checkbox enables/disables the "Acts" list, but does nothing for the "spell" or "wand" fields Could be a Nashorn issue (related to PIVOT-965?). > Components should paint using their "disabled" style if they or any ancestor > is disabled > > > Key: PIVOT-798 > URL: https://issues.apache.org/jira/browse/PIVOT-798 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0 >Reporter: Sandro Martini >Assignee: Sandro Martini > Fix For: 2.5 > > Attachments: recursive_disable.bxml > > > Add a utility method setEnabledRecursive(boolean) to the container classes, > but keep the current behavior as default. > Some info here: > http://apache-pivot-users.399431.n3.nabble.com/Component-isEnabled-does-not-affect-appearance-recursively-td3401718.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (PIVOT-798) Components should paint using their "disabled" style if they or any ancestor is disabled
[ https://issues.apache.org/jira/browse/PIVOT-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286587#comment-16286587 ] Roger Whitcomb edited comment on PIVOT-798 at 12/11/17 9:27 PM: Right now in trunk, with Java 8 the "Enable Magic" checkbox enables/disables the "Acts" list, but does nothing for the "spell" or "wand" fields Definitely a Nashorn issue (related to PIVOT-965) -- removing the second "stateChanged" callback fixes the problem. So, somehow the two Javascript callbacks with the same name are colliding with each other so that the second one gets invoked for either checkbox. was (Author: rwhitcomb): Right now in trunk, with Java 8 the "Enable Magic" checkbox enables/disables the "Acts" list, but does nothing for the "spell" or "wand" fields Could be a Nashorn issue (related to PIVOT-965?). > Components should paint using their "disabled" style if they or any ancestor > is disabled > > > Key: PIVOT-798 > URL: https://issues.apache.org/jira/browse/PIVOT-798 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 2.0 >Reporter: Sandro Martini >Assignee: Sandro Martini > Fix For: 2.5 > > Attachments: recursive_disable.bxml > > > Add a utility method setEnabledRecursive(boolean) to the container classes, > but keep the current behavior as default. > Some info here: > http://apache-pivot-users.399431.n3.nabble.com/Component-isEnabled-does-not-affect-appearance-recursively-td3401718.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-971) Add the ability to have tri-state checkboxes in ListView
[ https://issues.apache.org/jira/browse/PIVOT-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16280800#comment-16280800 ] Roger Whitcomb commented on PIVOT-971: -- Add test/demo features to the CheckedListViewTest program. Also added an Adapter class to ListViewItemStateListener for completeness (since the interface now has two methods). Sendingtests\src\org\apache\pivot\tests\CheckedListViewTest.java Adding tests\src\org\apache\pivot\tests\checked_list_view_test.bxml Sendingwtk\src\org\apache\pivot\wtk\ListViewItemStateListener.java Transmitting file data ...done Committing transaction... Committed revision 1817316. > Add the ability to have tri-state checkboxes in ListView > > > Key: PIVOT-971 > URL: https://issues.apache.org/jira/browse/PIVOT-971 > Project: Pivot > Issue Type: New Feature > Components: wtk, wtk-terra >Affects Versions: 2.0.4 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Labels: listview > Fix For: 2.1 > > Attachments: listview.diffs, tri-state listview.png > > > For one place in our application, a ListView is used along with checkboxes, > but it seems like it would be good to be able to use tri-state checkboxes > here, such that a mixed state could be indicated for some entries. But, then > the question becomes: if the checkbox is mixed, is it checked or not? Two > thoughts on that: > 1. Add a method to get the checkbox state for all items, so you can check > yourself if they are checked, unchecked or mixed. > 2. Add a property "mixedAreChecked", which if set true (default false) would > make the mixed state entries show up as checked. > Also, how do you set the "mixed" state for an item? Not sure about that yet. > Altogether: lots of implications throughout the code to support this feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (PIVOT-971) Add the ability to have tri-state checkboxes in ListView
[ https://issues.apache.org/jira/browse/PIVOT-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Whitcomb closed PIVOT-971. Resolution: Fixed Now that the test/demo program is in place, closing this issue as done. > Add the ability to have tri-state checkboxes in ListView > > > Key: PIVOT-971 > URL: https://issues.apache.org/jira/browse/PIVOT-971 > Project: Pivot > Issue Type: New Feature > Components: wtk, wtk-terra >Affects Versions: 2.0.4 > Environment: All >Reporter: Roger Whitcomb >Assignee: Roger Whitcomb >Priority: Minor > Labels: listview > Fix For: 2.1 > > Attachments: listview.diffs, tri-state listview.png > > > For one place in our application, a ListView is used along with checkboxes, > but it seems like it would be good to be able to use tri-state checkboxes > here, such that a mixed state could be indicated for some entries. But, then > the question becomes: if the checkbox is mixed, is it checked or not? Two > thoughts on that: > 1. Add a method to get the checkbox state for all items, so you can check > yourself if they are checked, unchecked or mixed. > 2. Add a property "mixedAreChecked", which if set true (default false) would > make the mixed state entries show up as checked. > Also, how do you set the "mixed" state for an item? Not sure about that yet. > Altogether: lots of implications throughout the code to support this feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PIVOT-965) Java 8 BXML scripting security issues in Apache Pivot RIAs
[ https://issues.apache.org/jira/browse/PIVOT-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286872#comment-16286872 ] Roger Whitcomb commented on PIVOT-965: -- In the "recursive_disable.bxml" file (created for PIVOT-798) the checkboxes do not work correctly because we have messed up the scope of listeners with these Nashorn changes: Right now in trunk, with Java 8 the "Enable Magic" checkbox enables/disables the "Acts" list, but does nothing for the "spell" or "wand" fields Definitely a Nashorn issue – removing the second "stateChanged" callback fixes the problem. So, somehow the two Javascript callbacks with the same name are colliding with each other so that the second one gets invoked for either checkbox. > Java 8 BXML scripting security issues in Apache Pivot RIAs > -- > > Key: PIVOT-965 > URL: https://issues.apache.org/jira/browse/PIVOT-965 > Project: Pivot > Issue Type: Bug > Components: core-serialization >Affects Versions: 2.0.4 > Environment: Windows, Sun JRE 64-bit 1.8.0_31b13 >Reporter: Karel Hübl >Assignee: Roger Whitcomb > Labels: java8, jdk8 > Fix For: 2.1 > > Attachments: 965.diffs, BXMLSerializer.patch, jnlpScripting.war > > > We encounter security issues in our pivot application after upgrading to JRE > 1.8. The application is deployed as RIA using Java Web Start. > I found out, that the problem is connected with nashorn script engine which > replaced rhino script engine from previous java version. BXMLSerializer is > using ScriptEngine to evaluate scripts in BXML files. It seems, that all > calls initiated from BXML scripts, are considered untrusted in JRE 1.8 RIA > Environment - this means security dialogs and exceptions are thrown, when > trying execute privileged actions (network communication, reflection ...). > Currently, I am not sure, if this is Pivot or Nashorn bug, but it is problem > for current Apache Pivot RIAs. To investigate the srcipting behaviour in > RIAs, I created testing non Pivot project > https://github.com/kaja78/jnlpScripting The project contains testing > application, which is deployed as JWS. When you execute the java web start > app in JRE 1.8, the security dialog is displayed when testing method is > executed from nashorn script engine (if you press cancel button on security > dialog, you get SecurityException). When you uncomment 2 lines in > Webcontent/jnlpScripting.jnlp file, rhino script engine is used instead of > nashorn and no security dialog is displayed. This fix works also for our > Pivot RIAs. > I believe, Pivot should work in JRE 1.8 RIA Environment without security > issues by default, so it should be fixed somehow in Pivot - may be, by > correct ScriptEngine configuration in BXMLSerializer or by including Rhino > libraries in Pivot distribution. Any idea how to "correctly" fix this issue? > Btw.: I found this bug: http://bugs.java.com/view_bug.do?bug_id=8045075 I am > not sure, if it is the same problem. But anyway, it should be fixed in > 1.8.25.b01 and we are encountering above issues in latest 1.8.0.31.b13. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
