Add dual-pane layout options (vertical split, separate sidebars/nav bars/status menu)

[cdmdotnet]

Dual-pane enhancements:

• vertical split mode (panes stacked one above other),
• separate sidebar per pane,
• separate Path Bar / Location Entry per pane
• separate status bar per pane

All options default to off, preserving existing behaviour when not enabled. New preferences exposed in a dedicated Dual Pane section of the Behaviour tab.

Details

"Show panes vertically – one above the other" (default: off)
  Adds a VPaned orientation for split-view in addition to the existing
  side-by-side HPaned layout.  The split_view_hpane is recreated with
  the appropriate GtkOrientation when the preference changes.

"Separate sidebar per pane" (default: off, requires vertical split)
  In vertical split mode each pane column gets its own independent
  sidebar (places or tree) locked to that pane's navigation so
  browsing in one pane does not move the other pane's sidebar.
  Implemented by wrapping pane1 in a new inline HPaned
  (primary_pane_content_paned) and adding a second sidebar box
  (sidebar2 / secondary_pane_content_paned) for pane2.

"Separate Path Bar/Location Entry per pane" (default: off, requires vertical split)
  Embeds a full toolbar (path bar / location entry) directly inside
  each pane column so each pane tracks its own navigation history
  independently without sharing the window-level toolbar.

"Separate statusbar per pane" (default: off, requires vertical split + separate sidebar)
  Adds a full-width NemoStatusBar below each pane column (spanning
  both the sidebar and content area).  The global statusbar is hidden
  by concealing its outer event-box wrapper rather than changing its
  visible property, preserving the GSettings binding that controls the
  floating-bar "selected items" overlay.  Each per-pane bar is locked
  to its pane via a new PROP_PANE construct property so its zoom
  slider and sidebar buttons operate on that pane only.  The places /
  tree toggle buttons call the new nemo_window_set_pane_sidebar_type()
  helper which swaps the sidebar widget in-place without firing the
  global notify::sidebar-view-id signal, keeping each pane's sidebar
  type independent.

[Jeremy7701]

My screen isn't big enough for all this.
Nothing to stop you starting two nemo instances if you want bars all over the place.

[cdmdotnet]

My screen isn't big enough for all this. Nothing to stop you starting two nemo instances if you want bars all over the place.

I considered smaller screens, which is why this has preference toggles which are all disabled by default, so wouldn't impact any existing users in that situation, and can be turned off at any time. Like the existing dual pane feature.

[mtwebster]

This does not build - have you even tested this?

I'm not interested in having the burden for all of this code essentially placed on me, for a feature no one has ever asked for.

[cdmdotnet]

Yes it does build. And yes I have tested this, rather extensively. That's not to say I haven't missed checking in some files. If you could give me something more to work with I could find out what you are experiencing then we could professionally work through what mistake I might have made in getting this across to you.

Build console output at a minimum.

[cdmdotnet]

I found the github build scripts and ran those manually and they reported a successful build as well - https://github.com/cdmdotnet/nemo/actions/runs/23117709943.

Again, I'm happy to help as I think this feature is very helpful, but like any development, I need a little more to work with than "it doesn't build on my machine"

[mtwebster]

../src/nemo-statusbar.c: In function ‘action_hide_sidebar_callback’:
../src/nemo-statusbar.c:159:36: error: invalid use of incomplete typedef ‘NemoWindowDetails’
  159 |         GList *panes = win->details->panes;
      |                                    ^~

You cannot access nemo-window's private struct from nemo-statusbar.

[cdmdotnet]

Thanks for the feedback. I'll look into what I've done wrong here for my build to succeed and the PR not to.

[mtwebster]

I found the github build scripts and ran those manually and they reported a successful build as well - https://github.com/cdmdotnet/nemo/actions/runs/23117709943.

You built the master branch there.

Failed build from this PR:
https://github.com/linuxmint/nemo/actions/runs/23084492164

I don't see how you could have built this locally and ran it.

[cdmdotnet]

I'm a bit confused. I specified my feature branch when I triggered the build, though I don't know what the build itself does.
The release it's created at https://github.com/cdmdotnet/nemo/releases/tag/feature%2Fhorizontal-dual-pane.mint22 says it's for my commit and branch.

I've also updated the release it created with deb packages I created locally... there's two, one renames a few things so I could do side by side testing without overwriting the pre-existing nemo.

Have i mis-understood what the build scripts do? I went to actions, selected the "Build" action, went "Run workflow"
and selected my branch - changing it from Master. Does that not build my branch using your build scripts? Is it locked to master branch only?

I didn't select the option for SSH on failure ... should I have?

[cdmdotnet]

I was one commit behind when I made the PR. I missed a check-in that had some tests, but appears to have had some other missed check-ins.

Anyways. It now builds against the github action. I'll create a separate PR for that