FWD » Core Development » User Interface

This task is for full implementation of the GUI widget implementation for SLIDER. Both static and dynamic usage is needed.

Make sure that the common widget options, attributes and methods are supported in the runtime code.

Please include both conversion and runtime support for these attributes/options:

Required:
HORIZONTAL, VERTICAL (only possible as an option, probably is the same as HORIZONTAL == NO)

Nice to have:
LARGE-TO-SMALL
NO-CURRENT-VALUE
MAX-VALUE
MIN-VALUE
TICK-MARKS
FREQUENCY

Created task branch 2612a from trunk revision 10935.

The question. Do we need the support for slider widget in ChUI? I'm asking because some client code can be common for ChUI and GUI and it is better to have the common code in standalone classes I guess.

Task branch 2612a for review updated to revision 10936.

This update adds first steps for SLIDER widget conversion support. With this change the slider widget is properly generating. The supported attributes(conversion level, converted code is able to be compiled) for now are:
HORIZONTAL, VERTICAL(which is not actual attribute but VIEW-AS option for SLIDER widget), MAX-VALUE, MIN-VALUE.

As far as I understand it, slider is a GUI-only widget.

Please test to confirm this.

OK. I'm glad you tested it.

Does the ChUI version work with the keyboard/focus or does it require mouse support?

Does the ChUI version work with the keyboard/focus or does it require mouse support?

In ChUI mode it works with keyboard(to change the value) and handles the focus gain/lost by focus change key. No mouse required.

Rebased task branch 2612a from P2J trunk revision 10937, new branch revision is 10938.

Task branch 2612a for review updated to revision 10939.

The update adds conversion base support for planned attributes:
LARGE-TO-SMALL, NO-CURRENT-VALUE, MAX-VALUE, MIN-VALUE, TICK-MARKS, FREQUENCY. Need to write testcases to verify all getters/setters are working properly and check if the dynamic case is working as well.

Do we need the support for slider widget in ChUI? I'm asking because some client code can be common for ChUI and GUI and it is better to have the common code in standalone classes I guess.

We now have an answer to your original question. Yes, when it is time to implement the client-side runtime support, please use a common widget approach with ChUI and GUI subclasses.

Greg Shah wrote:

We now have an answer to your original question. Yes, when it is time to implement the client-side runtime support, please use a common widget approach with ChUI and GUI subclasses.

OK.

Task branch 2612a for review updated to revision 10940.

This update completes conversion support for slider widget for all mentioned attributes. The next step is to resolve possible review notes, rebase with the recent trunk and test for Java 8 compatibility.

And if there are no notes/issues I guess we can put this into regression testing.

Code Review Task Branch 2612a Revision 10940

This is very good. Some minor thoughts:

1. In the SliderInterface, do we need setMinValue(int64) when we have setMinValue(NumberType) (int64 is a NumberType)? The same is true for setMaxValue(int64).

2. In the SliderInterface, shouldn't we implement setMinValue(double) instead of setMinValue(int)? The same is true for setMaxValue(int) and setFrequency(int).

3. HandleCommon is missing SliderInterface.

Please rebase, fix these issues and I'll do a final code review. Then it should go into testing. It can go next.

Greg Shah wrote:

Code Review Task Branch 2612a Revision 10940
2. In the SliderInterface, shouldn't we implement setMinValue(double) instead of setMinValue(int)? The same is true for setMaxValue(int) and setFrequency(int).

The MIN/MAX-VALUE are INTEGER, not DECIMAL. I thought this should map to the int internally. It is not correct?

The MIN/MAX-VALUE are INTEGER, not DECIMAL. I thought this should map to the int internally. It is not correct?

It depends.

1. Can you set these values using an INT64?
2. Can you set these values using a DECIMAL?

If so then the setters need to accept the types that are possible (and then cast/truncate as needed). The getter probably does need to return an INTEGER if that is what the 4GL does. If so, then internally storing as an int is good.

Rebased task branch 2612a from P2J trunk revision 10938, updated to revision 10942.

The update resolves the notes, fixes the javadoc errors. And we do not need set(Min|Max)Value(int64). Also the MIN/MAX attributes does not accept INT64 and DECIMAL. Moreover it is not possible to change attributes after realization. So I think int is OK as internal data storage.

Other attributes were checked too.

Code Review Task Branch 2612a Revision 10942

I'm good with the changes. Please put it through conversion regression testing. If it passes, you may merge it to trunk.

You don't need to do runtime regression testing.

Greg Shah wrote:

Code Review Task Branch 2612a Revision 10942

I'm good with the changes. Please put it through conversion regression testing. If it passes, you may merge it to trunk.

You don't need to do runtime regression testing.

OK. Testing is in progress.

The conversion testing is completed. Generated sources are identical, starting merge into trunk.

Branch 2612a was merged to trunk as revno 10939. Archived.

The slider widget testcases have been added to bzr repo(revision 1344).

