Opened 2 years ago

Closed 22 months ago

#348 closed bug (invalid)

MUIA_NoNotify only works if passed before MUIA_Slider_Max

Reported by: Andreas Falkenhahn Owned by:
Priority: normal Milestone: 5.0-2017R2
Component: Numeric.mui Version: 5.0-2016R2
Severity: minor Keywords:
Cc: OS Platform: All
Blocked By: Blocking:
Release Notes:

Description

AFAIU, it shouldn't matter if MUIA_NoNotify is passed before or after the attribute. Hence, both of these lines should do exactly the same:

SetAttrs(o, MUIA_NoNotify, TRUE, MUIA_Slider_Max, 100, TAG_DONE);
SetAttrs(o, MUIA_Slider_Max, 100, MUIA_NoNotify, TRUE, TAG_DONE);

If my assumption is correct, then we have a bug in MUIA_Slider_Max because when setting MUIA_Slider_Max, MUIA_NoNotify only works when it is specified before MUIA_Slider_Max.

Little demo attached. To reproduce, just hit the button two times. The second button press will trigger a MUIA_Slider_Level event although NoNotify was used.

Attachments (1)

main.c (2.1 KB) - added by Andreas Falkenhahn 2 years ago.

Download all attachments as: .zip

Change History (7)

Changed 2 years ago by Andreas Falkenhahn

Attachment: main.c added

comment:1 Changed 2 years ago by Thore Böckelmann

Component: Slider.muiNumeric.mui
Priority: undecidednormal

First of all, better use the appropriate attribures of Numeric class, i.e. MUIA_Numeric_Max instead of MUIA_Slider_Max. Although both attributes share the same value the MUIA_Slider_xxx attributes are considered obsolete.

Now back to the original topic. For Notify class the order of normal attributes and MUIA_NoNotify does not matter. However, for Numeric class the order does matter as it implements special handing for MUIA_NoNotify. Notify class will disable all further notification handling if MUIA_NoNotify=TRUE is passed anywhere in the list of attributes. Numeric class will disable notifications of MUIA_Numeric_Value for the following occurence of MUIA_Numeric_Mix/Max after it recognizes MUIA_NoNotify=TRUE.

A call like this will disable the notification for the MUIA_Numeric_Value if the new minimum value is larger than the current value, but not for the maximum value:

SetAttrs(slider,
  MUIA_NoNotify, TRUE,
  MUIA_Numeric_Min, minvalue,
  MUIA_Numeric_Max, maxvalue,
  TAG_DONE);

This means that you must use something like this to set both minimum and maximum value with a single SetAttrs() without triggering a notification for MUIA_Numeric_Value:

SetAttrs(slider,
  MUIA_NoNotify, TRUE,
  MUIA_Numeric_Min, minvalue,
  MUIA_NoNotify, TRUE,
  MUIA_Numeric_Max, maxvalue,
  TAG_DONE);

I cannot tell why Stefan Stuntz implemented things in this way, but he must have had a (more or less) good reason to do it. Unfortunately he did not add any comments about the reason.

Is there any reason why you need to pass MUIA_NoNotify after MUIA_Slider_Min/Max? The nnset() macro already does everything in the correct order, although for a single attribute only.

I admit this special situation definitely needs to be documented, otherwise other developers will stumble over the same obstacle again.

comment:2 Changed 2 years ago by Andreas Falkenhahn

No, there's no special reason to pass MUIA_NoNotify after the attribute. I could change this of course.

Still, are you sure that this is a deliberate design decision in MUI and not a bug? Having to use code like this seems weird and non-standard:

SetAttrs(slider,
  MUIA_NoNotify, TRUE,
  MUIA_Numeric_Min, minvalue,
  MUIA_NoNotify, TRUE,
  MUIA_Numeric_Max, maxvalue,
  TAG_DONE);

comment:3 Changed 2 years ago by Thore Böckelmann

The point is that for Numeric class the MUIA_NoNotify preceeding the MUIA_Numeric_Min/Max attribute is not meant to disable the notificiation for a modified minimum/maximum limit, but to disable the notification of a possibly clipped value and hence a triggered MUIA_Numeric_Value attribute due to the new limits. Of course the notification of MUIA_Numeric_Min/Max will be disabled as well. But usually an application will listen to MUIA_Numeric_Value notifications only, because that is the only attribute a user can modify, i.e. by dragging a slider.

A notification for MUIA_Numeric_Min/Max of course still is possible, but since only the application itself can SetAttrs() these attributes, it is quite useless to set up a notification for these. So the special handling of MUIA_NoNotify to disable a trigger on MUIA_Numeric_Value is definitely not a bug, but a simple tool to disable a notification on an implicitly modified current value. Dragging the slider is an explicit modification within unchanged limits.

Now that I have read my own example code again I must admit, that using MUIA_NoNotify twice when changing both limits in a single SetAttrs() call is very uncommon, because the current value can be clipped against one limit only, but not both. The current value is either smaller than the new minimum or larger than the new maximum. But no matter which new limit causes the current value to be clipped the application should be interested in a notification due to an implicit modification, unless it has very good reasons to be not notified. And that's the point where the special handling of MUIA_NoNotify joins the game.

comment:4 Changed 23 months ago by Thore Böckelmann

Milestone: future release5.0-2017R2
Status: newpending

Are there any questions left unanswered here?

comment:5 Changed 23 months ago by Andreas Falkenhahn

Status: pendingnew

No, this can be closed.

comment:6 Changed 22 months ago by Thore Böckelmann

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.