Maximized window column widths not saved in 0.9.1

[viking777]

If you're new to this issue you can skip to testing the fix.

I have installed 0.9.1 on two distros (mint15 and ubuntu 12.04) in both cases the result is similar, the 'Name' column in the panel is too wide (occupying about two thirds of the available width) and it is NOT possible to resize it downwards. It is possible to make it even wider, but that just makes things worse. The result is that other columns are compressed and difficult to read and the last column in the list is partially off the side of the screen. All other columns resize normally, up or down, only the 'Name' column has a this 'minimum' width.

I am using a single pane layout in 'Detailed' view with a standard font (sans10) and 4 other columns visible in addition to 'Name'. One of my installs is gtk2 the other gtk3, the result is the same in both. The application was installed from your own repos as an upgrade to 0.8.7 - which did not have this problem.

[IgnorantGuru]

Thanks for the report. I'm not able to reproduce this in 0.9.1 with GTK2 or GTK3. The name and other columns can be made very small. Also, no one who did early testing on 0.9.1 gave any reports of this, including the packager for Ubuntu.

First, please verify what version you're running with:

killall spacefm
spacefm --version

When you say it was installed from my repos, did you build from the master or next branches, build from the source tarball, or use my PPA?

This could be an issue with a GTK theme. You might also try installing from the Ubuntu PPA to see if there's any difference.

You can also try starting spacefm with a fresh test config to see if it was some issue with upgrading:

killall spacefm
spacefm -c /tmp/spacefm-test-config

If anyone else sees such a problem, please add a 'me too' here with any similar details - thanks.

[viking777]

Version on Ubuntu is:spacefm 0.9.1 GTK2 UDEV INOTIFY DESKTOP SNOTIFY Version on MInt is identical except for GTK3 Both were installed from your ppa.

Starting with a test config as indicated is even worse. The 'Name' column occupies 90% of the available window size and cannot be resized down. Even the column next to 'Name' disappears off the end of the window! (this test done on the ubuntu gtk2 install).

0.9.1 is not on the ubuntu ppa so I can't try that.

[IgnorantGuru]

I just tried installing spacefm-gtk3 from my PPA, and also from Debian sid (0.9.1 is in there already). No sign of any problem.

My first guess would be a theme issue, so you might explore that. I can't think of anything else that would cause this to vary, and even that is unlikely. As soon as the columns are created they're set resizable, and name column has a minimum size of 150 pixels (same as in 0.9.0 and 0.8.7).

[viking777]

OK, so I changed ppa's from your own to mati75's and downgraded from 0.9.1 to 0.9.0 and the problem went away, the 'Name' panel is now resizeable again (on both distros).

I don't know if it is the change of packaging or the downgrade that solved the problem, but one or the other has.

[Vladimir-csp]

I had this problem briefly on 0.9.0+ before release. Could not decrease "Name" column size. Even wanted to report a bug, but the problem went away with restart, and I could not reproduce it ever since. It was on gtk2 package made with debian dsc.

[viking777]

Well my question from yesterday has been resolved today. This morning I got an upgrade to 0.9.1 from the Ubuntu ppa (mati75) and immediately the problem has returned, the 'Name' column is too wide and cannot be resized smaller.

So the packaging method, unsurprisingly, has no bearing on this issue, it is a bug with version 0.9.1 on ubuntu based systems, however you install it.

Unlike Vladimir-csp's experience it it not cured by anything as simple as a reboot.

Starting spacefm with a test config as detailed above gives the same result. Measurements indicate that the minimum width of the 'Name' column on my 1280 pixel wide screen is 1024 pixels, which, coincidentally is exactly the vertical resolution of the screen, I don't know if that gives you a clue?

My main monitor is a 5x4 layout, but I have also tried it on a 16x9 laptop screen and the problem does not go away.

I also have an old desktop computer which runs a completely unmodified version of lxle (an lubuntu variant). I installed spacefm 0.9.0 on this and the 'Name' column was resizeable. I upgraded it to 0.9.1 and the 'Name' column was too large and only resizeable even larger.

