Opened 5 years ago

Last modified 3 years ago

#138 new defect

strange artifacts when using filename scroll buttons in load/save dialog

Reported by: HoraK-FDF@… Owned by: pulkomandy
Priority: minor Milestone: 2.9
Component: GrafX2 Version: 2.7
Keywords: Cc:

Description

Hi,

this happens for me only for existing files with new file names it has not happened but maybe it does also somehow. The arrows that appear at the start or end of the file name when its longer than the maximum width trigger that behavior and for the right it seem to do nothing (should it jump to the end?) while the left one jumps to the start of the file name. And when one of them is used and the cursor is moved right the strange artifacts are revealed like a scratch ticket. I could reproduce this on all three versions artifacts vary from file name to file name and sdl2 version looks a bit different then the other two but that means nothing I think. Tested with grafx2-2.7wip2785

Attachments (2)

gx2-filename-arrows-bug-001.png (491 bytes ) - added by HoraK-FDF@… 5 years ago.
gx2-filename-arrows-bug-002.png (512 bytes ) - added by HoraK-FDF@… 5 years ago.

Download all attachments as: .zip

Change History (13)

by HoraK-FDF@…, 5 years ago

by HoraK-FDF@…, 5 years ago

comment:1 by HoraK-FDF@…, 5 years ago

When clicking on another file its showed completely also a double click on the file name input line triggers that.

comment:2 by Thomas Bernard, 5 years ago

are you testing under windows ? the file names handling are specific under this system.
What is the file name you are trying with ?

comment:3 by HoraK-FDF@…, 5 years ago

yes windows it does not matter witch file name it must only be longer than the file input line so that the arrows at the edges appear. My file names contain "[A-Z][a-z][0-9]_"

comment:4 by Thomas Bernard, 5 years ago

I have no access for the moment to a window machine, but I don't reproduce it under FreeBSD :(
I noticed that clicking inside the filename input widget when it is active doesn't always move the cursor as intended. I think it computes the new position without taking the scroll into account.

Does the scroll using the arrow keys works as intended for you ?

comment:5 by HoraK-FDF@…, 5 years ago

yes the physical keys work like a charm

"I think it computes the new position without taking the scroll into account."

yes that true here on windows also

I will try a linux machine and look if I could reproduce it there.

comment:6 by HoraK-FDF@…, 5 years ago

I've just noticed another thing maybe its a new ticket:

  1. select a file
  2. click on the file-name input box
  3. 1st ESC breaks out of file-name input box
  4. 2nd ESC breaks out of load save menu but the entire GUI then flashes in the last four colors (when 2. was not made it leaves normal)

comment:7 by HoraK-FDF@…, 5 years ago

I've tested it on linux(Raspbian) the bug is also present but its somehow a bit different here the bug happens already by only clicking on the file input box and move the cursor right but the artifacts are only displayed till the outer border of the load save dialog.

comment:8 by Thomas Bernard, 5 years ago

just one question : what is your pixel size (in Picture & Screen size dialog)
and menu ratio adapt (from settings) ?

comment:9 by HoraK-FDF@…, 5 years ago

pixel size: normal 1x1
menu ratio adapt: x4

comment:10 by PulkoMandy, 4 years ago

Milestone: 2.8

comment:11 by PulkoMandy, 3 years ago

Milestone: 2.82.9
Note: See TracTickets for help on using tickets.