On Mon, Nov 7, 2011 at 2:21 AM, Christoph Wickert <christoph.wickert@googlemail.com> wrote:
Am Samstag, den 05.11.2011, 21:06 +0800 schrieb PCMan:
> As I got some little free time this week, I started to implement
> "custom actions" for pcmanfm/libfm.
> I'm now trying to implement this spec proposed by the author of
> nautilus actions.
> http://www.nautilus-actions.org/?q=node/377

Why not finish 1.0 before adding new features?

1. Actually this has been planned for more than one year, but I just don't have the time to do it.
I got tons of mails asking why there is no customized action nearly every month. This may be one of the top FAQs.
2. I'm confident that I can finish this one and the proposed spec by nautilus-action project seems to work well.
3. Adding this breaks no translated strings.
4. This won't slow down the overall development much as I already finished most parts of the spec.
5. The plan is to support the most important parts of the spec first, and to make it more complete in future releases.

> Now, I've made the decision. Let's use C/Vala and not introduce C++
> now.

Vala really helps a lot. With Vala, I got significant speed up in coding.

> For the upcoming PCManFM 1.0, here is the current TODO list in my
> brain.
> 1. Finish basic custom actions (DES-EMA spec) support (required)
> 2. Try to support ~/Template folder, if possible (lower priority, may
> postponed)
> 3. Refactor job system and make it less buggy. Use UI delegate and
> reduce unnecessary signal emission. (required, may be done in vala +
> C)
> 4. Code cleanup. (required, may be done in vala + C)
> 5. Fix bugs (doing 3 and 4 might fix some existing bugs as well)

I thought the only thing that was missing for 1.0 was the tree view on
the side pane?

Actually this is not the case. The problem is, the initial design of libfm is too ambitious and its implementation is flawed.
Initially I want to separate UI and the core non-UI parts, so later we can port it to other toolkits.
The deliberate separation of the UI part caused many problems and make the development difficult.
If I mixed the UI code and non-UI code and did not try to limit the use of GTK+ in ui modules only, things should be much easier.
In the beginning I also want to make the lib available for use by other projects but soon things become more complicated than expected. Many bugs in the job system soon become hard to debug.
That's why there are many weird unresolved bugs. Many of these bugs do exist, but are hard to reproduce.
I reviewed source code of KDE/KIO slave, thunar, and nautilus and tried hard to find a better way to refactor the code.
A code cleanup and some refactor of the job system are really needed for the file I/O parts in order to make file operations more reliable and less buggy.

Supporting ~/Template is another story. Previously it's has been partially done already, but due to problems of the job system, it cannot be finished. If the job system can be fixed, this can be finished immediately.

> For the future:
> 1. Support different filename encoding for different directories, so
> gvfs-mounted remote filesystems can have non-UTF-8 encoding.
> 2. Add "Send To" to popup menu. (no xdg spec for this, may see how
> thunar do it)
> 3. Per-folder settings (using tdb to store)  (low priority, need to
> deterimine what to store for each folder)
> 4. Integrate other thumbnailers
> 5. Profiling and optimization, decrease unnecessary export symbols
> 6. Port to gtk 3
> 7. Use GtkApplication to handle IPC.

Please make a proper roadmap with versions and milestones to handle all
these new features. If you don't set yourself clearly defined goals for
each version, you will not reach your goals but slow down the overall
development. If you had focused on the tree view you could have released
1.0 months ago. Release early, release often!
Sometimes, people just noticed that one feature is broken. So it seems that if this "single" feature can be fixed, then the program becomes good. From the perspective of the coder, this is not always true. The code behind these features is tangled sometimes.
Fixing a single feature often requires fixing many other parts as well. These fixes might even affect even more parts subsequently. Then fixing this one single feature becomes much harder than it looks like.
Of course, this only happens when the program is not well designed and is poorly written.
This don't happen quite often to experienced, professional, talented, and paid full-time developers.
Unfortunately, I'm not one of them. Sorry to have poorly written and buggy code which is hard to fix.
I reviewed the bugs in the tracker frequently but most of the remaining ones are not that easy to fix. Others cannot be reproduced. I'll try to fix the ones I can fix, and left the others, and then release 1.0.

The reason to tag and release a version is not only to make users and
packagers happy but to also build a common platform for further
development, so you will benefit from it, too.

Please ask yourself: How do you want to fix bugs for 1.0, when people
have to compile snapshots on their own in order to test and find bugs?
You can continue with your code from git or from your harddrive, but you
will never reach a wider audience and thus never have enough testers.
Not to mention other developers to help you.

I have to admit that I am becoming more and more disappointed by the
lack of direction and release engineering in LXDE development and I am
considering to orphan all my LXDE packages and the LXDE Spin in Fedora.
To be honest, maintaining such kind of projects without full-time developers is really difficult, much more difficult than I think when I started the project. In 2006-2008 I'm a student and I can do the development in summer vacations. So the project grew up fast at that time. However, now I got a full-time job in my real life. Doing this kind of development during leisure time soon becomes a nightmare. Your brain is full of ideas. You have the problems to solve, but you just don't have the time. This is quite cruel.
Cooperating with others might help, but this takes even more time. Communications, integrations, and do the real work takes much more time than expected. Of course we get much help from the communities. However, for the core gtk+ development, developers are hard to find. Many successful projects actually rely on paid full-time developers or contributions from companies. For amateurs, few people can really do that. For example, most of the small projects on http://gnomefiles.org/ are no longer vital.
If I were still a student, most of the components should have several nice new releases months ago. :-(

Please take a moment and ask yourself two questions:
    1. When did LXDE make the most progress? Was it recently or when we
       had constant releases?
    2. Where do you want to see your project in 1, 2 or three years
       from now?

I would like to see LXDE as a vital and developing project with a big
community. I am willing to do my part to make this happen, but IHMO this
requires that we all agree on a common roadmap and have a proper release

To change this, maybe a better new project leader is needed. What do you think?
Anyways, I'll try to finish the FM ASAP. At least with Vala now coding should be easier.


RSA(R) Conference 2012
Save $700 by Nov 18
Register now
Lxde-list mailing list