Opened 8 years ago
Last modified 8 years ago
#13245 assigned enhancement
Notify HaikuDepot of de/activated repos
Reported by: | humdinger | Owned by: | perelandra |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Preferences/Repositories | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | #13244 | Blocking: | |
Platform: | All |
Description
This is hrev50837.
When de/activating a repo, the Repositories prefs could check if HaikuDepot is running and send it a message to "Refresh repositories".
I was pondering if it should be done every time a repo is de/activated or only once when closing the prefs. Since refreshing repos can take a while, it may be bad if those refresh messages pile up at HaikuDepot. Though I guess HaikuDepot could be made smarter to handle that case efficiently.
OTOH, it might be nice to have HaikuDepot open, searching for some app, and activating a repo only temporarily to see if the app is in that repo. Then I don't want to have to close the prefs to see the list in HaikuDepot updated.
Change History (4)
comment:1 by , 8 years ago
Component: | Preferences → Preferences/Repositories |
---|
comment:3 by , 8 years ago
Blocked By: | 13244 added |
---|
Isn't the menu to filter by repository in HaikuDepot simpler and faster than enabling and disabling repos in package management?
You're right. But to lessen the effects of #13244, I currently have Michel's mega repo deactivated. #13244 is actually a blocker for this ticket. No use to inflict more freezes on the user until that one is solved.
But if repo changes are instead made via pkgman nothing will happen. So another method would be for HaikuDepot to put a monitor on the repository cache.
Good call, I think this would be the right approach.
An important question though would be, is this automatic refreshing expected by the user, or would it be confusing? Could it interrupt anything the user was doing (download/installing), reset current search parameters, do anything else that would make the user say "What are you doing, I was in the middle of doing X and now it changed on me!!!" ?
I thought about this and your example of "smart mail".
I think as long as the de/activating of repos is a result of the user's own action, it's completely save to update HaikuDepot's GUI. In fact, this is exactly what I expect and therefore wouldn't even go through the hassle of setting update-flags. HaikuDepot should always present the current state. It may have to learn to cancel a running update and start anew if it gets the message to update.
If I see something in HaikuDepot, I don't want it to fail when clicked on, but rather have it disappear when I just told via Repositories prefs to deactivate its repo. Currently, I get an error alert "failed to match for {packagename}".
One thing has to be made sure though: if it's not the currently selected item itself that's disappearing, the selection should be held and the position in the package list fixed, if possible.
All that said, de/activating repos and updating repos (in the background by the SoftwareUpdater to be) are rare enough occasions that I wouldn't mind an alert: "The repositories are about to be updated." "Thank you" (Or maybe even have the option not to update HaikuDepot's package list?)
comment:4 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Isn't the menu to filter by repository in HaikuDepot simpler and faster than enabling and disabling repos in package management? That's how I would check for packages in a specific repo.
But if you have launched Repositories from the HaikuDepot menu it would be good to have any changes trigger a refresh. I think updating every time a change in the Repositories preflet is made would be too much since it is a long process. But perhaps when Repositories makes changes it could send a message to HaikuDepot, which would then just set a flag indicating that the repositories have changed, but not do anything yet. Then two possible events could trigger a repository refresh in HaikuDepot.
1- Repositories quits and sends a message to HaikuDepot saying "Hey I am quitting, HaikuDepot you can refresh now". 2- The HaikuDepot application is activated (without quitting Repositories), when it would detect the set flag and do a refresh.
But if repo changes are instead made via pkgman nothing will happen. So another method would be for HaikuDepot to put a monitor on the repository cache. If HaikuDepot gets the node changed message, but it is not the current active application (you could be in either Repositories or Terminal making changes), it will set the flag but do nothing yet. Then when HaikuDepot activates it checks for the flag and refreshes repositories if needed. This sounds more inclusive to anything that would do repo adds or drops and be future proof.
So this would need: HaikuDepot adding a node monitor(s) on repo cache HaikuDepot catches node changed messages, sets a flag HaikuDepot adds flag check in AppActivated and refreshes repos if flag is on Repositories preflet sends message to HaikuDepot (if running) when it quits. (without this HaikuDepot would still do a refresh when it is activated, but triggering it this way will start the process a bit sooner, maybe)
An important question though would be, is this automatic refreshing expected by the user, or would it be confusing? Could it interrupt anything the user was doing (download/installing), reset current search parameters, do anything else that would make the user say "What are you doing, I was in the middle of doing X and now it changed on me!!!" ?
Sometimes manual and simple processes are better because you triggered it so you expect it to happen. I have a recent somewhat related experience. We just moved to Microsoft Intune on our work phones to get email. It has this new "feature" called a "Focused Inbox" that tries to be smart and filters out emails it does not think are as important as others, and collapses emails into conversions. I didn't realize it was enabled when I first setup their phones and they would come back to me all confused because they weren't getting email on their phone that they were getting on their computer. Well it was this "smart" feature that automatically rearranged their emails on them. They don't like it and want it turned off because they don't see their email in the order it comes in. OK, they are just used to the old way, but the point is they were confused by the email program doing stuff automatically on them without being clear about what it was doing. It was too much of a hassle so they just want that feature off. So just be careful what "automatic" features we implement.