(SOLVED) - Folders-Files No Longer Appear In Uniform Grid

[TuxerIT]

Hello,

I know this project is no longer developed, such a shame, an amazing file manager!

But in the meantime, I hope someone might know a fix/patch for this issue I am now running into.

With the latest versions of Linux, updated, GTK, X, dependencies, libs, etc., I can only assume, this is the reason I am seeing this issue.

Now in SpaceFM, I constantly run into files/folders not always lining up in a nice uniform grid.

Here are the folders/files sometimes appearing as they should in a nice uniform grid.

This is what I am constantly running into, seeing files/folder now lining up in a non-uniform grid;

Does anyone know a fix/patch for this?

THANKS

P.S. After posting this, I forgot to mention, I tried several different fonts with no success. This does not appear to be a font issue.

[TuxerIT]

I'm using Openbox 3.6.1, and thought this might be an issue with Openbox, on a newer updated since, considering Openbox is not in development, and this being some sort of DE/WM Standards Compliance that is outdated, causing this.

But I just tested this with the latest version of QtFM 6.2.1 and did not see this problem.

https://github.com/rodlie/qtfm

[TuxerIT]

I can now confirm there is an issue in SpaceFM in regards to fonts. No matter what fonts I use, I will eventually find files/folders/archives, etc., where the alignment becomes messed up.

I've tried around 7 different fonts, and was not able to correct this problem.

What's odd, is that for one particular file/folder/archive, etc., I can pick a font and size and it will be corrected, but then I'll find another file/folder/archive and the alignment is messed up, so I pick another font and size to correct it, but then I'll find another file/folder/archive with the alignment messed up again.

This just goes around in circles, some files/folders/archives, get corrected and then I'll find others messed up.

[ncmprhnsbl]

this seems to be a problem with spacefm built with gtk3 .. i presume that's what you're using? at least, i've yet to encounter it with gtk2 builds.. so my guess is that somewhere in the code for the text alignment(possibly to do with 'elipsize'), it's using a method that's incompatible with gtk3.. maybe in https://github.com/IgnorantGuru/spacefm/blob/master/src/main-window.c around line 2872 to do with 'strlen' (string length) or i could be completely wrong ;)

[TuxerIT]

I compiled it with GTK2 & GTK3 both are the same.

I actually tested spacefm in xfce and it didn't have this issue. Other users I know reported it working ok in gnome, mate, and xfce too, but not KDE.

So SpaceFM will show this issue in Openbox and KDE, that I know of.

SO, the question is, what is gnome, mate and xfce doing that makes it render correctly?

Hmm

[ncmprhnsbl]

interesting, using openbox here, and not seeing any alignment issues.. (using obarun/arch, spacefm-git(alpha branch) gtk2) can't see that window manager or DE would have any effect on in app behavior directly.. more likely something underlying like a missing dep or setting.. other things to look at would be gtk and icon themes.. but this: https://github.com/IgnorantGuru/spacefm/issues/782#issuecomment-728262328 suggests what you said about fonts is relevant.. guessing that font selection would have an effect on where text is broken up ..although it doesn't seem to make a difference here.. i wonder, how are you setting the font? here i'm doing directly in spacefm >rclick>view>style>font ..

[TuxerIT]

782 is talking about auto-hyphenation.

I can change fonts and it will fix the issue on some files/folders, but eventually I find the issue somewhere else...

I tried right clicking to set the fonts, it still doesn't work.

I use LXAppearance for theme, icons.

How are you change System Fonts? Do you have a .Xdefaults with any XFT settings in it?

I've used SpaceFM since this project started, and in that time, I never had this issue till now.

I use Slackware, and it was working in the previous version 14.2 in Openbox. Slackware has been recently updated to 15.0, and this is when the problem began, I believe because of all the updates in Linux.

I have tried these 3 file managers, and none of them have this issue; QtFM, PCManFM, Thunar.

So I don't understand, what a DE like Gnome, or Xfce are doing different, where end-users I know in Slackware on Gnome and Xfce that have tested this, don't see this issue.

As I mentioned I also tested SpaceFM in Xfce and didn't see the problem either.

I didn't look at the different Branches, I can try the Git Alpha to see if it makes any different, but I didn't think there were any changes to any of the Branches that were different?

What about Patches for your distro, with SpaceFM? I found two patches that Arch was using that I had to have one to get it to compile with the latest GCC.

spacefm-Fix-GCC-10-build.patch spacefm-glibc-2.28-compatibility.patch

P.S. I compiled the Alpha Git version, same problem...

I wonder if this was suppose to be the fix?

https://github.com/BwackNinja/spacefm/commit/b660f30596e670d11f226dcaa16ac9959a25b2f9

[TuxerIT]

So after my last reply, and after trying the Alpha version, and it didn't work, I looked at what was mentioned, relating to this;

https://github.com/BwackNinja/spacefm/commit/b660f30596e670d11f226dcaa16ac9959a25b2f9

1.0.6 has it the same; 109

"wrap-mode", PANGO_WRAP_WORD_CHAR, "wrap-width", icon_size < 110 ? 109 :

Since the Alpha didn't work, which is suppose to be 109, and 1.0.6 is also the same by what I can tell/see here. I changed the above to < 110 ? 105 : and made a patch and tested it.

With this patch I created and tested it 105.

I tested 3 different iconsets at 3 different sizes, and 6 different fonts at different sizes, and I could not find one issue any longer.

This appears to have fixed it for me, I will continue to keep an eye out and if I happen to run across seeing another problem I'll come back here and report it.

I made this 105, because on my box, the misalignment would take up 1/4 to almost 1/2 the pane area. Since I was seeing an extreme shift I made it 105, in hopes that a bigger change was needed. I'm certainly not an expert on this change, but I did not see any breakage anywhere within SpaceFM.

Here's the patch I made text_wrap.patch - (Be sure to change the extension from .txt to .patch

text_wrap.txt

[ncmprhnsbl]

interesting.. i took a different approach, noticing the difference in pango versions between arch and slackware (1.48>1.50) and testing in porteus(slackware15 based) i noticed if i reduced the font size(<9), the alignment would correct.. anyway, i built pango 1.50 for slackware and the alignment issue disappeared for any font size. if you want to try this, just grab the slackbuild from the 15 repo sources and the pango source from https://download.gnome.org/sources/pango/1.50/ it's a fairly trivial compilation. but probly fair to say there is some "weakness" in spacefms code that is sensitive to the vagaries of pango, where other fms aren't.

[TuxerIT]

I did change fonts size and it would correct the issue on some files/folders, but sooner I'd find more files/folders that were having the issue.

I guess updating Pango, shouldn't cause issues with other apps compiled against 1.48, I'll also give this a try, I'd rather update Pango, instead of hacking a bandaid on SpaceFM.

[ncmprhnsbl]

about newer pango being a problem: just going by arch's info: https://archlinux.org/packages/extra/x86_64/pango/ my guess is probly mostly not a problem two reasons:

1. it's libs are very genericly named/versioned (at least between 1.48 and 1.50)
2. only few things that use it list it as a make dependency but of course i could be completely wrong :)

[TuxerIT]

I compiled Pango 1.50.6 and then I recompiled SpaceFM, Openbox, and I also use pekwm, and it's been recompiled.

SpaceFM works great with Pango 1.50.6, I haven't found one issue with it.

I don't use a lot of apps in Linux, so the ones I compile, I'll eventually recompile them against this new version of Pango.

From what I understand, I don't think anything is going to break in a distro that someone compiles a new version of Pango for.

Thanks a lot for all your time and help it's been greatly appreciated to help solve this.

THANKS