On Fri, Mar 30, 2012 at 2:08 AM, Vadim Ushakov <email@example.com>
> The problem is, I'm now rewriting "job" related parts with vala andOh... I guess you are planning to rewrite the whole libfm with vala,
> currently they are in "job" branch.
> That's a large piece of code so I'm sure there might be some conflicts in
> the future.
aren't you? Well, this is _really_ a problem for me because I do not
think that vala is right thing here. Maybe I will have to fork the
program and develop it by myself sometime in the future. :(
Don't worry. There is no plan to rewrite everything in Vala.
If the existing parts work well, I won't replace them.
When GObject is involved, the readability of Vala code tends to be much better then its C counterpart.
The source code can be much shorter, too. I did the "actions" support in vala and it's working well now.
For the "jobs" part, the old one written in C is quite buggy and sometimes it eats the users data.
I found that the readability of that part soon becomes poor as the program grows.
The same happen to nautilus. The file operations part of code is dirty and is nearly unreadable to human.
Besides, there are some design problems of that part which caused some limitations.
So I did that part in Vala and now the code is much shorter and cleaner.
There is no plan to doing other parts with Vala at the moment.
Vala is not stable now, but it's improving and since it blends well with C, using it brings no problems.
I applied some patches from the bug tracker, they are marked in the
commit history with links to the appropriate tracker entries.
The problem of file managers in Linux is that there are too much of
> This file manager has the change to be a fairly good one, but it's too buggy
> ATM and I'm really too busy.
them. :) All of them implement the same things: copy, paste, file
properties, "open with" and so on. I think there should be some API to
do such standard things, so developers of all these file managers
could focus on inventing and implementing new features, instead of
reinventing "the wheel" over and over. And... libfm just provides that
API. So I believe pcmanfm is not just "a fairly good file manager",
but it has a chance for much more. For now I've tried to add libfm's
support to the dirmenu plugin of lxpanelx (it is my fork of lxpanel),
and it works quite fine (except for a couple of bugs that I have
already fixed in my branch). And I hope to find a dozen more use cases
for this library. :-)
That's why I started the project. I tried to keep libfm usable outside pcmanfm/lxde to provide a reusable and desktop neutral API to everyone. In addition, I deliberately separate the core parts and GUI parts in two separate libs.
So in the future we can even have different GUI flavors such as Qt4 if someone needs it.
This is the original plan, but it's a little bit too ambitious given currently limited man power.
I believed that a fork is not needed. We just need some coordination and cooperation.
What do you think?