Changes to the participation intervals GUI

[Lokorin]

Status: Included in version 1.4.0

Currently the participation intervals are displayed in a tab. In the tab there's a table and a tab group. The table has one row for each participation interval and the tab group contains tabs with the details of each participation intervals. The table rows act as shortcuts to the tabs, selecting a table row automatically switches to that tab.

Having every tab displayed when there's already a table feels like overkill. Maybe it would be better to remove the tabs and instead just display the participation based on the row selected in the table? The following would be in the participation tab:

The participation table to the left, then a composite with the buttons used for manipulating intervals, then a list of all the participants and furthest to the right a composite with the buttons for altering the participation.

What would be even better is that selecting multiple rows could show the intersection of the intervals, and allow removing and adding people to multiple participation intervals at the same time (i.e. one less thing to do ). It would also allow joining intervals by selecting them and then clicking a join button (I think impishfae suggested something like that). Splitting would only be allowed when exactly one interval is selected.

While doing this the buttons and functionality for creating new participation intervals could be added. It would also make sense to gray out the buttons that can not be used (e.g. gray out the split button if multiple intervals are selected).

By the way, graying out buttons that can not be used is something that the program lacks in general.

[impishfae]

This sounds awesome. I like your style.

[Lightning]

sounds good...
2 points to this:

1. I found out, that especially deleting some of these taps couses programm-crashes. Hopefully the re-designing will solve this problem.
2. As far as this "manipulating" is working also on the points, it would be great. If i atm. add someone to 1 of these tabs, he doesnt gain points in the zero-sum-system.
E.g. due to some lightning someone has no internet for 15 minutes. In this time he doesnt gain points. But for the the hour before and after he does. Due to the point, that he is offline not by his own fault it would be nice, if he would gain points for these 15 minutes.

[Lokorin]

The changes have now been committed. A word of warning though: removing multiple people from multiple intervals is currently very slow. This is because almost everything in the GUI is dependent on the participation, causing almost everything to be updated upon participation changes.

The real problem is that there's currently no functionality for locking updates so that e.g. no updating is done until the whole batch of removals are done. The lack means that removing 5 persons from 5 intervals will cause almost 25 resynchronizations of almost every table in the GUI, which takes time. So some kind of lock has to be added.

It shouldn't be hard to implement as every update is triggered by the update() method, the question is how. I see two important questions:

Q1. Should the lock be global or should it be possible to for instance just lock updates to table x?
Q2. If one locks, performs the removals and then just unlocks one will have an out of date GUI as none of the update requests caused by the removals will have gone through. How should the GUI be kept current after unlocking?


My thoughts about possible answers:
A1
The update code is currently fairly well structured, so local locks are not a whole lot of more work than a global lock. Whether or not a single global lock should be used depends on how question two is solved. If a global lock requires that the entire GUI is updated upon unlocking then it could cause situations when locking and then unlocking would be worse for performance than just skipping locks. I'd rather have a situation where one can always lock updates without worrying about performance.

A2
This depends on how question one is solved. If a global lock is used then performing an automatic update whenever unlocking will be negative for performance. If local locks are used then doing an automatic update would be reasonable as one would hopefully not be locking things that were not going to receive update requests.

A slightly more sophisticated solution would be to queue updates when a lock is active. Duplicates (same observable object and argument) could be removed from the queue, meaning that only unique update requests would be processed upon unlocking.

More things to consider
Updates can currently overlap. If for instance one changes the participation then the DKP will also be recalculated, causing two separate update requests that will both update the global statistics table (as it tracks both participation and DKP). Possibly one could queue things on based on the component that should be updated rather than depending on what was changed.

[Lokorin]

After thinking a bit about it I think that it should be implemented as a queue of updateXyz() method calls where duplicates are removed. The lock should be global (as it would not make a lot of difference). Such a system would ensure that an GUI area that became out of date while the lock was active will only be updated once when the lock is released.

To give an idea of how updates currently work: The GUI is an Observer and the DayBlock is an Observable, the following is the GUI's update() method (which is in the Observer interface).

[impishfae]

Found a bug.

Using the 'extend beginning' button, I selected a time before the start of the first participation interval. I think it's a refresh issue of some kind?

So I initially had:
1 20:02 to 22:28
2 22:28 to 22:39
3 22:39 to 22:39

Extended beginning and entered 20:00
This produced in the GUI
1 20:02 to 22:28
2 22:28 to 22:39
3 22:39 to 22:39
1 20:00 to 20:28

Clicking on the top entry made poor DKPLP fall over and the following NPE appear in the log

[Lokorin]

I was poking around in the code that updates that table yesterday, so that's probably when I broke something.

*edit*

It has been fixed.