So for me this bug affects two completely different machines and three different distros the only thing they have in common is that they all run either Ubuntu or Ubuntu based distros.

[IgnorantGuru]

Thanks for the info. Here is what I think I have learned about this...

If you disable or remove this gtk_tree_view_column_set_expand line in the 0.9.1 source, that should fix the problem. That's located in the file src/ptk/ptk-file-browser.c line 4595. That line tells the Name column to expand to fill available space. Without it, the Name column will be 'dumb' when you resize the window - you'll have to manually resize the columns. If possible, please test to see if that corrects the problem.

I was able to see some of this behavior on LinuxMint15 (MATE version), but usually only on the first run of spacefm. It's unpredictable. What I am able to reproduce (and not just on Ubuntu) is an issue that causes the initial gtk2 0.9.1 window (first run with no config) to not allow the Name column to be downsized. Usually this problem clears by the second run, but I think it's related to the same GTK issue.

What appears to be happening is that if SpaceFM sets the column widths on startup to a total width which is far less than the total available width in the list area, then the Name column expands and won't allow itself to be made smaller. This problem is triggered on initial load without a config because the column widths are set to width 100. This problem occurs unpredictably in other cases (perhaps because the column widths saved, when restored, do not quite add up to the total available space). It can be triggered deliberately by eg editing the session file and setting panel1_detcol_name0-y=100. Why is this happening on Ubuntu? Perhaps due to theme fluctuations or some other factor, the total restored width might be just a few pixels short of available space, triggering the Name column to expand and lock. Also, if you switch from one theme or distro to another with the same spacefm session file, theme differences may make the columns widths come up a little short, triggering the problem, at least on first run.

This appears to be a bug in GTK2, although I haven't seen much of it in GTK3 (possibly once or twice, but wasn't able to reproduce). It's a bug because the Name column should remain resizable regardless of whether it expands, just as it does when it expands due to the user making the window larger (it won't lock in that case).

Also, I can find no reason why this should be more present in 0.9.1 than 0.9.0, but given the unpredictable nature of the bug (at least as far as I can reproduce), it's hard to say what factors may impact it.

The problem with setting expand FALSE is that the Name column becomes dumb during resizing, so I'd like to find a more elegant solution than just removing that line. But I suspect that will work as a temporary fix. Any testing on this will be helpful, especially by you viking777 since you seem to reproduce this problem reliably.

Also, what version of LinuxMint was this encountered with? eg MATE, Cinnamon, etc.

[VastOne]

Just an FYI on this, I cannot reproduce this in FluxBox, OpenBox or Xfce 4.10 on Debian SID and Compton compositor

[viking777]

IgnorantGuru - I tried this mod with an unpacked deb package, commenting out the line, then running the installer from a shell, but this did not solve the problem. However in order to check it properly I will have to download the source code from your site and compile it myself. I won't be able to do that until tomorrow.

I am using Mint 15 Cinnamon and Ubuntu 12.04 Unity.

[IgnorantGuru]

95580b0 now in the next branch is my tentative solution to the gtk2 problem of the Name column not allowing downsizing on initial startup with no configuration. This problem appears the same in 0.9.0 and 0.9.1. Even with this fix, on first run with no config, the Name column still can get stuck in GTK2 under some conditions, but this always clears on the second run with the same config. (The behavior of GTK2 columns has always been this way - problems in GTK2).

I don't see any change from this fix in GTK3, which never prevents downsizing of the Name column on first or any run in my tests.

Also, I tried Mint15 Cinnamon (live DVD and installed spacefm from my PPA without a full system upgrade) and could not reproduce the problem as viking777 described it in 0.9.1, only the usual stuck Name column on first run with no config in GTK2. So it's unclear whether this will impact the problem. If not, you can also try disabling the set_expand line as described above.

You can test the next branch using the BUILD NEXT instructions in README. To make sure you're running next, run:

killall spacefm
spacefm --version

That should report "spacefm 0.9.1+". The plus indicates next branch. Please verify you're running next when testing. You cannot trust the version displayed in Help|About (derived from /usr/share files).

[IgnorantGuru]

