I got the interesting idea of trying to “resolve” this by creating a new stacked window everytime the “New” button is clicked instead. I asked whether that’d be a reasonably good way to solve this, and as I never got a response for that in the IRC, I decided to move through with it anyways, construct an actual proof of concept and show it off. Mostly to satisfy my own curiosity.
You can generate a new stacked window by clicking on the New button/using the keyboard shortcut that is already there. Each window has the same exact layout, things like the color picker “stay” on the window that you opened it on and hide if you open a different one, and, of course, you can draw different things/zoom in and zoom out, and this will not affect what’s happening in the other windows. Un-stacking windows is also do-able, of course. (Keep in mind that I deliberately chose not to draw anything on the screen or use a rational resolution for the windows, in order to keep the focus on whether this is actually a good idea and not just show off eye-candy.)
I have yet to figure out details, such as what will be done with the titles of the stacked windows. What started as an interesting alternative solution to calculating the correct coordinates for new windows eventually turned into an interesting concept that takes advantage of a powerful (and surprisingly undocumented!) feature of the system, like some of the document editors that are currently available for Haiku do.
Keep in mind that the screenshots are an early work-in-progress and mostly an experiment that seemed neat enough to the point where I am wondering if I should polish this and submit this for review. I am not sure if I am going to carry on with this. Now that the initial concept is here, I am absolutely open to feedback, as long as it’s within the scope of what I am trying to achieve here.
First off, I realize that this likely came off much more passive aggressive than I intended it to in retrospect, especially because of the fact that I said that as an opening sentence. Sorry about that.
I’ll ask about it there, although I want to reiterate that this was more of an experiment that I carried out on my own accord to learn the Haiku API better in a creative way, building a new feature and less about bug fixing. I mostly shared this because of the “wow, I didn’t expect this to work so nicely” thought that I had in the back of my head and wanted to share this with people. I am fully aware that this is not automatically a better idea just because I built it.
Also posted about this on the bug report. It’s good being able to propose a solution while being sure that I am capable of resolving it, instead of overpromising and underdelivering.
It’s not a problem of passive agressive. What’s a bit puzzling is the behavior of “hey, so here is a tool to track issues and discuss solutions, and I just decided to ignore it, twice in a row, by instead using an IRC channel then a forum”.
There is a bug report and you are fixing it. Why pretend you aren’t?
The UI design is part of the solution too. Just commenting “I think this can be solved by stacking IoM windows together, which will result in the views being automatically aligned” is great progress on this bugreport. There are people who don’t write any code and just do mockups and post them on the bugtracker.
In the Haiku team there are also people who say “I will work on this” on a ticket and then go missing for 10 years. No problem with that.
Is our bugtracker too intimidating? Honestly I think it should be a “safer” place for these things. Now you have announced your work to everyone in the haiku community, including users and people who just happen to watch our forum, instead of just the developer team. If you didn’t want to “overpromise”, then you failed at that…
I like the idea to stack the windows on the top of the desktop.
I always arrange my windows like this manually.
If the windows could save their possitions it would be fine.
To remember the tabs possition would be even better. Which don’t work yet.
Well, it’s certainly a roundabout way of fixing it and goes beyond the original task, and if I were to proceed with what I talked about initially, I’d probably have to make it optional eventually. Which still leaves out the problem of making sure that new windows stay on the screen, as well as additional problems, such as “how do I limit the amount of windows in a single workspace?”. As @bitigchi also said in the bug report, I also do see this more as a new feature than a bug fix, in the same kind of way you could remove the entire application off the system and not have any of the problems associated with it anymore.
I can see how trying to break through barriers and do anything revolving a single issue, even if it’s only tangential, is relevant and actually useful now.
No, I do not honestly believe it is. Maybe explaining the way I work may clarify as to why I sometimes do some things in an idiosyncratic way: I like experimenting with different ideas in creative ways, but I definitely did not have a good picture of what is the general stance towards stacked windows by community members. Me going through the effort of figuring out whether something is wanted or not, particularly through conversations, in order to validate my own intuition as I’m progressively working on it for the good of the project, as I believe that software should be user-oriented. I’m trying to learn, not impress. Judging by the result, I form a general picture as to how much I should pursue a said change, even if it’s a minor one. (For instance, after analyzing tons of YouTube videos and testing the programs myself, I worked on improving the UX of FirstBootPrompt and changed the order of the “Restart” and the “Shutdown” buttons.)
What I’m trying to say is “Hey, I did this, will this help you and should I get it included”, rather than “NEW FEATURE EVERYONE! WOOT WOOT, MAINTAINERS APPROVE THIS PLS NOW” champagne popping noises
Why? Once the window is created you can easily detach and move it if needed.
With UI bugs the fix is often something like this: change the way the UI works a little, and suddenly the initial problem simply cannot happen anymore.
The help you need is from developers to review the code, and the best way to reach them is on the bugtracker, especially when you are working to fix a specific bug.
I hope we don’t need to delve into hours of discussion for every change you make
So, here is how I think the process should work:
You look at the bug
You think of a way to fix it
You ask on the bugtracker “could we just use stack&tile and stack the new windows with the current one?”
Someone says “yes, seems like it would work”
You reply “ok, I’ll try to come up with a patch”
Patch gets submitted, reviewed and merged
Seems simple and efficient. There is no need to move the discussion to IRC and then to the forum.
To be honest, I just had a wildly different impression of what I was doing here from the perspective of “whether this solves a problem”. So, developers first, users second, try to figure out an alternative if this happens to be unpopular with the users. Makes sense, thanks for taking the time to explain this like I’m five.
I hope we don’t need to delve into hours of discussion for every change you make
Yeah, I think both of us had enough for the year. (Sorry!)
Why? Once the window is created you can easily detach and move it if needed.
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.
Some problems I can see with the stacking approach is what to do when many, many windows are open, which is what jstressman was doing to open the original bug. This is a general problem with stacking though, and also is an issue with most tabbed interfaces and it is solved there in various ways (make the tabs really small, add left/right scrolling buttons and maybe a dropdown menu, etc.) Though this is a bigger issue with stacked windows and does not need to be solved for this issue in particular.
I do not think that this could work with other apps as well, but thank you for your nice words and the constructive input. I’ll circle back to this in the bug report.
Some problems I can see with the stacking approach is what to do when many, many windows are open, which is what jstressman was doing to open the original bug.
I brought this up in the bug report. I was thinking of calculating a max amount of windows by opening up a lot of them in a reasonably low DPI-kind of setting, setting an upper limit, and then alerting the user if they are really sure that they want to carry on with creating new windows, as this could cause issues with their work. You could technically achieve the same effect by hand as well, as far as I know, so a more general solution here would be needed, as you also said.
Maybe I could check what could be done about this after we get done with the Icon-O-Matic bug. Is there a bug report for the problem you just mentioned?
Honestly, I think that this should be left up to the user. “As far as the system can handle the windows for and as far as the user can handle the lack of organization” for. But creating a lot of tabs and then suddenly creating a new window without any sort of warning would probably not be a good idea.
In general usage people will probably not open many Icon-O-Matic windows. But unfortunately if the user double-clicks a large number of icons selected in Tracker it will open many windows, so the code should deal with it in some way. I say this in particular for this issue since that is exactly what caused the bug report.
I actually think it might be fine to do both stacking and then cascading, with a maximum number of windows stacked per group (which AwaysLivid could find with testing.) The cascading can be the usual shift of 20 pixels x and y or whatever we tend to use. This code should also ensure that the windows don’t go offscreen when cascading (the bug in question.) Maybe once the cascaded windows touch the bottom right of the screen they just keep opening there in that position (stacks on stacks.) Of course if there are 10 stacked per group this would have to be 100s of windows so is probably unlikely.
With all that said this complicates this bug fix but the resulting code could then be extracted for general usage as we discussed so long ago. I also don’t know how capable the stack and tile API is to make this happen.
To avoid this becoming a rabbit hole I don’t know if the cascading has to happen right now but maybe once the “max stacked windows” is reached it can just start opening more windows on top in the same position. Not ideal but maybe better than before where they end up offscreen. Long term the stacking plus cascading could be added.
One more point on the maximum windows per stack: we can probably find a good heuristic which takes into account the size of the stacked window group to find the maximum number of tabs. Maybe we say the minimum tab size is 100 pixels (I’m not sure if that is enough, but it gives a number for the example), then if the window is 1000 pixels wide the max stacked windows is 10, since 10x100 = 1000.
Long term for sure, I agree. If AlwaysLivid feels so inclined to work on that in relation to this bug, he could, but I don’t think it should be a requirement to trying Stacking for this bug.
One thing I think that sometimes slows things down for Haiku is letting the perfect be the enemy of the good. I know maybe that is part of why Haiku is pretty high quality and consistent but there are times where valid bug fixes get stymied and slowed down due to issues like this. I know it has happened to me and that can be demotivating.
