From: PCMan <pcm...@gm...> - 2011-11-05 13:06:17
|
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 Though the code in my hard disk is far from usable, it's 50% completed now. The new code is written in Vala and I found out how to blend vala and C code in libfm. Previously I evaluated several C++ solutions/libraries and consider using C++ inside pcmanfm. Now, I've made the decision. Let's use C/Vala and not introduce C++ now. Vala is not perfect and might not be the best, but it works well enough. After trying it for several days I'm satisfied. So I'll use it more in future LXDE development. 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) 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. |
From: PCMan <pcm...@gm...> - 2011-11-05 16:08:58
|
Yet another TODO item for 1.0 release. 1. Implement an easy way to add new desktop entry to desktop. 2. May optionally integrate lxshorcut? On Sat, Nov 5, 2011 at 9:06 PM, PCMan <pcm...@gm...> wrote: > 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 > > Though the code in my hard disk is far from usable, it's 50% completed now. > The new code is written in Vala and I found out how to blend vala and C > code in libfm. > Previously I evaluated several C++ solutions/libraries and consider using > C++ inside pcmanfm. > Now, I've made the decision. Let's use C/Vala and not introduce C++ now. > Vala is not perfect and might not be the best, but it works well enough. > After trying it for several days I'm satisfied. So I'll use it more in > future LXDE development. > > 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) > > 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. > > |
From: Julien L. <gi...@ub...> - 2011-11-06 18:08:00
Attachments:
91-integrate-lxshortcut.patch
|
Le 11/05/2011 05:08 PM, PCMan a écrit : > Yet another TODO item for 1.0 release. > 1. Implement an easy way to add new desktop entry to desktop. > 2. May optionally integrate lxshorcut? Maybe it will be covered by the nautilus-actions specs ? Or, there is a preliminary patch for this support (see attached). It could also be improved by launching the same UI than when you launch "Open with ...". Regards, Julien Lavergne |
From: Julien L. <gi...@ub...> - 2011-11-06 17:52:26
|
Good to see some progress for pcmanfm :) Le 11/05/2011 02:06 PM, PCMan a écrit : > 5. Fix bugs (doing 3 and 4 might fix some existing bugs as well) You can have a look at the bug tracker if you want ideas of bugs to fix :) > For the future: > (...) > 3. Per-folder settings (using tdb to store) (low priority, need to > deterimine what to store for each folder) This is actually one of the most annoying behavior I have with pcmanfm. At least, having the way to sort the files / folders will be very nice. By default, it's useful to sort files by name, but for some others folders (like Downloads folder), it makes more sense to sort them by "last modified". Actually, you have to switch each time you change the folder :( > 4. Integrate other thumbnailers Maybe the one by default could be also improve too ? It sometimes failed when there are many files to preview, and also failed on remote folder (like on a camera which is plugged). Regards, Julien Lavergne |
From: Christoph W. <chr...@go...> - 2011-11-06 18:21:33
|
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? > Now, I've made the decision. Let's use C/Vala and not introduce C++ > now. Thanks! > 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? > 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! 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. 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. Regards, Christoph |
From: PCMan <pcm...@gm...> - 2011-11-06 21:04:50
|
On Mon, Nov 7, 2011 at 2:21 AM, Christoph Wickert < chr...@go...> 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 > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Martin B. / b. <br...@bs...> - 2011-11-11 10:30:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-11-06 22:04, PCMan wrote: > On Mon, Nov 7, 2011 at 2:21 AM, Christoph Wickert < > chr...@go...> wrote: 1. Actually this has been > planned for more than one year, but I just don't have the time to do > it. This is my main concern. I don't really care about the technical choices (to some extent at least...). The social and community cuilding ones I do care about. YOU planned this a year ago. YOU don't have time to do it. If the plan was known and better utilized as a community building piece OTHER interested parties would be able to participate and HELP /YOU/ with this work. > 4. This won't slow down the overall development much as I already > finished most parts of the spec. There you did it again. "...as I already finished..." >> 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. > > Cooperating with others might help, but this takes even more time. NO IT DOES NOT! It only takes more time when it is not done in a proper manner. By the people skilled for it. Yes I do consider myself among those, I am not skilled in the development parts as I have repeated numerous times but communication and coordination I can do. In a way I feel that 2011 more or less marked the year where LXDE grew out of propotions and have to grasp what ever there are. We got recognized by several distros and had media attention to stuff. Problem? Almost no releases. This will not lead to more interest; rather the opposite. I do respect the wish to produce "quality releases" but with proper planning/annoucements and with rapid releases attention will continue to grow and interest not be lost. We have had it repeated already in this thread but it is very very central to what we do and where we stand now. Release early. Release often. LXDE and PCManFM is no longer a pet project aimed to a dozen people. (3749 installs of pcmanfm according to debian popcon, the number for ubuntu is 41161) - -- brother http://sis.bthstudent.se -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJOvPlBAAoJEJbdSEaj0jV7zQsH/RLovMDto+oFQQ0s/4QUaYJ3 PNzAyaGpd69vhG6GKNvjToUWPvEi5Y7nPnrrNcCMQc0ZzrVeKa3UuYP2sM1eoiKN mynX/v9ua/9QWfN3zdQRcCjnBuvd1nNabQl7lPc9oOS0+Q+gFinBFupIFTYKLcNd f868rsMVSzC927bU/9qKi8h0enoZoYNxvBCel+BpOXoggkc575h2JpQ4MD5shiQ/ uqMT435tDqwzdhYKrgz0Fs5+EF8BjUmtwzifqWF4S1eXU2roc1wZyMlHA6gAS7GV bSvcZcItgcJdsVwzLakeWxaDZa6knVjYb53PE5WJhXEDSh/GWoXwtyE3L72SGRE= =BQBm -----END PGP SIGNATURE----- |