PCManFM file manager is being ported to Qt

[pcma...@gmail.com]

Hello,

I'm PCMan, developer of LXDE and its file manager PCManFM.

Congrtulations to your great project. I'm really impressed.

Though we're using different GUI toolkits, we have similar goals.

This statement, however, is not true anymore as I'm also using Qt now.

I'm not going to port LXDE to Qt, only the file manager will get a Qt port.

For screenshot, source code, and detailed introduction, please see the blog post.

http://blog.lxde.org/?p=966

It's still a work in progress and I'm still learning how to use Qt.

Basically the folder browsing part is already usable, but others are not.

Speed is slightly slower than its Gtk+ brother, but is still fast and relatively lightweight.

The porting should be very fast and easy, though.

The core of the Qt-based file manager is libfm, the same library used by the gtk+ version.

When finished, it will remain desktop independent and won't have KDE dependency.

That says, it's a pure Qt application, which can be used inside Razor.

The only drawback is it requires glib/gio and Qt compiled with glib integration.

To mount remote filesystems and manage volumes, it requires gvfs.

Don't worry about gvfs, it's a gnome product, but it can work independently without gnome.

If anyone is interested in helping the development, feel free to contact me.

Thank you!

[Kevin Krammer]

On Tuesday, 2013-02-19, pcma...@gmail.com wrote:

> When finished, it will remain desktop independent and won't have KDE
> dependency.

Well, that is easy. I don't think there is any file manager which depends on
KDE. Even KDE's own two file managers, Konqueror and Dolphin, do not depend on
KDE.
There would be no point in making a file manager depend on any workspace
components.

> To mount remote filesystems and manage volumes, it requires gvfs.
> Don't worry about gvfs, it's a gnome product, but it can work independently
> without gnome.

I think that GVFS is actually not a GNOME product but part of GIO.
Its concepts of mount daemons is pretty cool, I always wondered if one could
write a Qt based client library for the protocol so one could have Qt
applications as clients to them and potentially even use Qt for implementing
more mount daemons.

Are you by chance aware of any project or attempt at implementing of the
client part of GVFS in another software stack than gobject?

Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

[Alec Moskvin]

