Improvements to search in Adept3

Regarding 2):

I triaged this a bit and it seems that Adept3 searches for partial matches in package names. However, only the first word in a package name seems to be recognized. E.g. "phy" will show phylip, "phys" will show dphys-swapfile. "paw" and "paw-d" will show paw-demos, while "demos" will not.

In the descriptions, matches are only shown for full words. E.g. "physic" will show no results, while "physics" will give you a host of them. As a further experiment, the package paw-demos is decribed as "Physics Analysis Workstation ...". So to find it from the description, one needs to search for "phsics", "analysis" or "workstation", while "phsic", "analys" or "work" will not work.

This is confusing and strange. Moreover I'm not exactly sure, I've figured out the search behaviour correctly.

So the search behaviour should deffinitely be improved so that Adept finds parts of any word, be it at the beginning, the end or somewhere in between, in the package name and in the description.

This way the user will always find what he wants.

3) Begin search with 2 or 3 characters:

Timbl explained (https://bugs.launchpad.net/ubuntu/+source/adept/+bug/263438/comments/25) that Adept 3 requires at least four characters to start searching.

This behaviour is not expected by the user, who probably used search in the KDE4-menu (Kickoff) or the Alt-F2-menu (whatever it's called) before. The KDE4-menu will search upon the first character entered while the Alt-F2-menu needs two characters. So it would make sense to allow search with 2 characters in Adept to have at least some consistency.

Furthermore, with the current search users won't (easily) find certain apps/packages, whose names consist of only 3 characters. E.g: VLC, K3B, Ark, GCC. Because of this, I consider searching with 3 characters a mandatory feature (as far as usability is concerned). No packages/important keywords with only 2 letters come to my mind, however as stated above, a 2-character search would (in my eyes) be even better.

Only Wishlist? This is a high usability bug. They are a lot of some important packages with 3-character name. I think that this bug is marked only as Wishlist because it affects to Kubuntu. Canonical doesn't show love to Kubuntu.
Synaptic shows packages for 2-character search, and they are some software with 2-character name. for it, Synaptic shows they.
And, for packages with one character in the name, Synaptic has the classic search mode. But Adept doesn't have it. :-(

Yes it is wishlist because Canonical doesn't love us even though we are Canonical's bitches and get money for reading such completely pointless and irrelevant comments.
I really suggest you stop blaming all the crap on Canonical, in fact I would suggest you read up on who is actually creating Kubuntu and if they are really idiots who can't follow their own rules for assigning the right importance to bugs.

Quoting from the Wiki:
Wishlist: a request to add a new feature to one of the programs in Ubuntu.
These aren't always bugs, but can be ideas for new features which do not yet exist.
These can also be requests to have software packaged for Ubuntu.
If it is non-trivial to implement, it should rather be written as a feature specification, see FeatureSpecifications

As my bug 292699 has (incorrectly in my view) been marked as a duplicate of this, I will repeat my comments from that bug here. My report doesn't constitute a wishlist, unless wanting an application to actually function fits that description.

The new adept manager installed with 8.10 does not function properly.

Biggest problem: it doesn't show all available packages. In fact when you search for a package, it shows an entirely wrong set of packages. For example. Search for "apache". There's no sign of any apache packages shown, but Adept lists
libclucene, libssl,librpc-xml-perl and ksystemlog. Apache CAN be installed using "apt-get install apache2" so the repository list obviously knows about it.

This is a real pain because I seem to be lacking some Apache support files and with a working Adept I could find them, but with this I can't.

The "state" and "requested" section is also totally un-intuitive. I THINK I've just about worked it out now, but I'm not certain about that.

For the first It would reach when Adept 3.0 begin the search, after the second or third character is typed. For Fine tuning, later is still time.

Why four? I think it is important to change that as soon as possible. There are many many packages that have only three Characters and there are also a few that have only two!

The way I see it version 3.0 is huge step back. A lot of useful functionality gone, only bugs added. Probably the only feature that I do not miss is the usage of tags - never found them being useful.
All other stuff just disappoints:

1) Search is limited to 4 symbols, if you are going to introduce such feature have it disabled by default, and switch to turn it on well hidden
2) The search return unpredicted result, I can find these packages with apt-get, but they are not listed in adept manager
3) Packages are not listed
4) There is no list of all packages
5) There is no way to see complete description of package for some packages
6) During some operations you can see 'Fail' statement, but passes so fast and latter on, no way to see what was wrong.
7) There is no way to have more than one filter.

I really can continue this list for very long. My suggestion is take a previous version of Adept and put as many things back as you can. BTW layout before was better too. It was ugly but better.

I am thinking about installing synaptic, I do not want to, but have no other idea how to manage packages, unless go to command line tools completely.

If I type one or two * before the search-entry, Adept also find packages with only two or three letters.

For exsample: *vlc

Certainly not ideal, but better than nothing until an update appears.

This post should probably be titled "Fixes for Adept search." The definition of "search" as understood by most users is that you get hits which contain your query. Any search that fails to return a package named "foo-bar" when you type "bar" isn't actually searching. What it's doing now is giving results only based on the start of the package name. This is called "sort and jump".

I do not understand the reason why old one was removed. It was so much better: it looks better, it has better functionality and most importantly it works. Can someone explain what was the reason to replace it instead of porting to new libraries?

The search in adept is pathetic that I now use synaptic even though it looks ugly.

Can somebody explain to me why, in the past 17 months the only action taken on this bug is to reduce the importance from High to Wishlist (by the same person who set it to High in the first place)? This is really sad. Inability to do a proper search is not a wishlist issue. Maybe the point is moot now that KPackageKit is the package manager of choice? If so, then just be honest and mark "Won't Fix". Crap like this is what makes me think I'm just wasting my time trying to contribute to Ubuntu bug triage. We rarely fix anything, we just fiddle about on launchpad until the problem goes away (or the people who complained in the first place lose interest).

FYI: it's still hopelessly broken on Karmic.

Guess I'll do my triage bit here, mark it incomplete, and ask if anybody's having this problem on the latest Lucid? Next month we can mark it incomplete again and ask if it's still a problem on the latest Maverick...

Uh, yeah. It's still there. The Adept person no longer works on this, and as this is no longer the default package manager, this issue is less important.

Unfortunately, Adept has been unmaintained by its original authors for several years, and nobody has stepped up to continue its development. (Though the Muon Suite is arguably its spiritual successor) As such, Adept has been removed from releases of Kubuntu from 12.10 onwards, and no additional improvements will be made to the software.

We thank you for reporting this bug all the same, and apologize for taking so long to respond to it.