I have reverted the 95580b0 commit in b75071a because it breaks the behavior of the panel memory under some conditions - causes the Name column to grow in some themes. So for now the only test is to disable the set_expand line and see the result - thanks.

[viking777]

The result of my experiments. These were conducted on Ubuntu 12.04 Unity using the GTK2 versions of spacefm 0.9.1 and 0.9.1+ . Line 4595 in 0.9.1 and 4635 in 0.9.1+ were altered, then a full configure/make/make install carried out. Removing the lines in either version allowed the column to be resized manually, either up or down. Replacing the TRUE value with FALSE also allowed manual resizing in either direction.

The problem with both of these options is, as you have already guessed I am sure, that the 'Name' column reverts to a width of 150 pixels every time the program is started which is actually worse than the original problem!

Sorry.

For the moment I have resorted to changing line 4597 (set_min_width) to 640 pixels which gives me what I want, but I realise that is not a solution that will work for everyone and it is certainly not convenient to do either.

[IgnorantGuru]

viking777: Thanks for your testing. Removal of that line was mainly to let me know where your problem is coming from. (Removing the set_expand line is equivalent to setting it FALSE - that is it's default. When setting that FALSE, all columns now have expand set FALSE, so the behavior is for GTK to expand the last column rather than Name.)

The problem with both of these options is, as you have already guessed I am sure, that the 'Name' column reverts to a width of 150 pixels every time the program is started which is actually worse than the original problem!

That should not be the case - SpaceFM restores column widths, so it should restore them to your last used value. Only when starting with no config (first run) should the Name column be 150. You are getting much behavior I simply can't explain or reproduce. I tested with set_expand FALSE (including on Mint) and restoration of set column widths works fine. The only consequence is when you resize the window, the Name column doesn't automatically grow/shrink - it stays at what you set it.

At this point, yours is the only report thus far of a consistent problem with columns (aside from the GTK2 issue of the Name column not downsizing on first run only, which I can reproduce). And I'm noting that you report tests from several Ubuntu distros giving you the same results.

I don't see anything to indicate a problem in SpaceFM's code, and I simply don't know where the unusual behavior you're reporting is coming from. Ubuntu has a record of breaking GTK apps (eg their global menu bar), so perhaps something is similar here. And GTK does show its share of problems in this area in general.

There is not much difference in how the columns are created in 0.9.0 vs 0.9.1 - set_expand is the same. What is different is that 0.9.0 only sets the column sizes before the widgets are realized, whereas 0.9.1 sets the column sizes on various events after realization as well, as part of the new panel memory. For whatever reason, it appears GTK is not working properly for you in this area.

Pending more information, this report is not actionable further, as I cannot reproduce it even on the systems you list, and I find no problems in SpaceFM's code to explain your report.

As general suggestions, I would experiment with different themes and GTK versions. It is inexplicable to me that you report the same column behavior in GTK2 and GTK3 - more possible evidence that Ubuntu is breaking something in GTK?

Sorry I can't be more help with this but we'll see what additional facts present themselves.

Again if anyone else sees similar behavior, please drop a 'me too' here with your distro, GTK version, GTK theme in use, and brief description of the behavior you're seeing.

[viking777]

Ok, thanks for trying to help out. I will just live with it for now and wait and see what happens. It will probably go away one day just as mysteriously as it arrived. One thing I would say though and that is that memorizing the size of columns does not work for me at all. The name column opens up at 640 pixels - because that is what I have set it too, the next three are all 100 pixels despite me constantly resizing them to be larger and the last column occupies the remaining space. It was never like that on earlier versions, it has only been introduced from 0.9.1 onwards. It is not a big deal though, Spacefm is such a superb file manager that I can easily overlook a few quirks like that.

[viking777]

Mainly to prove I am not insane, I looked out a Ubuntu 13.04 live cd. Booted from it, added mati75 ppa and installed spacefm 0.9.1 on it. Opening it up the column layout was exactly the same as my other distros, with the 'Name' column too long and the last column disappearing off the side of the window. I resized all the columns I could (you can't resize 'Name' except to make it bigger), saved the session and shutdown Spacefm. On restarting it the columns had reverted to their original arrangement.

I did this to prove that this bug is nothing to do with my personal configuration errors or themes (unless it is the default Ubuntu theme it conflicts with) as no previous configuration can possibly have taken place on a live cd.

I don't know why this is not reported by anyone else or not reproducible by yourself as it is 100% reproducible on any medium, machine or distro I care to use.

The thought crossed my mind that maybe other users are not showing as many columns as I have in view? I am using 'Name', 'Size', 'Permission', 'Owner', and 'Modified' columns.

I understand that if I am the only one reporting this problem then it isn't worth your time in chasing an answer, but I just give you this information to use as you like, ignore it if you wish I won't be offended, and after all it is only a relatively minor bug in a very decent program.

[IgnorantGuru]

So to summarize your reports (mostly for my notes, and correct me where I'm wrong):

You have tested SpaceFM 0.9.1 on several Ubuntu variants on several different machines, with GTK2 and GTK3. In all cases you found the following anomalies:

1) On SpaceFM's first run or with a new test config dir, The Name column was wider than expected and the Size column was partially horizontally scrolled out of the viewable area.

2) You could not make the Name column smaller. You could make the window larger, add other columns and resize them.

3) Restarting SpaceFM, you still could not make the Name column smaller, nor were the sizes of the other columns restored.

