I really didn't see the point in having separate floating windows since we don't even use the Directories window anymore after having loaded results. It's just a waste of space and it's confusing.

If for whatever reason you'd like to merge the non-squashed commits let me know. The messy commit tree is kept there just in case for now: https://github.com/glubsy/dupeguru/commits/tab_window_dev

I could see some users preferring the existing separate windows, so would kinda like to have an option to use either I think. The tabs being on the same level of the menu might be a bit confusing at first. Again going to have to mess around a bit more with this to form a more complete opinion. There is a conflict now here due to the recent merges.

I fail to see how useful it would be to keep the separate windows. Once the directories have been selected for scanning and the scan results have been delivered, the Directories window is totally useless since the focus is solely on the Results window. I fail to see how users would want to keep a superfluous floating window behind the Results window at all times. Maybe I'm missing the bigger picture here?

I'm curious to know how different it might look on MacOS however. I couldn't manage to get a MacOS VM running for testing, but hopefully it doesn't conflict too much with their styles.

I can try to make an option to use either solution, but it might end up adding some needless complexity to the code, since we'll have to account for both cases.

I'd prefer to have the tabs on the same level as the menu in order to avoid using space from the Result window. The default tabs position tends to clutter things a bit too much.

I was expecting those conflicts, should be easy fix. There should be some more conflicts if you merge #683 but I'll take care of them.

Only reason for still having the directories view is if you wanted to modify some of the settings there to do another scan based on what you saw in results. I have done that before, having to tab back/forth is a bit more work but not a deal breaker in any way. If it seems like it would be too much added complexity to have both we can move to the tab view only.

With regards to the tabs at the same level of the menu, I am just not sure how obvious it might be initially to a user mainly, I think once a user gets used to it then there is no issue. I can't say that I have seen an example of this layout in other software so mainly just from an intuitive perspective was slightly concerned. Not something at this point I am going to say we have to change unless there is feedback otherwise.

I should probably test this in OSX to see how these changes behave there with the Qt version.

Part of me wonders if there is any reason to let the user remove the tabs. It seems to me it makes things simpler if the three tabs are just there all the time. Let me know if you see a reason why not to do this but I cannot think of a downside to just having them there always.

There's always the View menu which lists the currently active windows/tabs. I like being able to hide the tab bar to save space, especially if it is located at the default position. We need to maximize the available space since dock widgets can take a portion of that space too. It's all optional anyway so it should be fine.

I'd rather keep the tabs dynamic and not static, since we might add extra tabs later. For example, I hope to finish working on an extra one for user defined filters for files and directories (provided I get around to finishing the GUI part which is a bit tricky for me).

Leaving tabs dynamic is fine. Found some issues with the tabs / view menu:

• View menu for the ignore list is not available when the results tab is selected (if you show ignore, then results, then you can't click view ignore again unless you toggle to directories first then it works once again).
• Using the view menu to get to the results list always moves the tab order if it was originally listed before the ignore list, using the view menu to show the ignore list does not appear to change the tab order.
• With the option to hide the tab bar completely, there is no way to get back to the directories tab

I think the following would make some of the UI a bit more intuitive:

• For the view menu, it seem options to toggle to the Directories and Ignore List tabs should always be available and active, and the Results tab item active if there are results. Seems like these three items should be in the same section of the view menu.
• For the file menu, it would be nice to just leave the Load and Save actions active regardless of which tab was selected, and only disable the save options if there are no results.
• For the Mark, Actions, Columns menu items I am ok with how they are as it is clearer when those are/are not available. Personally I would rather only see those options when available, however the way it seems fine as well.
• The "Use default position for tab bar" option should default to true, as it is the more obvious version, users wishing to save space can choose to use the menu bar position or disable showing it entirely.

Thanks for reporting these issues.

• The tab order will be changed when recreating the Results list, I don't think there is a way around this currently. The tabs don't have a fixed index. edit: this was a bug and should be fixed now
• I have to admit the way the menus are enabled / disabled is a bit wonky but it's the best I could do so far in order to keep the old "separate floating windows" logic mostly intact.
  Might have to check back on this later but it is a bit finicky to depopulate / repopulate menus considering the items are scattered around across different windows/widgets/tabs.
  I also suspect that removing and adding back menu items might confuse the user, so graying things out seemed like the best compromise.

• View menu seems to behave better, I did not get into a case were it prevented me from moving to an existing tab.
• The graying out of the Mark, Actions, Columns is alright, especially if the alternative adds more complexity.
• Seems like the "Show tab bar" option on view should be remembered on launch.

I think the way this is now, could be considered good to go, I do want to see the impact on OSX.

I don't think the "show tab bar" option should be remembered. If anything it will confuse some users. Plus it's easily accessible from the menu anyway, so it's not too difficult to find and use.

Seems to work fine on MacOS Catalina:
Default tab bar position:

Custom tab bar position:

A side note: the main menu doesn't work unless switching windows back and forth when starting dupeguru from the terminal. Might not be a problem when started by the end user though, just something to be aware of just in case (it happens in all branches). Also there is this ugly "python" in the main menu (it might just be because it was started from the terminal also) which always holds the "preferences" menu items. Weird.

Ah that seems to work fairly well, the "python" in the menu bar gets replaced with "dupeGuru" once the app is packaged into a apple application package. It runs that way from terminal as that is the "name" of the program running. Issue with the menu the first time is interesting, but not sure why that is. Either way that can be looked into later, I wonder if the packaged application will have the same issue or not. If you are good with your changes here, I'll give everything one more look over then merge this provided there is nothing else, looks good.

It's fine by me, I'm done with this feature branch. I am now bracing myself for the conflicts that will arise in the other merge request.

• Using the view menu to get to the results list always moves the tab order if it was originally listed before the ignore list, using the view menu to show the ignore list does not appear to change the tab order.

Fixed this issue in #683.