Just so you know, icons don't work outside of KDE (and if the default
GNOME icon theme is not installed - I think) because QIcon::fromTheme()
is badly broken :(

http://i.imgur.com/WSEjiYT.png

In Razor it's fixed like this:

https://github.com/Razor-qt/razor-qt/blob/master/libraries/qtxdg/xdgicon.cpp
https://github.com/Razor-qt/razor-qt/tree/master/libraries/qtxdg/qiconfix

Alec

[PCMan]

Thank you for the info.
I'm aware of the problem. The default icon theme is hard-coded now for
ease of testing.
Later it will be configurable via either
1. reading xsettings, or
2. specify in config file.
I just don't have time for it now. It will be handled when I start
working on preferences.
Thanks for the feedback.
BTW, maybe I can use your qtxdg later if needed.
Nice work!

> --
> --
> You received this message because you are subscribed to the Google
> Groups "Razor-qt" group.
> For more options, visit this group at
> http://groups.google.com/group/razor-qt?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Razor-qt" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to razor-qt+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jerome Leclanche]

About icon themes: https://bugreports.qt-project.org/browse/QTBUG-25718

Good work!

J. Leclanche

[Pier Luigi]

2013/2/19 <pcma...@gmail.com>:

> It's still a work in progress and I'm still learning how to use Qt.
> Basically the folder browsing part is already usable, but others are not.
> Speed is slightly slower than its Gtk+ brother, but is still fast and
> relatively lightweight.
> The porting should be very fast and easy, though.
> The core of the Qt-based file manager is libfm, the same library used by the
> gtk+ version.
> When finished, it will remain desktop independent and won't have KDE
> dependency.
> That says, it's a pure Qt application, which can be used inside Razor.
> The only drawback is it requires glib/gio and Qt compiled with glib
> integration.
> To mount remote filesystems and manage volumes, it requires gvfs.
> Don't worry about gvfs, it's a gnome product, but it can work independently
> without gnome.
> If anyone is interested in helping the development, feel free to contact me.

What's the advantage of this approach compared to say using Solid to
enumerate volumes and mount file systems with FUSE?

This is the direction I'm taking with Hawaii file manager and should
be DE agnostic without even involving wrappers around C code.

Out of curiosity, do you know what was gvfs goal in the first place,
was FUSE so bad?

--
Out of the box experience
http://www.maui-project.org/

[PICCORO McKAY Lenz]

On Wed, Feb 20, 2013 at 10:05 AM, Pier Luigi <pierluig...@gmail.com> wrote:

2013/2/19  <pcma...@gmail.com>:

What's the advantage of this approach compared to say using Solid to
enumerate volumes and mount file systems with FUSE?

well from user's point of view , fuse are less stable an more faster due are directly in userspace..

gvfs depends on backends and layers fo interaction on vario filesystems, including FUSE for URI handle.. 

BTW: pcmanfm will fail using uri's if fuse an gvrfs are out of date, bug +

 

This is the direction I'm taking with Hawaii file manager and should
be DE agnostic without even involving wrappers around C code.

 

Out of curiosity, do you know what was gvfs goal in the first place,
was FUSE so bad?

gvfs not like me, but handle many protocols in nice interfaces easy to integrate as does some others mocosoft-like OS, fuse handles directly the filesystems.but have to implement into the code throuth library access of code itsefl, this are a problm due app must depend of specific fuse lib if lib will change api

 

--
Out of the box experience
http://www.maui-project.org/

--
--
You received this message because you are subscribed to the Google
Groups "Razor-qt" group.
For more options, visit this group at
http://groups.google.com/group/razor-qt?hl=en

---
You received this message because you are subscribed to the Google Groups "Razor-qt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to razor-qt+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Lenz McKAY Gerardo (PICCORO)

http://qglochekone.blogspot.com

[Kevin Krammer]

On Wednesday, 2013-02-20, Pier Luigi wrote:

> What's the advantage of this approach compared to say using Solid to
> enumerate volumes and mount file systems with FUSE?

I guess from a file manager's perspective there is not as much difference as
long as the file manager does all file system access in a thread (in order not
to block when remote file system latency kicks in).
But then again it would probably due that for "normal" mounts like NFS as
well.

Most content display/editing applications make a distinction on how the handle
remote vs. local content and a FUSE mount usually appears as "local", which
can lead to blocking the UI.

One nice thing about GVFS mount daemon is, as far as I understand, that they
do both. I.e. provide asynchronous access API through a socket and FUSE mount
for application's that do not support GVFS directly.

> This is the direction I'm taking with Hawaii file manager and should
> be DE agnostic without even involving wrappers around C code.
>
> Out of curiosity, do you know what was gvfs goal in the first place,
> was FUSE so bad?

One thing that might not be relevant for Hawaii and Razor-Qt is that FUSE is,
as far as I know, a Linux-only technology.

[PICCORO McKAY Lenz]

are irrelevant due razorqt and hawaii are only linux desktops available

On Wed, Feb 20, 2013 at 10:35 AM, Kevin Krammer <anda...@gmail.com> wrote:

One thing that might not be relevant for Hawaii and Razor-Qt is that FUSE is,

as far as I know, a Linux-only technology.

EXCELENT, +

 

[PCMan]

The advantages of using gio/gvfs are:
1. It has full support of "cancelable" async I/O operations. FUSE
supports multi-threading if the backends developed with FUSE implement
it. However, the operations are not cancellable.
2. Many FUSE backends are buggy and no more maintained, such as the
ones for samba.
3. FUSE lack proper UI integration. Most of the existing backends
won't show a dialog asking for username/password, but gio does.
4. gio/gvfs is actively developed and most of the backends work well
5. Using it to enumerate volumes has additional benefit. As everyone
knows, the upstream developers of udisks, upower, and u*everything
likes to break backward compatibility very much. They always enjoy
rewriting everything during every release. I don't want to waste my
time follow the insane changes and fix broken compatibility all the
times. Let them do it. I use their high level wrapper and save the
time to do more important things.
6. Of course, you can argue that fstab, mount, and pure udev works
well, but many existing programs are using udisks/udisks2/policykit.
Using our own implementation causes incompatibility.
7. The only interface to FUSE is via POSIX APIs, but this is quite
limited. In some special cases this is not enough.
8. FUSE itself is stable, but many existing backends are not.
9. glib/gio provides most of the freedesktop.org spec implementations.
10. glib is already there and exists in nearly every system, so why not use it?

Besides, in my file manager, I wrote specialized code for local file
I/O and bypass gio/gvfs layer. So things are faster than ordinary gio
using programs.
This is the rationale behind the whole thing. I'll show you why this
is a good choice later when my program is finished. :-)

