PCManFM Qt 0.1.0 released.

1,514 views
Skip to first unread message

PCMan

unread,
Mar 25, 2013, 10:42:06 PM3/25/13
to pcmanfm-develop, lxde-list, razo...@googlegroups.com, lubuntu user list
Hello world,
I just released PCManFM Qt file manager 0.1.0.
The tarball is available for download here.

http://sourceforge.net/projects/pcmanfm/files/PCManFM%20%2B%20Libfm%20%28tarball%20release%29/

You'll need libfm to build it (which is included in many distros).

This release contains no thumbnail support.
However a fully working thumbnail support is already in the git.
Because this requires some changes to the upstream libfm library,
it's scheduled for the next release and not make public at the moment.

To turn on the desktop icon management feature, run with the command:
> pcmanfm-qt --desktop

Generally it's a good idea to add this command to your session startup script.

To turn the desktop icon manager off again, do this:
> pcmanfm-qt --desktop-off

If you don't want to use the desktop icons, you can still add the
command to your session startup script:
> pcmanfm-qt --daemon

In this way, it will becomes a background daemon. Every time you need
to open a folder with pcmanfm-qt, it can be shown "immediately".

Thank you.

Jerome Leclanche

unread,
Mar 26, 2013, 9:25:45 AM3/26/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list, lubuntu user list
Thanks, this is brilliant.

Some early feedback; I'm guessing you're aware of most of it:

 - UX for when going to a directory that doesn't exist is pretty bad; I would suggest graying out the background and either an infobar or a chrome-style error message with a button to create the directory.
 - "Operation is not supported" on the gvfs stuff: the icons should be hidden or grayed out if they are unusable.
 - My cursor gets stuck to the "Waiting..." cursor after clicking about in the left panel.
 - Please implement zooming in/out with ctrl mousewheel and ctrl+/- :)
 - Applications in Open With / Properties have no icons
 - There's no way to permanently delete a file without moving it to the trash (shift-del)
 - "Open with pcmanfm-qt" on directories makes no sense :-)
 - Should be able to open directories in new tabs (ctrl+dblclick / rightclick->open in new tab)
 - Compress menu item doesn't do anything
 - Any way to filter current directory? (ctrl+f foo and only the matching items stay)

Very cool stuff otherwise. I love that we have quite a few solid qt file managers now :)

J. Leclanche



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



PICCORO McKAY Lenz

unread,
Mar 26, 2013, 10:41:48 AM3/26/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list, lubuntu user list
We have a rock solid DECENT file manager.. 

i have only one question:
> pcmanfm-qt --desktop
can work with pcmanfm GTK vesion?

great work, take in consideration jerome, that the developer pcman are not a programer, its a dmedician.. honor! 
--
Lenz McKAY Gerardo (PICCORO)

pcma...@gmail.com

unread,
Mar 26, 2013, 12:00:04 PM3/26/13
to razo...@googlegroups.com, pcmanfm-develop
Really thank you for the quick feedback.

Jerome Leclanche於 2013年3月26日星期二UTC+8下午9時25分45秒寫道:
Thanks, this is brilliant.

Some early feedback; I'm guessing you're aware of most of it:

 - UX for when going to a directory that doesn't exist is pretty bad; I would suggest graying out the background and either an infobar or a chrome-style error message with a button to create the directory.

I'll consider improving this later. For now, I mostly copied the gtk+ version and did not redesign the UI too much.
 
 - "Operation is not supported" on the gvfs stuff: the icons should be hidden or grayed out if they are unusable.
Indeed. You mean the trash can and computer:///?
 
 - My cursor gets stuck to the "Waiting..." cursor after clicking about in the left panel.

Weird, I cannot reproduce this. Any way to reproduce it? The Qt theme you used?
 
 - Please implement zooming in/out with ctrl mousewheel and ctrl+/- :)
Well, I need to figure out a better way to do it.
 
 - Applications in Open With / Properties have no icons
Actually, there should be icons and I wrote code for it.
I have icons here. So weird. What icon theme are you using now?
 
 - There's no way to permanently delete a file without moving it to the trash (shift-del)
I forgot to do it.
Actually, I don't know how to add a "shortcut key" to a window without adding the action to the main menu.
I tried QShortcut but it does not work. I did not find enough documents for it. Help is needed.
 
 - "Open with pcmanfm-qt" on directories makes no sense :-)
Oops, maybe a small check is needed to ensure we don't show our own desktop entry files in the menu.
 
 - Should be able to open directories in new tabs (ctrl+dblclick / rightclick->open in new tab)
I forgot to do this. :(
 
 - Compress menu item doesn't do anything
Open the preferences dialog, go to the "advanced" page, and choose an archiver there.
However, this should really be improved and a sensible default should be set.
Oops, I forgot to add Qt-based file archivers. Do you know good Qt archivers except for ark and peazip?
 
 - Any way to filter current directory? (ctrl+f foo and only the matching items stay)
The feature is provided in the latest Gtk+ version, but I haven't port it to Qt version yet. 
 
Very cool stuff otherwise. I love that we have quite a few solid qt file managers now :)
Thank you. I tried Razor-Qt recently and like it too. :-)
Though I'm from the LXDE camp, the aim of LXDE project is to provide lightweight programs 
for X and nobody says it should be gtk+ only. Personally I'm willing to try Qt when applicable.
This is my first attempt and I just begin learning Qt. So help is really wanted and patches are welcomed.

Regards

pcma...@gmail.com

unread,
Mar 26, 2013, 12:03:08 PM3/26/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list, lubuntu user list


PICCORO Lenz McKAY於 2013年3月26日星期二UTC+8下午10時41分48秒寫道:
We have a rock solid DECENT file manager.. 

i have only one question:
> pcmanfm-qt --desktop
can work with pcmanfm GTK vesion?

The Qt version and gtk+ version use different names/paths for binary programs and config files.
So it's safe to install them both and even running both of them at the same time.
The desktop manager, however, should only be launched from one of them.
The behavior of that desktop icon manager is creating a full screen widget covering the whole root window and paint on it.
Although you can launch both of them, only one of them can be visible at a time.
Thanks!

Petr Vanek

unread,
Mar 27, 2013, 7:53:39 AM3/27/13
to razo...@googlegroups.com
hi,
I tried pcmanfm-qt finally today. And I can find it very promissing.

I'm also interested in "proof of concept" to repalce feature lacking  Razor's icon view desktop plugin with libfm implementation. Can we arrange some small talk about basic code organization, please?


ad pcmanfm-qt test: I face 2 issues now:

1) RPM packaging showstopper (patching workaround required): installation on RPM 64bit distro - libs are expected in lib64 directory. It's isually done by cmake variable LIB_SUFFIX in libfm-qt/CMakeLists.txt

from:
install(TARGETS fm-qt
  LIBRARY DESTINATION lib
  PUBLIC_HEADER
)

to:
install(TARGETS fm-qt
  LIBRARY DESTINATION lib${LIB_SUFFIX}
  PUBLIC_HEADER
)

there are also code snippets how to autodetect it (eg. in our Razor's git).


2) an instant crash clicking on "Applications" item/menu. Unfortunately it's in libs where I have no debug symbols...

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7fffee1d2700 (LWP 7955)]
0x00007ffff5d429b7 in g_logv () from /usr/lib64/libglib-2.0.so.0
(gdb) bt
#0  0x00007ffff5d429b7 in g_logv () from /usr/lib64/libglib-2.0.so.0
#1  0x00007ffff5d42b82 in g_log () from /usr/lib64/libglib-2.0.so.0
#2  0x00007ffff23598b3 in ?? () from /usr/lib64/libmenu-cache.so.2
#3  0x00007ffff235995d in ?? () from /usr/lib64/libmenu-cache.so.2
#4  0x00007ffff5d5f345 in ?? () from /usr/lib64/libglib-2.0.so.0
#5  0x00007ffff4976e0f in start_thread () from /lib64/libpthread.so.0
#6  0x00007ffff4c737dd in clone () from /lib64/libc.so.6


cheers,
petr

On 03/26/2013 05:03 PM, pcma...@gmail.com wrote:


PICCORO Lenz McKAY嚙踝蕭 2013嚙羯3嚙踝蕭26嚙踝蕭P嚙踝蕭嚙瘦UTC+8嚙磊嚙踝蕭10嚙踝蕭41嚙踝蕭48嚙踝蕭g嚙瘩嚙瘦