Created task branch 2612b from trunk revision 10962.

Rebased task branch 2612b from P2J trunk revision 10965, still no changes from trunk.

Task branch 2612b for review updated to revision 10966.

This is the fix for conversion support of the dynamic slider attribute setting. The interface mane should be truncated to have no "Interface" suffix to properly generate data wrapper method.

Rebased task branch 2612b from P2J trunk revision 10966, new branch revision is 10967.

Task branch 2612b for review updated to revision 10968.

This is the preparation steps to have GUI implementation. The SliderWidget and SliderCOnfig bases are changed to BaseEntity and BaseConfig respectively to have more features that can be demanded in runtime implementation. The SliderConfig is added to config manager classes to create the instance. Making the preparation to support dynamic widget. On the client side the changes made to be able to reconstruct widget and implement UI independent and GUI specific features. The ChUI mode is still postponed to the moment when it will be required. The GUI mode now has only placeholders to get compiled and verify the logic is OK. Continue with GUI implementation. Looks like we need to make SVG image for slider thumb.

Cool!

Rebased task branch 2612b from P2J trunk revision 10967, new revision 10971.

Task branch 2612b for review updated to revision 10972.

Adding mouse handling base. Preparing to rebase for 10969 trunk. Working on handling mouse drag event. The source still has the commented experimental code and some debug calls.

Rebased task branch 2612b from P2J trunk revision 10969, new revision 10974.

Task branch 2612b for review updated to revision 10975.

Adding support for moving slider pointer by mouse drag. The next step will be to implement the different slider pointers via vector SVG images. There can be 7 different pointers: down, right for no tic marks mode, up, down, left, right, both for tic marks enabled mode. All of them has different sizes and shapes so we need separated images for each one, however one of them can be drawn without bitmap(tic mark enabled BOTH mode).

Please see #2565 (and branch 2565a) for our current work on mouse pointer support. Please review that branch and make sure you don't duplicate any work already done there.

Greg Shah wrote:

Please see #2565 (and branch 2565a) for our current work on mouse pointer support. Please review that branch and make sure you don't duplicate any work already done there.

OK. But this is not exactly related to slider "pointer". The slider "pointer" is like the thumb for scrollbar, may be not a good word to identify the object, I just do not know the better one.

If the mouse pointer doesn't change, then #2565 is not related.

I think it is best called the "thumb".

Task branch 2612b for review updated to revision 10977.

This is rework for all thumb images to exactly match the pictures taken from 4gl and small logic fix to display vertical tick marks. The most of the time today was spent for the finding the SVG drawing that can give the expected results. Because if we just make 1:1 vector - the final converted bitmap will not match the 4gl. So there are many artifacts while using SVG image as source for controls. So the current SVG images looks unusual or a bit ugly while opening in inkskape. But the P2J picture is OK. This is the reason I prefer to work with pure bitmaps.

Continue working on slider widget. Need to verify other GUI widget parts for correct calculations and drawing.

Slider testcases updated in bzr to revision 1465.

Rebased task branch 2612b from P2J trunk revision 10970, new revision is 10978.

This is all coming along nicely. My only comment is that the colors/shading of the edges of the SVG thumbs does not match the 4GL examples shown in note 40.

Greg Shah wrote:

This is all coming along nicely. My only comment is that the colors/shading of the edges of the SVG thumbs does not match the 4GL examples shown in note 40.

Yes, you are right, the pointers from #40 does not match the pictures. Just because they are different ones. It is possible to have 8 different thumb types(depending on tic mark option: top/bottom/right/left/both vertical/both horizontal/none vertical/none horizontal), each of which has different colors/shading. We have to consider each one separately. Working on it. #40 and #46 just does not have the same thumb to compare(I have complete set for 4GL to reproduce in P2J).

This is good headway! It looks like you are very close.

Task branch 2612b for review updated to revision 10983, 10984.

Added missed ASSIGN statement support. Now the base integer variable is properly updating.

Also I've made the change looking strange, so need your comments. I have found in 4GL when the slider value is changing the change trigger is calling twice. It looks like a bug. So the question: do we need to simulate this behavior? In this update I have added the code to reproduce 4GL reaction. But if it is not required - let me know and I remove additional call.

So the code is now ready to be tested and commit as working GUI slider widget. Waiting for the confirmation to start testing(we need the conversion test too because the rule file was changed).

Rebased task branch 2612b from P2J trunk revision 10971, new revision is 10985.

Also I've made the change looking strange, so need your comments. I have found in 4GL when the slider value is changing the change trigger is calling twice. It looks like a bug. So the question: do we need to simulate this behavior? In this update I have added the code to reproduce 4GL reaction. But if it is not required - let me know and I remove additional call.

What testcases shows this behavior?

Greg Shah wrote:

What testcases shows this behavior?

Every test in uast/slider/ directory. In all of them the on value-changed of Sl trigger is listening.