[PICCORO McKAY Lenz]

On Wed, Feb 20, 2013 at 11:46 AM, PCMan <pcma...@gmail.com> wrote:

The advantages of using gio/gvfs are:
1. It has full support of "cancelable" async I/O operations. FUSE
supports multi-threading if the backends developed with FUSE implement
it. However, the operations are not cancellable.
2. Many FUSE backends are buggy and no more maintained, such as the
ones for samba.
3. FUSE lack proper UI integration. Most of the existing backends
won't show a dialog asking for username/password, but gio does.

i said before that in "fuse are more unstalbe" an gvfs have more propert insterfaces to implement it on apps, so implement it on any apps are more code to write and less tim to spend.. this its a important point in a development of and app...

 

4. gio/gvfs is actively developed and most of the backends work well
5. Using it to enumerate volumes has additional benefit. As everyone
knows, the upstream developers of udisks, upower, and u*everything
likes to break backward compatibility very much. They always enjoy
rewriting everything during every release. I don't want to waste my
time follow the insane changes and fix broken compatibility all the
times. Let them do it. I use their high level wrapper and save the
time to do more important things.

This its the principal benefic over FUSE, but currently gvfs less that 1.8.0 broke uri's if u not have glib 2.26  or more recently

 

Besides, in my file manager, I wrote specialized code for local file
I/O and bypass gio/gvfs layer. So things are faster than ordinary gio
using programs.
This is the rationale behind the whole thing.

the behabior of local files management in pcmanfm are very good , excelent work. 

[Kevin Krammer]

On Wednesday, 2013-02-20, PICCORO McKAY Lenz wrote:
> On Wed, Feb 20, 2013 at 11:46 AM, PCMan <pcma...@gmail.com> wrote:

> > 4. gio/gvfs is actively developed and most of the backends work well
> > 5. Using it to enumerate volumes has additional benefit. As everyone
> > knows, the upstream developers of udisks, upower, and u*everything
> > likes to break backward compatibility very much. They always enjoy
> > rewriting everything during every release. I don't want to waste my
> > time follow the insane changes and fix broken compatibility all the
> > times. Let them do it. I use their high level wrapper and save the
> > time to do more important things.
>
> This its the principal benefic over FUSE, but currently gvfs less that
> 1.8.0 broke uri's if u not have glib 2.26 or more recently

In Hawaii's case the latter part isn't that problematic since they are using
Solid which also keeps a stable interface above low-level hardware APIs.

[PICCORO McKAY Lenz]

On Wed, Feb 20, 2013 at 12:23 PM, Kevin Krammer <anda...@gmail.com> wrote:

In Hawaii's case the latter part isn't that problematic since they are using

Solid which also keeps a stable interface above low-level hardware APIs.

an spend time in implement it? are easy to doit or require understand u'r work? need more specific close to lib code?

its good that code are easy to implement and time spend cheap, for alive contuinuiting of projects

 

Cheers,
Kevin

--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

[Kevin Krammer]

On Wednesday, 2013-02-20, PICCORO McKAY Lenz wrote:

> On Wed, Feb 20, 2013 at 12:23 PM, Kevin Krammer <anda...@gmail.com> wrote:
> > In Hawaii's case the latter part isn't that problematic since they are
> > using
> > Solid which also keeps a stable interface above low-level hardware APIs.
>
> an spend time in implement it? are easy to doit or require understand u'r
> work? need more specific close to lib code?

