bugGNU Octave - Bugs: bug #53805, doc: some default Qt properties...

 
 

bug #53805: doc: some default Qt properties are different between systems

Submitter:  Mike Miller <mtmiller>
Submitted:  Tue 01 May 2018 07:55:21 PM UTC
   
 
Category:  Documentation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Documentation
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 12 Jun 2018 12:31:27 AM UTC, comment #25: 

I pushed a small change to set the ShadowColor default to match Matlab here (http://hg.savannah.gnu.org/hgweb/octave/rev/d2d9701d2dcb).

Rik <rik5>
Group administrator
Mon 11 Jun 2018 04:53:03 PM UTC, comment #24: 

Yes, the ShadowColor property of a uibuttongroup is [0.7 0.7 0.7] too.
And the HighlighColor property of uipanel and uibuttongroup is [1 1 1].
If they are not mentioned in the documentation, it might be that they are platform dependent (or that they changed over time) but I can't check that now.

Guillaume <gyom>
Mon 11 Jun 2018 03:48:58 PM UTC, comment #23: 

"ShadowColor" is available for uipanel and for uibuttongroup.  Could you check that the default for uibuttongroup is also [0.7, 0.7, 0.7]?

Also, "HighlightColor" doesn't list a default.  Could you check that the one we are using ([1 1 1]) is correct for uipannel and uibuttongroup?

Rik <rik5>
Group administrator
Tue 05 Jun 2018 04:28:36 PM UTC, comment #22: 

At last, a default value is not mentioned in the documentation but the ShadowColor property of a uipanel seems to be [0.7 0.7 0.7] instead of [0 0 0].

https://www.mathworks.com/help/matlab/ref/matlab.ui.container.panel-properties.html#bt79ov_-1_sep_shared-ShadowColor

Guillaume <gyom>
Tue 05 Jun 2018 02:59:02 PM UTC, comment #21: 

Thanks Pantxo! There is one last Matlab quirk that I don't manage to fully understand yet: uicontrol's edit has a white background by default despite the backgroundcolor porperty saying otherwise. I.e in Matlab:


figure;
h = uicontrol('Style','edit');
get(h,'backgroundcolor')
ans =
    0.9400    0.9400    0.9400


and the edit uicontrol is displayed with a white background. The only related information I could find about this is:
https://www.mathworks.com/matlabcentral/answers/65

Guillaume <gyom>
Tue 05 Jun 2018 02:35:06 PM UTC, comment #20: 

Thanks Guillaume, I pushed your patch here:

http://hg.savannah.gnu.org/hgweb/octave/rev/ecc488aa56a0

Pantxo Diribarne <pantxo>
Group Member
Tue 05 Jun 2018 11:21:58 AM UTC, comment #19: 

Thanks Rik. According to the online Matlab documentation, uicontrol, uibuttongroup and uipanel have a default background color of [0.94,0.94,0.94]. I attach a small diff for libinterp/corefcn/graphics.in.h.


(file #44298)

Guillaume <gyom>
Thu 17 May 2018 04:49:42 PM UTC, comment #18: 

The default colors come from the root object.  The defaults are set in libinterp/corefcn/graphics.in.h.  Look for the macro BEGIN_PROPERTIES.  For example,


    BEGIN_PROPERTIES (uipanel)
      color_property backgroundcolor , color_values (1, 1, 1)


Since we are no longer getting the default colors from the environment, we should look through the Matlab documentation and use their defaults for compatibility.  I can review such a changeset if you want to make one.

Rik <rik5>
Group administrator
Thu 17 May 2018 04:27:16 PM UTC, comment #17: 

Could you clarify where do the default color values come from now? After this change, the background color of a uipanel is white, while its default value in Matlab is [.94 .94 .94]:
https://uk.mathworks.com/help/matlab/ref/matlab.ui.container.panel-properties.html#d119e1197796

Guillaume <gyom>
Thu 17 May 2018 05:04:23 AM UTC, comment #16: 

I removed the code which copied colors from the existing window theme on to the root graphics object here: http://hg.savannah.gnu.org/hgweb/octave/rev/2b0680bdb1ed.

Closing report.

Rik <rik5>
Group administrator
Tue 15 May 2018 01:28:17 AM UTC, comment #15: 

I'd prefer that this be fixed on stable, since it will fix generation of the user manual for 4.4.1, and it will only be changing default values, not a big behavioral change.

Mike Miller <mtmiller>
Group Member
Tue 15 May 2018 01:26:25 AM UTC, comment #14: 

Seems like no one cares, so let's remove that code from the Qt toolkit initialization.

That will fix this bug, no need to change anything else since the properties will be constant again and not system-dependent.

Mike Miller <mtmiller>
Group Member
Mon 07 May 2018 01:45:53 PM UTC, comment #13: 

Let me post something on Octave Maintainers and see if there is any objection to just removing the code from _init_qt_.

Rik <rik5>
Group administrator
Mon 07 May 2018 03:12:11 AM UTC, comment #12: 

I see. Looks like this has been in QtHandles since before it was merged into Octave.

If we get rid of this behavior for Octave 5, then we can also keep the documented default color values in the manual, since they will be constant from system to system.

Mike Miller <mtmiller>
Group Member
Mon 07 May 2018 02:26:31 AM UTC, comment #11: 

It certainly depends on whether the backend has been initialized.


run-octave --gui
>> get (0, 'defaultuicontrolbackgroundcolor')
ans =

   1   1   1

>> h = plot (1:10);
>> get (0, 'defaultuicontrolbackgroundcolor')
ans =

   0.28627   0.30588   0.34510


I can see why it might be nice to keep colors, particularly ui objects, within the current color scheme.  On the other hand, this is Matlab-incompatible.  Matlab has a default background color (https://www.mathworks.com/help/matlab/ref/matlab.ui.container.buttongroup-properties.html) and the correct way to override it is to set up the default scheme in the root object.


Rik <rik5>
Group administrator
Mon 07 May 2018 01:09:34 AM UTC, comment #10: 

Which graphics toolkit did you test with?

As part of the '__init_qt__' function, it is supposed to use the Qt theme palette to override various default color properties. Look for 'root.set' in libgui/graphics/__init_qt__.cc.

With octave-cli I get


>> get (groot, "DefaultuicontrolBackgroundColor")
ans =

   1   1   1


but with octave-gui I get


>> get (groot, "DefaultuicontrolBackgroundColor")
ans =

   0.93725   0.93725   0.93725


This is the code I found when I was looking for a cause for the differences between various color properties on two different systems. I have not tested, but I assume that these colors pulled from Qt can vary depending on the user's desktop environment or theme. For example, mine is a very light gray, while yours (at least the one in octave.pdf) is a dark slate gray.

Mike Miller <mtmiller>
Group Member
Mon 07 May 2018 12:54:05 AM UTC, comment #9: 

Back to the original bug.  I looked at just one example which was the "backgroundcolor" property for uicontrol objects.

In the generated octave.pdf file, I have


backgroundcolor: def. [0.28627 0.30588 0.34510]


This is different from graphics.in.h which defines it as 1,1,1.


    BEGIN_PROPERTIES (uicontrol)
      color_property backgroundcolor , color_values (1, 1, 1)


It is also different than what I get if I directly query the graphics system.


get (groot, "DefaultuicontrolBackgroundColor")
ans =

   1   1   1


And finally, it isn't what I get if I create a uicontrol object and query it.


h = uicontrol ();
get (h, "BackgroundColor")
ans =

   1   1   1


Something is messed up here.


Rik <rik5>
Group administrator
Mon 07 May 2018 12:35:21 AM UTC, comment #8: 

The second construct ("%reldir%/graphics.in.h") fails, but the first works.  I changed the graphics property texi files to depend on graphics.in.h and genprops.awk.  See http://hg.savannah.gnu.org/hgweb/octave/rev/8cac064e6623.

Rik <rik5>
Group administrator
Sun 06 May 2018 10:08:08 PM UTC, comment #7: 

No, but it should work with "libinterp/corefcn/graphics.in.h", or more properly, "%reldir%/graphics.in.h".

Mike Miller <mtmiller>
Group Member
Sun 06 May 2018 09:55:05 PM UTC, comment #6: 

I'm not sure the VPATH machinery work outside of C-derived langugages.  I tried adding graphics.in.h and make fails with


make[2]: *** No rule to make target 'graphics.in.h', needed by 'doc/interpreter/plot-axesproperties.texi'.  Stop.


On the other hand, adding $(srcdir)/libinterp/corefcn/graphics.in.h works just fine, and touching the graphics.in.h does force a rebuild.

Rik <rik5>
Group administrator
Sun 06 May 2018 04:25:24 PM UTC, comment #5: 

Also there is no need to specify $(srcdir) or $(builddir) in the dependency list, that's exactly the place where make can find the relative file name in either the current directory or in the vpath (in the source directory).

Mike Miller <mtmiller>
Group Member
Sun 06 May 2018 04:07:47 PM UTC, comment #4: 

As long as this does not force a rebuild when we distribute the docs in the source release. I think that would mean depending on the original source files only, maybe both on graphics.in.h and genprops.awk (same dependencies as graphics-props.cc).

I'm happy to test this, just a little short on time today.

Mike Miller <mtmiller>
Group Member
Fri 04 May 2018 11:26:20 PM UTC, comment #3: 

@Mike: For comment #2, is it enough to add graphics-props.cc (in libinterp/corefcn) to the list of dependencies in the Makefile rules for each graphics prop texi file?  Example rule in doc/interpreter/module.mk:


%reldir%/plot-axesproperties.texi: %reldir%/genpropdoc.m
        $(AM_V_GEN)$(call gen-propdoc-texi,axes)


Could change this to


%reldir%/plot-axesproperties.texi: %reldir%/genpropdoc.m $(srcdir)/libinterp/graphics-props.cc
        $(AM_V_GEN)$(call gen-propdoc-texi,axes)


The exact selection of a dependency might be a little tricky since graphics-props.cc is a generated file.  Maybe we want $(builddir) instead of $(srcdir).  Or maybe we choose graphics.in.h which is the file that graphics-props.cc is generated from.

Rik <rik5>
Group administrator
Thu 03 May 2018 07:39:25 PM UTC, comment #2: 

I've now also noticed that if new properties are added or if default values are changed, the Texinfo files are not regenerated. A user who is continuously following development and rebuilding in the same directory may not see updated sets of properties in the generated docs.

Mike Miller <mtmiller>
Group Member
Thu 03 May 2018 08:13:39 AM UTC, comment #1: 

We generally disable the display of default values for properties that may be system dependent (e.g. root "screenpixelsperinch"). It is enough to switch a flag in genpropdoc.m.

Pantxo Diribarne <pantxo>
Group Member
Tue 01 May 2018 07:55:21 PM UTC, original submission:  

Some of the default plot properties may differ between systems. When building the Octave user manual, the default property values are pulled from an Octave script. But depending on the system where this build is done, the default values that are written into the user manual may be different.

I am of the strong opinion that the user manual should be built to produce identical output on all systems.

The attached diff shows some differences between the generated plot properties on my system and on jwe's system used to build the official release of Octave.

All of the properties that differ are (I think) because of Qt theme differences between our systems.

  • uibuttongroup backgroundcolor
  • uibuttongroup shadowcolor
  • uicontrol backgroundcolor
  • uipanel backgroundcolor
  • uipanel shadowcolor


There may be more on another system with a much more different theme.

Mike Miller <mtmiller>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #44298:  graphics.diff added by gyom (1KiB - text/x-patch)
file #44065:  propdefs.diff added by mtmiller (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by mtmiller (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-05 gyom Attached File- Added graphics.diff, #44298
    2018-05-17 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2018-05-03 pantxo StatusNone Confirmed
    2018-05-01 mtmiller Attached File- Added propdefs.diff, #44065

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code