Swing Maintenance Team

From iDempiere en

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

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
  • 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)

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)

At the moment the Swing repository is *very* outdated. I will re-synchonize it with the active trunk in the first half of december. Please stay tuned...

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). :-) See Mercurial Bayen Best Practice for more.