I am afraid I don't understand. Spend time implementing what?

> its good that code are easy to implement and time spend cheap, for alive
> contuinuiting of projects

Indeed. Hence the idea of having a stable API and make backends for different
underlying systems.

Cheers,
Kevin

[Евгений Пивнев]

Current packaging state: https://build.opensuse.org/package/show?package=pcmanfm-qt&project=X11%3AQtDesktop%3Atrunk

[PCMan]

Thank you.
You need the latest version of libfm.
The old version accidentally used a C++ keyword in C header file.
So that's why the code cannot compile.
It has been fixed in newer releases of libfm previously.

On Thu, Feb 21, 2013 at 7:04 PM, Евгений Пивнев <ti.e...@gmail.com> wrote:
> Current packaging state:
> https://build.opensuse.org/package/show?package=pcmanfm-qt&project=X11%3AQtDesktop%3Atrunk
>
>>

[PICCORO McKAY Lenz]

On Thu, Feb 21, 2013 at 8:54 AM, PCMan <pcma...@gmail.com> wrote:

Thank you.
You need the latest version of libfm.
The old version accidentally used a C++ keyword in C header file.

that libfm 1.1.0 has this fix?

 

So that's why the code cannot compile.

i cannot compile in qt 4.6 , i' need qt 4.7, I confess that hav'n detailed code either error due I am very busy at work

[PCMan]

Oops,
Qt seems to be more buggy then I think.
QListView with icon mode does not wrap text correctly.
I tried all kinds of possible options, and finally understood that it
does not handle multi-line elided text at all, which Windows 95
already did well 18 years ago.
Now I'm fighting with QStyledItemDelegate to get a workaround.
However, after I inspected the source code of it, I noted that its
behavior laying out item text is quite bizarre and I consider it
broken.
I checked the source code of Dolphin and surprisingly found that they
did not use QListView at all. KDE guys draw their own custom widget.
Wow!
So sad that I'm stucked. :-(
Keep playing with the item delegate stuff. Hope that I can get it done soon.

[Jerome Leclanche]

I'm guessing you hit this issue? http://i.imgur.com/3uusf.png

I'm hoping a solution can be implemented at the Qt level, I think everyone who wrote a file manager has hit it and it's quite infuriating.

J. Leclanche

[Alec Moskvin]

Yep, in multiline mode Qt wraps around the width of the icon... which
makes no sense. And the code is somewhere deep in a private class making
it difficult to override.

I've faced this a few months ago, and I couldn't find a better way to do
it than this: https://github.com/Razor-qt/razor-qt/pull/530

[PCMan]

