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


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

Submitted by:  Mike Miller <mtmiller>
Submitted on:  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

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( 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>
Project 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>
Project 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].


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:

and the edit uicontrol is displayed with a white background. The only related information I could find about this is:

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

Thanks Guillaume, I pushed your patch here:


Pantxo Diribarne <pantxo>
Project 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,

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>
Project 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]:

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>
Project 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>
Project Administrator
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>
Project Administrator
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>
Project 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>
Project Administrator
Mon 07 May 2018 02:26:31 AM UTC, comment #11:

It certainly depends on whether the backend has been initialized.

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>
Project 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

but with octave-gui I get

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>
Project Administrator
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

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

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

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

Something is messed up here.

Rik <rik5>
Project 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>
Project 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>
Project Administrator
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

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>
Project 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>
Project Administrator
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>
Project Administrator
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:

Could change this to

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>
Project 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>
Project Administrator
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>
Project 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>
Project Administrator


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

Attach Files:

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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project 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.4