bugGNU Octave - Bugs: bug #55240, Teminal background color now only...

 
 

bug #55240: Teminal background color now only applies to text, not entire terminal area

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Tue 18 Dec 2018 09:57:58 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 02 Jan 2021 11:18:04 PM UTC, comment #18: 

These days this problem has been cured somehow for 6.1.0 and 7.0.0. I can't point to a specific relese or cset, but I don't see this bug anymore.

Closing report.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 15 Jan 2019 07:41:40 PM UTC, comment #17: 

No hurry, Torsten, thanks for your prolonged attention for this bug.

Which Windows version runs in your VM? as Win10 seemingly isn't as clearly affected as Win7.

I must say that it is only on my laptop that I could clearly pinpoint the cset where the change occurred.
On my desktop several "local" branches (locally applied trial patches) and two mxe-octave build trees just made for confusion.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 15 Jan 2019 07:10:41 PM UTC, comment #16: 

Philip, thanks for testing and sorry for the late reply, but I tried to do some mxe builds for my Windows VM box but ran into problems (as always).

The original place for restoring hunk #5 in main-window.cc is well before creating and initializing the console widget and the underlying terminal. Therefore, I really don't see a reason why adding this hunk together with having "windows" as selected style in the preferences file results in different behavior compared to the state before my changeset.

I hope to get my mxe environment back to normal soon, so I can make some tests by myself.

Torsten Lilge <ttl>
Group Member
Sun 13 Jan 2019 04:22:17 PM UTC, comment #15: 

Adding back the hunk does not help.
Backing out set 2355f66cf91d does work. But then I can't upgrade to tip as the *.ts files have merge conflicts (obviously).

I was wondering if that restored hunk is called at the right time? Is it really needed?

On Windows 10 the terminal background seems solidly colored but it does portray what I described in comment #2 and comment #5. So the bug is more conspicuous in Windows 7.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 12 Jan 2019 10:19:59 PM UTC, comment #14: 

Styles make no difference.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 12 Jan 2019 10:12:19 PM UTC, comment #13: 

Tonight I added hunk #5 of main-window.cc back in and (cross)-built again.
Unfortunately I see no difference.

That said I have several mxe-octave build trees and the one where I found the difference (on a relatively slow laptop) was not the one I just tried with (on a relatively fast desktop).

What I can do is simply (1) also try on my laptop and (2) locally backout 2355f66cf91d completely and see what happens. That will take a bit of time. Hopefully this weekend I can report back.

Oh and I can try the various styles again.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 12 Jan 2019 08:33:33 AM UTC, comment #12: 

I fully agree to not backout the cset.

Hunk #5 in main-window.cc is what came into my mind, too. That's why I was asking whether you have restarted octave with the different styles. But I now see, that hunk #5 is at a very early stage of start up and the selected style from the settings is still not active there.

Could you please add the removed code sequence for your next window build and retry?

Torsten Lilge <ttl>
Group Member
Fri 11 Jan 2019 10:41:23 PM UTC, comment #11: 

Torsten, it turned out to be the cset by you of Dec 13:
2355f66cf91d allow to select the gui style in the preferences dialog.

I'd suggest to NOT backout that cset, just leave there and let's see what can be done about the issue at hand.

(I know next to nothing about Qt so the following is flagrant guesswork:)
Maybe hunk #5 in main-window.cc ? I see no replacement for that code.
Maybe somehow the style "Windows" isn't picked up or inintialized properly? As I wrote in comment #2 and comment #10 I didn't see much difference between the four styles.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 10 Jan 2019 11:00:21 PM UTC, comment #10: 

Makes no difference. I think I went through all the styles in comment #2.

What may have happened is an upgrade in mxe-octave to Qt5.12 (22937c7fe60d Update QT5 5.12.0 …).
However on my laptop I haven't upgraded up to that cset so that shouldn't affect things as both builds (13 dec w/o & 14 dec with issue) are from my laptop.
Puzzling...

Philip Nienhuis <philipnienhuis>
Group Member
Thu 10 Jan 2019 09:06:02 PM UTC, comment #9: 

