Request for more filtering options on search

Bug #326541 reported by mabuse
2
Affects Status Importance Assigned to Milestone
DC++
Fix Released
Undecided
Unassigned

Bug Description

It would be a really handy feature to define own "filetype" filters.

For example we do have a file tye "archive" that would give you only zip, rar, ace and lzh-Files.
It would be really cool to add mx own types like for comics: cbr, cbz, cba, ace, zip, rar, lzh and folders.
So that I don't have to scroll trough endless lists of mp3 . . .

As far as i have been told is that an idea that would require changes in the protocol or the hub software, so I suggest an additional local filter: Search for all files on the hub, but show only . . .

Thanx for a great software!
mabuse

Revision history for this message
eMTee (realprogger) wrote :

Ok here is a patch proposal for configurable search types for ADC using the EX parameter of SCH command while still retaining the current way of search for NMDC.
This adds 5 predefined search type groups as in SearchManager::TypeModes and gives possibility to add unlimited number of user-defined types. There's a new pane in Settings to manage them. It stores the extension list in DCPlusPlus.xml in an ID - extensionlist pair format. ID is a name given by the user for user-defined types, for predefined types the ID is the corresponding enum in SearchManager::TypeModes and the GUI should show their predefined translated name for them.
At the time of search if a predefined type selected, it will send the defined extension list with SCH in ADC hubs and will do the same as before in NMDC hubs. If user-defined search type selected, it works on ADC only, for NMDC hubs it'll send TYPE_ANY with the search request.
Predefined types can't be deleted atm, this can be allowed later when NMDC support is dropped.
Please comment.

Revision history for this message
Toast (swetoast-deactivatedaccount) wrote :

im good with this patch im supporting this :)

Revision history for this message
Big Muscle (bigmuscle) wrote :

To patch: file extensions are already defined in ShareManager, so I don't see any reason why to define them again in SearchManager.

Revision history for this message
poy (poy) wrote :

very good patch overall, i have a few remarks:

- i would prefer having a vector (StringList) carried around instead of a string that has to always be broken up between its ';' chars and created again. then the function in charge of loading / saving to file will convert between the vector and a plain ';'-separated string.
it would simplify functions like SearchManager::checkExtensions which won't have to remake a new string but will just filter the vector it has been given.

- is there a reason for having search types managed by the search manager? they seem to never interact with the search manager; they are only a setting, so it might be more logical to put them in the settings manager (as is done for connection types for ex).

- how is the NMDC situation handled? when selecting NMDC hubs in the search window and using custom search types, the user should be made aware that her types aren't going to get applied.
also, what happens if a user modifies one of the predefined types?
how about keeping a cached list of default search types for NMDC, so they don't have to be queried for again before every search?

Revision history for this message
eMTee (realprogger) wrote :

For (1) I chose this to have the simplest data type to store the extension data in, if its more optimal to store them in a larger and more sophisticated object I can change it.

For (2) I put it to search manager because these data belong to searches and it is the used model in eg. ShareManager or WindowManager with their own data. However, putting it to SettingsManager sounds more reasonable not to say that a bug I found when the settings file does not extist yet is easier to fix this way.

(3) I also thought that some warning would be nice to show when a custom search type selected and there are any NMDC hubs online. My ideas were put a warning message to the statusbar or add '(ADC only)' to the custom defined names in the dropdown elements. Any better idea? (Btw. in the settings pane there is a warning that the types configured here have affect on ADC searches only)
Users cannot modify/delete the name of predefined types (only the extension list). This can be allowed later when NMDC support is dropped.
I don't understand the last question. Extension list for both of predefined and custom searches can be changed between searches. The only thing can be done is to skip querying the ADC extension list when there aren't any onine ADC hubs.

Also the predefined extensions in the patch are for testing only, I'd like to see proposals for default extensions for the 5 predefined groups. I think there should be no more than 15-20 extension per type.

Revision history for this message
poy (poy) wrote :

i've added a generic StringListDlg that i would like to see used here instead of asking the user to put ';' to delimit extensions. this way, a simple list can be used everywhere and semicolons will only appear when interfacing with the settings file.
as for performance, there's almost no overhead to using a vector; actually, when micro-optimizing a vector may even be better than all the ';' chars... but the main reason to have a list here is not performance but plain logic; semicolons only make sense in the context of loading & saving to file.
the StringListDlg allows customization of the addition command (see the public hub list dlg for an example) so invalid extensions can be checked for when they are individually being entered instead of when validating the whole list.

as for the NMDC problem, i would like not having to see legacy types when i have selected only ADC hubs, but this can be thought of later on.

Revision history for this message
eMTee (realprogger) wrote :

Patch rewritten to meet poy's requirements...

Revision history for this message
poy (poy) wrote :

applied with various little touch-ups.

Changed in dcplusplus:
status: New → Fix Committed
Revision history for this message
eMTee (realprogger) wrote :

They were more than little touch-ups, really ;)

However, to make things really usable I'd like to propose some changes in the StringListDlg level, which I believe would be better for either HubListDlg and SearchTypeDlg :

- Make sure extisting string cannot be added again
- After addition the focus would be nice to be moved back to the input line, and also the just added value would be nice to be deleted or at least selected (to be able to easily type the next thing to add)
- It would be useful to change so pressing Enter in the input line would call Add and not close the dialog without adding the current value.

Revision history for this message
poy (poy) wrote :

ok, all done.

Revision history for this message
eMTee (realprogger) wrote :

SearchTypeDlg::getTitle() adds the SearchTypes enum instead the real name for predefined types... maybe

=== modified file 'win32/SearchTypesPage.cpp'
--- win32/SearchTypesPage.cpp 2010-07-05 20:17:42 +0000
+++ win32/SearchTypesPage.cpp 2010-07-05 20:43:20 +0000
@@ -193,7 +193,7 @@
   return;
  }

- SearchTypeDlg dlg(this, Text::toT(name), extListT);
+ SearchTypeDlg dlg(this, types->getText(cur, 0), extListT);
  if(dlg.run() == IDOK) {
   StringList extList;
   Text::fromT(dlg.getValues(), extList);

(not tested)
above this all look ok.

Revision history for this message
poy (poy) wrote :

Fixed in DC++ 0.770.

Changed in dcplusplus:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.