Opened 7 years ago

Last modified 7 years ago

#8735 assigned bug

Icon-O-Matic windows appearing entirely off-screen.

Reported by: jstressman Owned by: leavengood
Priority: normal Milestone: R1
Component: Applications/Icon-O-Matic Version: R1/Development
Keywords: Cc:
Blocked By: #9546 Blocking:
Has a Patch: yes Platform: All

Description

Since the icons in the Haiku source are not correctly associated with Icon-O-Matic when you check out the source, I was highlighting many of them and choosing Icon-O-Matic from the "Open with..." dialog so that I could then ALT-S, ALT-W to save and close each window, thus correctly associating the icons so that I could view them in Tracker and open them with a normal double click.

The problem arises when it opens those many windows. Each subsequent window opens slightly down and to the right of the previous one... but when you do this with many windows, they go right off the bottom right edge of the screen.

Luckily I was just saving and closing each window with the hotkeys anyway, but this isn't good behavior.

This might also be related to similar misbehaving in #8414 and #3505

This is with hrev44335 (gcc2h)

Attachments (2)

patch (957 bytes ) - added by humdinger 7 years ago.
Move window when it'd be outside the screen
patch.updated (5.4 KB ) - added by humdinger 7 years ago.
Doing it the StyledEdit way

Download all attachments as: .zip

Change History (11)

comment:1 by jscipione, 7 years ago

There is code in StyledEdit for positioning new document windows correctly based on the available screen area for anyone wishes to implement a fix for this bug (or #8414).

by humdinger, 7 years ago

Attachment: patch added

Move window when it'd be outside the screen

comment:2 by humdinger, 7 years ago

Has a Patch: set

comment:3 by humdinger, 7 years ago

Attached a patch that addresses the issue. Is it acceptable to hardcode those pixel values? It depends on the border width and window tab height... One could move it into the MainWindow() constructor and use DecoratorFrame(), but then IconEditApp's member fLastWindowFrame isn't kept uptodate.

comment:4 by humdinger, 7 years ago

Forget that first patch. I went with more or less 1:1 copying from StyledEdit. I changed that one too to use a variable for the window offset. I also adjusted the horizontal value so a window is now flush to the screen border. As long as the decorator doesn't change...
Should there be some BControlLook thingy or something to get dimensions of borders, window tabs etc.? I know BWindow has a DecoratorFrame() but that doesn't help here.

by humdinger, 7 years ago

Attachment: patch.updated added

Doing it the StyledEdit way

comment:5 by axeld, 7 years ago

I would prefer to put it into a new file into shared, and use that from both instead of duplicating the same code.

You could either create the window first, and then do the cascading with the window as argument (which could could use to retrieve the decorator frame), or pass in the last opened (or even current) window as a reference to compute the offset from.

comment:6 by mmadia, 7 years ago

Blocked By: 9546 added

comment:7 by mmadia, 7 years ago

To note, #9546 is for moving StyledEdit's cascade related code into src/kits/shared.

comment:8 by leavengood, 7 years ago

Owner: changed from stippi to leavengood
Status: newassigned

StyledEdit's code isn't perfect either, see #8556.

As per that ticket, I have a Ruby prototype for a "NewWindowPolicy" class which I will port to C++ and put in the the shared kit, then it could also be used for Icon-O-Matic, and other applications which need that behavior. Given this, I'll take over this ticket, and #9546.

comment:9 by axeld, 7 years ago

Thanks Ryan! Other candidates that come to mind are Mail, People, and DiskProbe. Maybe Web+, and MediaPlayer are using something similar, I don't know.

Note: See TracTickets for help on using tickets.