grc: implement search for blocks in flow graph

[ZakyHermawan]

Description

it is getting harder to search for blocks in flowgraph once the flow graph getting bigger,
this PR will Implement quick search for blocks in flowgraph,
matched block will be set as selected, just like when you click or block some blocks in flowgraph

search shortcut: Ctrl+g
a window will pop to ask user to input the block they want to search
you can press enter or click the ok button to begin search

the searching process is done by using simple substring matching with each block.name in flow graph

Related Issue

Fixes #5983

Which blocks/areas does this affect?

grc/gui/Actions.py: add a new action to search for blocks in flow graph with gtk
grc/gui/Application.py: select all searched blocks
grc/gui/Dialogs.py: make a new EntryDialog class to take user input for block search
grc/gui_qt/components/window.py: register action for block search in flowgraph

Testing Done

UI Test on gtk and qt gui

Checklist

• I have read the CONTRIBUTING document.
• I have squashed my commits to have one significant change per commit.
• I have signed my commits before making this PR
• My code follows the code style of this project. See GREP1.md.
• I have updated the documentation where necessary.
• I have added tests to cover my changes, and all previous tests pass.

[willcode]

Would you add a screenshot?

[ZakyHermawan]

@willcode here's the screenshot of the UI testing

with qt gui:

with gtk:

[willcode]

Ok, interesting. Let's get some opinions on whether this would be used by other people. We don't have many modal dialogs, so I'm also not sure whether a search field or a dialog is a better choice.

[ArlinJae]

GNU Radio user here, would 100% use this

[willcode]

@haakov @dl1ksv @marcusmueller @mormj I could use some opinions on this. It may just be my lack of imagination, but I can't imagine knowing there's a certain block somewhere, not being able to find it on a well organized flowgraph, and having this be useful.

[dl1ksv]

In my opinion, the examples are not a proof, that you need a search function to find a special block.
So I looked for a more complex example in gnuradio.

But even here I'm in doubt if a search function will bring a real advantage.
May be the fg would be clearer if the the different block types ( filter, math ) would have different colors.

Another solution could be an additional tree list containing the used blocks. Just like the already existing list of available blocks. And clicking a block in the used blocks list could lead to the block in the fg.

But if you implement a search function , don't use a modal dialog, but use an entry in the menu bar.

[willcode]

I kind of like the idea of an additional panel showing the blocks by both type and name, though name is usually something ugly like blah_source_0_0. This could, perhaps, be combined with the variable editor so we don't need a new panel.

I'm going to close this PR. I don't see us going this route. Thanks for thinking up new functionality. If you think of a way to combine the variable editor and a block listing in an easy-to-read way, I'd be interested.