pcma...@gmail.com

unread,
Mar 27, 2013, 12:49:18 PM3/27/13
to razo...@googlegroups.com
Petr Vanek於 2013年3月27日星期三UTC+8下午7時53分39秒寫道:

hi,
I tried pcmanfm-qt finally today. And I can find it very promissing.

I'm also interested in "proof of concept" to repalce feature lacking  Razor's icon view desktop plugin with libfm implementation. Can we arrange some small talk about basic code organization, please?

You mean the code organization of PCManFM-Qt/Libfm-Qt?
Of course. The core libfm library in C language is well-documented, but the C++ part is not.
Well, I did my best to make the source code easier to understand.
There are some parts, however, containing mixed C/GObject and C++ code.
I'm quite OK with it since I used C/GObject quite often, but some C++ lovers might find it a little bit weird. :-)
I'm on a vacation tomorrow and will be back 5 days later. I'll try to improve it a little then.

ad pcmanfm-qt test: I face 2 issues now:

1) RPM packaging showstopper (patching workaround required): installation on RPM 64bit distro - libs are expected in lib64 directory. It's isually done by cmake variable LIB_SUFFIX in libfm-qt/CMakeLists.txt

from:
install(TARGETS fm-qt
  LIBRARY DESTINATION lib
  PUBLIC_HEADER
)

to:
install(TARGETS fm-qt
  LIBRARY DESTINATION lib${LIB_SUFFIX}
  PUBLIC_HEADER
)

there are also code snippets how to autodetect it (eg. in our Razor's git).

Thank you very much for the tip.
I'll fix this later.
 


2) an instant crash clicking on "Applications" item/menu. Unfortunately it's in libs where I have no debug symbols...

Oops, I don't really know what happens here. Maybe installing lxmenu-data package fix it. However it should not crash even when the application menu data files are abscent. :-(
Theoratically it should show the xdg application menu in a folder view, similar to what Mac OS X Finder does.
There must be something wrong here. I need to debug this later.

Jerome Leclanche

unread,
Mar 28, 2013, 7:18:41 AM3/28/13
to razo...@googlegroups.com
Could you avoid registering x-directory/normal in pcmanfm-qt.desktop? It's been deprecated for years :)

J. Leclanche

PICCORO McKAY Lenz

unread,
Mar 28, 2013, 11:24:34 PM3/28/13
to razo...@googlegroups.com
umm but for me was usefully in lenny... as happen with gtk version..
that still work inclusivelly in etch, lkxde and pcmanfm are the only
desktop taht work in EVERY version of desktop linux or machine...

but in any case, one day will be removed no?
>>> 2013嚙羯3嚙踝蕭26嚙踝蕭P嚙踝蕭嚙瘦UTC+**8嚙磊嚙踝蕭10嚙踝蕭41嚙踝蕭48嚙踝蕭g嚙瘩嚙瘦
>>>>>> http://sourceforge.net/**projects/pcmanfm/files/**
>>>>>> PCManFM%20%2B%20Libfm%20%**28tarball%20release%29/<http://sourceforge.net/projects/pcmanfm/files/PCManFM%20%2B%20Libfm%20%28tarball%20release%29/>
>>>>>>
>>>>>> You'll need libfm to build it (which is included in many distros).
>>>>>>
>>>>>> This release contains no thumbnail support.
>>>>>> However a fully working thumbnail support is already in the git.
>>>>>> Because this requires some changes to the upstream libfm library,
>>>>>> it's scheduled for the next release and not make public at the
>>>>>> moment.
>>>>>>
>>>>>> To turn on the desktop icon management feature, run with the command:
>>>>>> > pcmanfm-qt --desktop
>>>>>>
>>>>>> Generally it's a good idea to add this command to your session
>>>>>> startup
>>>>>> script.
>>>>>>
>>>>>> To turn the desktop icon manager off again, do this:
>>>>>> > pcmanfm-qt --desktop-off
>>>>>>
>>>>>> If you don't want to use the desktop icons, you can still add the
>>>>>> command to your session startup script:
>>>>>> > pcmanfm-qt --daemon
>>>>>>
>>>>>> In this way, it will becomes a background daemon. Every time you need
>>>>>> to open a folder with pcmanfm-qt, it can be shown "immediately".
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> 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<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<https://groups.google.com/groups/opt_out>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> --
>>>>> 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<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<https://groups.google.com/groups/opt_out>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lenz McKAY Gerardo (PICCORO)
>>>> http://qglochekone.blogspot.**com <http://qglochekone.blogspot.com>
>>>>
>>> --
>>> --
>>> 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<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<https://groups.google.com/groups/opt_out>
>>> .

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

unread,
Mar 31, 2013, 5:10:38 AM3/31/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list, lubuntu user list
Please create pcmanfm-qt git.
Source below differes from sf git content.

akar...@gmail.com

unread,
Apr 17, 2013, 5:55:06 AM4/17/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list, lubuntu user list
hi PCMAN,

i add these lines(and one delcare in .h) to mainwindow.cpp for support path-entry focusing shortcuts
.
void MainWindow::keyReleaseEvent(QKeyEvent *event) {
   
    Qt::Key key = static_cast<Qt::Key>(event->key());
    Qt::KeyboardModifiers modifiers = event->modifiers();
    if((modifiers == Qt::ControlModifier && key == Qt::Key_L) ||
       (modifiers == Qt::AltModifier && key == Qt::Key_D)) {
       
        pathEntry->setFocus();
        pathEntry->selectAll();
    }
}

,and BTW, console arguments doesn't work, i add these lines
for my very own use:
    for (int i = 1; i < argc; ++i) {
      if(strcmp(argv[1],"--desktop") == 0)
        desktop = true;
      else if(strcmp(argv[1],"--daemon-mode") == 0)
        daemon_mode = true;
    }
#which should be "daemon_mode" not "daemon" in code it says.

regards,
AKar

Andrej N. Gritsenko

unread,
Apr 22, 2013, 4:30:10 PM4/22/13
to pcmanfm-develop, lxde-list, razo...@googlegroups.com
Hello!

PCMan have written on Tuesday, 26 March, at 10:42:
>Hello world,
>I just released PCManFM Qt file manager 0.1.0.
>The tarball is available for download here.

I never looked into razor-qt before and I wasn't aware such DE even
exists but now that I looked into its site I've found out some conceptual
similarities with LXDE. And I've got some crazy idea. Since libfm/pcmanfm
has Qt port already and LXDE as whole has too few active developers, it
might be reasonable to join projects (razor-qt and LXDE), i.e. port to Qt
rest of LXDE components so LXDE will be based on Qt instead of GTK and
razor-qt will get few missing applications as well. It's a crazy idea, I
know, and may be even silly one, I just got that thought and decided to
write it out loud. :)
I never did comparizon on resourses consumption between pcmanfm GTK
and Qt versions though, it should be done somehow sometime. And if Qt is
more lightweight than GTK then... you know. :)
The only problem is that GTK is C but Qt is C++...

Cheers!
Andriy.

PCMan

unread,
Apr 23, 2013, 1:04:05 AM4/23/13
to pcmanfm-develop, lxde-list, razo...@googlegroups.com
Thank you guys very much for the proposal. It's not crazy at all.
The proposal is very practical. Actually, it's also what I'm thinking about now.
As the lead developer and founder of a some what famous DE, it's
really hard for me to say this. Even I personally found that using Qt
is much more productive and I already tested razor-qt for a while, I
felt that we should not abandon our LXDE users/supporters.
Politically, we belongs to the Gtk+ camp and moving toward Qt will
make some supporters disappointed. Technically, porting to Qt is much
easier than it looks like.
It only took me 1 - 2 months to port 90% of the functionality of pcmanfm to Qt.
So porting all other LXDE components to Qt is applicable and practical.
I've been evaluating razor-qt for months. I followed up the project
regularly and joined their mailing list. It has very similar goals
with us and its development is really rapid.
After months it's nearly complete now and contains even much more stuff than us.
The infrastructure and library APIs are also well designed.
So personally I like razor-qt very much and admire their work.
Resource usage is a little more than ours, but that's understandable
because it has more features.
Free software is all about choice, but too many choices is not always good.
Diversity is nice, but having duplicated work with the only
differences in GUI toolkits is non-sense. This only creates
unnecessary divergence and waste precious man power.
Since we have the same goals, merging the effort is reasonable.
Though the future of Qt is uncertain (will Digia sell it someday?), it
still has many supporters and ubuntu is moving toward Qt. Currently,
Gnome 3 seems to be the only user of gtk+3. XFCE2 is using gtk2 and
they're also suffering from the painful porting.
Gtk2 seems to be lighter than Qt in some cases, but it's no longer
true for gtk3.
Besides, it's KDE that's bloat, not Qt. Compared with gtk+, Qt
contains much more than just GUI widgets. It also offers xml parsers,
database supports, network stuff, and even webkit support. With gtk+,
you need to install many other libraries for these but with Qt they're
built-in. That explains the bigger library size. So it's not really
bloat.

