Icon-O-Matic Stacking Window Concept

Somewhat related: I do like the idea of using stacking for this, it however makes the popped out color picker even worse in my opinion, i get very easily confused by modal windows for such tiny tasks, for example Koder has a single global find window for all my open documents, as a result this window is hard to find, hard to use and even worse overlapps my documents and battles them for focus.

Maybe a nicer in-view UI solution can be found for the color picker after the tabbed change is merged :slight_smile:

There’s a problem with the numbers: I tried this, and it’s very hard to keep track of those because Icon-O-Matic, internally, counts how many windows of Icon-O-Matic exist. Not how many windows are stacked.

The edge cases that would have to be considered would be:

  • Pulling out Icon-O-Matic 2 could mean that everything else would have to be renumbered.
  • If I measure the amount of windows, then other, non-Icon-O-Matic windows would also be counted in.
  • I can completely reorder the stacked windows in an order that does not make much sense.

I can also completely ignore all of that. If the user wants to pull out a specific window out of the stack, we could also just keep the number as-is.

In my concept, the color picker window automatically hides if a window that doesn’t have the color picker gets opened. If another window with the color picker open gets opened, the color picker of that said window replaces the color picker of the previous window. Nothing really changes. I am glad that me trying to innovate has opened up several conversations about the Haiku API and the overall look-and-feel of Icon-O-Matic (your feature should not be absolutely disastrously difficult to implement), but that will definitely have to come after the initial window stacking functionality gets implemented, 'cause priorities.

1 Like

ah sorry, the numbering is not the important point.
It is the up-stacked line the second line on top if the first row is full…

EDIT: and yes file names or tab names would be much better and more variable.

Oh, I got a bit confused because I am really not sure how I should differentiate between lots of Icon-O-Matic windows. I thought of numbers, but file names could work too. Really unsure about this, and that’s the only thing (apart from some minor bugs) preventing me from just pushing the code that I wrote straight up for review.

Just copy whatever StyledEdit does I’d say, it deals with exactly the same problem

1 Like

Maybe yeah. I really do not think that the limit should be dictated by an app, but by the system. Bringing up tons of tabs is also already possible through the user interface. (Sidenote: Getting a keyboard shortcut does make breaking stuff way easier, though. Resizing windows like this is fun!)

Cool, so we’ve basically already established that I’m close to being done. :D

I won’t take a look at this now, but I should have some extra time next week. If this takes much more time than expected, I’ll just push it straight up to Gerrit for preservation and a preliminary review.

One thing I determined long ago is most of our apps do need something extra (like a special C++ class) for window management to implement some of these more advanced features. As I recall the BApplication and BWindow API doesn’t quite have enough info to do it well. StyledEdit has some of this code, but not all. I coded up a prototype in Ruby 10 years ago which I probably still have somewhere but not on this current machine. All this discussion is making me want to step back up to help on this again and maybe I will.

Though I do believe some of the StyledEdit bugs were fixed by someone else and I helped review the Gerrit at least.

Keep in mind real use cases. In real use cases, your icons will have names. And this is what will be used to distinguish different windows.

I don’t think there would be a case where people just randomly open 10 blank icon o matic windows and need to switch between them.

No, that would be a bad idea. If I remember that window 5 has something in it, I don’t want it to suddenly become window 4.

BWindow now has a MoveOnScreen function which could easily be added to Icon-O-Matic to solve the problem of windows going completely offscreen, at least.

That was for assigning names to the windows, and I think it is still not working perfectly, but really the extra complexity of doing exactly the “right thing” (keeping track of which window numbers are used or not) is a bit pointless.

1 Like

Yes maybe so, which is why I thought accepting the “good enough” fix made sense. If I find time to mess with this, maybe I will, but there are plenty of better things to do.