4) SpaceFM 0.9.0 does not exhibit these anomalies on these systems (except perhaps the Name column not getting smaller on first run in GTK2).

5) When you set set_expand to FALSE on the Name column, column sizes were still not restored.

Also, I tried Ubuntu 13.10 amd64 desktop live, added mati75's PPA, and installed spacefm. I could not reproduce your problems. On first run, as expected, I cannot make the Name column smaller, though the default width was as expected. When restarting SpaceFM I can resize all columns and column sizes were restored. The panel memory involving columns in other panels also worked normally. Ubuntu was running libgtk2.0 (2.24.20-1ubuntu1), which was the latest (apt-get upgrade would not offer to update it).

Based on the info thus far, this does not appear to be a bug in SpaceFM's code. It could be a bug affecting limited systems in Ubuntu's GTK, GTK proper, a theme, etc.

Your expanding your tests beyond Ubuntu-based distros would provide more data on what is introducing this problem. For example, if you can reproduce it on a Debian live disc, this would indicate you're likely hitting a GTK bug which only affects a small percentage of systems. If you can't reproduce it on Debian, this would indicate likely Ubuntu-specific breakage (which apparently does not affect all systems).

So the next step to pursue this is to take Ubuntu out of the loop, especially because Ubuntu has a history of breaking GTK apps.

Also, I recommend running spacefm from a terminal so you can see any GTK or theme-related warnings, because the behavior you report indicates some kind of breakage in the behavior of GTK functions.

[viking777]

