From: PCMan <pcm...@gm...> - 2012-09-15 03:25:08
|
Hello, I just added file searching capability to pcmanfm/libfm. However it is very primitive and is not finished yet. Some parts do not work and some UI needs polishing, too. At least this is a good start. :-) Source code is in 'search' branch of both pcmanfm and libfm. Please try it. BTW, the search branch of pcmanfm is done using git merge. Andriy will hate this very much, but the merge was done before he suggest using git rebase. I don't know how to convert the merged result to use git rebase instead. If someone knows how to do it, please help. Thanks! |
From: Stephan S. <gma...@sp...> - 2012-09-15 05:11:15
|
I noticed my own little git reference sheet didn't have that either, so asked in #git @ FreeNode. I haven't tried it yet, but here's the answer I got: 1) make a branch of master to keep track of commits after the merge 2) reset master to the commit before the merge 3) rebase search against master 4) merge master 5) cherry-pick those extra commits after the original merge (I assumed that you merged search into master and that you've since made other commits you want to keep.) Reminder: Until you're used to doing this, backup your repo first. On 12-09-14 11:25 PM, PCMan wrote: > Hello, > I just added file searching capability to pcmanfm/libfm. > However it is very primitive and is not finished yet. > Some parts do not work and some UI needs polishing, too. > At least this is a good start. :-) > > Source code is in 'search' branch of both pcmanfm and libfm. > Please try it. > > BTW, the search branch of pcmanfm is done using git merge. > Andriy will hate this very much, but the merge was done before he > suggest using git rebase. > I don't know how to convert the merged result to use git rebase instead. > If someone knows how to do it, please help. > > Thanks! > > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > |
From: Andrej N. G. <an...@re...> - 2012-09-15 09:49:36
|
Hello! PCMan has written on Saturday, 15 September, at 11:25: >BTW, the search branch of pcmanfm is done using git merge. >Andriy will hate this very much, but the merge was done before he >suggest using git rebase. >I don't know how to convert the merged result to use git rebase instead. >If someone knows how to do it, please help. It can be done very easy: 1) backup your working tree 2) remake it with rebase: git checkout search git reset --hard <last commit before your merge> <the rebase itself as I've written to you before> 3) sync if resulting tree is different from backup (not sync .git/ dir of course!) and make update commit if need 4) replace the search branch on remote with fixed one I'll try to find that commit a bit later if you don't do that yoursef before that. Andriy. |
From: PCMan <pcm...@gm...> - 2012-09-15 16:02:12
|
>On Sat, Sep 15, 2012 at 5:49 PM, Andrej N. Gritsenko <an...@re...> wrote: > Hello! > > PCMan has written on Saturday, 15 September, at 11:25: >>BTW, the search branch of pcmanfm is done using git merge. >>Andriy will hate this very much, but the merge was done before he >>suggest using git rebase. >>I don't know how to convert the merged result to use git rebase instead. >>If someone knows how to do it, please help. > > It can be done very easy: > > 1) backup your working tree > 2) remake it with rebase: > git checkout search > git reset --hard <last commit before your merge> > <the rebase itself as I've written to you before> > 3) sync if resulting tree is different from backup (not sync .git/ dir > of course!) and make update commit if need > 4) replace the search branch on remote with fixed one > > I'll try to find that commit a bit later if you don't do that yoursef > before that. > > Andriy. Thanks for your help. I worked on the search2 branch you created instead. Now the "search" branches of both pcmanfm and libfm are pushed to online git repo. Implementation of most of the features required by file searching are finished now. Access the new tool at "Tool/File Search" menu of pcmanfm. TODO: 1. searching based on mtime did not work reliably. There might be something wrong when calculating the timestamps? Check this later 2. The search result should always be shown in "detailed list" mode regardless of the default view mode set in config. 3. We need to add a column to the detailed list view to show the folders containing the found files. This column should only be shown for search://, not other folders, though. 4. Add a "Search files" item to popup menus of folders. When the preceding 4 things are done, we don't need other file searching utility in LXDE. The file searching feature built into PCManFM is powerful enough and can totally replace gnome-search-tool or catfish. Please help test the source code in our git repo if your're interested. Cheers! |
From: Axel F. <axe...@gm...> - 2012-09-15 19:24:41
|
On 15/09/2012 18:02, PCMan wrote: > 3. We need to add a column to the detailed list view to show the > folders containing the found files. This column should only be shown > for search://, not other folders, though. Windows Explorer and Nautilus also use the location column to display the original location of files in the Trash Can. Thunar doesn't apparently. ;) -- Axel FILMORE #--------------------------------------------# - Vala Desktop - An Experimental Desktop written in Vala https://launchpad.net/valadesktop #--------------------------------------------# - Vala Compiler - A Compiler For The GObject Type System https://live.gnome.org/Vala #--------------------------------------------# |
From: Stephan S. <gma...@sp...> - 2012-09-15 19:42:14
|
This reminded me of something I keep forgetting to ask. Is there any possibility that PCManFM will gain a filter bar similar to the ones in Dolphin and Konqueror? (So I can filter the list of files in the current directory by a substring rather than just the prefix that the built-in GTK+ listview search gives me.) On 12-09-14 11:25 PM, PCMan wrote: > Hello, > I just added file searching capability to pcmanfm/libfm. > However it is very primitive and is not finished yet. > Some parts do not work and some UI needs polishing, too. > At least this is a good start. :-) > > Source code is in 'search' branch of both pcmanfm and libfm. > Please try it. > > BTW, the search branch of pcmanfm is done using git merge. > Andriy will hate this very much, but the merge was done before he > suggest using git rebase. > I don't know how to convert the merged result to use git rebase instead. > If someone knows how to do it, please help. > > Thanks! > > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > |
From: PCMan <pcm...@gm...> - 2012-09-16 03:16:01
|
On Sun, Sep 16, 2012 at 3:41 AM, Stephan Sokolow <gma...@sp...> wrote: > This reminded me of something I keep forgetting to ask. Is there any > possibility that PCManFM will gain a filter bar similar to the ones in > Dolphin and Konqueror? > > (So I can filter the list of files in the current directory by a > substring rather than just the prefix that the built-in GTK+ listview > search gives me.) Yes, I plan to do that later. A filter bar at the bottom of the window can be handy. Having the view only show the files matched is possible. With the current code base of pcmanfm/libfm, this is not difficult. Thanks :) > On 12-09-14 11:25 PM, PCMan wrote: >> Hello, >> I just added file searching capability to pcmanfm/libfm. >> However it is very primitive and is not finished yet. >> Some parts do not work and some UI needs polishing, too. >> At least this is a good start. :-) >> >> Source code is in 'search' branch of both pcmanfm and libfm. >> Please try it. >> >> BTW, the search branch of pcmanfm is done using git merge. >> Andriy will hate this very much, but the merge was done before he >> suggest using git rebase. >> I don't know how to convert the merged result to use git rebase instead. >> If someone knows how to do it, please help. >> >> Thanks! |
From: PCMan <pcm...@gm...> - 2012-09-16 08:04:33
|
On Sun, Sep 16, 2012 at 12:02 AM, PCMan <pcm...@gm...> wrote: >>On Sat, Sep 15, 2012 at 5:49 PM, Andrej N. Gritsenko <an...@re...> wrote: >> Hello! >> >> PCMan has written on Saturday, 15 September, at 11:25: >>>BTW, the search branch of pcmanfm is done using git merge. >>>Andriy will hate this very much, but the merge was done before he >>>suggest using git rebase. >>>I don't know how to convert the merged result to use git rebase instead. >>>If someone knows how to do it, please help. >> >> It can be done very easy: >> >> 1) backup your working tree >> 2) remake it with rebase: >> git checkout search >> git reset --hard <last commit before your merge> >> <the rebase itself as I've written to you before> >> 3) sync if resulting tree is different from backup (not sync .git/ dir >> of course!) and make update commit if need >> 4) replace the search branch on remote with fixed one >> >> I'll try to find that commit a bit later if you don't do that yoursef >> before that. >> >> Andriy. > > Thanks for your help. > I worked on the search2 branch you created instead. > Now the "search" branches of both pcmanfm and libfm are pushed to > online git repo. > Implementation of most of the features required by file searching are > finished now. > Access the new tool at "Tool/File Search" menu of pcmanfm. > > TODO: > > 1. searching based on mtime did not work reliably. There might be > something wrong when calculating the timestamps? Check this later This one is already fixed and now works like a charm. > 2. The search result should always be shown in "detailed list" mode > regardless of the default view mode set in config. > > 3. We need to add a column to the detailed list view to show the > folders containing the found files. This column should only be shown > for search://, not other folders, though. This requires more rework of FmStandardView and FmFolderModel. Though it can be simply done by adding a "Location" column to FmStandard view, it's better to make this more flexible. There must be a way to specify what columns to show in a FmStandardView and in what order they're shown. For example, some API like the following may be needed. void fm_standard_view_set_visible_columns(FmStandardView* view, int columns_ids[]); int* fm_standard_view_get_visible_columns(FmStandardView* view); The variable column_ids is an array of integer ids of the columns to show. Another related question is, should we allow adding new columns to FmStandardView and FmFolderModel by the users of the library. This flexibility requires even more changes to the API, though. > 4. Add a "Search files" item to popup menus of folders. 5. folder paths might need to be escaped before added to the search:// URI. However, this hurts readability of the URI. It's no big deal since the URI is generated by the search dialog, not typed by the user. > When the preceding 4 things are done, we don't need other file > searching utility in LXDE. > The file searching feature built into PCManFM is powerful enough and > can totally replace gnome-search-tool or catfish. > > Please help test the source code in our git repo if your're interested. > > Cheers! |
From: Andrej N. G. <an...@re...> - 2012-09-16 10:18:11
|
Hello! PCMan has written on Sunday, 16 September, at 16:04: >> 2. The search result should always be shown in "detailed list" mode >> regardless of the default view mode set in config. I don't like the idea. Some may want to see search results with icon view for example. It should be done via 'per-folder view mode' setting which was discussed a bit already, BTW. >> 4. Add a "Search files" item to popup menus of folders. This one is pretty easy to do, even from pcmanfm - callback for folder menu designed exactly for such purposes. >5. folder paths might need to be escaped before added to the search:// URI. >However, this hurts readability of the URI. >It's no big deal since the URI is generated by the search dialog, not >typed by the user. It's common practice however - see search patterns in browsers. So the escaping is way to go. Andriy. |
From: PCMan <pcm...@gm...> - 2012-09-16 13:03:51
|
On Sun, Sep 16, 2012 at 6:18 PM, Andrej N. Gritsenko <an...@re...> wrote: > Hello! > > PCMan has written on Sunday, 16 September, at 16:04: >>> 2. The search result should always be shown in "detailed list" mode >>> regardless of the default view mode set in config. > > I don't like the idea. Some may want to see search results with icon > view for example. It should be done via 'per-folder view mode' setting > which was discussed a bit already, BTW. Adding many items to the icon view induced more UI flickering sometimes since this caused relayout of a lot of items. In detailed list mode, this also cause insertion of items and changed the layout, but the performance hit and flickering caused is less when compared to icon view. Besides, the most important issue is for two files in different folders with the same time, it's not able to differentiate them in icon view mode. In detailed list view mode, we can add a column for showing their locations. For usability and performance perspective, whether this is customizable or not, the search result should use detailed list mode "by default". Of course we can make this customizable and let the user change it, but detailed list should be the default. >>> 4. Add a "Search files" item to popup menus of folders. > > This one is pretty easy to do, even from pcmanfm - callback for > folder menu designed exactly for such purposes. > >>5. folder paths might need to be escaped before added to the search:// URI. >>However, this hurts readability of the URI. >>It's no big deal since the URI is generated by the search dialog, not >>typed by the user. > > It's common practice however - see search patterns in browsers. So > the escaping is way to go. > > Andriy. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Pcmanfm-develop mailing list > Pcm...@li... > https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop |
From: Andrej N. G. <an...@re...> - 2012-09-17 18:22:35
|
Hello! PCMan has written on Sunday, 16 September, at 21:03: >On Sun, Sep 16, 2012 at 6:18 PM, Andrej N. Gritsenko <an...@re...> wrote: >> PCMan has written on Sunday, 16 September, at 16:04: >>>> 2. The search result should always be shown in "detailed list" mode >>>> regardless of the default view mode set in config. >> I don't like the idea. Some may want to see search results with icon >> view for example. It should be done via 'per-folder view mode' setting >> which was discussed a bit already, BTW. >Adding many items to the icon view induced more UI flickering sometimes >since this caused relayout of a lot of items. >In detailed list mode, this also cause insertion of items and changed >the layout, but the performance hit and flickering caused is less when >compared to icon view. >Besides, the most important issue is for two files in different >folders with the same time, it's not able to differentiate them in >icon view mode. >In detailed list view mode, we can add a column for showing their locations. >For usability and performance perspective, whether this is >customizable or not, the search result should use detailed list mode >"by default". >Of course we can make this customizable and let the user change it, >but detailed list should be the default. That's OK for me but we should hardcode that behavior before we can make it customizable which isn't nice you know. But I agree, we can do it as temporary workaround. I would like you to test how "internal" VFS "example" for menu:// works so we can eliminate hardcodes for search:// too and migrate all its engine into VFS instead - that's not hard to do but will simplify things a lot. I think the sequence of branches merge should be now: 1) 1.0.1 is released; 2) two days timeout; 3) '1.0.2' rebased+merged into 'master', tagged 1.0.2~alpha0; 4) 'fm-file' rebased+merged into 'master'; 5) 'search' rebased+merged into 'master'; 6) FmSearchJob migrated to VFS; 7) search GUI moved from pcmanfm into libfm, tagged 1.0.2~alpha1; 8) let users test everything. With best regards. Andriy. |