To sum up, if our developers and users are willing to joint the effort
and help razor-qt instead of mirrors what they have with gtk+, I'm not
against the idea.
Instead of having two incomplete DEs, at least we can have a really good one.
For those who get used to gtk+, learning C++ and Qt is much easier
than learning GObject. I started porting pcmanfm to Qt immediately
after reading the Qt tutorial and "hello world".
Maybe a vote is needed for this issue?
Comments are wanted, please.

gary sheppard

unread,
Apr 23, 2013, 2:13:01 AM4/23/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list
I have to admit, this sounds very good.


Petr Vaněk

unread,
Apr 23, 2013, 5:10:00 AM4/23/13
to razo...@googlegroups.com, PCMan, pcmanfm-develop

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi all,

I had some free time again (finally) so here comes another goodie of
"cross desktop summit":

Raw and hacked pcmanfm-qt as a razor desktop plugin. See my
first-time-compiled-and-non-crashing environment in this screenshot:

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

notes:
- I'm using gray background as a "debug" to see plugin location/size
- I did not use all libfm-qt bells and whistles, only the file opening
works now.
- I did not measure anything - like memory usage, system startup time
(well, *everything* will be faster than my original icon view
implementation IMHO), or CPU.
- source code is full of hack to make it compile/working

Razors, I'd like to know your opinion about it. For me it's much easier
to use production ready backend for this task. On the other side it
would bring new dependencies: libfm (glib stack), libfm-qt. Also some of
our coding standards should be changed a bit becasue mixing qlib and Qt
introduces some naming clash so we should ise Q_SIGNALS instead of
signals then (only razorsettings.h would be affected for now).

But for me - it's clear sign to GO ;)

thanks,
petr

On 3/26/13 3:42 AM, PCMan wrote:


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRdk/oAAoJEC8yRjM4uE2tsFwH/35GShm5VTfWizpXBAxp+P0b
ac1q29GW5/jqL9DVBarrTu91GkdseXNF8yFcpIq/Y2M/dg1qDgtjT/KqS44AkTQV
kVJauup3bbASd7kbixlN75hQKULUZwmVXipd8IIfG+ArCwtQrWhke6I4f+u+sixP
x1imVl6ev2G05+ZQmoob46K12GcQqoc0UBpbtHa0eqxbnxHJwEH/th50f7ZEPD5l
zzkvg0CVDoA47gCz82ga4maVWNH6ERcG8tbX7H9BZwDk7KeSR4dgSdBm8Y1FsvSt
fzbY4Ik2uSV/dGgKjejDnGhTnR9A3rqleSYjAcP60IvhyPZpUlEqnhuZb9iM28E=
=mB9U
-----END PGP SIGNATURE-----

Andrej N. Gritsenko

unread,
Apr 23, 2013, 6:44:52 AM4/23/13
to pcmanfm-develop, lxde-list, razo...@googlegroups.com
Hello!

PCMan has written on Tuesday, 23 April, at 13:04:
>On Tue, Apr 23, 2013 at 4:30 AM, Andrej N. Gritsenko <and...@rep.kiev.ua> wrote:

>> I never looked into razor-qt before and I wasn't aware such DE even
>> exists but now that I looked into its site I've found out some conceptual
>> similarities with LXDE. And I've got some crazy idea. Since libfm/pcmanfm
>> has Qt port already and LXDE as whole has too few active developers, it
>> might be reasonable to join projects (razor-qt and LXDE), i.e. port to Qt
>> rest of LXDE components so LXDE will be based on Qt instead of GTK and
>> razor-qt will get few missing applications as well. It's a crazy idea, I
>> know, and may be even silly one, I just got that thought and decided to
>> write it out loud. :)
>> I never did comparizon on resourses consumption between pcmanfm GTK
>> and Qt versions though, it should be done somehow sometime. And if Qt is
>> more lightweight than GTK then... you know. :)
>> The only problem is that GTK is C but Qt is C++...

>Thank you guys very much for the proposal. It's not crazy at all.
>The proposal is very practical. Actually, it's also what I'm thinking about now.
>As the lead developer and founder of a some what famous DE, it's
>really hard for me to say this. Even I personally found that using Qt
>is much more productive and I already tested razor-qt for a while, I
>felt that we should not abandon our LXDE users/supporters.
>Politically, we belongs to the Gtk+ camp and moving toward Qt will
>make some supporters disappointed. Technically, porting to Qt is much
>easier than it looks like.

Well, that shouldn't be too big problem. I believe it shouldn't take
too much efforts to support both GTK2 and Qt versions to honor GTK2 users.
Why I don't talk about GTK3? Many of you know GTK3 is a lot more buggy
and resourse consuming. And less of you know about another GTK3 problem:
they tend to change APIs too much and too fast. For example, last night I
did researches to implement some new plugin into libfm-gtk. And what I
see? Let's say, class GtkVBox. In GTK 3.0 they've marked it deprecated
and suggested to use newly created GtkBox. In GTK 3.2 they've created new
GtkGrid class and in 3.4 they've deprecated GtkBox as well telling to use
GtkGrid. What will be next? They deprecate GtkGrid in a year or too? So
who knows if applications designed for GTK 3.0 can be even compiled in
mere year or two without lots of workarounds and conditionals? I wouldn't
be so sure. But what about Qt, BTW, is its API somewhat stable? At least
I strongly want libfm to be compatible with libraries of year 2010 - it's
glib 2.22 for example. The Qt was 4.5.4 at that time. Is it possible or
hard to have things compatible with both Qt 4.5.4 and with latest one?

>To sum up, if our developers and users are willing to joint the effort
>and help razor-qt instead of mirrors what they have with gtk+, I'm not
>against the idea.

At least I appreciate your work on libfm/pcmanfm Qt port, it is great
thing. And as soon I finish my work on libfm/pcmanfm 1.2 (there are a lot
of features to implement in my TODO list, there are few bugreports in the
tracker and a lot of (currently 101) tickets in FR tracker that I want to
close by implementations in 1.2, at least 80% of them), I think we can do
comparizon together and add all missing things into Qt port.

>Instead of having two incomplete DEs, at least we can have a really good one.

Exactly my thoughts. :)

>For those who get used to gtk+, learning C++ and Qt is much easier
>than learning GObject. I started porting pcmanfm to Qt immediately
>after reading the Qt tutorial and "hello world".
>Maybe a vote is needed for this issue?
>Comments are wanted, please.

With the best wishes.
Andriy.

Kevin Krammer

unread,
Apr 23, 2013, 6:55:58 AM4/23/13
to razo...@googlegroups.com
On Tuesday, 2013-04-23, PCMan wrote:
> Compared with gtk+, Qt
> contains much more than just GUI widgets. It also offers xml parsers,
> database supports, network stuff, and even webkit support. With gtk+,
> you need to install many other libraries for these but with Qt they're
> built-in. That explains the bigger library size.

To be more precise: Qt is also a set of individual libraries, the difference
is that one can get them from the same source.

A lot of size or dependency fear is based on misconceptions based on how Qt
was structured in Qt3 times. Since Qt4 applications only need to link with and
depend on Qt modules that they actually use, e.g. only link QtCore and
QNetwork for a network server program.

Cheers,
Kevin

--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc

Andrej N. Gritsenko

unread,
Apr 23, 2013, 7:56:56 AM4/23/13
to pcmanfm...@lists.sourceforge.net, lxde...@lists.sourceforge.net, razo...@googlegroups.com
Hello!

