Don't allow modifying limit filter. Reason being:
1. As it is unrelated to search.
2. It will be irregular to allow changing the limit when advance
search syntax is enabled but not in the other case. If it's that
necessary, an option can be added to change the limit.
To load an NAT, track's xml node is required. So I've created a
tuple wth track's xml node alongside with a Track(local) object,
and appended them to the search_results list.
Reason being, I'm planning to add two more builtin search dialogs.
One for album and one for artist. It makes more sense to move
(possibly) common code to a separate class.
Some noticeable points:
* No need to separate code for auto lookups and searches. Only
the dismax filter setting and escaping lucene syntax part is
additional in searches. Rest is same for both.
* No need to pass advance query setting as argument. It can be
retrieved directly.
By "result space" I mean the area where feedback to user is
shown , i.e. progress, error and search results. As it is
updated frequently, rather than inserting and deleting widgets
directly into main layout, i.e. verticalLayout, updated a dummy
widget (i.e. center_widget), instead. This helps in two ways:
* Specifying widget properties for this one only.
* Layout remains unaffected.
* For further searching without closing the dialog.
* Pressing <Enter> after inserting a search query in the search
box would result in closing the dialog rather than searching. This
needs to be fixed.
* AttributeError will be raised if the tracks are loading (
self.tracksTable will be undefined) and accept is triggerred.
Handle this case.
* Merge track_selected() and closeEvent() functionality into
self.accept().
If user chooses to, i.e. if config.setting["builtin_search"] is
set.
Don't pass the file object to SearchDialog.__init__(), as same
class is used for displaying search results, for which there are
no linked files.
Don't return list of release. Release list can be extracted in
searchdialog.py. This is to make searchdialog.py more generic.
Same method (i.e. parse_tracks) can than be used to parse track
node for both displaying similar tracks and searching.
Search results table isn't setup immediately after dialog is
displayed. Thus it's header state needs to be restored later, and
hence a separate method for that.
