The All Packages list is already relatively compact, the one here is just about ~40% taller. We could move the search bar to the bottom below the package list to connect these.
The current HaikuDepot is somewhat cumbersome. To view all the app information, manually drag the divider and then return it to the list (back-and-forth). It’s an odd flow.
I’ll leave the designs here. That’s all from my side for the time being
An easy solution for that would be to switch the Category popup and Search terms text field.
IMO the lists are compact enough with the 32px-icons-double-lines. If the list is so vast that you long for 16px-icons-single-line, I’d rather add terms to the search to prune the results…
A few comments, even if the designs aren’t further explored by @Nukacal for now. Thanks for your work so far anyway, they surely are hearty food for thought!
Thank you! I don’t want to leave this hanging. I’ve tried to incorporate your feedback here. If we can reach a consensus, hopefully, this can become the blueprint for the next version of HaikuDepot
If there’s more to address, I’ll pick it up when I can
Personally I want a tab between featured and all packages, that would list all “usefull” packages. i.e gui apps… currently this is done with show->dev packages and such, but this is a bit annoying.
That is not directly relatedto your design however. The current iteration apart from not beeing “pixel perfect” (i.e some elements like the splitter or the scrollbars are not perfectly aligned) seems quite good to me. The final render with a working gui would probably look even better.
If there are no hard objections I’d move to try and implement this in an experimental fashion
Please, no 
There is no need to list “all pacckages” without any filtering. No one is going to read through a list of thousands of packages.
We need a list that always shows search results. The default search can be “featured packages” and then you can edit the search request, to list only a category, seargh by name, etc. This will not be implemented with tabs. It should look more like Tracker queries window, maybe with an unfoldable “advanced search” panel if we don’t want to put search terms at the top level.
In that situation, the compact mode of the list doesn’t need to be usede. Search results can appear in big entries with useful info as the featured view does currently.
I’m a bit confused where you read that from. I am annoyed that it works like that currently, I did not say that I want an unfiltered list.
Agreed. I’d use the term “end-user packages” or “user-facing apps” or something, but I fully agree with the idea. We can fight about terminology later. We may already have a mechanism for it.
When I set the prominence of an app I have the following choices:
100 gets an app on the Featured list
200 creates a second alphabetized Featured list after the first one, which is … a bit weird. I discussed it with Humdinger but we decided against using it.
300 currently does nothing AFAIK
1000 is what I use to take an app off the Featured list.
So a setting of 300 or below is available to mark GUI apps. Marking the apps is an afternoon’s work. I don’t mind doing it. Coding the new tab I will leave to my betters.
Not saying this is the most elegant solution. But it is available.
This should probaly be automated instead, if this is not tagged yet already, this is not something that should be a manual task. It may only be an afternoon now, but it will be endless work catching up in the future… 
I think the difference between Search and Filter needs to be clearly defined.
When you Search you add items to a list. When you Filter, you remove items from a list.
When the user performs a search, a new list of the search results should be created. The results could be presented in a new tab.
All tabs, whether search results or pre-defined (“Featured packages” or “All packages”) can then be filtered. The filter should probably be per list, meaning per tab.
This removes any need to define whether a search should be performed on “Featured packages” or “All packages” and all the user confusion this is currently causing. “Searching” in those tabs should be performed with a filter.
TLDR: Search results should be shown in a new tab. Each tab should be able to be filtered.
@Nukacal Do you have an example with the “new” view with a screenshot? with humdingers header feedback applied.
This is the first wip version (one line change, heh)
I’d put the screenshot below the description.
How would you deal with that for example for this? The description is quite long, and could be even longer… i don’t have any space problems on a 4k screen, but this should be useable aswell on a smaller screen, and argueably a screenshot is important for identification… if it isn’t, and this is supposed to be like a screenshot library it would make sense to have it below
edit: with defaults
Correct; see the constant PROMINANCE_ORDERING_PROMINENT_MAX in HaikuDepotConstants.h which is currently filtering anything < 200.
I’d be interested to hear what a more elegant solution might look like. This seems to be easily comprehensible, is easily administered and works reliably all the time.
Can you explain how you would automate this?
If something is a GUI app or not? I figure this is either already done (because apps have an “open” button), or this would be done by either checking launch flags, or if the binary has a ressource section with a mimetype
Ah yes that is done by looking for deskbar links. You can find this logic in PackageManager::_CollectPackageActionsForActivatedOrInstalled in the file PackageManager.cpp.
I love the UI proposed by @Nukacal for the HaikuDepot!
I have always found the position of the search form weird, as in, visually disconnected from list it is searching. Now that it is above the package list, I think it is much more intuitive as to what it will have effect on, but perhaps right above the package list (under the tabs) could be better?
Anyway, IMHO, your work is awesome! Keep it up!
It’s probably not very practical to filter for this on the client-side (in HaikuDepot) though because I would imagine that it is trawling through the HPKG contents which would be very time-consuming to do in bulk for many thousands of packages.
On the HDS server side however I do pull changed HPKGs down and parse them there already to extract the HVIF icons. I could probably also mirror this process of looking for the deskbar links, capture that in the database and then feed it back out to HaikuDepot in to use in bulk.
However there’s a problem working on HDS at the moment owing to not being able to apply a change to the Kubernetes cluster.
I’m actually wondering, isn’t that possible with the files list aswell? it seems very tedious to have to download and install a package only to figure out it doesn’t have what i want. Though i can understand if that data is too much to store serverside.
You should be able to detect anything starting with “app:” in the package provides, and that info is available in the HPKR file without needing to download anything.
I don’t know how that would fit into HaikuDepot’s logic and if it allows to access that however.
Also it assumes recipes correctly declare apps as “app:” entries.
Actually you’re right; it is probably possible to extract the information from the HPKR instead. In any case I have to download the HPKG to extract the icons anyway.
I’m doing this in Java inside the application server actually so the package does not get installed. It’s running on a Debian container image.
HDS is operating a PG relational database of the metadata it captures from the packages (also screenshots, icons etc…) so it discards the HPKG after it has processed it.
