Suggestions to improve Haiku Depot

I would like to share with you some suggestions and ideas to improve Haiku Depot or expand its capabilities. I consider the first 3 the ones should be implemented, and 4 to 6 would need more development or discussion. Any comment will be welcome.

  1. Cancel button

Problem

When you click “Install” button after selecting a package to install, this button turns grey (and hence it isn’t clickable), after some seconds it turns into a progress bar (also not clickable), and finally when the process is done two buttons appear: “Open” and “Uninstall”.

However, if you regretted about installing that package in the middle of the process, you are unable to stop it, and you can only uninstall after it spent some of your time, internet data and space in disk.

On the other hand, if the package has dependencies, first the “Install” button after clicked turns grey and then changes to a progress bar. But after some seconds a popup appears asking if you want to install the needed dependencies. There you have two buttons: “Apply” that follows with installation and “Cancel” that allows you to cancel the whole job.

Solution

Once the button “Install” is clicked, it should become immediately “Cancel” or “Abort”. The progress bar could be either alongside or below on the status bar. If the user decides to press “Cancel”, then all the job is discarded and the system should revert to its previous state like nothing has been done, and the caché of the downloaded parts should be deleted.

  1. Menu item "Show pending"

Problem

When you click on several packages to install and then click other packages’ entries to see them, would be hard to find what packages you chose to install and are being installed or in the queue waiting to be installed.

Solution

Add in menu “Show” an option “Show pending” to filter what packages are being installed or are waiting to be installed.

  1. Ratings’ filters

Problem

Currently there isn’t many ratings to applications (yet). But in the case there would be a lot of them, would be hard to find specific ratings or to read them comfortable. Also would be mixed reviews in several languages which you couldn’t understand or the reviews are (or aren’t) relevant to certain versions of the application.

Solution

Add a dropdown list to filter ratings by language and another one by version. If the rating hasn’t a language specified or it doesn’t contain text, it would be found in a default option like “No language”.

  1. [Idea not to consider very soon] Integration with proprietary repositories or repositories with paid software

Issue

Since Haiku is still a ongoing process in beta stage, there is currently almost none software providers who are selling software targetted to Haiku (the only exception I’m aware is TuneTracker Systems). So if you want to install proprietary software or software you purchased in advance (such as old BeOS software) you have to install them manually, or in the best scenario, the package could be opened in Haiku-Depot to be installed.

The current situation is that Haiku-Depot was thought as the place to install software that doesn’t cost money: search, click install, use. But in order to encourage more software companies to add Haiku support to their products and allow an easier experience to users that want to install these softwares, there could be a way to allow repositories to send not just the cryptographic key and name, but also describe other information such as if the software can be automatically installed or has to be purchased first.

What could be done

Allow repositories to send more information to client such as if software has or not source available, if it could be installed or has to be purchased and in this case the link to the website where the user can install it.

If Haiku Depot detects that an application does cost money, then it won’t show “Install”, but “Buy” instead. Clicking that button would open the default web broser to the software url.

There would still be some problems: if you are directed to the website to purchase the software, then you probably open your account in company’s services (if necessary), pay and claim the serial (if applicable). After that you would download the HPKG package and double clic to install in Haiku Depot. In this case it wouldn’t make any sense to allow proprietary repositories or repositories with non-gratis software: you could go directly to company’s website to the whole process. The only thing that having a propietary repo would be useful for is to get updates of the proprietary or paid software.

To address the aforementioned issue and make possible to install such software, it would require to add additional capabilites to Haiku Depot: add a service to allow logging into company’s services to install the software if you have already bought it, otherwise it would direct to their store.

Please keep in mind that this idea needs to be worked a lot to even consider it seriously.

  1. Package caché policy

Problem

Currently when you uninstall an application you installed from the repositories, it will be gone and deleted. Then if you find yourself without internet and wanted to reinstall that application again, you won’t be able to reinstall it until you find a connection or downloaded it in advance or in an USB stick. Or just would exist the case you want a specific version of the package for whatever reason.

Solution

Add a caché policy configuration to allow the user to decide if he/she wants to keep a copy of the package once uninstalled in case he/she wants to reinstall it under lack of connection scenarios. The cache policy should be configured as “Enabled” or “Disabled”. In case it is “Enabled”, it should allow user to configure the max. size of the cache before it has to delete the lower priority packages in caché (the priority itself would have to be defined), or the max. age after which the older caché packages would be deleted, or if previous versions should be kept or not. If Haiku Depot (or the system) would support storage of previous versions of the packages, then alongside of button “Install” could have a “Revert to previous version” button that once clicked, it should warn user what could happen if he/she reverts to an older version.

  1. Smart dependencies tree handling

Problem

If an application has dependencies, Haiku Depot will install them before installing the requested application. But if you uninstall that application, the dependencies are left installed even if they aren’t useful to the system or other installed applications.

