File Browser support and feedback thread

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!)

Resources:

  • Translations (contributions very welcome!):
  • Source code, issues, contributions:
  • Downloads, comments, details:

https://openrepos.net/content/ichthyosaurus/file-browser

Previous questions:

You can find a detailed change log on Github.

There is also a FAQ covering some questions.

  • File Browser on Gemini PDA (and landscape mode in general): https://openrepos.net/comment/36221#comment-36221 [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:
8 Likes

Thanks for fixing the horizontal mode. I verified it on a Gemini PDA - it works.

Thank you for testing; that’s good to hear! :slight_smile:

Any chance of an official aarch64 bit build?
I can confirm that it builds just fine and runs out of the box on my Xperia 10 II.

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…

Of course, hopefully this weekend once I’ve got some free time. And thanks for confirming :).

(Quote from https://openrepos.net/comment/37478#comment-37478):

I was thinking about implementing two panes in horizontal mode. Copying files between multiple File Browser instances/windows is also on my radar.

I didn’t think of tabs yet. I’ll have to think about the best solution, any input welcome :).

Can you explain what you mean by that?

3 Likes

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 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’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 :slight_smile: .

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 :wink: (https://github.com/ichthyosaurus/sailfish-patch).

3 Likes

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

1 Like

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

2 Likes

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").

3 Likes

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 :wink:

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).

1 Like

File Browser Browser didn’t see some catalogues in Android storage. Other apps see.