If 3a90eff58fb5 "editor encodings ..."  is still okay, then the next cset that might have caused the issue is the one that provides changing gui styles ...

What happens if you choose "windows", and then restart, i.e. making sure that "windows" style is active during start up?

Torsten Lilge <ttl>
Group Member
Thu 10 Jan 2019 08:45:51 PM UTC, comment #8: 

The change occurred between
3a90eff58fb5 "editor encodings ..."
-and-
34cc6edf2041 "sqp.m: Eliminate ..."
(so Panxto's cset is off the hook :-) it happened later than that)

But I think I'll check the mxe-octave log as well.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 06 Jan 2019 10:44:06 PM UTC, comment #7: 

Looking at my hg logs, and considering the behavior I described in comment #2, it might be this one by Panxto:
http://hg.savannah.gnu.org/hgweb/octave/rev/76ac35f71573

... but I'd have to update to the revision before and after, build / make dist & cross-build both revisions, to find out. Only later this week I'll have time for that.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 06 Jan 2019 10:34:24 PM UTC, comment #6: 

(FYI yellow (very light) is the background color I have for the terminal window)

Philip Nienhuis <philipnienhuis>
Group Member
Sun 06 Jan 2019 10:33:13 PM UTC, comment #5: 

"weeks (weeks)" was a bit pessimistic.
AFAICS the change occurred around Dec 13; a binary from Dec 14 does show the bug, one from Dec 13 does not.

Another thing I see is that after entering "clc", the screen is solid yellow. Yet increasing the screen size shows what I described in comment #2 (white borders disappearing as soon as the border equals a char column size or height).
On my laptop I had the "clc" command in .octaverc, so that's why it behaved a bit differently than on my desktop.

Does this help?

Philip Nienhuis <philipnienhuis>
Group Member
Sun 06 Jan 2019 09:08:05 PM UTC, comment #4: 

Thanks for picking up again.

E.g. green background of default text gives me a solid green background in the editor, so there it works (no bug there).
I think it's a problem specifically with the (cmd.exe?) based terminal on Windows.

As I have loads of binary installers archived (2 or more each week), I'll see if I have some time the next week (weeks) to bisect and find out when it happened. As my Xmas holiday is over now this might go slow.
The change occurred after Nov 7 (I still had one oldie installed from that date that doesn't show this bug).

Philip Nienhuis <philipnienhuis>
Group Member
Sun 06 Jan 2019 08:08:49 PM UTC, comment #3: 

Unfortunately, except for the new style on windows, I can not find a changeset that directly affects the console widget. Could you please test if a colored background in the editor shows the same effect?

Torsten Lilge <ttl>
Group Member
Wed 19 Dec 2018 10:57:30 AM UTC, comment #2: 

Makes no difference. I tried all styles.
(I can say I like "Fusion" ... :-) )

On my laptop it is a bit different. There the background area is continuously lightish yellow (the color I've set) but the right and bottom borders remain white unless the border exactly coincides with the border between character columns or vertical line "borders".
IOW, if I slowly drag the lower right corner to resize the terminal to make it bigger, these white areas grow slowly until they disappear suddenly whenever a complete new column of characters is in the terminal area or a complete new line's height is included.

Hard to tell whether it's graphics HW dependent (my desktop is NVidia, my laptop Intel), on my laptop an desktop I may have slightly different mxe-octave build trees.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 19 Dec 2018 05:58:24 AM UTC, comment #1: 

Philip, could you please test again after having switched the style back to "windwos" (preferences, tab "Gerenal")?

Torsten Lilge <ttl>
Group Member
Tue 18 Dec 2018 09:57:58 PM UTC, original submission:  

I think two screenshots can save many words:

Terminal_background1.png = a cross-build from November, still OK

Terminal_background2.png = a cross-build from yesterday (fully up-to-date, af99ea9c325)

To me it looks like a regression albeit a cosmetic one.
This has started I think less than a week ago.

Philip Nienhuis <philipnienhuis>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-02 philipnienhuis StatusNone Fixed
        Open/ClosedOpen Closed
    2018-12-18 philipnienhuis Attached File- Added Terminal_background1.PNG, #45692
        Attached File- Added Terminal_background2.PNG, #45693

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code