New question by @Levone1 (https://openrepos.net/comment/37429#comment-37429):
Could you make it remember ‘show hidden’ globally? You basically have to enable it for each directory, and re-enable each time you use it…
Answer (https://openrepos.net/comment/37431#comment-37431):
That’s already possible: swipe right to get to the global app settings. There you can enable “show hidden” by default, and you can disable folder-specific settings.
(Apparently I can’t edit the top post anymore…)
I’m generally not a big fan of the SF “glass” look, (I’ve ranted about it for years), but it is nice in certain situations… In a file manager, though, (and a text editor, which most devs seem to agree with)l I think especially that a solid bg is better, because it takes away any visual confusion / obstruction.
for example, here’s my tweaked skin for Mixplorer on Android
…
I’m not necessarily stuck on those colors - just an example…
Here’s a visual of Mixplorer tabs (horizontal scroll to switch)
I generally like the glass look, even though (or because) it is a challenge as it takes quite a different design approach than what we’re used to on other platforms. I can see you point, though. Especially with lively wallpapers, an information-heavy screen can get a bit “messy”. The upcoming version of File Browser includes an option to enable a solid window background 
.
This looks really interesting. I think this would make for a nice patch through Patchmanager, as it doesn’t follow Sailfish’s style guide but still looks nice. I never miss a chance to promote my patch tool 
(https://github.com/ichthyosaurus/sailfish-patch).
I just noted that control elements (play/stop button and time ruler) are missing when opening videos from the file browser and starting play back.
This is a regerssion under SFOS 4.2
There are two ways to start playback of videos from the file browser: you can use the build in media player with a simple swipe to the left or you can open the video file from the top menu, thus invoking the Gallery app. I am talking about the latter case because - while in both cases, control elements are missing - directly playing back video files with the Gallery app or from Jolla’s file browser under settings → memory comes with the control elements.
So I am wonderig why Gallery app behaves differently depending on whether Gallery app is opend directly (or via sttings → memory ) or via the file browser.
File Browser’s built-in media player is deliberately kept very simple. It’s not meant to be a media player but rather a way to preview media files. I still want to add a few controls (e.g. a seek bar) but I didn’t have time for this yet.
I don’t know why Jolla’s gallery app behaves differently in some cases; I can’t reproduce this either (but I’m still on 3.4). File Browser simply runs xdg-open <file> so there’s nothing special to it. Maybe file a bug report for Jolla Gallery?
In the meantime, you can install a dedicated video player. IIRC there’s a good one in Openrepos.
Thank you for replying! That Gallery behaves differently depending from how it’s opened is what surprised me. I like the simple video player of File Browser so my post was merely about the strange behaviour of Gallery.
I was not sure whether this was something for a new thread before knowing how File Browser invokes Gallery
I suspect the issue lies in the introduction of firejail for jolla-gallery. I presume, xdg-open hasn’t been (fully) adopted for that and causes this issue.
I have filed a bug report (both here in the forum as well as internally with jolla) for that: [4.2.0.21] [X10 II] Video player overlay missing from videos
Another interesting issue that arises from this is that you can’t open videos if jolla-gallery is running in the background. You simply get the “open successful” banner on top, but nothing happens. I have filed a bug for that as well: [4.2] [Xperia 10 II] Jolla-Gallery won't close properly / can't open video from file manager
Xperia 10 / SFOS 4.3.0.12
I love File Browser to read PDF documents. I would like to make a minor tweak and hope someone can show me the way to do this.
Problem is: On vertical scrolling in the PDF document, at the tinyest little movement downwards, the bottom bar appears. It disappears after 5 seconds or on scrolling upwards.
While reading and repeatedly scrolling up, it happens very often, that while releasing the finger from the screen, a little movement downwards occurs. In this case, immediately the bottom bar (with the page numbers and so on) comes up or flickers and this is annoying while reading.
So I would like to implement a threshold by some tweak. I would like that the bottom bar only appears if the scrolldown movement is at least e.g. 10 pixel or so, and does not react on smaller scrolldown events.
Is this possible? Can somebody tell me how to do this? I’m not a coder but I can edit some system files without problems, if someone tells me what I have to do.
File Browser uses the system documents app inline for showing PDFs. This means you would have to patch sailfish-office.
You can copy this config file and use it to create a new patch with sailfish-patch. Put the config file in a new folder, change the Prefix: /usr/share line to Prefix: /usr/, and run sailfish-patch -u.
The files you’re interested in are in /usr/lib/qt5/qml/Sailfish/Office/. I presume the relevant file is ToolBar.qml. Maybe you can add some kind of threshold at line 90 ("_active = flickable.contentY < _previousContentY").
Can I try this way:
“_active = flickable.contentY < (_previousContentY - 20)” ?
edit: I tried it, and a value of 1 instead of 20 works fine . Problem solved .
Thank’s very much @ichthyosaurus !
Finally I changed it into
’ _active = (flickable.contentY + 1) < _previousContentY ’
The addition in the first part works smoother than the subtraction in the second part.
Now the screen is much more quiet when reading PDF docs. The permanent flickering of the bottom bar on the tinyest touching the screen or wrong movement of the finger is gone and I’m happy!
On the other hand, it’s now more difficult to reach the bottom bar to do something on it. Now this needs some fine motor skills
Thanks again @ichthyosaurus !
I’m glad to hear it’s working!
You may want to publish the patch in Patchmanager’s web catalog (sailfish-patch can help you with that as well).
Are you running version 2.5.1 from OpenRepos? If not, I suggest you should update to this version and try again.
Indeed. It was 2.50. Thanks.
With SFOS 4.4 the File Browser can´t install Android-APKs manually
Do you have FileBrowser 2.5.1-1 yet? I checked on my Xperia 10 right now and in File browser, going to the directory where the .apk is, click on the .apk file, information window with type, size, rights, owner, group… opens.
There pull down, is there no install option?
Where to get it?
Sailfish Store → 2.5.0
Storeman → 2.5.0-1
Chum → Not listed
Storeman, File browser 2.5.1-1 by Ichtyosaurus from 30.3.2022 .
