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

[jstressman]

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)

[jscipione]

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).

[humdinger]

Move window when it'd be outside the screen

[humdinger]

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.

[humdinger]

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.

[humdinger]

Doing it the StyledEdit way

[axeld]

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.

[mmadia]

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

[leavengood]

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.

[axeld]

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.

[alwayslivid]

Hi, after reading this bug report, I tried to think out of the box and begun experimenting with a concept of using stacked windows for new instances of Icon-O-Matic, instead of opening new windows, of my own accord. I thought that imitating the feature that some other document editors that specifically exist for Haiku (like Koder) is also a valid fix that also extends the overall user experience by introducing a "single workspace", like in professional image manipulation programs.

This definitely isn't a one-size-fits-all solution (IIRC, stacked windows were attempted in WebPositive and were not included, and I don't think this would make sense at all in some the other applications mentioned in this thread), but it seems interesting (as in "usable") and also "enforces organization" onto the user. And the best thing about this is that this bug ceases to exist.

(Keep in mind that these screenshots are not representative of a final, polished product and if I were to be given the go to implement this, there are problems such as an easier-to-resolve graphical bug as a result of opening too many windows, the window titles and being able to use multiple "workspaces" if the user wants to.)

[bitigchi]

Nice feature, but hardly looks like a fix. If anything, opening new windows stacked should be an optional feature, not default behaviour. Stacks are a nice way of organising windows in accordance with the user's will. It's a bit bold to assume on the software's part that the user automatically desires to tab two documents instead of observing/working on them side by side. Default behaviour should always assume new/existing documents should appear in a new window at an appropriate coordinate (like how Tracker does) or at their last closed position (if existing document).

[alwayslivid]

Thanks for the feedback. Just for future reference before I take a look at hopefully fixing the bug all over again, mind if I ask (in case anyone knows) why other document editors opt to use stacked windows and what the philosophy behind that decision tends to be?

[bitigchi]

I don't think there is a philosophy per se, probably because it's common to open many files at once during coding (and the stacking API allows it). Personally I find it more comfortable to be able to glance at many files as much as I can during coding, instead of having to click tabs forth and back and trying to remember what the code was in the previous window.

[diver]

Do you mean Koder?

[pulkomandy]

It is easy to detach tabs after they are created, I think that is simpler and better than making it optional.

In the case of Icon-O-Matic, I like the idea that the window are stacked by default, because it also allows to rapidly switch between the two windows and visually compare two icons and see if everything lines up.

For the more "philosophy" thing, it really depends on what you're doing. Usually text editors in big IDEs will allow you to have both tabs and a split-screen so you can fit 2 or 3 documents side by side. Both are useful, and screen splitting can only get you so far (after 2 or 3 documents, or maybe 4 to 6 if you have a large screen and small font), you need another way to manage your work. But really it's a case by case thing, and different applications will need different ways to do things. And possibly even the same application in different contexts, which is why Stack&Tile is a nice way to handle this: it can be easily modified by the user to fit whatever they are doing.

[alwayslivid]

Two clarifications about the thing I worked on:

a) Keep in mind that the thing that I coded shows a completely different view, as in, if you have zoomed in on the first window and not on the second window, the tiles will not be tiled up together. I think that it may be a good idea to keep it that way -- if somebody needs to copy something from another icon or use it as a base, I'd presume that they'd open the icon itself in the first place.

b) When I said "optional", I meant introducing something like a "Ctrl + Shift + N" keyboard shortcut that opens a window in a detached manner to begin with. Just some productivity stuff. Maybe that could come afterwards.

[bitigchi]

I still don't think doing this by default is a good idea.

1. What happens a detached and closed window reopens? Will it be stacked by default or open at the location/workspace that it was saved and closed at? Lots of corner cases when the workspaces come into play.
2. What about different window sizes? Haiku's current stack implementation does not care about individual window sizes, and messes everything up by using the first window's size. Try stacking DeskCalc with WebPositive.
3. Why force the user an extra step of detaching the window and probably having to resize it?
4. What if user doesn't want his view obstructed with the new tab?
5. Will there be a need to add an option like "Open in Background Tab"
6. Other unimplemented applications will stick out or vice versa. But having the stacking up to the user automatically gives a unified behaviour.