Stephan Sokolow has written on Tuesday, 23 April, at 2:19:
>On 13-04-23 01:14 AM, PCMan wrote:
>> Audacious is really perfect. However, it's core library is tight with
>> Gtk+, so porting to Qt is quite difficult. I studied this earlier and
>> had the conclusion.
>> Fortunately, there are several nice Qt music players.
>> Qmmp if you like WinAmp UI.
>> Clementine is also a nice one.
>> If you prefer xmms2, there exists some Qt UI frontends for it which
>> are lightweight.

>Unfortunately, I've already looked and been unable to find anything else
>with the wide format and feature support I require.

I should agree with you and I still stick with Audacious and I will.

>>> (And I do already have a fair few Qt apps. KRename, Filelight since
>>> Baobab's radial view is a lazy afterthought, K3b since others are too
>>> crash-happy or too spartan, Okular since Lubuntu's Evince doesn't do CHM
>>> or offer bitmap/screenshot select-to-clipboard for PDF, GoldenDict, LyX,
>>> and Skype, for example.)

>> There exists many nice independent Qt applications.
>> What they need is polishing, advertising, and grouped together.
>> Just like what we did with LXDE, we can group some nice independent Qt
>> apps as well.

>For example, GoldenDict and LyX. The only major KDE applications I
>really need are K3b, Tellico, and KDiff3... though I do like Okular much
>more than ChmSee or xchm for reading CHM files.

Despite the fact Openbox is my favourite WM and I'm using PCManFM
(it's why I've started to polish it in the first place) and Lxpanel (I
found no alternative so far - all other are either incomplete or too
bloated) I just cannot use my desktop without KDE/Qt applications: it's
Konsole (which still is the best terminal program - full featured and
bugless) and Kmix - the best tray mixer application with built-in keys
support I ever seen. So I'm using Qt always anyway. Another application
that I always use is Firefox. Other are used less often but some of them
are GTK and some are Qt. So my desktop is always mixed and I don't think
it's a bad thing as far they can coexist.

>> As the founder of the project, emotionally I'm a little bit reluctant
>> to replace our work with others'. However, from the perspective of the
>> whole free software community, merging the effort rather than
>> divergence brings much more benefit to the world. So I support the
>> change. :-)

>I perfectly agree with the sentiment. One of my many "if I can ever find
>the time" projects is to investigate the "rarfile" Python module as a
>possible successor to my rar.py. (A partially-finished module for
>listing files in rar archives without depending on the rar/unrar
>binaries or linking against a GPL-incompatible library.)

It's why merging teams together means not just adding efforts but
somehow multiply them and we could have much better desktop than if we
just implement something in parallel. At least I think so. :)

Cheers!
Andriy.

Alec Moskvin

unread,
Apr 23, 2013, 8:50:42 AM4/23/13
to razo...@googlegroups.com, Petr Vaněk, PCMan, pcmanfm-develop
Can it be it be made a separate package with RPM/DEB? If yes, then I don't see a problem. (And if not, then we can always fix that before the next release :)

--
Sent from my phone. Please excuse my brevity.

Abdurrahman AVCI

unread,
Apr 23, 2013, 4:39:40 PM4/23/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list
Hi,

23 Nisan 2013 Salı 10:44:52 UTC tarihinde Andriy G yazdı:

Qt doesn't break API or ABI compatility within the lifetime of a major release.
So, conceptually if you have a program that compiled with Qt 4.0 (circa 2005),
it should compile fine with Qt 4.8.4, the latest Qt4 release. Only new stuff
added during minor releases, nothing removed or broken.

In fact Qt5 doesn't break the API much either, so you can have an application
that compiles with Qt4 and Qt5 with minimal ifdefs.
 

Kuzma Shapran

unread,
Apr 23, 2013, 5:56:50 PM4/23/13
to razo...@googlegroups.com, Petr Vaněk, PCMan, pcmanfm-develop
It's the first thing I thought - ability to make plugins outside of Razor's source code. I hope it can be relatively easy for panel plugins - thanks to the new API, and then the next step - desktop plugins.

Andrej N. Gritsenko

unread,
Apr 24, 2013, 9:55:28 AM4/24/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list
Hello!

Abdurrahman AVCI has written on Tuesday, 23 April, at 13:39:
>23 Nisan 2013 Salı 10:44:52 UTC tarihinde Andriy G yazdı:
Thank you very much for clarification. That's great thing for the
development and application life.

>> >Instead of having two incomplete DEs, at least we can have a really good
>> one.

>> Exactly my thoughts. :)

So what do we have now? I would like to hear from razor-qt guys what
they think about the idea to merge our efforts and teams to make LXDE and
razor-qt camps the one. I mean LXDE and razor-qt to be similar things but
just based on different toolkits - GTK2 for LXDE and Qt for razor-qt.
This way the razor guys will affect quality of GTK2 versions and lxde
guys will give Qt versions of missing parts (file manager for example).
As I said a bit earlier, two teams together is definitely more than just
sum of two and you all know that.

PICCORO Lenz McKAY

unread,
Apr 24, 2013, 10:05:08 AM4/24/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list

On Tue, Apr 23, 2013 at 4:30 AM, Andrej N. Gritsenko <and...@rep.kiev.ua> wrote: 
    The only problem is that GTK is C but Qt is C++... 

This are the reason why QT ar few more heavy than other, but also the reason why are more easy to devel in it

On Th, 23 apr 2013 00:34:05 UTC-4:30, PCMan wrote:
Instead of having two incomplete DEs, at least we can have a really good one.


Let's face it, with this, the users who will benefit will be those of "razorqt" since LXDE hav many things (although come from third-party programs) working, plus LXDE only consumes between 80 and 160 Mb, while due scale of qt4/qt5 framework razorqt obviously needs more resources (significative more)...

in linux have ram and cpu cycles is everything .. since in Linux everything is a file (access I / O, vs cpu cycles) and that affects the ram consumption


for razorqt this are the best notice in years... truly... for lxde relateds, this are only a plus....

Alexis López Zubieta

unread,
Apr 24, 2013, 3:31:56 PM4/24/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list
Hello everyone:

I'm a student of informatics sciences in the University of Informatics Sciences of Cuba. I belong to a free software project that aims to provide to the cuban user a stable, functional and lightweight operative system. We have been working on it for a while and recently we made our 4th release. We use as desktop environment a fork of LXDE that we call "Guano" but as we are a reduced team (6 members only) the balance between productivity and time is crucial to us. In this aspect the combination of C and Gtk don't show the best numbers, so we where studding the possibility of creating our on lightweight desktop environment in order to improve the architecture of LXDE and make it more scalable, functional and integrated. But is not wise to start another project and duplicate efforts, instead of that we want to join forces with you to create a fully functional and lightweight desktop environment.

We have done some research and we have some ideas and workforce that could be useful to the cause. In my opinion we must gather and plan the next step in order to make this transition quick and clean. I propose to start a new thread in both mailing lists and coordinate a live chat meeting.

Waiting for your opinion


--

University of Informatic Sciences (UCI) http://www.uci.cu
Nova Light Development Team http://www.nova.cu
Alexis López Zubieta azub...@estudiantes.uci.cu

 




Andrej N. Gritsenko

unread,
Apr 24, 2013, 4:59:03 PM4/24/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list
Hello!

Alexis López Zubieta has written on Wednesday, 24 April, at 15:31:
>I'm a student of informatics sciences in the University of Informatics
>Sciences of Cuba. I belong to a free software project that aims to
>provide to the cuban user a stable, functional and lightweight operative
>system. We have been working on it for a while and recently we made our
>4th release. We use as desktop environment a fork of LXDE that we call
>"Guano" but as we are a reduced team (6 members only) the balance
>between productivity and time is crucial to us. In this aspect the
>combination of C and Gtk don't show the best numbers, so we where
>studding the possibility of creating our on lightweight desktop
>environment in order to improve the architecture of LXDE and make it
>more scalable, functional and integrated. But is not wise to start
>another project and duplicate efforts, instead of that we want to join
>forces with you to create a fully functional and lightweight desktop
>environment.

>We have done some research and we have some ideas and workforce that
>could be useful to the cause. In my opinion we must gather and plan the
>next step in order to make this transition quick and clean. I propose to
>start a new thread in both mailing lists and coordinate a live chat meeting.