You're a genius!!
What a simple, effective, and smart fix.
I'm on the wrong path of trying to implement my own sizing/painting.
I even copy/paste some code from qcommonstyle.cpp. :-(
After several hours of hacking, it still doesn't work.
Thank you for the tip! So nice!
It really helps! I'm going to apply this to my file manager.
Thanks a lot!

> --
> --
> You received this message because you are subscribed to the Google
> Groups "Razor-qt" group.
> For more options, visit this group at
> http://groups.google.com/group/razor-qt?hl=en
>
> ---

> You received this message because you are subscribed to a topic in the Google Groups "Razor-qt" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/razor-qt/nJJl5KRsTGU/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to razor-qt+u...@googlegroups.com.

[PICCORO McKAY Lenz]

thanks for clarify alec, grr i'm too busy at work, i'll chek the git
repo at sourgeforce for this change, important for my lenny prt ..
there's no sense for powered machine in using light software.. so
light software are most important to older releases of desktops/linux

> You received this message because you are subscribed to the Google Groups
> "Razor-qt" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to razor-qt+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

[Александр Соколов]

Good program, thanks.

I have comments:

1. Use REQUIRED' argument in the pkg_check_modules 

pkg_check_modules(LIBFM REQUIRED

  glib-2.0

  gio-2.0

  gio-unix-2.0

  libfm

  libstartup-notification-1.0

  x11

)

2. You incorrectly process localized strings at least in the TabPage::onFolderFsInfo - http://i.imgur.com/NWJeCHC.png You should convert localized string to QString through QString::fromLocal8bit.

Please replace

      msg = tr("Free space: %1 (Total: %2)").arg(free_str).arg(total_str);

on

      msg = tr("Free space: %1 (Total: %2)").arg(QString::fromLocal8Bit(free_str)).arg(QString::fromLocal8Bit(total_str));

3. In the pacmanfm.cpp I found next comment

  // TODO: implement single instance

  // 1. use dbus?

  // 2. Try QtSingleApplication http://doc.qt.digia.com/solutions/4/qtsingleapplication/qtsingleapplication.html

Why you want to have single instance for file manager?

4. IMHO If you disable a border around a sidePane interface will be cleaner.

with border - http://i.imgur.com/RHMgw0J.png

witout border - http://i.imgur.com/EHZZ5zL.png

I can prepare the pull requests but I dont't know how to send it on sourceforge. Throught email?

P.S. The libfm is a library, so maybe libfm-qt should be library too? Qt wrapper library under libfm. But program should be called pacman-qt?

2013/2/23 PICCORO McKAY Lenz <mckayg...@gmail.com>

--
Best regards,
Alexander.

[PICCORO McKAY Lenz]

On Sun, Feb 24, 2013 at 1:48 AM, Александр Соколов <sokol...@gmail.com> wrote:

Good program, thanks.

I have comments:

1. Use REQUIRED' argument in the pkg_check_modules 

pkg_check_modules(LIBFM REQUIRED

  glib-2.0

  gio-2.0

  gio-unix-2.0

  libfm

  libstartup-notification-1.0

  x11

)

gio-unix-2.0 ? why

 

3. In the pacmanfm.cpp I found next comment

  // TODO: implement single instance

  // 1. use dbus?

  // 2. Try QtSingleApplication http://doc.qt.digia.com/solutions/4/qtsingleapplication/qtsingleapplication.html

Why you want to have single instance for file manager?

must be due threath mnagement... in the GTK version theres tow king of process, one instance for desktop managemen and the rest for file management.. all derved forn one process and multiple instances in group, so i thionk the qt version will conflict with the destop management instance

 

P.S. The libfm is a library, so maybe libfm-qt should be library too? Qt wrapper library under libfm. But program should be called pacman-qt?

i dont thinkso, due pcmanfm-qt used libfm, so libfm-qt its obviosly will use libfm core

[PCMan]

Thank you for the tip! I already fix them.
About single instance, I finally did it with dbus.
Single instance really helps for a file manager, especially when you
manages the desktop icons. Every new window opened will be in the same
process so all cached resources are shared. This has speed and memory
advantages.
If you manage the desktop icons with the file manager, it will be
running till logout.
Opening new windows after the first one becomes much more faster.
So single instance really makes sense for a file manager.

BTW, the latest code in my git repo already has very primitive desktop
icons support.
Turnning it on with "pcmanfm-qt --desktop", just like in the gtk+ version.

There will be libfm-qt library which can be used in other qt programs.
It will be a thin wrapper of libfm core C library.
I haven't build the library because the API/ABI is not yet stable and
I'm not familiar with cmake. lol

If you have your own git clone, just give me the url.
I can pull your changes manually.
Thank you very much!

[PICCORO McKAY Lenz]

On Sun, Feb 24, 2013 at 1:19 PM, PCMan <pcma...@gmail.com> wrote:

Thank you for the tip! I already fix them.
About single instance, I finally did it with dbus.
Single instance really helps for a file manager, especially when you
manages the desktop icons. Every new window opened will be in the same
process so all cached resources are shared. This has speed and memory
advantages.

hell yeah, but one question, its possible that qt and GTK verson can be intalled nd running at same time.. if both turn on desktop primitive manage obviously not, but if desktop manage can be handled by libfm core, both this made a powered library to implemented..

and for instances , a group management of running process will improve stability for better OS comunication an priority assing (like java does in threath group), for memory consuption handling