Probably there are more issues, but these first come to mind. Haiku's Stack is an excellent feature but it should be explicitly left to user's decision, otherwise it looks like it's deciding on user's behalf. Just my two cents.

[pulkomandy]

What happens a detached and closed window reopens? Try stacking DeskCalc with WebPositive.

We are talking about stacking Icon-O-Matic windows together when you use the "New" menu in Icon-O-Matic here. We are not considering any other case, where, of course, windows will still open as they do now.

As I said in my previous comment it should be done on a case by cases basis where it makes sense. Here, it makes sense.

Why force the user an extra step of detaching the window and probably having to resize it?

Why force the user to attach tabs manually in cases where it obviously makes sense to do it automatically?

Resizing is independant, Icon-O-Matic windows all start with the same size anyway.

What if user doesn't want his view obstructed with the new tab?

This happens wether the new window is stacked or not (the current behavior is to open the new window on front of the previous one, just offset by a few pixels)

Will there be a need to add an option like "Open in Background Tab"

No.

Other unimplemented applications will stick out or vice versa. But having the stacking up to the user automatically gives a unified behaviour.

Having some applications do it automatically make the feature more discoverable. It is there for applications to use and I trust application developers to make wise choices about when to use it or not, just as they do for every other degree of freedom we give to them.

[alwayslivid]

On 2. What about different window sizes? Haiku's current stack implementation does not care about individual window sizes, and messes everything up by using the first window's size. Try stacking DeskCalc with WebPositive.

A single workspace has a specific size. If the user doesn't want that, they can just break a specific window (or windows) into a new workspace. The UI sort of "predetermines" the size by having a very big size by default. In my concept, which I have already programmed, changing the size of a second or a third window also changes the size of the first window. This starts being a problem if the user spawns hundreds of windows, but I am planning to address that. It makes sense for me not to have the window size altered when changing tabs, as the user cannot possibly remember the size of the tab that they are currently opening, which causes the same exact confusion as the one you brought up in the DeskCalc/WebPositive example (I am ignoring the case of the altered UI elements here, as this does not apply).

What if user doesn't want his view obstructed with the new tab?

Will there be a need to add an option like "Open in Background Tab"

Your scenario is that the user who wants to open a file does not care about a file. With windows, they'd have the window overlap the window you care about. We could do that way easier with stacked windows, although I don't see the need for it.

otherwise it looks like it's deciding on user's behalf

Why force the user an extra step of detaching the window and probably having to resize it?

It's a UX decision -- we decide for the user by definition. Why are you making the assumption that the user would want to detach it? I don't attach many tabs that should probably be attached because I am way too bored to do so.

Other unimplemented applications will stick out or vice versa. But having the stacking up to the user automatically gives a unified behaviour.

I am trying to figure out a way to address this, so that this will not be a problem.

[alwayslivid]

Excerpt of what leavengood said on this forum thread (​https://discuss.haiku-os.org/t/icon-o-matic-stacking-window-concept/11661/10):

As the person who has held that bug for almost 10 years and have not yet followed up on it, I think this looks neat, certainly for Icon-O-Matic. We still might want to solve this problem in a general way using cascading windows for other apps, but that can maybe be something I finally pick up again.

Is a new API method that detects whether a BWindow is present within the coordinates of the screen desirable? This goes beyond my solution for Icon-O-Matic, but I just wanted to open up this side-subject on the side.

P.S. Should I proceed with developing this Icon-O-Matic concept further?

[pulkomandy]

Is a new API method that detects whether a BWindow is present within the coordinates of the screen desirable? This goes beyond my solution for Icon-O-Matic, but I just wanted to open up this side-subject on the side.

There is already a BWindow::MoveOnScreen: ​https://git.haiku-os.org/haiku/tree/headers/os/interface/Window.h#n179

We could just add that to all apps that have problems with their windows ending up offscreen.

P.S. Should I proceed with developing this Icon-O-Matic concept further?

Yes.

[alwayslivid]

Yes.

Submitted for review after testing and realizing that some of the features that I was trying to implement were already implemented: ​https://review.haiku-os.org/c/haiku/+/4776