This thread is intended for questions and feedback concerning File Browser.
File Browser is quite popular and questions are currently scattered around the Open Repos comments section, Jolla store comments, and Github issues. In this forum we have a place where detailed answers are possible that may benefit more users.
(Comments in any of the other channels are still very welcome, of course!)
File Browser on Gemini PDA (and landscape mode in general): File Browser | OpenRepos.net ā Community Repository System [hint: landscape mode is currently quite buggy] Update: a longstanding bug with landscape mode has been fixed in version 2.4.3.
How to use the āfilter lineā for filtering and searching files:
How to use File Browser for managing (sorting, deleting, moving, linking, ā¦) many files at once:
Thanks for this thread ā¦ Maybe you saw my comment on Openrepos, but I am hoping for tab support, (select a file in a directory, switch tabs, go to other directory, paste, back to previous tab, select different file, switch to a 3rd tab, etc).
Besides that, I like solid bg for file manager, (plus a few other UI preferences), but I can probably do thatā¦
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 had modded my Fileman qmls to be similar, using code for background, rectangle, etc,u but then Fileman got dropped, and so I statted using File-browser ā¦ I think a solid bg and colors for different elements is helpful.
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 (GitHub - ichthyosaurus/sailfish-patch: Develop SailfishOS patches).
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
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").
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
.
(