Points 2,3,4,5 all correct. As for point 1, the name column is too wide on every start up, not just the first run. It is not the Name column that is partially out of the viewing area, it is the last visible column whatever that may be (in my case it is the 'Modified' column.

Starting spacefm from a terminal gives one warning only

** (spacefm:4229): WARNING **: No root settings found in /etc/spacefm/  Setting a root editor in Preferences should remove this warning on startup.   Otherwise commands run as root may present a security risk.

I don't see this as even remotely relevant to the bug and anyway I already have a root editor specified so it is erroneous.

My libgtk2.0 version is 2.24.10-0ubuntu6 but bear in mind that I am running 12.04 lts not the latest version so this is probably the correct version for this ubuntu release.

I do run a non-ubuntu based distro - Manjaro - but as yet Arch have not moved their spacefm version beyond 0.8.7 - which operates normally. As soon as they do so I will test on that, but I am not really confident about compiling Arch packages for myself.

Thanks for replying, but like I say, don't waste too much time on it, it is not a major show stopper by any means, just a minor annoyance.

[VastOne]

"I already have a root editor specified so it is erroneous. "

Just curious viking777... if this is a first run from terminal, how is this possible?

[IgnorantGuru]

jfyi, Arch's spacefm package is at 0.9.1 as of yesterday. There is also spacefm-git in the AUR which builds and installs the next branch (GTK3) (currently the next branch is equivalent to 0.9.1).

The root settings warning is normal for a new spacefm user.

[viking777]

Don't see 0.9.1 on my aur repo, but no matter, 0.9.0 is there so I installed that and it works perfectly as it does in all other distros. I then installed spacefm-git and ran that (version is 0.9.1+). This is much better than in Ubuntu but not as good as previous versions. The behaviour is the same if I start it with my own config or a blank test config. The good news is that the 'Name' column is fully resizeable, so I only have to drag it a little smaller for the hidden part of the last column to be brought into view. The bad news is that it does not retain this panel sizing despite hitting 'Save Session' before a restart. On the next start the end column is again partially out of view.

You ask a question about the 'root editor' error. It is possible to have a root editor specified if I run my own profile from the terminal and not a blank one. However it doesn't matter either way since the message appears whichever profile is in use. I never get any errors relating to gtk.

On manjaro however I do get gtk errors. I will post them when I have booted back into Manjaro.

In short spacefm 0.9.1+ is better on Manjaro than it is on Ubuntu, but not as good as any of the previous versions (in respect to column sizing that is).

[viking777]

Error messages running spacefm 0.9.1+ from terminal with test config.

[manjaro@fujitsu ~]$ spacefm -c /tmp/spacefm-test-config

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:85:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:207:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:244:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:290:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:325:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:416:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:869:17: Not using units is deprecated. Assuming 'px'.

** (spacefm:663): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist

** (spacefm:663): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2031:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2148:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2165:18: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2181:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2239:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2246:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2259:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2323:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2373:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2388:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2497:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nautilus.css:46:15: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nautilus.css:46:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nautilus.css:94:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nautilus.css:99:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nautilus.css:128:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nautilus.css:133:18: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nemo.css:46:15: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nemo.css:46:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nemo.css:94:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nemo.css:99:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nemo.css:128:17: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: nemo.css:133:18: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: unity.css:23:18: Not using units is deprecated. Assuming 'px'.

(spacefm:663): Gtk-WARNING **: Theme parsing error: epiphany.css:12:17: Not using units is deprecated. Assuming 'px'.

With that little lot it is a wonder it runs at all, but it does and much better than on Ubuntu! As you can see these are mostly theme related errors, and I did have to alter themes to get spacefm to work properly on Manjaro. My present theme is Shiki-Nouveau-Dust. Changing to the default 'Adwaita' results in no error messages at all on start up, but it causes the loss of the alternate white/grey line shading on all columns of the program window, and this has a serious effect on readability which is why I changed to the 'Shiki' theme in the first place. However this is off topic for the present bug report.

[IgnorantGuru]

Thanks for the results. To clarify a few items:

There is no need to Save Session - that is done automatically on exit.

Any theme warnings invalidate your report. You need to use a GTK3 theme up to date for your current version of GTK3. Please use Adwaita only for these tests.

You might try this test: Set the column widths as you like them, then press Ctrl+T to create a new tab. Are the columns in the new tab exactly like the columns in the old tab? Or did something shift?

Also, when you restart SpaceFM, is the window size exactly as you last left it? If your WM is forcing the window to another size, this could explain your columns being too wide for the window. Or is the Name column merely restoring larger than you saved it, while the window is the same size?

What GTK3 version is in use on Arch? (eg 3.8?)

[viking777]

There is no need to Save Session - that is done automatically on exit.

I know that, but where I live it is a technique we call 'Belt and Braces'

Please use Adwaita only for these tests.

I am happy to test with Adwaita, but I am not happy to use it due to the reasons given above.

You might try this test: Set the column widths as you like them, then press Ctrl+T to create a new tab. Are the columns in the new tab exactly like the columns in the old tab? Or did something shift?

The new tab in this test results in the same column sizes as the original opening of the program, ie the last part of the end column disappears from view.

Also, when you restart SpaceFM, is the window size exactly as you last left it?

I open all spacefm windows maximised, so they are exactly the same size every time I open them.

What GTK3 version is in use on Arch?

GTK version 3.10.2-1

[IgnorantGuru]

I open all spacefm windows maximised, so they are exactly the same size every time I open them.

This would have been helpful to share earlier in this report. SpaceFM 0.9.1 never saves column widths when the window is maximized or fullscreen, so this may be part of your problem - if you're making the adjustment while the window is maximized, they will be ignored when saving. For these tests, please don't maximize the window. If your problem only affects maximized windows, include that information in the report.

Due to it setting and saving column widths more frequently in 0.9.1 (to support panel memory), saving the column widths when maximized causes them to be too large when returning to unmaximized. So 0.9.1 leaves the maximized columns to the default behavior, which will vary between GTK2 and 3, but generally looks reasonable. In no case do I see the columns larger than the window. In general the Name column will grow while maximized. This behavior is intended - it means you can adjust column sizes while maximized or fullscreen without interfering with your unmaximized column sizes. The only caveat is that the widths in those modes are not saved between sessions - they are considered temporary states.

If you plan to use SpaceFM maximized, you're better off setting column widths in an unmaximized window, close SpaceFM, then restart it and maximize it. From then on, the column widths should remain as you set them while unmaximized, even if you start SpaceFM maximized. The Name column will grow while maximized to fill the extra space.

It appears that most if not all of the problems you're reporting are due to using an old session file saved on another size screen (which will indeed push columns into the scroll area if the new window is smaller), as well as using the maximized setting while trying to adjust columns.

[viking777]

This would have been helpful to share earlier in this report.

I most certainly would have shared it earlier if I knew it was relevant. Your reasons for considering column changes in maximized windows as 'temporary states' must seem very logical to you, but are not remotely so to me. I am not a coder or a Linux expert in any way, but I have been using it for a dozen or so years, and in all that time I can't remember any other file manager imposing such restrictions (and I like file managers and have used a lot of them).

So if I can offer some feedback, if it is not possible to set column sizes in a maximised window then make that abundantly clear somewhere where people will see it (ie not buried in the depths of the user manual). I don't quite know how you will do this but that is up to you to decide.

Thank you anyway for solving my problem, I will send you a donation which will perhaps make up for the time I have obviously wasted.

Please keep developing spacefm it is one of the most interesting Linux projects I know of.

[IgnorantGuru]

Indeed I didn't document this change - an oversight. For future reference, especially when asked to start SpaceFM from a default config, if you maximize a window that's an important step to include in terms of reproducing it. But verbal descriptions of these kinds of things are difficult so I understand the miscommunication. For some reason it didn't occur to me earlier either. Sometimes screencasts are helpful too so I can see what you're doing.

SpaceFM is an unusual file manager, and the new panel memory creates some unique conditions to handle, but I'll consider how the treatment of maximized and fullscreen might be adjusted. The problem is that some people like to keep it maximized, and others just go into that state temporarily, so it's hard to satisfy both uses.

Also, it's fine to use 3rd party themes (I do too), just be advised that they do sometimes create breakage. If a problem appears with a 3rd party theme but not with Adwaita, you need to inform the theme maker.

Thank you very much for your donation! It wasn't a waste of time if we found the source of the confusion, which is why I pursued it - seemed like something was missing.

[IgnorantGuru]

The next branch (due in 0.9.2) now handles maximized and fullscreen as described here, and includes miscellaneous changes to how those modes are handled. That branch can be tested using the BUILD NEXT instructions in README. Thanks for testing.

[VastOne]

Nice going viking777 and IgnorantGuru in keeping this alive to the end and resolved

[OmegaPhil]

I'm running the latest next on Debian Testing and can confirm that switching over to the Detailed View (compared to my normal Compact View) in a maximised window on my secondary monitor, the Name column refused to reduce its size - could only be made bigger. Restarting SpaceFM fixed this - so it isn't reproducable.

[IgnorantGuru]

I have seen that column stick on rare occasions. Almost certainly a random GTK3 bug that will never be investigated or fixed by the current gtk developers.

[OmegaPhil]

*I'm using GTK2