gcmd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gcmd-dev] Search to be removed from Gnome Commander(?)


From: Uwe Scholz
Subject: Re: [gcmd-dev] Search to be removed from Gnome Commander(?)
Date: Thu, 13 Jan 2022 22:22:19 +0100

Hi Michael,

Am Wed, 12 Jan 2022 23:09:35 +0100 schrieb mi:
>
> Uwe,
> 
> > I could close all open issues which are waiting for the 1.14.0 release.  
> 
> Amazing .... Congrats ! And thank you so much !
> 
> > All but one. ;-)  
> 
> aaargh
> 
> I think that with the given conditions, your suggestion of
> 'outsourcing' F9 search makes sense. It also fits into the good old
> philosophy of a chain of specialized tools.
> 
> > There are some graphical alternatives for file searching, like for
> > example catfish or recoll.  
> 
> I did not try these but on first glance, recoll is based on QT
> libraries and xapian, which is a heavy weight, whereas catfish is
> rather light, depending only on a few libgir and python. I'd think
> that the latter fits better to gcmd.
> 
> The drawback would probably be 'integration'. Would it still be
> possible to have gcmd 'work' on the list of results (files) ? Or
> maybe catfish has some basic capabilities too.
> 
> I never really used F9 because i'm usually kicking off a terminal for
> more complex file operations. But with F9, we can apparently use copy
> or move, and it would probably possible to make the advrename tool
> work on the results too.
> 
> The question is, what is it that the average user wants to achieve.
> And i believe the standard aim is, she just wants to find a lost file
> to look into it or move it to a better location. Or delete it.
> 
> And most modern desktops anyway try their best to make it superfluous
> to create folders and sort anything at all (resulting in a horrible
> mess on disk) so modern users won't use F9 for cleaning up anyway.
> 
> That's why i think the most lightweight capabilities would be
> sufficient.
> 
> But we could also decide to be different and offer more capabilities
> just because it's a Commander - and not Apples 'Finder'.

Actually I would be sad if we would have to remove the internal file
search. But I have spend quite a lot of time with this problem now and
did not find a solution for it. And the feature itself seems to be
something not many other linux file managers provide. Hm. 

From a user perspective of curse it is up to her to select whatever
external file tool she wants :) I think we should leave the default
search command empty so that the user has to decide which tool should
be started when pressing F9. We should simply show a message dialog that
the search command is empty when using it the first time.

Interestingly, when I testing catfish I found two issues: First thing
was that it is not able to search on a connected samba share (I did not
try a FTP folder). And also I could not open a local folder in which a
found file is located, from within catfish by calling a file manager.
In this case I got an error (in Gentoo Linux) which was already
documented for Fedora just recently:
https://bugzilla.redhat.com/show_bug.cgi?id=2009994
Hello Mamoru! ^_^




reply via email to

[Prev in Thread] Current Thread [Next in Thread]