On Fri, Mar 30, 2012 at 2:08 AM, Vadim Ushakov <[email protected]> wrote:
> > The problem is, I'm now rewriting "job" related parts with vala and
> > 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.
>
> Oh... I guess you are planning to rewrite the whole libfm with vala,
> 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.
> > Can you also take a look at our bug tracker and see if you can help?
> > We need to fix the most important ones of them to have a 1.0 stable
> release.
> > http://sourceforge.net/tracker/?group_id=156956&atid=801864
> > Here are known bugs to fix. Maybe you have fixed many of them?
>
> I applied some patches from the bug tracker, they are marked in the
> commit history with links to the appropriate tracker entries.
>
> > This file manager has the change to be a fairly good one, but it's too
> buggy
> > ATM and I'm really too busy.
>
> The problem of file managers in Linux is that there are too much of
> 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?
>
>
> --
> Regards,
> Vadim Ushakov
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Lxde-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxde-list