Solution

As it happens with apt in Debian based OS when running “apt-get autoremove”, Haiku Depot (or the underlying package management system) should be able to know if dependencies that are left behind are not used anymore and if that’s the case, ask the user if he/she wants to uninstall them too. In order to avoid any issues in unresolved dependencies (such as in case applications that are not packaged in HPKG or under development that need the dependency), this option should be disabled by default.

Not true, they will be moved to the state folder in the /system/packages/administrative.

I agree. You may want to create an enhancement ticket at the bug tracker for that. I suggest being as concise in the ticket description as possible and if needed add a link to this thread.

The problem here is that to have only the pending jobs shown, you’d have to remove the checkmarks of all the other filters (available, installed, develop, source). One at a time…
I’d suggest, now that we have lists in tabs (“Featured” and “All” (in the nightlies)), to add another tab “Pending/Downloaded” that collects all the packages you install in that session.

As miqlas pointed out, it isn’t gone when uninstalled.
Instead of a configuration, I’d rather the system transparently first looks into the “administrative” folder if the needed package already exists and install it from there. In such a case the button should change from “Install” to “Reinstall”.

Mind you, I don’t know how well HaikuDepot currently works offline. Does it show the (cached) list of applications so a not-installed package can be chosen?

Ratings are already filtered according to your Locale preferences, so only languages you can understand will be shown.

You can add custom repositories in the Repositories preferences. I guess people wanting to “lock” their repo to specific users would use HTTP authentication here, or some GET parameter in the URL. Both should just work already.

HaikuDepot and SoftwareUpdater will then show the packages as usual.

The app is also missing a Quit option in the Tools menu.

It would be nice if you could just click on a URL to a repo and it get automatically added instead of having to enter it manually.

Actually it would be nice if some of Haiku’s config files moved toward formats that remained easy to read but easier to process reliably (INI = bad , YAML = good).

At least let the program ask you if you really want to do it…

Well that’s generally how such things work… why would you assume otherwise?

I was assuming something like, a popup “Add this repository, OK, CANCEL” maybe show if is is encrypted/trust ed etc…

I kind of see this as falling under the “engrained habits from OtherOS” category. I personally haven’t had issue with programs omitting this functionality. OTOH, I see this as possibly useful if for some reason the title tab close box is out of reach. Honestly, I think the last time I used the File->Quit flow to quit an app (especially a single window app) was circa Windows 3.11. Gawd I’m getting old.

1 Like

I think there is some inconsistency between Haiku apps concerning menus and what’s in them. I’m guessing the Haiku project has a HIG (Human Interface Guidelines) for making application UI functionality easily discoverable and predictable.

Indeed: https://www.haiku-os.org/docs/HIG/index.xml

1 Like

For the “Quit” item, we’d need to add another top menu. Other applications often get away with putting “About” and “Quit” in their “File” menu. Putting it into HaikuDepot’s “Tools” menu would be a bit too much, IMO.

The new menu would probably be called “App”. Some programs use their icon instead (Vision for example), which I’d prefer, but Ii don’t think we have a standard API for that?

While thinking about how lonely the “Quit” would be in that new menu, I wonder if we shouldn’t put a “Help” in there (and all Haiku apps with a menu) that summons the user guide page of the app…

2 Likes

Vision doesn’t use much private API, I’m pretty sure this is a public API that it’s using to add this menu.

The more you talk about it the more rediculous that menu sounds… Add meaningful features not fluff. As far as that goes my status bar ticket was closed dispite it not actually being implemented anything close to what I suggested…there is still no numerical indication of progress either Percent or download rate etc…

2 Likes

HaikuDepot (HD) will still load-up from any HPKR data that is resident on the local machine. Likewise, HD will recognize that there is no network access available and will work with any previously downloaded data from HaikuDepotServer.

Can you please provide a reference to the ticket.

https://dev.haiku-os.org/ticket/14425

For the “Quit” item, we’d need to add another top menu. Other applications often get away with putting “About” and “Quit” in their “File” menu. Putting it into HaikuDepot’s “Tools” menu would be a bit too much, IMO.
The new menu would probably be called “App”. Some programs use their icon instead (Vision for example), which I’d prefer, but Ii don’t think we have a standard API for that?

This is just what I always thought. What do “Quit” or “Preferences” have to do with “File” to go into “File menu”?

“File” menu should only contain items related to file management (open, close, save, metadata, print…) while “Quit”, “Preferences”, “About the creators”, “UI Language” or “Devices” should be inside “Application” or “Settings” menu.

I suppose it’s mainly the tradition to save space. I do think that having a menu with just one “Quit” item is a bit odd.
Putting that (plus Help and where applicable About") in a small app-icon menu wouldn’t be all bad.

The problem I see is that contrary to a labeled menu, an app-icon menu might not be recognized as such and people may not try clicking on it.