Dear Levente, Dave, List,
here are patches with only the sample code of quick search.
I did not attached any backtrace, because there are several points,
where the program can suffer from segfault at my quick search, exactly
operations with original Object browser. Please do a second search,
don't finish at the first and you can see the error.
Please take me a better solution for copying elements of original tree
or how i can resolve this problem with GUI.
I used these patches on the last repository.
Sorry for the unfitted wxTextCtrl at new floating window, but at first
i couldn't create it with ctlTree.
Thank for your help!
Regards,
Marton Akos
On Mon, Mar 9, 2009 at 10:38 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Sun, Mar 8, 2009 at 11:31 AM, Levente Torok <toroklev@gmail.com> wrote:
>
>> Look. The problem is the following.
>> We have exteremely large number of items in the obj browser tree.
>> In general, this is very unpleasant to manually search for items in the
>> tree even if we know the exact name of it. For this reason we usually use
>> psql console since it has mighty tab completion.
>> If only such a quick filtering functionality would be integrated in the GUI, it would be extremely helpful.
>
> Except that, per my previous comments, it's like to be a lot more code
> and less useful than a true search.
>
>> (not to mention the console integrated in the pgadmin)
>
> It can easily be in 1.10, using the plugins mechanism - in fact
> integrating psql is our standard example.
>
>> I wouldn't like to do any click or key hit, if unneccessary and the synaptic's quick seach such as:
>> http://www.basicconfig.com/files/imagepicker/j/jinlusuh/Screenshot-Synaptic%20quick%20search%20seamonkey.png
>> are good examples of this but Compiz config, or KDE's control center are worth considering too.
>
> I understand what you are suggesting, but believe that in many cases
> *more* clicks will be required. A search results listing can easily
> show additional pertinent information about each matching object such
> as it's type, owner and comment. With a filter, you can view the type
> through the location on the tree, but that might require scrolling.
> For information such as the owner or comment, you must locate and
> click *every* object until you find the one you actually want.
>
> In addition, you could easily further refine a search results listing
> by sort by different columns, or applying filtering to the results
> list (for example, to only show objects owned by a certain user). That
> is much harder to present in a UI in the design you propose.
>
> What do others think?
>
> --
> Dave Page
> EnterpriseDB UK: http://www.enterprisedb.com
>
--
People seldom notice clothes, if you wear a big smile.
OLVASD: http://napirajz.hu
