bugGNU Octave - Bugs: bug #64985, 'windowstate' property is...

 
 

bug #64985: 'windowstate' property is unimplemented

Submitter:  Nicholas Jankowski <nrjank>
Submitted:  Tue 05 Dec 2023 03:27:06 PM UTC
   
 
Category:  Plotting Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 16 Jan 2024 01:19:29 AM UTC, comment #15: 

documentation about windowstate being unimplemented is at least now updated in the property documentation with the patch in bug #65167.

Nicholas Jankowski <nrjank>
Group Member
Fri 12 Jan 2024 02:36:21 AM UTC, comment #14: 

this turned into a 'review all the properties in the docs and try to make it consistent' exercise.  I'll have something together even if it's a partial doc fix in the next couple days.

Nicholas Jankowski <nrjank>
Group Member
Thu 11 Jan 2024 05:02:54 AM UTC, comment #13: 

@nrjank: Do you want to try and finish off this bug before the 9.1 release, or wait?  Either way is fine.  I think we're getting close.

Rik <rik5>
Group administrator
Tue 19 Dec 2023 01:26:41 AM UTC, comment #12: 

There is an Octave Developer's Meeting tomorrow.  We should probably discuss things a bit more.  My sense is that the release doesn't happen this year, but maybe in January, 2024.

Rik <rik5>
Group administrator
Mon 18 Dec 2023 08:00:06 PM UTC, comment #11: 

it's on my 9.1 to-do list. When do you think we're going to try locking things down?

Nicholas Jankowski <nrjank>
Group Member
Mon 18 Dec 2023 07:28:53 PM UTC, comment #10: 

@nrjank: A part of this bug is simply documentation which could be done on the stable branch.  Any desire to finish that part ahead of the 9.1 release, or should we table it for now?

Rik <rik5>
Group administrator
Thu 07 Dec 2023 02:07:28 AM UTC, comment #9: 

It requires a case-by-case review.

The root object, for example, is never displayed so one can't actually interact with it using the mouse.  Hence, "hittest" and "pickableparts" are unused.  "monitorpositions" seems to work for me, so I would say that it just needs to be documented.  "pointerlocation" is unimplemented.  "pointerwindow" doesn't seem to be a documented property by matlab.

