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