On Mon, Nov 7, 2011 at 2:21 AM, Christoph Wickert <
[email protected]> 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.
>
> Thanks!
>
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
> management.
>
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.
> Regards,
> Christoph
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Lxde-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lxde-list
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Lxde-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxde-list