According to Matlab, "clipping" has no effect for figures (which it doesn't).  So it is correct to say it is unused.  "pickableparts" isn't a property of Matlab figures so it is unused as well in Octave.  "currentcharacter" seems to be unimplemented in Octave.  "dockcontrols" is unimplemented.

For graphics primitives such as Line or Text or Image, the "children" property is unused.

You probably need to check the axes object.  I think the documentation is out-of-date.  For example, the "gridcolor" property is implemented and works just fine.

Rik <rik5>
Group administrator
Tue 05 Dec 2023 08:37:40 PM UTC, comment #8: 

that message is explicit enough it probably removes the need for the Note i was asking about in that diff. 

should other cases of doc_unused be changed to doc_notimpl? In addition to adding windowstate, doc_unused is currently applied to:

Root:
hittest
pickableparts
monitorpositions
pointerlocation
pointerwindow
a list of Root object 'overridden shared properties':
            "beingdeleted", "busyaction", "buttondownfcn", ...
            "clipping", "createfcn", "deletefcn", "handlevisibility", ...
            "hittest", "interruptible", "selected", ...
            "selectionhighlight", "uicontextmenu", "visible"

Figure:
clipping
pickableparts
currentcharacter
dockcontrols

Axes:
clipping
ambientlightcolor
clippingstyle
colororderindex
gridalphamode
gridcolor
gridcolormode
linestyleorder
linestyleorderindex
minorgridalphamode
minorgridcolor
minorgridcolormode
projection
sortmethod
xticklabelrotation
yticklabelrotation
zticklabelrotation

Line:
children

Text:
children
editing

Image:
children

Surface:
children

Patch:
children
interpreter

Scatter:
children

Light:
children

uimenu:
buttondownfcn

uicontextmenu:
buttondownfcn

uitoolbar:
buttondownfcn

uipushtool:
buttondownfcn

uitoggletool:
buttondownfcn


a bunch of those like the root list, 'children', and buttondownfcn fall under 'Overridden shared properties'. not being sure what exactly that implies, should they be noted differently/stay doc_unused?

Nicholas Jankowski <nrjank>
Group Member
Tue 05 Dec 2023 08:10:43 PM UTC, comment #7: 

Last comment, since this is a documentation change only it could go on the stable branch.

Rik <rik5>
Group administrator
Tue 05 Dec 2023 08:10:16 PM UTC, comment #6: 

The number of properties that are accepted, but unimplemented, is rather small and can be handled manually.  Typically there is even a note in the commit message when a property is added that isn't implemented.  What programmers, such as myself, should do is also modify genpropdoc.m at the time of the commit to update that.

I would suggest that instead of using "doc_unused", use "doc_unimpl" which expands to


  doc_notimpl = "%s is not yet implemented for __objname__ objects.  \
__prop__ is unused.";


Rik <rik5>
Group administrator
Tue 05 Dec 2023 04:55:54 PM UTC, comment #5: 

ok. easy enough to update on a case by case basis then.  I was thinking adding a note to the top of the generated properties pages would be worthwhile, but I'm not as familiar with generating texi from the m file (linebreaks, escape characters, etc).  What would be the right way to format/break the long line in the sprintf here:



diff -r 189360f2a7e0 doc/interpreter/genpropdoc.m
--- a/doc/interpreter/genpropdoc.m        Mon Dec 04 22:04:52 2023 -0800
+++ b/doc/interpreter/genpropdoc.m        Tue Dec 05 11:48:20 2023 -0500
@@ -634,6 +634,9 @@
 \n\n__fcnmsg__";
         s.valid = valid_fcn;

+      case "windowstate"
+            s.doc = doc_unused;
+
       case "windowstyle"
         s.doc = "The window style of a figure.  One of the following values:\n\
 @table @code\n\
@@ -2250,7 +2253,7 @@
   elseif (is_prop_subset)
     ## Do nothing
   else
-    str = sprintf ("%s\n\nProperties of @code{%s} objects (@pxref{XREF%s,,%s}):",
+    str = sprintf ("%s\n\nProperties of @code{%s} objects (@pxref{XREF%s,,%s}).  Note that properties marked as unused are accepted and stored by Octave but have no effect on the object:",
                    str, objname, objname, objname);
   endif
   str = sprintf ("%s\n\n@table @asis", str);


Nicholas Jankowski <nrjank>
Group Member
Tue 05 Dec 2023 04:38:05 PM UTC, comment #4: 

I don't know how to find the ones that are just placeholders.  Even if you took the list of all properties and examined the output of


for p in $properties; do
  echo "PROPERTY: $p";
  hg locate '*.h' '*.cc' '*.m' | xargs grep -iw $p
done


it would be difficult to determine if a property was unimplemented for one type of graphics object but implemented for another for another (for example, if "color" was implemented for lines but not patches), or to determine if its implementation was incomplete.

John W. Eaton <jwe>
Group administrator
Tue 05 Dec 2023 04:34:39 PM UTC, comment #3: 

I was going to look at adding such a note, is it sufficient to add a case for windowstate with s.doc = doc_unused in genpropdoc.m, or should there be a more explicit description.  Are there any other properties we know we ignore that should get the same treatment?

Nicholas Jankowski <nrjank>
Group Member
Tue 05 Dec 2023 04:19:05 PM UTC, comment #2: 

okay, the behavior makes sense.  Perhaps we should get in the habit of marking such things as non-functional in the help documentation. Are there other properties we know operate the same way?

Nicholas Jankowski <nrjank>
Group Member
Tue 05 Dec 2023 03:43:15 PM UTC, comment #1: 

The windowstate property was added in this changeset http://hg.savannah.gnu.org/hgweb/octave/rev/cb9451780a15 to allow Octave to accept it instead of throwing an unrecognized property error but it doesn't seem that anything has been done to make it actually work.

Changing this to a feature request.

John W. Eaton <jwe>
Group administrator
Tue 05 Dec 2023 03:27:06 PM UTC, original submission:  

As reported over on discourse, attempting to use the 'WindowState' property for figures seems to have no effect, whether during creation or later using the set command.

Tested on Windows with Octave 8.4.0 and 9.0.1 (hg id: 14cb31ec0251), as well as on Ubuntu with 9.0.0 (hg id: 4f09c1b4148).

the following commands all produce a normally sized figure window:


figure (1, "windowstate", "maximized") %new named fig
figure ("windowstate", "maximized") %new fig unnamed
figure (1, "windowstate", "maximized") %new fig into existing fig


similarly:

a = figure;
set (a, "windowstate", "maximized")


fails to change the state of the window.  same behavior for "minimized", and "fullscreen".  Tested on single and multiple monitor setups in case the latter was causing the problem.

can anyone verify if this behavior is a regression or was it always nonfunctional parameter?

Nicholas Jankowski <nrjank>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by nrjank (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-05 rik5 Summarymake 'windowstate' property do what it is supposed to do 'windowstate' property is unimplemented
    2023-12-05 jwe Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        Item GroupIncorrect Result Feature Request
        Release9.0.90 dev
        SummaryFigure windows ignoring 'windowstate' property make 'windowstate' property do what it is supposed to do

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code