>Waiting for your opinion

This would be just wonderful to have you joining forces. I've started
the thread with idea to join forces with razor-qt team. In case someone
doesn't know, I'm the main developer of libfm and pcmanfm at the time
being, mainly because PCMan has a lot less time and I have much more and
I have interest in making it. Yes, I'm working with GTK but last time we
found out that making it compatible with such fast changing GTK3 doesn't
worth all the efforts. Therefore Qt looks like as viable alternative for
another toolkit instead of GTK3 and PCMan started his experiments with Qt
and it is what libfm-qt / pcmanfm-qt are. Yes, I can handle all bugs and
feature requests for libfm / pcmanfm alone, but what with another LXDE
components? LXDE team has very few developers. But since razor-qt has not
too many developers too and they have the same goals (not build monstrous
integrated complex but rather a desktop toolkit) I think it would be
beneficial for both teams to join forces. And since you want something
alike, that sound very promicing. But we should get razor-qt voices first
I believe. From LXDE side - I and PCMan support the idea, some other
developers aren't sure yet.

Andriy.

gary sheppard

unread,
Apr 24, 2013, 5:32:04 PM4/24/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list
From and End User point of view, I really hope all of you do decide to co-operate!

Best Wishes


Petr Vaněk

unread,
Apr 25, 2013, 10:11:45 AM4/25/13
to razo...@googlegroups.com, pcmanfm-develop, Lxde...@lists.sourceforge.net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi all,
I'm one of Razor committers.

On 4/24/13 10:59 PM, Andrej N. Gritsenko wrote:
> This would be just wonderful to have you joining forces. I've started the thread with idea to join
forces with razor-qt team. In case someone doesn't know, I'm the main
developer of libfm and pcmanfm at the time being, mainly because PCMan
has a lot less time and I have much more and I have interest in making
it. Yes, I'm working with GTK but last time we found out that making it
compatible with such fast changing GTK3 doesn't worth all the efforts.
Therefore Qt looks like as viable alternative for another toolkit
instead of GTK3 and PCMan started his experiments with Qt and it is what
libfm-qt / pcmanfm-qt are. Yes, I can handle all bugs and feature
requests for libfm / pcmanfm alone, but what with another LXDE
components? LXDE team has very few developers. But since razor-qt has
not too many developers too and they have the same goals (not build
monstrous integrated complex but rather a desktop toolkit) I think it
would be beneficial for both teams to join forces. And since you want
something alike, that sound very promicing. But we should get razor-qt
voices first I believe. From LXDE side - I and PCMan support the idea,
some other developers aren't sure yet. Andriy.

The idea is great for sure. For me, personally, is the Qt way to go
because of its "ease of development" style for applications. I can
compare it briefly myself as my patches probably live in Evolution (Gtk
mail client) and it was quite hard core school of GUI programming ;)
Since then I live with Qt as mi choice.

I'd like to hear your ideas of cooperation/integration for sure.

I'm little bit afraid of one thing in potential merging. I think it
would be more "philosophical" clash of users than real usage affects.
Current LXDE users might raise their voice with: "down with Qt, we want
Gtk" because they don't understand (and they don't need to understand of
course) the easiness of development etc. It can be quite hazard for name
of LXDE.

On the other side I don't see any point against the move.

Here are some unordered thoughts about Qt world of Razor:

- - Currently we are using Qt4 with initial preparation for switch to
Qt5 (which would be quite easy).
- - With Qt5 the Qt libraries are even more modularized tan in Qt4.
- - KDE guys are working on so called "frameworks" = KDE technologies
and libraries split to *independent* modules mostly (where possible)
integrated into Qt itself.
- the independency should be real, meaning - no cross dependencies
between frameworks and also no global packages in distributions
- which means we could use eg. Solid (hardware info framework -
batteries, automounting, ...) in Razor instead our own backends because
Solid is much more tested and it works on almost all platforms while we
are stuck in udisk/udisk2 only.

cheers,
petr

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJReTmhAAoJEC8yRjM4uE2tOEEH/0oLGzJN1mEw/pmqCl5KVF0U
BEluXtRCu/XnPH57+amEXizbgw5DOFH6gcoxGlYqaKQ80V7glKC5F8oSPVfNaVTC
08XROtVvpQ++LyFDg0GAbOPRAa8eaY4Uuu6CsraIZEDTGK8WeX0TB11OVBdtjGrB
vxUdvHzkXrKOVWSjSfGVQPAzWfYkwX3k2dF7QjGAuss5fi9VNshupcvrrPBr3ONJ
C/giOGYfeHbl38s7+1Gl9Smk3nIbrw2Brw/OOQzKlwLUn5Fg0hxdWUYlJWoZWA7C
tGdzIgylniW2arcSYQp81O4LLd10FKGqIhRxCFCmX8uBEkLY0O7kBoQ3HzdS3+U=
=3iWk
-----END PGP SIGNATURE-----

Alexis López Zubieta

unread,
Apr 25, 2013, 12:01:25 PM4/25/13
to lxde...@lists.sourceforge.net, razo...@googlegroups.com
Hello!

I would like to clarify that the reason of this thread is not to fork
LXDE or Razor-qt instead we are inviting you and the Razor-qt community
to join us in order to make a better product. Both of you are making a
lightweight desktop environment (now on LW DE) for those that need it.

I live in Cuba a third world country, as such we can't buy every year
the last computer model for our schools, business and homes so we have
to use what we have at maximum, thats why we (the Nova Project) are
interested in developing a LW DE. We have many users with Pentium III at
700 MHz with 128 MB of RAM those are our stakeholders (the people who is
going to use our product). But we have another limitation most of you
have an advanced knowledge of computing, those people has none, so all
the basic functionalities must be a simple thing to do, we can't ask to
such user to open a terminal. As you can see the task that we have isn't
simple at all. And this situation is common in every third world
country, those who has the major part of the world population. So what
we do is important for a lot of people.

That's why we are so interested in join forces with you and with
Razor-Qt. I don't pretend that you to recode everything, my intention is
to call you guys realize that you are no making an experimental project
or a toy you are making critical systems (for the major part of the
world). Thats why I invite you to review what you have done and what you
can do now on, you also should think in what we can do working spited
and what we can achieve together.

Andrej N. Gritsenko, Julien Lavergne, PCMan and the rest that think in
the integration of the different communities as an opportunity please
step in and lets make a formal proposal to the communities, to state our
points in a more compressible way. Can I count on you?

Best Regards


http://www.uci.cu

Andrej N. Gritsenko

unread,
Apr 25, 2013, 6:04:55 PM4/25/13
to lxde...@lists.sourceforge.net, razo...@googlegroups.com, pcmanfm-develop
Hello!

I reply to two letters in our mailing lists because they are linked
by the theme but subjects of them weren't so clear on theme.

Alexis López Zubieta has written on Thursday, 25 April, at 12:01:
I believe our goals are similar. At least what I always wanted from
DE? It should be:

1) lightweight: it should not be slow in any way on netbooks for example
2) easy to use: I should do anything with just few keypresses (or mouse
clicks for those who loves to hug their rats:)
3) comfortable: it should have some default settings to be nice for new
users without terminal tricks and in the same time let me change every
element of my desktop system if I am advanced user
4) modular: I should have the possibility to construct my desktop from
some elements if I want that

Also I know that accessibility is really thing which is required and it
even more important than any bells and whistles because those people who
need accessibility are more dependent on those things than we are.

You stated above what are computers your people have so let it be the
requirements which we have to support, i.e. LW DE should work fine on
them. I believe that is possible - my main desktop was 450 MHz Celeron
with 128 MB RAM just 4 years ago and it worked fine with KDE 3.5. It
started non momentally of course but I was able to watch movies, surf
internet with Firefox, edit documents, etc. I don't see any reason that
shouldn't be possible today.

And in other letter, Petr Vaněk has written on Thursday, 25 April, at 16:11:
I still write libfm, libfm-gtk, and pcmanfm with glib and gtk base. I
given up the GTK3 support due to reasons I mentioned before - there is
still support for GTK3 up to 3.4 but I hardly will even try to adapt it
to newer versions, even if users will ask me. But I belive GTK2 support
is something we still have to have. At least because some old systems may
(and will) work easier with gtk2. And also because some users may don't
wish to install Qt just because they use exclusively Gtk applications
otherwise.