Code Review Task Branch 2612b Revision 10985

This is great work!

1. Please add comments to the javadoc for both versions of SliderWidget,setNoCurrentValue(). As you mention in note 52, the 4GL behavior is very confusing. So it is important to explain this in the javadoc so that it explains how the logic is "reversed" from what would be expected AND that this reversal matches the 4GL behavior.

2. Can you use an int64 or decimal with a slider?

3. Can PAGE_UP/PAGE_DOWN/HOME/END keys be used with a slider?

1. Please add comments to the javadoc for both versions of SliderWidget,setNoCurrentValue(). As you mention in note 52, the 4GL behavior is very confusing. So it is important to explain this in the javadoc so that it explains how the logic is "reversed" from what would be expected AND that this reversal matches the 4GL behavior.

OK. I'll add in a next branch revision shortly.

2. Can you use an int64 or decimal with a slider?

The only data is possible to use with slider is INTEGER.

3. Can PAGE_UP/PAGE_DOWN/HOME/END keys be used with a slider?

Yes, these keys are valid for slider, I've missed to check them. The reaction is also not obvious.
For horizontal:
HOME - move to the left edge,
END - move to the right edge
PAGE_DOWN - 4 values steps to the right
PAGE_UP - 4 values steps to the left

For vertical:
HOME - move to the top edge,
END - move to the bottom edge
PAGE_DOWN - 4 values steps up
PAGE_UP - 4 values steps down

The strange thing is it is not dependent on the LARGE-TO-SMALL option. The pressing HOME not always mean setting slider value to MIN-VALUE and pressing PAGE_DOWN not always decrease the slider value.

I'll implement this in a next branch update later today.

Guy: Eugenie's slider testcases exhibit a strange behavior in GUI. Consider this code:

message "Hit a key to start".
pause.

/** Define widgets **/
define variable Sl as integer initial 5
    view-as slider max-value 25 min-value 1 horizontal.
/* define variable Stat as logical. */
define variable SlValue as character.

define button ExitButton label "Exit".

/* Define frames */
define frame f0
   Sl ExitButton
with side-labels size-chars 40 by 22 centered title "Slider, horizonlal test #01".

/* Trigger definitions */

on value-changed of Sl
   do:
      SlValue = Sl:screen-value.
      message "The value changed to: " SlValue.
   end.

enable all with frame f0.

message "Width in pixels: " Sl:width-pixels ", in chars: " Sl:width-chars.
message "Height in pixels: " Sl:height-pixels ", in chars: " Sl:height-chars.

wait-for choose of ExitButton.

When run in GUI, the trigger executes twice for each value change. This occurs when the user changes the value by either keys or mouse.

Interestingly, when run in ChUI, the trigger only executes once per value change.

Can you see anything in the testcases that might cause this or is this just a strange "feature" of the 4GL GUI?

2. Can you use an int64 or decimal with a slider?

The only data is possible to use with slider is INTEGER.

Changing the Sl variable in slider_test01.p to int64 works without any problem in ChUI. I didn't test in GUI, but I would expect it to work fine.

The only data is possible to use with slider is INTEGER.

Changing the Sl variable in slider_test01.p to int64 works without any problem in ChUI. I didn't test in GUI, but I would expect it to work fine.

Yes, it is true. I've double checked the previous notes(which I used to conclusion above). The MIN/MAX attribute values are INTEGER, not the slider value itself. Need to fix this.

But the question: even if we can initially assign the big enough value the screen value can be from MIN to MAX - when the screen value commit back to variable it can not be outside the INTEGER range. Some confusing point?

But the question: even if we can initially assign the big enough value the screen value can be from MIN to MAX - when the screen value commit back to variable it can not be outside the INTEGER range. Some confusing point?

Just make sure our error handling is the same as the 4GL. For example, if they raise and error, so should we.

Task branch 2612b for review updated to revision 10986.

Notes resolution for point 1 and 3 from #60 note. The handling of the INT64 is in progress.

Task branch 2612b for review updated to revision 10987.

Added support for INT64 internal slider variable. Screen value remains int. The respective testcases uploaded in bzr revision 1469.

Code Review Task Branch 2612b Revision 10987

I'm fine with the changes. Please put them through regression testing.

Greg Shah wrote:

Code Review Task Branch 2612b Revision 10987

I'm fine with the changes. Please put them through regression testing.

OK. Starting with conversion testing.

The conversion testing completed, generated codes are identical. Continue with runtime testing.

The main part completed without regressions. Running CTRL-C one.

If CTRL-C testing passes, please go ahead and merge 2612b to trunk.

Greg Shah wrote:

If CTRL-C testing passes, please go ahead and merge 2612b to trunk.

OK. The testing completed, no regression, had to run CTRL-C 3 way tests in a separate session.

Starting the merge action.

The results are in 2612b_10987_2791e7a_20160217_evl.zip.

Branch 2612b was merged to trunk as revno 10972 then it was archived.