From: Vadim U. <ige...@gm...> - 2012-03-29 04:31:39
|
Various bugfixes and ui impovements for libfm and pcmanfm: https://github.com/geekless/libfm https://github.com/geekless/pcmanfm -- Regards, Vadim Ushakov |
From: PCMan <pcm...@gm...> - 2012-03-29 16:13:01
|
Amazing!!! You did so much!! I need to take a weekend to see what you've done. Great job! 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. 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? This file manager has the change to be a fairly good one, but it's too buggy ATM and I'm really too busy. It's very exciting and encouraging that you have these fixes. On Thu, Mar 29, 2012 at 12:31 PM, Vadim Ushakov <ige...@gm...> wrote: > Various bugfixes and ui impovements for libfm and pcmanfm: > > https://github.com/geekless/libfm > https://github.com/geekless/pcmanfm > > > -- > 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 > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Axel F. <axe...@gm...> - 2012-03-29 16:55:11
|
I started a *very experimental* port of PCManFm's Desktop to Vala, only the Desktop currently :-) https://github.com/afilmore/lxdesktop I use a simplified build of LibFM : https://github.com/afilmore/libfmcore Only double clicking Desktop Items works currently. I'm starting the Drag And Drop part. :-P I don't know what I can achieve with this, maybe nothing, just an experiment, learning Vala/Gtk+. :-) On 29/03/2012 18:12, PCMan wrote: > Amazing!!! > You did so much!! > I need to take a weekend to see what you've done. > Great job! > > 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. > > 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 > <http://sourceforge.net/tracker/?group_id=156956&atid=801864> > Here are known bugs to fix. Maybe you have fixed many of them? > > This file manager has the change to be a fairly good one, but it's too > buggy ATM and I'm really too busy. > It's very exciting and encouraging that you have these fixes. > > On Thu, Mar 29, 2012 at 12:31 PM, Vadim Ushakov <ige...@gm... > <mailto:ige...@gm...>> wrote: > > Various bugfixes and ui impovements for libfm and pcmanfm: > > https://github.com/geekless/libfm > https://github.com/geekless/pcmanfm > > > -- > 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 > Lxd...@li... > <mailto:Lxd...@li...> > https://lists.sourceforge.net/lists/listinfo/lxde-list > > > > > ------------------------------------------------------------------------------ > 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 > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list -- Axel FILMORE |
From: Vadim U. <ige...@gm...> - 2012-03-29 18:08:07
|
> 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. :( > 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. :-) -- Regards, Vadim Ushakov |
From: PCMan <pcm...@gm...> - 2012-03-30 00:09:11
|
On Fri, Mar 30, 2012 at 2:08 AM, Vadim Ushakov <ige...@gm...> 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 > |
From: Alexis L. Z. <azu...@es...> - 2012-03-30 02:22:22
|
El 29/03/12 19:09, PCMan escribió: > When GObject is involved, the readability of Vala code tends to be > much better then its C counterpart. PCMan did you ever consider use C++ in the development of libfm. I have been making some experiments with GObject and C++ and I found that C++ is more efficient and clear when you are going to use objects. About libfm: Please count on my. Greetings Alexis López Zubieta University of Informatics Sciences 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci |
From: PCMan <pcm...@gm...> - 2012-03-30 11:04:12
|
On Fri, Mar 30, 2012 at 10:22 AM, Alexis López Zubieta < azu...@es...> wrote: > El 29/03/12 19:09, PCMan escribió: > > When GObject is involved, the readability of Vala code tends to be > > much better then its C counterpart. > PCMan did you ever consider use C++ in the development of libfm. I have > been making some experiments with GObject and C++ and I found that C++ > is more efficient and clear when you are going to use objects. > Yes, I did some experiments with c++ as well, but here are the drawbacks. 1. ABI instability. It's very hard to maintain ABI compatibility with C++. 2. Slow startup time and large symbol table due to unnecessary export of many long symbols caused by name mangling. 3. Significantly larger binary size + dependency on libstdc++. 4. UTF-8 support is not widely available. STL strings works with ASCII only. wstrings need additional encoding conversion. 5. No reference counting support. Using boost::intrusive_ptr may solve this, but the code will become very long. 6. Compilation is really slow for large projects. 7. Harder to debug. 8. Hard to use in non-C++ projects, such as some plain C programs and vala projects. 9. Too complicated and hard to master. Error-prone if not used correctly 10.Existing code is almost finished. Rewriting with C++ is just a waste of time. 11.Vala provides similar code readability but 100% integration with GObject without additional dependency. I think it's enough for me. 12.I fully agreed that the objects provided by C++ is cleaner than the terrible GObject runtime system. However, the additional costs and side effects it brings just offset the benefit. Porting to actually C++ means a complete rewrite. Personally I like C++ and use it under Windows since it's very difficult to develop Windows programs with plain C. In this case, I think C language is a more suitable choice, especially when it's intended to be used in other C programs. About libfm: > > Please count on my. > > > Greetings > > Alexis López Zubieta > University of Informatics Sciences > > > > > 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS > INFORMATICAS... > CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION > > http://www.uci.cu > http://www.facebook.com/universidad.uci > http://www.flickr.com/photos/universidad_uci > > > ------------------------------------------------------------------------------ > 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 > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Julien L. <gi...@ub...> - 2012-04-01 13:15:01
|
Le 03/29/2012 06:31 AM, Vadim Ushakov a écrit : > Various bugfixes and ui impovements for libfm and pcmanfm: > > https://github.com/geekless/libfm > https://github.com/geekless/pcmanfm > > Thank you for this, I already added some of them to the Ubuntu package for testing :) If you are looking for others fixes, you could check exo git repository, for the part libfm included (example : http://git.xfce.org/xfce/exo/log/exo/exo-icon-view.c). I added this commit also http://git.xfce.org/xfce/exo/commit/exo/exo-icon-view.c?id=7385e5018fe5eb0bdcd05eacdcf79dbd74406d9a which seems to fix a lot of crashes when doing mount / umount operations, and random crashes we had on Ubuntu. Regards, Julien Lavergne <http://git.xfce.org/xfce/exo/commit/exo/exo-icon-view.c?id=7385e5018fe5eb0bdcd05eacdcf79dbd74406d9a> |
From: PCMan <pcm...@gm...> - 2012-04-04 11:12:27
|
Hello Vadim Ushakov*,* I'm going to merge most of your changes to my libfm/pcmanfm repos since most of them look quite nice. Thank you. I, however, have some questions about this. 1. We're now preparing for 1.0 stable release, and the UI is now considered frozen. We can do the UI improvement in the next release, but not now. In addition, new strings cannot be added at the moment. So, I'd like to put some of your UI changes to a separate branch rather than master branch. 2. If I just want to pull your other fixes to my master branch, and leave your major UI changes in a separate feature branch, what's the better strategy to do it? Git cherry-pick seems to work in this case, but it seems to cause future merging problems as well. I'm not that familiar with git, so please give some suggestions. I'll try to incorporate your UI changes later, but for the incoming release, it's better to merge the important bug fixes first. Any suggestions on how to do this cleanly? I don't think forking the project is needed as we're mostly moving toward the same direction. Any chance to cooperate? If Vala is a problem for you, I'll limit its use in specific places only, such as the actions module. There is no plan to rewrite the program with vala. For thumbnail generation part, I used FmPath for hash key rather than FmFileInfo pointers simply because sometimes you may want to load a thumbnail but you don't have a FmFileInfo structure at hand. Requiring query of file infos prior to loading thumbnails can be expansive in some potential use cases. That's why it's designed like this. To improve performance, it's possible to cache the FmPath hash value in FmPath structure itself. Though this costs 4 bytes per FmPath structure. For the ffmpeg thumbnailer part, supporting external thumbnailers is planned, but I did not do it because there is no reliable way to correctly detect existing thumbnailers installed. There must be a way to detect available thumbnailers rather than hard-coding ffmpeg. In Gnome 2 the installed thumbnailers are registered in gconf. Too bad! However, we can generate a list with gconftool and cache the list so we don't need gconf at runtime. (this is not very clean, either). In Gnome 3, the way to install thumbnailers changed again, and it's even undocumented. In XFCE, they use tumbler and the way to install thumbnailers seems to be differ again. How to get a list of installed thumbnailers reliably? To best of my knowledge, I cannot find one. :-( Maybe we can have a cached list of thumbnailers once we have good gnome-independent ways to detect them. Any comments? On Thu, Mar 29, 2012 at 12:31 PM, Vadim Ushakov <ige...@gm...> wrote: > Various bugfixes and ui impovements for libfm and pcmanfm: > > https://github.com/geekless/libfm > https://github.com/geekless/pcmanfm > > > -- > 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 > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Martin B. / b. <br...@bs...> - 2012-04-04 11:21:38
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-04-04 13:12, PCMan wrote: > 2. If I just want to pull your other fixes to my master branch, and > leave your major UI changes in a separate feature branch, what's the > better strategy to do it? Git cherry-pick seems to work in this case, > but it seems to cause future merging problems as well. I'm not that > familiar with git, so please give some suggestions. A correct cherry-pick will be indentified and mergable. if the changes between the branches are too great the merge will fail but that should not be the case. Probably the easiest would be to have a multitude of branches maintained (like one per feature with only one or maybe two /small/ commits) and then rebase to have the same ancestors all the time. When ready to merge it is as easy as doing "git rebase master; git checkout master; git merge" - as the rebase will be without real impacts if the commits are small enough. (this coming weekend I will most probably be actively hacking on LXDE stuff. I am going away to get some peace from other distrubances. main focus will be to get lxdm and lxpanel going. if you want me to look at a git strategy for pcmanfm/libfm I probably will find time for that.) - -- brother http://sis.bthstudent.se -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPfC6xAAoJEJbdSEaj0jV70YQH/ArvM93TXY8sR0j4ll4rOMPe /lLhlXDYdf0Ch9H4Yzf1CuoZJFeTQChRz0jkFgkfG3h4qW6GI2AQB2HME5EQvMEw zBIlZEEElwX1C1L8GPAd6n39cDB9hFT7hzet3XCfaWtt29mSqV+x/OTQxDVP+1Vt xXQhCzwv1EK2IfJ+6RbVhUbGOkas7fhsUuNc6tN3ZBkUBhfRJap9i5uA3zT0FC7G HnASsy8xCFVfcLp99R5DqZIEfsPgx5FxmpVo40bWDuWZmbkXcTpn4eupbgpIujjl nch+x9ucBltOkk3ltGFIHjNRMv8fmo23u0wrY/mzdxlfVBDacODhQlHtFFrmckA= =n7kD -----END PGP SIGNATURE----- |
From: PCMan <pcm...@gm...> - 2012-04-04 11:32:06
|
On Wed, Apr 4, 2012 at 7:21 PM, Martin Bagge / brother <br...@bs...>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2012-04-04 13:12, PCMan wrote: > > 2. If I just want to pull your other fixes to my master branch, and > > leave your major UI changes in a separate feature branch, what's the > > better strategy to do it? Git cherry-pick seems to work in this case, > > but it seems to cause future merging problems as well. I'm not that > > familiar with git, so please give some suggestions. > > A correct cherry-pick will be indentified and mergable. if the changes > between the branches are too great the merge will fail but that should > not be the case. > Thank you. I haven't use git cherry-pick previously and a google search showed some side effects of it. So I think I need to figure out a better merging strategy prior to doing it. > > Probably the easiest would be to have a multitude of branches maintained > (like one per feature with only one or maybe two /small/ commits) and > then rebase to have the same ancestors all the time. > When ready to merge it is as easy as doing "git rebase master; git > checkout master; git merge" - as the rebase will be without real impacts > if the commits are small enough. > > The problem is, some of the changes Vadim Ushakov are big enough and touch the UI. Others are small pieces which fixes simple bugs. I'd like to merge the bug fixes first and leave the UI and string changes and new features for the next release. If you can take a look on this, that's really helpful. He really gets some nice fixes which I want to pull in very much. Some of the fixes seemed to solve some related problems lying in our bug trackers. Thanks > (this coming weekend I will most probably be actively hacking on LXDE > stuff. I am going away to get some peace from other distrubances. main > focus will be to get lxdm and lxpanel going. if you want me to look at a > git strategy for pcmanfm/libfm I probably will find time for that.) > > - -- > brother > http://sis.bthstudent.se > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBCAAGBQJPfC6xAAoJEJbdSEaj0jV70YQH/ArvM93TXY8sR0j4ll4rOMPe > /lLhlXDYdf0Ch9H4Yzf1CuoZJFeTQChRz0jkFgkfG3h4qW6GI2AQB2HME5EQvMEw > zBIlZEEElwX1C1L8GPAd6n39cDB9hFT7hzet3XCfaWtt29mSqV+x/OTQxDVP+1Vt > xXQhCzwv1EK2IfJ+6RbVhUbGOkas7fhsUuNc6tN3ZBkUBhfRJap9i5uA3zT0FC7G > HnASsy8xCFVfcLp99R5DqZIEfsPgx5FxmpVo40bWDuWZmbkXcTpn4eupbgpIujjl > nch+x9ucBltOkk3ltGFIHjNRMv8fmo23u0wrY/mzdxlfVBDacODhQlHtFFrmckA= > =n7kD > -----END PGP SIGNATURE----- > |
From: PCMan <pcm...@gm...> - 2012-05-07 18:23:35
|
Hi all, I just merged some changes done by Vadim Ushakov with git cherry-pick and they are in our git master now. I only merge the ones fixing bugs. Other new features which changes UI will be pulled into a separate branch for new features later. Now we're in a UI freeze state preparing for 1.0 release. Regarding to the thumbnail part, I did not apply them because: 1. I finished a better gnome3-compatible external thumbnailer support. Now libfm reads /usr/share/thumbnailers and generate thumbnails with the external thumbnailers. 2. The cache part and the "look for thumbnails" by fileinfo part requires some more review since that part is more complicated. To test the external thumbnailer thing, see external-thumbnailer branch of libfm. Things like ffmpegthumbnailer won't work since it supports gnome2 and write its config in gconf. A simple new config file put into /usr/share/thunmbnailer can fix this easily. Thanks On Wed, Apr 4, 2012 at 7:31 PM, PCMan <pcm...@gm...> wrote: > > On Wed, Apr 4, 2012 at 7:21 PM, Martin Bagge / brother <br...@bs...>wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 2012-04-04 13:12, PCMan wrote: >> > 2. If I just want to pull your other fixes to my master branch, and >> > leave your major UI changes in a separate feature branch, what's the >> > better strategy to do it? Git cherry-pick seems to work in this case, >> > but it seems to cause future merging problems as well. I'm not that >> > familiar with git, so please give some suggestions. >> >> A correct cherry-pick will be indentified and mergable. if the changes >> between the branches are too great the merge will fail but that should >> not be the case. >> > > Thank you. I haven't use git cherry-pick previously and a google search > showed some side effects of it. So I think I need to figure out a better > merging strategy prior to doing it. > >> >> Probably the easiest would be to have a multitude of branches maintained >> (like one per feature with only one or maybe two /small/ commits) and >> then rebase to have the same ancestors all the time. >> When ready to merge it is as easy as doing "git rebase master; git >> checkout master; git merge" - as the rebase will be without real impacts >> if the commits are small enough. >> >> The problem is, some of the changes Vadim Ushakov are big enough and > touch the UI. Others are small pieces which fixes simple bugs. > I'd like to merge the bug fixes first and leave the UI and string changes > and new features for the next release. If you can take a look on this, > that's really helpful. > He really gets some nice fixes which I want to pull in very much. Some of > the fixes seemed to solve some related problems lying in our bug trackers. > > Thanks > > >> (this coming weekend I will most probably be actively hacking on LXDE >> stuff. I am going away to get some peace from other distrubances. main >> focus will be to get lxdm and lxpanel going. if you want me to look at a >> git strategy for pcmanfm/libfm I probably will find time for that.) >> >> - -- >> brother >> http://sis.bthstudent.se >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQEcBAEBCAAGBQJPfC6xAAoJEJbdSEaj0jV70YQH/ArvM93TXY8sR0j4ll4rOMPe >> /lLhlXDYdf0Ch9H4Yzf1CuoZJFeTQChRz0jkFgkfG3h4qW6GI2AQB2HME5EQvMEw >> zBIlZEEElwX1C1L8GPAd6n39cDB9hFT7hzet3XCfaWtt29mSqV+x/OTQxDVP+1Vt >> xXQhCzwv1EK2IfJ+6RbVhUbGOkas7fhsUuNc6tN3ZBkUBhfRJap9i5uA3zT0FC7G >> HnASsy8xCFVfcLp99R5DqZIEfsPgx5FxmpVo40bWDuWZmbkXcTpn4eupbgpIujjl >> nch+x9ucBltOkk3ltGFIHjNRMv8fmo23u0wrY/mzdxlfVBDacODhQlHtFFrmckA= >> =n7kD >> -----END PGP SIGNATURE----- >> > > |