>I'd like to hear your ideas of cooperation/integration for sure.

As I already said, together people may do much more than splitted.
Since we decided to give up GTK3 support, we want to have lightweight DE
based on two toolkits - GTK2 for old or small systems (Debian Squeeze on
Celeron II, Raspberry Pi, etc., etc.) and Qt for more modern systems to
allow more flexibility. I do not ask Razor people to start develop GTK
applications and don't ask LXDE people to start develop Qt applications
but everyone can help others such way GTK version will get features it
misses now and Qt version will get features it misses. Everyone in both
camps have own zone of knowledge and working together may make it better.
Of course, everyone will more or less get new knowledge but I don't see
anything bad in that.

>I'm little bit afraid of one thing in potential merging. I think it
>would be more "philosophical" clash of users than real usage affects.
>Current LXDE users might raise their voice with: "down with Qt, we want
>Gtk" because they don't understand (and they don't need to understand of
>course) the easiness of development etc. It can be quite hazard for name
>of LXDE.

It's what I want - just don't give up Gtk, at least until it will be
abandoned by their creators and major distros. I.e. we have LXDE which is
GTK2 based and Razor-Qt which is Qt based, but both have near the same
number of similar feature components (they are different for now but will
be closer and closer with time). Only developers will know those DE are
close one to other, users will see Gtk one and Qt one so no concerns are
raised.

>On the other side I don't see any point against the move.

>Here are some unordered thoughts about Qt world of Razor:

>- Currently we are using Qt4 with initial preparation for switch to
>Qt5 (which would be quite easy).
>- With Qt5 the Qt libraries are even more modularized tan in Qt4.
>- KDE guys are working on so called "frameworks" = KDE technologies
>and libraries split to *independent* modules mostly (where possible)
>integrated into Qt itself.
> - the independency should be real, meaning - no cross dependencies
>between frameworks and also no global packages in distributions
> - which means we could use eg. Solid (hardware info framework -
>batteries, automounting, ...) in Razor instead our own backends because
>Solid is much more tested and it works on almost all platforms while we
>are stuck in udisk/udisk2 only.

Many Qt applications still use GIO so why not use gvfs then? And some
things may be done via libfm which also uses gio/gvfs. When I prepared
release 1.0.0 I get rid of every memory leak so it should be memory safe
for now, valgrind finds no problems so far.

Anyway, I'm not going to learn more Qt in nearest future because I
have to bring libfm and pcmanfm to 1.2-beta state (there are huge number
of features to implement for 1.2 series, I want to clear FR tracker as
much as possible).

Cheers!
Andriy.

gary sheppard

unread,
Apr 25, 2013, 7:06:04 PM4/25/13
to razo...@googlegroups.com, lxde-list, pcmanfm-develop
What effect will all of these new features have on memory, and CPU usage for pcmanfm 1.2 beta?

QT5 is being developed to work well all the way down to smart phones. Are you sure GTK2 is very much lighter in system weight?

Another point is: Many distro's are dropping GTK2 or have said they will do so very soon as it is getting more difficult to support New and Old.

I will say, I like LXDE. I also like Razor QT. In my opinion as a user, it would be wise to plan to fully merge the projects cores or their entirety when QT5 is adopted. Till then, co-operate as much as possible. Plan now on how to "tool up" for your separate looks.

I can hardly wait to see what comes in future cooperative releases.


Jerome Leclanche

unread,
Apr 25, 2013, 7:26:23 PM4/25/13
to razo...@googlegroups.com, lxde-list, pcmanfm-develop
Quick point from the Razor side of things

None of us have any wish to alienate current LXDE users; there's many valid reasons to prefer a GTK-oriented DE.
That said, there's plenty of choice when it comes to lightweight GTK DEs. I personally fully support this new direction though I think it should be discussed.
If there are LXDE devs interested in talking about this, feel free to pop in #razor-qt on freenode and ping me (Adys) or another Razor dev.
 

J. Leclanche

Дмитрий Антонов

unread,
Apr 26, 2013, 5:12:07 AM4/26/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list, lubuntu user list
PCManFM is no longer a lightweight file manager.
Besides, he's still in development. When it will finish, it will be even slower and will consume more resources.

Andrej N. Gritsenko

unread,
Apr 26, 2013, 8:55:35 AM4/26/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list
Hello!

О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ has written on Friday, 26 April, at 2:12:
>PCManFM is no longer a lightweight file manager.

How can you tell that? Where you've got such conclusion? And if there
is some problem with it as lightweight file manager then, please, report
that problem and help find what may be wrong, please.

>Besides, he's still in development. When it will finish, it will be even
>slower and will consume more resources.

PCManFM core is finished. Development on it is about few feature
requests to extend its functionality when user require that, such as new
content menu items for example. It will never be slower, I promise. Just
because any feature requests that affect its responsiveness are being
refused. All additional resourse consumption will be tiny bit of RAM to
load extra code (which implements those features) and it's all.
If you meant Qt version of PCManFM then yes, it's not finished yet
but I believe core is already complete so no further slowness either.

Best regards.
Andriy.

Andrej N. Gritsenko

unread,
Apr 26, 2013, 9:54:10 AM4/26/13
to razo...@googlegroups.com, lxde-list, pcmanfm-develop
Hello!

gary sheppard has written on Thursday, 25 April, at 16:06:
>What effect will all of these new features have on memory, and CPU usage
>for pcmanfm 1.2 beta?

At least we refuse feature requests that can affect responsiveness
(i.e. CPU usage), only optional functionality (thru context menu for
example) being added there. Only feature which will affect CPU will be
plugins system which is planned but I'll do it as much as possible on
idle to not affect responsiveness. A tiny bit increased memory usage is
unavoidable unfortunately, because new features execution code and data
will consume the memory, but I believe it will be really just a tiny bit.

>QT5 is being developed to work well all the way down to smart phones. Are
>you sure GTK2 is very much lighter in system weight?

As much I can say, GTK3 version consumes 20-30% more memory than GTK2
one. PCMan told me Qt consumption lies between those two and I have no
reasons to doubt. I didn't make any CPU usage tests on them though, it
will require good testing plan and number of repeated tests to get all
the statistics. I'm not much good in that.

>Another point is: Many distro's are dropping GTK2 or have said they will do
>so very soon as it is getting more difficult to support New and Old.

It's why we have to make a decision now which toolkit we will use
when GTK2 will be abandoned. It is not abandoned now, just because a lot
of things still use it - a whole DE such as XFCE for example. But yes, it
will be abandoned eventually. So discussed this we got to agreement that
Qt is much better as second toolkit to future migration than GTK3 is.

>I will say, I like LXDE. I also like Razor QT. In my opinion as a user, it
>would be wise to plan to fully merge the projects cores or their entirety
>when QT5 is adopted. Till then, co-operate as much as possible. Plan now on
>how to "tool up" for your separate looks.

Thank you very much.

Cheers!
Andriy.

PICCORO McKAY Lenz

unread,
Apr 26, 2013, 10:06:03 AM4/26/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list
On Fri, Apr 26, 2013 at 8:25 AM, Andrej N. Gritsenko <and...@rep.kiev.ua> wrote:
Дмитрий Антонов has written on Friday, 26 April, at  2:12:

>PCManFM is no longer a lightweight file manager.
Thats true...
 
    How can you tell that? Where you've got such conclusion? And if there
is some problem with it as lightweight file manager then, please, report
that problem and help find what may be wrong, please.
that as it develops, there is also more resources and developer  "used to" consume
 

>Besides, he's still in development. When it will finish, it will be even
>slower and will consume more resources.
Moore law! obviosly, as more power, also more lines of code, more cycles to compute.. and so... 

"its inevitable" 
Mr Smith.
 

  

Andrej N. Gritsenko

unread,
Apr 26, 2013, 10:46:30 AM4/26/13
to lxde...@lists.sourceforge.net, pcmanfm...@lists.sourceforge.net, razo...@googlegroups.com
Hello!

JM has written on Friday, 26 April, at 15:44:
>I am trying pcmanfm-qt for the first time in Archlinux where a PKGBUILD has been done for
>it. First I didn't see icons, then I chose icons in the preferences section and after I
>restarted it the icons showed (pcmanfm does not look for a .gtkrc-2.0 file?). Then it
>looks a bit strange compared to the GTK version, the left sidebar is not organized the
>same way.

