[jira] Created: (PIVOT-547) Bug in JSON.java prevents the use of Element as a destination for data binding
Bug in JSON.java prevents the use of Element as a destination for data binding -- Key: PIVOT-547 URL: https://issues.apache.org/jira/browse/PIVOT-547 Project: Pivot Issue Type: Bug Components: core-xml Affects Versions: 1.5 Reporter: Michael Allman Priority: Minor Attachments: xml_binding_fix.patch A bug in the JSON.put method prevents using an Element instance as a destination for data binding. This issue arises because Element implements both the Dictionary and Sequence interfaces. I've attached a proposed fix. The approach I've taken is to test if the key can be parsed into an int. If not, it's assumed to be a Dictionary key. This fixes the issue with Element and should fix the issue for the more general case of any other class that implement Dictionary and Sequence. Given that this is a bug, I've generated the patch against the 1.5.x branch. Cheers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (PIVOT-547) Bug in JSON.java prevents the use of Element as a destination for data binding
[ https://issues.apache.org/jira/browse/PIVOT-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Allman updated PIVOT-547: - Attachment: xml_binding_fix.patch Proposed fix > Bug in JSON.java prevents the use of Element as a destination for data binding > -- > > Key: PIVOT-547 > URL: https://issues.apache.org/jira/browse/PIVOT-547 > Project: Pivot > Issue Type: Bug > Components: core-xml >Affects Versions: 1.5 >Reporter: Michael Allman >Priority: Minor > Attachments: xml_binding_fix.patch > > > A bug in the JSON.put method prevents using an Element instance as a > destination for data binding. This issue arises because Element implements > both the Dictionary and Sequence interfaces. > I've attached a proposed fix. The approach I've taken is to test if the key > can be parsed into an int. If not, it's assumed to be a Dictionary key. > This fixes the issue with Element and should fix the issue for the more > general case of any other class that implement Dictionary and Sequence. > Given that this is a bug, I've generated the patch against the 1.5.x branch. > Cheers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [jira] Resolved: (PIVOT-542) enable the serializer to initialize components written in java code
Thoughts with >>>. My mail program did not auto > the previous email :-) Thanks for responding to this. I'll close this out. -Original Message- From: Greg Brown [mailto:gkbr...@mac.com] Sent: Wednesday, June 23, 2010 2:41 PM To: dev@pivot.apache.org Subject: Re: [jira] Resolved: (PIVOT-542) enable the serializer to initialize components written in java code > The seriliazer already plays the initialization role. The serializer is the creator and the initializer. In the model you suggest, it is only the initializer - the new keyword is used to create the object. This is inconsistent. If you only need initialization, you should use the bind() method. >>>bind() cannot automatically perform full binding actually on its own without coding. Coding is not bad, but its not needed here. With the proposed approach, variables, not just @WTKX variables, including those defined in superclasses are automatically initialized because the xml is just the freeze dried version of the object. In fact the Bindable interface with the initialize method encourages you to reach in and get resources. A cleaner approach is that the properties at the root level of the serializer are really the properties of the object being created. > My understanding is that skins are views. Components are model/controllers. > The view should not be loading user data and other child content into the > mode/controller so I'm not sure I would agree that the skin should be doing > this at all because part of the initialization is also Component data such > as userData. Skins shouldn't get involved in the model data, but they are allowed to add sub-components. For example, all composite component skins do this (Spinner, ScrollBar, Frame, etc.). >>>That's a great point. And in fact, this initialize() proposal does not change this it all. > With the editor, there are a few ways to do this. This is actually a very > direct approach. In the thoughts below, I am still forced, at a minimum, to > use an interface and for me to write code for wiring. I'm not against > writing code but when the serializer can do it naturally, that's a win. The problem is that the suggested modifications to the serializer are not natural because they don't fit in with the overall design of the framework. >>>I think I get your point about skins and I think I appreciate skins more now than I did before. >>>But I can see from other recent changes to the Bindable interface that you are moving closer to this initialize proposal. If you take Bindable to the next step, you starting getting the initialize approach I am proposing. Not against Bindable, but its another interface that's not always needed and bind() cannot automatically initialize all of the object's properties automatically such as userData or other properties define in your code-behind. The serializer is actually inconsistent in its ability to initialize instance variables of the calling object when you call bind(). Bind() can only do @WTKX variables, but a component has a lot of variables in superclasses that could use similar help. >>>Lets say you remove the Bindable interface because you don't want component writers to have to worry about another interface and their methods for initialization. What would you do? The initialize() proposal is an answer and it does more initialization of variables since bind() only does @WTKX annotated variables. The semantics of Bindable combines two logical elements into one: some bind() which is instance variable initialization and notifying the object it has been bound (that it has been initialized through binding). @WTKX still stays because it initializes variables only in your subclass without any extra work, a huge convenience. >>Notifying that a bind has occurred is actually closer to @PostConstruct which is a java standard. It is called after instantiation and automatic variable initialization. But in pivot Bindable tries to do both. It combines two things into one. Teasing this apart slightly with this proposal around initialization semantics actually improves consistency of instance variable initialization and provides a new capability for clients. You can't annotate instance variables in superclasses without access to source code, but you still want them initialized from the serializer just like @WTKX variables in your subclass. It's a big convenience. >>>Example: Think about the MyDialog just posted to the user list. In it, you define a subclass of Dialog. But to allow them to use it they have to use an include in the bxml because the "contents" of the dialog are in the bxml. I say skip the include. When you need to use the MyDialog in code or bxml, just refer to the class as you would any other pivot-provided component. The bxml just backs the object being created. In this case, there is total consistency between code and bxml in terms of using MyDialog regardless of how its deployed by the client. The MyDialog.bxml would be used behind the scenes,
RE: [RFC] Selection change events
I'm not sure of the current implementation, but if by doing a selection indirectly, you fire an event for each selection, as it is selected in the set being set, then that could be inefficient or at least push the burden of inefficiency into the client. If it fires after all of them have been selected, then it should be okay. I think some platforms, can't recall immediately, allow you to receive each individual selection, if you want it, then a post selection event that has all of them. It probably uses a timer underneath to determine which selections get grouped together. -Original Message- From: Sandro Martini [mailto:sandro.mart...@gmail.com] Sent: Thursday, June 24, 2010 5:53 PM To: dev@pivot.apache.org Subject: Re: [RFC] Selection change events Hi Greg, for me the change is right, and maybe with this application selection listeners could see what to do (and when it's the case ignoring the "indirect change" event, like today) ... and on all selectable components, right ? Have you an idea on the performance impact of this change on tables/trees and other containers with many elements inside ? Bye, Sandro
RE: [RFC] Selection change events
This sounds good. But why would you pass null? Should it not be be the previous selection info (the current selection prior to changing it indirectly? This would be consistent with doing it "directly." -Original Message- From: Greg Brown [mailto:gkbr...@mac.com] Sent: Thursday, June 24, 2010 3:34 PM To: dev@pivot.apache.org Subject: [RFC] Selection change events Hi all, I am thinking about making a change to how selection change events are fired and I would like to hear your feedback. Currently, selection change events are fired only when an explicit call has been made that affects the selection. For example, in ListView, calling either setSelectedRanges() or clearSelection() will fire this event. However, an operation that indirectly changes the selection state (such as adding or removing an item from the ListView's model data) does not trigger an event. This was originally done by design - selectedRangesChanged() includes the previous selection as an argument, and we didn't want to have to manually re-construct that every time the selection changed as a side effect of a model change: public void selectedRangesChanged(ListView listView, Sequence previousSelectedRanges); However, in practice, I have found this to be a bit challenging. More than once I have registered a selection change listener expecting to receive notification of all selection changes, forgetting that it is not designed that way. If I am getting tripped up by this, I'm guessing that other developers might be as well. So, I am proposing that components that maintain a selection state also fire selection change events when the selection changes indirectly. In this case, a null value would be passed for the previous selection. This will save the effort of re-constructing the previous selection info and will give the listener additional information about the nature of the change (i.e. null == indirect state change). Please let me know what you think. Thanks for your input, Greg
Re: FindBugs report on trunk
I've just seen commits ... very good, and as always thank you very much. Bye, Sandro
Re: FindBugs report on trunk
> TextAreaSkin.java:1397 instanceof will always return true, since all > org.apache.pivot.wtk.text.Element are instances of > org.apache.pivot.wtk.text.Element > TextAreaSkin.java:1377 instanceof will always return true, since all > org.apache.pivot.wtk.text.Element are instances of > org.apache.pivot.wtk.text.Element Fixed. > Wtk-Terra: > TerraActivityIndicatorSkin.java:88 Dead store to increment That may be a false positive. The increment value is a local final and is used elsewhere. > TerraPanoramaSkin.java:378 Dead store to scrollTop > TerraPanoramaSkin.java:385 Dead store to scrollLeft Fixed.
[jira] Resolved: (PIVOT-468) Update tutorials to use Bindable where applicable
[ https://issues.apache.org/jira/browse/PIVOT-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Brown resolved PIVOT-468. -- Resolution: Fixed > Update tutorials to use Bindable where applicable > - > > Key: PIVOT-468 > URL: https://issues.apache.org/jira/browse/PIVOT-468 > Project: Pivot > Issue Type: Improvement > Components: tutorials >Reporter: Greg Brown >Priority: Minor > Fix For: 2.0 > > > The only tutorial that currently uses bind() is FileBrowsing, so this > probably isn't critical. Deferring to 2.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: FindBugs report on trunk
Hi Greg, >> Wtk-Terra: >> TerraActivityIndicatorSkin.java:88 Dead store to increment >> TerraPanoramaSkin.java:378 Dead store to scrollTop >> TerraPanoramaSkin.java:385 Dead store to scrollLeft > > These are probably worth looking into. These are less important on all I send in the previous mail ... FindBugs in this case say: "the variable x is defined (and assigned and maybe computed as a value), but never read, or never used after its assignment". Bye
Re: FindBugs report on trunk
> Core: > BeanSerializer.java:81 Method > org.apache.pivot.beans.BeanSerializer$NamedObjectBindings.putAll(Map) > makes inefficient use of keySet iterator instead of entrySet iterator Ignore this. > Tools: > EventLoggerSkin.java:44 > org.apache.pivot.tools.wtk.EventLoggerSkin$TreeNodeComparator > implements Comparator but not Serializable > ComponentPropertyInspectorSkin.java:30 > org.apache.pivot.tools.wtk.ComponentPropertyInspectorSkin$NameComparator > implements Comparator but not Serializable > ComponentPropertyInspectorSkin.java:37 > org.apache.pivot.tools.wtk.ComponentPropertyInspectorSkin$ClassComparator > implements Comparator but not Serializable Ignore these. > Tutorials (ok, small things but good to show our users that all Pivot > code is written in the right way): > Expenses.java:46 Write to static field > org.apache.pivot.tutorials.webqueries.Expenses.instance from instance > method new org.apache.pivot.tutorials.webqueries.Expenses() > ListViews.java:69 Method > org.apache.pivot.tutorials.lists.ListViews$1.updateSelection(ListView) > concatenates strings using + in a loop Ignore these. > Wtk: > TreeView.java:626 org.apache.pivot.wtk.TreeView$PathComparator > implements Comparator but not Serializable > BindException.java:1 The class name > org.apache.pivot.wtkx.BindException shadows the simple name of the > superclass org.apache.pivot.beans.BindException > Bindable.java:1 The class name org.apache.pivot.wtkx.Bindable shadows > the simple name of implemented interface > org.apache.pivot.beans.Bindable Ignore these. > TextAreaSkin.java:1397 instanceof will always return true, since all > org.apache.pivot.wtk.text.Element are instances of > org.apache.pivot.wtk.text.Element > TextAreaSkin.java:1377 instanceof will always return true, since all > org.apache.pivot.wtk.text.Element are instances of > org.apache.pivot.wtk.text.Element > > Wtk-Terra: > TerraActivityIndicatorSkin.java:88 Dead store to increment > TerraPanoramaSkin.java:378 Dead store to scrollTop > TerraPanoramaSkin.java:385 Dead store to scrollLeft These are probably worth looking into.
FindBugs report on trunk
Hi to all, some little things seen by FindBugs on Pivot trunk: Core: BeanSerializer.java:81 Method org.apache.pivot.beans.BeanSerializer$NamedObjectBindings.putAll(Map) makes inefficient use of keySet iterator instead of entrySet iterator Tools: EventLoggerSkin.java:44 org.apache.pivot.tools.wtk.EventLoggerSkin$TreeNodeComparator implements Comparator but not Serializable ComponentPropertyInspectorSkin.java:30 org.apache.pivot.tools.wtk.ComponentPropertyInspectorSkin$NameComparator implements Comparator but not Serializable ComponentPropertyInspectorSkin.java:37 org.apache.pivot.tools.wtk.ComponentPropertyInspectorSkin$ClassComparator implements Comparator but not Serializable Tutorials (ok, small things but good to show our users that all Pivot code is written in the right way): Expenses.java:46 Write to static field org.apache.pivot.tutorials.webqueries.Expenses.instance from instance method new org.apache.pivot.tutorials.webqueries.Expenses() ListViews.java:69 Method org.apache.pivot.tutorials.lists.ListViews$1.updateSelection(ListView) concatenates strings using + in a loop Wtk: TreeView.java:626 org.apache.pivot.wtk.TreeView$PathComparator implements Comparator but not Serializable BindException.java:1 The class name org.apache.pivot.wtkx.BindException shadows the simple name of the superclass org.apache.pivot.beans.BindException Bindable.java:1 The class name org.apache.pivot.wtkx.Bindable shadows the simple name of implemented interface org.apache.pivot.beans.Bindable TextAreaSkin.java:1397 instanceof will always return true, since all org.apache.pivot.wtk.text.Element are instances of org.apache.pivot.wtk.text.Element TextAreaSkin.java:1377 instanceof will always return true, since all org.apache.pivot.wtk.text.Element are instances of org.apache.pivot.wtk.text.Element Wtk-Terra: TerraActivityIndicatorSkin.java:88 Dead store to increment TerraPanoramaSkin.java:378 Dead store to scrollTop TerraPanoramaSkin.java:385 Dead store to scrollLeft Tell me on what to do ... Bye, Sandro
Re: PIVOT-535
To me some parts are not-so-clear, so maybe showing some minimal classes (for example a minimal and simple usage) could help to clarify and comments ... Bye, Sandro
Re: [RFC] Selection change events
> The performance impact should be negligible. I was sure of it :-) ...
Re: [RFC] Selection change events
The performance impact should be negligible. On Jun 24, 2010, at 5:52 PM, Sandro Martini wrote: > Hi Greg, > for me the change is right, and maybe with this application selection > listeners could see what to do (and when it's the case ignoring the > "indirect change" event, like today) ... and on all selectable > components, right ? > Have you an idea on the performance impact of this change on > tables/trees and other containers with many elements inside ? > > Bye, > Sandro
Re: [RFC] Selection change events
Hi Greg, for me the change is right, and maybe with this application selection listeners could see what to do (and when it's the case ignoring the "indirect change" event, like today) ... and on all selectable components, right ? Have you an idea on the performance impact of this change on tables/trees and other containers with many elements inside ? Bye, Sandro
[RFC] Selection change events
Hi all, I am thinking about making a change to how selection change events are fired and I would like to hear your feedback. Currently, selection change events are fired only when an explicit call has been made that affects the selection. For example, in ListView, calling either setSelectedRanges() or clearSelection() will fire this event. However, an operation that indirectly changes the selection state (such as adding or removing an item from the ListView's model data) does not trigger an event. This was originally done by design - selectedRangesChanged() includes the previous selection as an argument, and we didn't want to have to manually re-construct that every time the selection changed as a side effect of a model change: public void selectedRangesChanged(ListView listView, Sequence previousSelectedRanges); However, in practice, I have found this to be a bit challenging. More than once I have registered a selection change listener expecting to receive notification of all selection changes, forgetting that it is not designed that way. If I am getting tripped up by this, I'm guessing that other developers might be as well. So, I am proposing that components that maintain a selection state also fire selection change events when the selection changes indirectly. In this case, a null value would be passed for the previous selection. This will save the effort of re-constructing the previous selection info and will give the listener additional information about the nature of the change (i.e. null == indirect state change). Please let me know what you think. Thanks for your input, Greg
[jira] Commented: (PIVOT-544) Add a command line argument, "--undecorated", to support removing native Frame chrome on a non-fullscreen window
[ https://issues.apache.org/jira/browse/PIVOT-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882289#action_12882289 ] Greg Brown commented on PIVOT-544: -- I think the existing full-screen mode might be better suited for kiosk deployments. But undecorated is useful nonetheless. > Add a command line argument, "--undecorated", to support removing native > Frame chrome on a non-fullscreen window > > > Key: PIVOT-544 > URL: https://issues.apache.org/jira/browse/PIVOT-544 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 1.5 >Reporter: Michael Allman > Fix For: 2.0 > > Attachments: undecorated_command_line_arg_trunk.patch > > > Attached is a patch which adds a new command line argument for Pivot desktop > apps, "--undecorated=(true|false)", that allows for an undecorated top level > frame. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-544) Add a command line argument, "--undecorated", to support removing native Frame chrome on a non-fullscreen window
[ https://issues.apache.org/jira/browse/PIVOT-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882229#action_12882229 ] Roger Whitcomb commented on PIVOT-544: -- Just wanted to add to the use case for this change: Kiosk applications where the app is deployed in a mall or store setting and the computer is running only this app and users interact with it without knowing the OS or anything behind it. Generally you DON'T want the user to close the app anyway ;) > Add a command line argument, "--undecorated", to support removing native > Frame chrome on a non-fullscreen window > > > Key: PIVOT-544 > URL: https://issues.apache.org/jira/browse/PIVOT-544 > Project: Pivot > Issue Type: Improvement > Components: wtk >Affects Versions: 1.5 >Reporter: Michael Allman > Fix For: 2.0 > > Attachments: undecorated_command_line_arg_trunk.patch > > > Attached is a patch which adds a new command line argument for Pivot desktop > apps, "--undecorated=(true|false)", that allows for an undecorated top level > frame. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (PIVOT-239) Create an Eclipse launch configuration for ScriptApplication
[ https://issues.apache.org/jira/browse/PIVOT-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Brown updated PIVOT-239: - Priority: Major (was: Minor) With an increased emphasis on Bindable (see PIVOT-546), this feature will become much more important. > Create an Eclipse launch configuration for ScriptApplication > > > Key: PIVOT-239 > URL: https://issues.apache.org/jira/browse/PIVOT-239 > Project: Pivot > Issue Type: New Feature > Components: tools >Reporter: Greg Brown > Fix For: 2.0 > > > This will allow developers to easily launch WTKX+script applications from > within Eclipse without having to compile anything. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PIVOT-468) Update tutorials to use Bindable where applicable
[ https://issues.apache.org/jira/browse/PIVOT-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882159#action_12882159 ] Greg Brown commented on PIVOT-468: -- With the introduction of the context argument documented in PIVOT-546, it is now possible to use Bindable in most, if not all, tutorial examples. This will significantly simplify the code and allow the reader to better focus on the functionality being demonstrated. > Update tutorials to use Bindable where applicable > - > > Key: PIVOT-468 > URL: https://issues.apache.org/jira/browse/PIVOT-468 > Project: Pivot > Issue Type: Improvement > Components: tutorials >Reporter: Greg Brown >Priority: Minor > Fix For: 2.0 > > > The only tutorial that currently uses bind() is FileBrowsing, so this > probably isn't critical. Deferring to 2.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PIVOT-546) Add a context argument to Bindable#initialize()
Add a context argument to Bindable#initialize() --- Key: PIVOT-546 URL: https://issues.apache.org/jira/browse/PIVOT-546 Project: Pivot Issue Type: Improvement Components: core-beans Reporter: Greg Brown Fix For: 2.0 This value would be a Dictionary that would allow the caller to access the serializer's namespace. This will allow untrusted applications to take advantage of Bindable without needing to use the BXML annotation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PIVOT-546) Add a context argument to Bindable#initialize()
[ https://issues.apache.org/jira/browse/PIVOT-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Brown resolved PIVOT-546. -- Resolution: Fixed > Add a context argument to Bindable#initialize() > --- > > Key: PIVOT-546 > URL: https://issues.apache.org/jira/browse/PIVOT-546 > Project: Pivot > Issue Type: Improvement > Components: core-beans >Reporter: Greg Brown > Fix For: 2.0 > > > This value would be a Dictionary that would allow the caller > to access the serializer's namespace. This will allow untrusted applications > to take advantage of Bindable without needing to use the BXML annotation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MessageType.APPLICATION constant in use?
I believe it was originally intended to propagate the application icon to an alert or prompt - I believe some OS X applications do this. However, it is probably safe to remove. On Jun 24, 2010, at 4:12 AM, Noel Grandin wrote: > Hi > > I can't find a use for the constant MessageType.APPLICATION in the pivot > code. > > Is it intended for something, or can I remove it? > > -- Noel Grandin
[jira] Resolved: (PIVOT-538) Table is uneditable when opened modally
[ https://issues.apache.org/jira/browse/PIVOT-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Brown resolved PIVOT-538. -- Resolution: Not A Problem OK, great. Since you have it working now, I'm going to resolve this as not a problem. > Table is uneditable when opened modally > --- > > Key: PIVOT-538 > URL: https://issues.apache.org/jira/browse/PIVOT-538 > Project: Pivot > Issue Type: Bug > Components: wtk >Reporter: Kelvin Bell > Fix For: 1.5.1 > > Attachments: pivotmodaltest.zip, Working-pivotmodaltest.zip > > > Tables that are in a modal Frame/Dialog/Sheet have rows which are not > editable (TableViewRowEditor & setRowEditor become useless). If the Frame > (exact same code) is opened non-modally, then the tables are editable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
MessageType.APPLICATION constant in use?
Hi I can't find a use for the constant MessageType.APPLICATION in the pivot code. Is it intended for something, or can I remove it? -- Noel Grandin
