[ilya_shaikovsky]

look to https://jira.jboss.org/jira/browse/RF-4724

this feature implementation for pickList should works as it should for you and will be also good addition to listShuttle.

[klester]

Ilya - Sorry I'm a bit confused. Are you saying you agree with the implementation of the last patch I submitted to disable the movement of items by clicking/double-clicking based on the controls that are visible, and that you are also OK with the change it makes to the ListShuttle?

I'll work on issue RF-4724 next. If the last patch I submitted for https://jira.jboss.org/jira/browse/RF-6729 gets committed soon, then I'll create a new patch for RF-4724. Otherwise I'll just make the patch for RF-6729 cumulative for both issues.

[nbelaevski]

Ilya is out of the office, so I'll clarify his point. He meant to say that addition of the attribute proposed in RF-4724 solves the problem, so that the user will be able to switch move by click feature off explicitly if he hides some controls. And then there's no need in logic disabling this feature basing on values of attributes controlling buttons visibility.

What do you think?

[klester]

Nick - I think that adding the "switchByDblClick" attribute would be a nice addition and would give the user additional flexibility, but I think that it should be used in addition to the last patch I submitted.

I'm just having trouble envisioning a situation where a user would want to hide the "Remove" controls, yet still want to give the user the ability to remove items by clicking on them. It seems to me that the reason a user would hide the "Remove" controls would be that they want to specifically disable the ability to remove items. So I think that if the user hides the Remove controls, then they will ALWAYS want to disable the removing of items by clicking. Perhaps this isn't a correct assumption on my part, but I can't think of a situation where they wouldn't want to disable the removal of items if the Remove controls aren't visible.

Given this assumption, I think it would make sense to always disable the movement of items depending on the controls that are visible. The switchByDblClick attribute could also be used to accomplish this, but requires an extra step by the user, and would also disable their ability to copy items by clicking on them for this example.

I really don't see either way as "wrong", and for backwards compatibity it makes more sense to just rely on the "switchByDblClick" attribute, I just see it as a little less user friendly.

[klester]

I uploaded a patch for issue RF-4724 in the following new Jira issue: https://jira.jboss.org/jira/browse/RF-6769. This patch does not include the logic to automatically enable/disable the movement of items by clicking on them based on the controls that are visible.

If you don't think we should auto-disable the movement of items based on the controls that are visible, then you can simply ignore the latest patch to RF-6729, and just close the issue.

If you think we should include this functionality, then let me know and I'll merge the two patches.

Kevin

[ilya_shaikovsky]

I'm just having trouble envisioning a situation where a user would want to hide the "Remove" controls, yet still want to give the user the ability to remove items by clicking on them. It seems to me that the reason a user would hide the "Remove" controls would be that they want to specifically disable the ability to remove items. So I think that if the user hides the Remove controls, then they will ALWAYS want to disable the removing of items by clicking. Perhaps this isn't a correct assumption on my part, but I can't think of a situation where they wouldn't want to disable the removal of items if the Remove controls aren't visible.

perhaps I could agree there with you in general.. but usually when we choosing between such options I prefer not to do something 'automatically'. If there will be even only one user who wants for example hide all buttons and allow the user move items only by clicks/dblclicks - the component should work for him. and if we do this auto turn off - it will not.

[klester]

Fair enough. In that case you should use patch RF-6769 which contains the logic for the new 'switchByDblClick' attribute. You can ignore my last patch for RF-6729, and just close that issue since there is really nothing else to be done for it since we are going to rely on the new switchByDblClick attribute.

[nbelaevski]

Kevin,

Let me thank you for another great patch! I've just committed RF-6769 and rejected the second patch for RF-6729.

[klester]

Congrats on the latest release! Fixing over 1100 bugs is quite an accomplishment!

I had some personal stuff to take care of, but I'm back and would like to tackle a few more JIRA issues. I see that you've changed the structure of your SVN repository, and I'm confused on which branch I should make my changes. Should I make the changes to the /branches/community/3.3.X branch, or a different branch? I don't yet see the SVN structure specified in the "RichFaces 4.0 Build System" wiki.

Kevin

[jbalunas]

Hi Kevin welcome back!!

For now use the /branches/community/3.3.X branch while we are working on the new 4.0 build system.

[jbalunas]

One more thing Kevin.

We just got a new contributor agreement application setup for jboss.org and I'm not seeing your entry, and I can't remember if you signed this before. Could you take a look at http://www.jboss.org/contribute/ and sign the agreement. It is a pretty standard OSS agreement.

Thanks

[klester]

Jay,
It looks like the OSS agreement is only for committers, and unfortunately I am not (yet) an official committer to RichFaces. My contributions to date have been in the form of "Patch" Jira issues, so do I still need to sign it?

Kevin

[jbalunas]

Actually the agreement is for anyone submitting a patch, you can use your jboss.org login to get access to the page, then you can apply to the RichFaces project as a personal contributor.

I agree it is a bit confusing - once the new project site is up we'll have a page describing all of this.