It is in very early state really. But it's better to ask PCMan about
details, I'm working on 1.2 GTK version now and never took a part in Qt
version yet. I'm sorry.

>I tested what interests me most : the USB stick is mounting alright, internal
>partition too, and once I unmount a volume the pcmanfm-qt program does not close, which
>is nice, because the pcmanfm gtk version "closes" (I'd rather call that crash) when
>unmounting any partition... still a problem with the current Version: 1.1.0-1.

I remember that issue and that is in feature list for 1.2 as well.

>The qt version does not close and just states that the directory is invalid. (this is not
>perfect but better than a crash).

>I see it will indeed still need some enhancements, and probably translations too.

>Qt ? Difficult to go without it anyway, many good programs rely on it, and if the next
>gtk version is too heavy and too difficult to code with, lets use Qt ! \o/

>I have a wish for the wish list : it would be nice to be able to split the main window in
>two independent panes at will (and make it again one only on the fly when two panes will
>not be needed anymore). I personally don't mind using mc/midnight commander, which is very
>good for that, but the two pane in a GUI light file manager is a feature which has been
>longed for many times by the members of the LinuxVillage (http://beta.linuxvillage.net
>forum).

Of course, the twin-pane mode will be in pcmanfm 1.2, it is a long
waited optional feature by many.

Andrej N. Gritsenko

unread,
Apr 26, 2013, 11:17:14 AM4/26/13
to razo...@googlegroups.com, lxde-list, pcmanfm-develop
Hello!

Jerome Leclanche has written on Friday, 26 April, at 0:26:
>Quick point from the Razor side of things

>None of us have any wish to alienate current LXDE users; there's many valid
>reasons to prefer a GTK-oriented DE.
>That said, there's plenty of choice when it comes to lightweight GTK DEs. I
>personally fully support this new direction though I think it should be
>discussed.
>If there are LXDE devs interested in talking about this, feel free to pop
>in #razor-qt on freenode and ping me (Adys) or another Razor dev.

I've joined #razor-qt@freenode today and we got to conclusion that it
would be good if LXDE developers subscribe to razo...@googlegroups.com
mailing list and razor-qt developers to lxde...@lists.sourceforge.net,
it will be good as next step of further co-operation.

Thank you in advance.

Andriy.

PICCORO McKAY Lenz

unread,
Apr 26, 2013, 1:47:40 PM4/26/13
to razo...@googlegroups.com
On Thu, Apr 25, 2013 at 6:36 PM, gary sheppard <rhy...@gmail.com> wrote:
QT5 is being developed to work well all the way down to smart phones. Are you sure GTK2 is very much lighter in system weight? 
its true.. 

qt5 its a complete framework that abstract many operations in middle layer.. GTK only paint widget and organize the comunication between system and user... (in fast words, )
 
Another point is: Many distro's are dropping GTK2 or have said they will do so very soon as it is getting more difficult to support New and Old.
i hate that 

Дмитрий Антонов

unread,
Apr 26, 2013, 3:14:18 PM4/26/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list, lubuntu user list
PCManFM consumes too much memory (RAM).

IgnorantGuru

unread,
Apr 26, 2013, 9:20:23 PM4/26/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list, lubuntu user list
Great work PCMan!  And thanks for the conversion wiki.  I've been shopping for a GUI toolkit myself - perhaps to take SpaceFM there eventually - though I'm not sure I like qt.  Is there a discussion somewhere of why LXDE and/or you are choosing to migrate to qt?  I understand the desire to move away from Red Hat's poisoning of the GTK well, but why did you choose qt?  And what other toolkits did you review?  I would like to see the discussion or analysis.

Also, what are the current thoughts on gvfs now that you're moving in a more qt direction?  Any plans for change there?

I've dropped you a link
http://igurublog.wordpress.com/2013/04/26/lxde-and-calculate-snub-gnome-3/

Drole de Zebre

unread,
Apr 27, 2013, 7:17:22 PM4/27/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list, lubuntu user list
Hello!


What about Elementary (EFL), FLTK toolkits to replace GTK 2?
Thank you for your answer!

PCMan

unread,
Apr 28, 2013, 7:47:48 AM4/28/13
to IgnorantGuru, razo...@googlegroups.com, lxde-list, pcmanfm-develop, lubuntu user list
About gvfs, I'll keep using it for now. Mixing GIO and Qt works
perfectly and Qt has built-in glib integration.
Gvfs has more and more backends and many of them has no FUSE-based equivalence.
An alternative would be to use KDE's KIO slave, if you're OK with the
KDE dependencies.
In comparison, gvfs is "relatively" more desktop-independent.
When the backends are carefully separated by packagers, it's actually
desktop independent and only brings few gnome deps.
If your gvfs installation depends on the whole gnome, blame the
packager of your distro.

Since people are curious about the GUI toolkit issue, I wrote down
another wiki page (not completed).
http://wiki.lxde.org/en/GUI_Toolkit_Comparison

There is no perfect toolkit. So it's all about a balance between cost
and benefit.

What I considered important:

1. It should be fast and light:
If you insist on this point, then Qt and Gtk+ are out. But when you
also consider the following points, things become different.

2. It should have good i18n support, including unicode, RTL, and other
complicated text layout.
GTK+ and Qt have exellent support in this fields while FLTK and FOX
toolkiit only have very basicones. Enligtenment, I'm not sure.
If your program is going to be used in non-English speaking countries,
this is a critical issue.

3. It should accept text input from an input method editor
Again, it's an essential feature for people from countries like China,
Japan, Korea, and Taiwan (where I come from).
So, I think only Gtk+ and Qt have good enough support for this.

4. It'll be better if it has accessibility support.
Undoubtedly, Gtk+ is the best one here, and Qt follows. The others are
irrelevant.

5. It should be really easy to program with, making us more productive.
I'll never call "writing C with GObject" easy and efficient. So GTK+
is out. (I know vala, but it has many issues, like generating
"incorrect" C code that's hard to debug). If you're doing OOP, why not
use a language with "native" OO support and compiler optimized for the
task?

6. It should supports glib integration, so I can use all of the nice
non-GUI libraries based on glib. Qt, GTK+, and E17 are the ones that
support glib. Others cannot do this.

7. It should be well-maintained:
Qt and Gtk+ win. E17 has slower development, and FLTK is now splitted
into two incompatible branches and each of them have many supporters.
The future is uncertain.

8. It should be themable and looks good.
Then apparently FLTK and FOX are not the right choice. FLTK has some
"so-called" themes, but it's very primitive and limited, not really of
the same level as Gtk+/Qt.

If you consider 2 - 8 required and also want it to stay
ultra-lightwight, then there is no such toolkit.
If you make some compromise, then Qt is probably a good one.
Consider the rich feature set it provides, it's not that heavy.
To get the same feature set, you need to install tons of other
libraries in the G universe.
Besides, Qt is modular. If you only need the core features, link with
QtCore and other modules won't be loaded.
The whole library of course is huge, but you only need to link with
the module you really used.

Hope this answer your questions.

Drole de Zebre

unread,
Apr 28, 2013, 8:37:13 AM4/28/13
to razo...@googlegroups.com, IgnorantGuru, lxde-list, pcmanfm-develop, lubuntu user list
Very good!
Thank you! :)

Alexis López Zubieta

unread,
Apr 28, 2013, 9:59:34 AM4/28/13
to PCMan, IgnorantGuru, razo...@googlegroups.com, lxde-list, pcmanfm-develop, lubuntu user list
El 28/04/13 07:47, PCMan escribi�:
Nice work!!
I'm agreed with you, we will have to decide between an extra slim and
low functional desktop and a functional and no so slim (this doesn't
means fat) desktop.
http://www.uci.cu

Kevin Krammer

unread,
Apr 28, 2013, 11:18:14 AM4/28/13
to razo...@googlegroups.com, lxde-list, pcmanfm-develop
On Sunday, 2013-04-28, PCMan wrote:

> About gvfs, I'll keep using it for now. Mixing GIO and Qt works
> perfectly and Qt has built-in glib integration.

Only on Unix though, but I guess that is of little concern to Unix desktop
environment projects :)

