Opened 9 years ago

Closed 9 years ago

#6935 closed bug (fixed)

Font glitches in Tracker after window management combo

Reported by: humdinger Owned by: czeidler
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/Development
Keywords: Cc: superstippi@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by bonefish)

This is 39660.

I think this only appeared after Ingo's resizing work with hrev39656. Do this:

  • Open a Tracker window, for example ~/
  • Press the window management combo CTRL+ALT and release it
  • Select a file

See this bolding and a funny character:

first combo, then click on file

Or do this:

  • Open a Tracker window, for example ~/
  • Select a file
  • Press the window management combo CTRL+ALT and release it
  • Click in some blank, white area of the window

Now the whole line is bolded:

select a file first, the key combo

Waving a window in front of it redraws the glitch correctly.

Attachments (2)

combo+click.png (44.1 KB ) - added by humdinger 9 years ago.
first combo, then click on file
select+combo.png (44.0 KB ) - added by humdinger 9 years ago.
select a file first, the key combo

Download all attachments as: .zip

Change History (8)

by humdinger, 9 years ago

Attachment: combo+click.png added

first combo, then click on file

by humdinger, 9 years ago

Attachment: select+combo.png added

select a file first, the key combo

comment:1 by bonefish, 9 years ago

Description: modified (diff)

Since I'm not going to work on any of those weirdo side effects of my changes -- and if no one else intend to -- I'll just revert them for the time being.

comment:2 by axeld, 9 years ago

Cc: superstippi@… added
Component: Applications/TrackerServers/app_server

IIRC every window has a drawing state, and you obviously mess with it when drawing the decorators. Maybe it's also just the drawing state of the painter. CC'd stippi as he can likely give a better answer to that.

In any case, it's not a weirdo side effect :-)

comment:3 by anevilyak, 9 years ago

Could it also potentially lie in faulty assumptions when computing the dirty region? Normally resize actions to date have resulted in a modification of the right/lower window bounds, while with something like this the region being modified could be on any side. Is that perhaps not being taken into account properly?

in reply to:  2 comment:4 by bonefish, 9 years ago

Replying to axeld:

IIRC every window has a drawing state, and you obviously mess with it when drawing the decorators. Maybe it's also just the drawing state of the painter. CC'd stippi as he can likely give a better answer to that.

The only thing I have changed in the decorator code is the colors it uses. I haven't touched the drawing code in any other way. The only other change somewhat related to drawing is that the border regions are now invalidated a bit more often. The code doing that is basically only copied from pre-existing code.

In any case, it's not a weirdo side effect :-)

Well, you haven't convinced me. :-)

comment:5 by czeidler, 9 years ago

Owner: changed from axeld to czeidler
Status: newassigned

comment:6 by czeidler, 9 years ago

Resolution: fixed
Status: assignedclosed

Hopefully fixed without further regressions in hrev39707.

Note: See TracTickets for help on using tickets.