Swing Maintenance Team

This page is for everyone who wants to improve the Swing client. It was done in the weekly meeting of 2013-23-01. (There is a page about Comparison of Clients also.)

Features that are worth a jira ticket and will be worked on can be collected as "blocking" on jira tracker IDEMPIERE-588 Swing Client improvement.

We began by collecting missing features:

missing features

• WebStart (IDEMPIERE-591)
• Toolbar is not configurable (IDEMPIERE-234)
• List View Columns are not configurable
• http://wiki.idempiere.org/en/Swing_Client_Security
• form layout http://wiki.idempiere.org/en/NF001_FormLayout

CarlosRuiz: that one is maybe the most important IMHO - because it is creating some duplicate effort to try to maintain both different approaches to position fields

• http://wiki.idempiere.org/en/NF001_QuickEntry
• http://wiki.idempiere.org/en/NF001_CustomWindowToolbarButton
• http://wiki.idempiere.org/en/NF001_ColumnToolbarButton
• <CarlosRuiz>active session and broadcast message (even if i have no idea on how to do it in swing) (IDEMPIERE-294)
• <CarlosRuiz> - on the Welcome screen the Recent Items
• <CarlosRuiz> and the new portlets to show reports (not sure if this works on swing)
• <CarlosRuiz> - the little "new" icon in front of menu and favourites options
• <a42niem> and the calendar stuff
• <CarlosRuiz> - setup wizard form doesn't have swing counterpart
• <nmicoud> Print format wizard
• <CarlosRuiz> and the tab editor
• <CarlosRuiz> in zk we implemented some zoom functionality from the ending message of a process - or the process log (IDEMPIERE-370 Implement link from process ending message to next records)
• <Deepak> We added link when process called from button generating a document. This link can be used to navigate to newly generated record

• at the end of a process, ability to return to parameter panel
• Field group labels is not hidden when attached field is not displayed (IDEMPIERE 349)

• in progress
  • scroll wheel works in very small steps in Swing Client (IDEMPIERE-572)
  • Swing text areas break user flow when cycling focus with tab key (IDEMPIERE-573)
  • Swing AutoReducible ComboBox not reduced when used with cursor keys (IDEMPIERE-574)
  • Swing: Toolbar Button to start Process from button fields (IDEMPIERE-587)
  • Restricted items on Combobox (IDEMPIERE-90)
  • DocAction button is showing now just "Action" instead of the name of an action (part of IDEMPIERE-594)

• done
  • SaveAndCreate Button (raised by nmicoud but done by hengsin. ;-)

Ticketing and Peer Review Procedures

The Team consists of

• Nicolas Micoud
• Thomas Bayen
• Dirk Niemeyer
• ...you?

Our workflow

• everyone can write an issue into the above list of missing features
• everyone can create a JIRA ticket. A JIRA ticket means either that the issue is of special significance or that the reporter takes responsibility that someone work on this ticket. (We do not want to create a bunch of dead tickets that noone reads and resolves.)
• Every issue where the Swing Maintenance Team should be responsible becomes the following attributes:

- Component "Swing Client"

- Label "SwingUI"

- Link the new issue as blocking to IDEMPIERE-588 (Swing Client improvement)

• If one wants to work on an issue he sets himself as the Assignee. (Others may comment at any time or give code if they want.)
• If one really does work he sets the status to "Progress". Others are aware to ask him before they do code on the same issue
• If the Assignee thinks his code is well done he changes status to "Peer Review". He needs to give a link to his contribution in the comment.
• If one experienced member of the Swing Maintenance Team has reviewed he may reopen the ticket or mark it as resolved. This Team member includes the code into the iDempiere Swing Repository at https://bitbucket.org/tbayen/idempiere-swing
• If another Team member (not the Assignee and not the Reviewer) has done a second review he closes the issue. After 4 weeks (and noone else complaining) the issue may be closed by anyone who thinks it is solved.

The Swing Repository (BBP philosophy)

The Swing Repository can be found at https://bitbucket.org/tbayen/idempiere-swing .

The first idea was to insert here peer reviewed code one patch after the other and do a pull request to the main idempiere repository from time to time. This did not work. Our peer review is not good enough to guarantee perfect quality. We can not use the same branch for our peer review (= possible unstable code) and for pull requests to the main trunk (= stable code). Often we see much more issues in our code if Carlos Ruiz or Heng Sin as Maintainers of the main Repository look onto it. But then it was not trivial to separate working patches from not working patches. We agreed that swing changes should stay in the swing directory. But half of our contributions affect other parts of idempiere so this separation is not easy possible. The solution is: We separate them all and create a new staging area. I call this BBP (Bayen's Best Practice). :-)

The Repository is owned by one person (Thomas Bayen) so it is assured that commits are worked on one after the other. Thomas is responsible to synchronize the repository with the main trunk from time to time.

If you have an enhancement you first create a JIRA tracker. Then you commit to your own cloned repository using the tracker ID and the tracker title as the commit message. Every new issue has to be based on the actual main trunk version (branch "development" - whatever means "actual" for you: you may have synchronized with main trunk further than the swing repo if you want) - not on the swing branch. (Only if you stick to this rule we can assure that every issue commits are independent from other issues!). So you open a new head in branch "development" for every issue. (It may be you have to use the "-f" switch of hg for that.) Then you do a pull request to the swing repository.

I will integrate all issues as new heads into the swing repository. We can pick them one by one if they are reviewed and discuss them separately with the trunk maintainers.

If you add something to an issue you add to the head for that issue and choose the same commit message.

If your issue depends on another issue you may take the head of this parent issue as your commit base and use a commit message of your new issue tracker.

At last I created a branch "swing". In this branch I merge all heads of "development". This is our "stage" for testing and peer review purposes. I would invite everyone to use that version. (I use it in daily work so I will keep it as stable as possible.)

And yes - juggling with commits and heads confuses your mind highly. Don't think it's not the same for me. :-) If you see something that can be improved or made easier on the BBP please tell me.