> Gvfs has more and more backends and many of them has no FUSE-based
> equivalence.

I always like the idea of GVFS mount daemons. I think that a Qt based
implementation of at least the client library would make a nice official Qt
addon, that is, assuming that a couple of the mount daemons can be made
crossplatform.

Basically getting remote file access available on all Qt supported platforms,
even on those that do not support it themselves.

When GVFS was introduced I investigated the option of implementing the
protocol using Qt native facilities, but at that time maintainer Alexander
Larsson said that the protocol wasn't stable enought yet.

> An alternative would be to use KDE's KIO slave, if you're OK
> with the KDE dependencies.

KIO will be one of the KDE frameworks rated as Solution, i.e. depends on
runtime services (just like GVFS), but it has very little other dependencies.

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

Kevin Krammer

unread,
Apr 28, 2013, 11:21:49 AM4/28/13
to razo...@googlegroups.com, lxde...@lists.sourceforge.net, pcmanfm-develop
On Friday, 2013-04-26, Andrej N. Gritsenko wrote:

> Many Qt applications still use GIO so why not use gvfs then? And some
> things may be done via libfm which also uses gio/gvfs.

I doubt that many Qt applications use GIO, due to most of the library's
functionality already being present in Qt itself.

GVFS however, could be really interesting. I wonder how much work it would be
to implement the client side parts of GVFS in Qt terms.
signature.asc

pcma...@gmail.com

unread,
Apr 28, 2013, 12:27:17 PM4/28/13
to razo...@googlegroups.com, lxde-list, pcmanfm-develop
anda...@gmail.com於 2013年4月28日星期日UTC+8下午11時18分14秒寫道:

On Sunday, 2013-04-28, PCMan wrote:

> About gvfs, I'll keep using it for now. Mixing GIO and Qt works
> perfectly and Qt has built-in glib integration.

Only on Unix though, but I guess that is of little concern to Unix desktop
environment projects :)

> Gvfs has more and more backends and many of them has no FUSE-based
> equivalence.

I always like the idea of GVFS mount daemons. I think that a Qt based
implementation of at least the client library would make a nice official Qt
addon, that is, assuming that a couple of the mount daemons can be made
crossplatform.

Basically getting remote file access available on all Qt supported platforms,
even on those that do not support it themselves.

When GVFS was introduced I investigated the option of implementing the
protocol using Qt native facilities, but at that time maintainer Alexander
Larsson said that the protocol wasn't stable enought yet.

IIRC, there was some attempt in the past to make it work with Qt.

And there was also some work to make KIO slave work with Gtk+.

None of them seems to be active, though.
 

> An alternative would be to use KDE's KIO slave, if you're OK
> with the KDE dependencies.

KIO will be one of the KDE frameworks rated as Solution, i.e. depends on
runtime services (just like GVFS), but it has very little other dependencies.

Really glad to hear that!! It's a long awaited feature.
Gvfs, however, has one thing that always beat KIO slave.
It's implemented in plain C and can hence be usable from nearly any programs.
C++ APIs, like KDE ones, are hard to use in C programs.
Creating a C wrapper around a C++ library is really a boring task and I guess nobody will want to do it.
So, I personally prefer C-based libraries in this case.
Unleass there can be a pure C implementation of the KIO protocol or a thin C wrapper for the C++ API it projects, it's difficult to use KIO in Gtk/Gnome programs.

Andrej N. Gritsenko

unread,
Apr 29, 2013, 2:32:14 PM4/29/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list
Hello!

О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ has written on Friday, 26 April, at 12:14:
>PCManFM consumes too much memory (RAM).

If you think ~15 MB on i386 or ~20 MB on x86_64 is too much then
consider to use Midnight Commander isntead. Other file managers with
functionality similar to PCManFM use more RAM. May be some very early
version of PCManFM (1st generation - 0.1.7 or whatever) with very basic
functionality consumed less but I doubt you want so basic functionality
ever from GUI file manager. I'm sorry.

With best wishes.
Andriy.
Message has been deleted

Дмитрий Антонов

unread,
Apr 30, 2013, 2:32:04 AM4/30/13
to razo...@googlegroups.com, pcmanfm-develop, lxde-list, lubuntu user list
I am using Windows XP and Explorer and it works very fast and consumes little resources.

Kevin Krammer

unread,
Apr 30, 2013, 12:48:46 PM4/30/13
to razo...@googlegroups.com, lxde-list, pcmanfm-develop
On Sunday, 2013-04-28, pcma...@gmail.com wrote:
> anda...@gmail.com於 2013年4月28日星期日UTC+8下午11時18分14秒寫道:

> > I always like the idea of GVFS mount daemons. I think that a Qt based
> > implementation of at least the client library would make a nice official
> > Qt
> > addon, that is, assuming that a couple of the mount daemons can be made
> > crossplatform.
> >
> > Basically getting remote file access available on all Qt supported
> > platforms,
> > even on those that do not support it themselves.
> >
> > When GVFS was introduced I investigated the option of implementing the
> > protocol using Qt native facilities, but at that time maintainer
> > Alexander Larsson said that the protocol wasn't stable enought yet.
>
> IIRC, there was some attempt in the past to make it work with Qt.
> Kommodity http://websvn.kde.org/trunk/playground/libs/kommodity/

Interesting, didn't know about that one. Still a wrapper though, i.e. would
still need GLib event loop integration which is only available in the Qt unix
event dispatcher.

> And there was also some work to make KIO slave work with Gtk+.
> https://live.gnome.org/KioGioBridge

Right, knew about that one. Not the best approach IMHO.

> > > An alternative would be to use KDE's KIO slave, if you're OK
> > > with the KDE dependencies.
> >
> > KIO will be one of the KDE frameworks rated as Solution, i.e. depends on
> > runtime services (just like GVFS), but it has very little other
> > dependencies.
>
> Really glad to hear that!! It's a long awaited feature.
> Gvfs, however, has one thing that always beat KIO slave.
> It's implemented in plain C and can hence be usable from nearly any
> programs.

Both GVFS mount daemons as well as KIO slaves operate as separate processes,
communicating with the applications using (Unix domain) sockets and D-Bus.
The sockets are as always a perfect dependency and license barrier, a client
can always use a totally different implementation than the "server" (GVFS
mount daemon or KIO slave)

> C++ APIs, like KDE ones, are hard to use in C programs.

Sure, but why would one use a library based on a different technology stack if
the actual API is the protocol on the socket?
It is like wrapping dbus-glib instead of either using the low-level protocol
library (like Qt did) or implementing the protocol directly (e.g. Java, Mono,
etc, did that).

> Creating a C wrapper around a C++ library is really a boring task and I
> guess nobody will want to do it.

And it would be as pointless as wrapping a C application library. There are
major differences in APIs on whether they are intended for other library
developers or application developers.
This is why xlib sucked so much, because it was originally intended for
application developers but then always wrapped by toolkit developers.
XCB allows toolkit developers to be far more effective because they don't have
to wrap API that wanted to be "easy" for app developers.

I personally always find it puzzling why the moment the socket type is not IP
based, a large portion of people start to assume that there is some kind of
dependency between servers and clients, right?

Like if web browers written in C could only easily connect to web servers
written in C, not to those written in C++, Erlang, Python, Ruby, NodeJS, etc.
Hilarious thought, no?
signature.asc

PICCORO McKAY Lenz

unread,
Apr 30, 2013, 4:11:12 PM4/30/13
to razo...@googlegroups.com
On Sat, Apr 27, 2013 at 6:47 PM, Drole de Zebre <droled...@gmail.com> wrote:
What about Elementary (EFL), FLTK toolkits to replace GTK 2?

i think its a exceent idea, FLTK are really more lighter rather than GTK+ or QT, specially qt...
 

PICCORO McKAY Lenz

unread,
Apr 30, 2013, 4:13:18 PM4/30/13
to razo...@googlegroups.com

Lenz McKAY Gerardo (PICCORO)


On Sun, Apr 28, 2013 at 7:17 AM, PCMan <pcma...@gmail.com> wrote:
There is no perfect toolkit. So it's all about a balance between cost
and benefit.
2. It should have good i18n support, including unicode, RTL, and other
complicated text layout.

arrgg have right! 
Reply all
Reply to author
Forward
0 new messages