drewnaylor / guinget Goto Github PK

This can result in marking the wrong packages by accident.

This would help in case there aren't easily-accessible manifest files, such as if the Store source is being shown. It could also help if the user wants to double-check something for a particular package. Clicking "Show in winget" will run cmd /k winget show (PackageId) -v (PackageVersion). May need to turn off multi-select for this; will have to check Synaptic for that. Probably wouldn't make sense to allow multi-select for this anyway, since most people probably wouldn't mark multiple packages at once.

We need to make sure the manifests can be found, and if they're not, at least stop trying to load them. Preferably it'll just try to download them, but if the remote source can't be found, we'll have to let the user know.

This will allow people to point it to another package list in case the default one changes or goes down. I want multiple sources to be supported eventually, but this would be a good first step. Preferably this would be in a file like sources.txt in the winget-frontends folder to allow for multiple sources, but for now the config file is an easy place to put it.

The -e is very important in this case, as it specifies to get that exact package name. This is happening because there are two crystaldiskmark packages and it gets confused. There will soon be a bugfix update (likely 0.1.0.1) to provide the -e to winget so it works correctly and doesn't complain while being nonfunctional if installing one of these packages.

This needs to be changed to make sure we're not double-clicking on the column headers before displaying the package context menu.

Almost forgot to put this in the documentation and changelog.

I'd like it to be so that the SQLite database is read for package ID and version, and afterward look for a manifest in the local cache with that ID and version. Opening each manifest to check ID and version may be the fastest way to reliably do this, which will ensure we don't run into an issue where a package ID has a dot where it shouldn't.

If a source such as the Store source doesn't have an easily-accessible manifest zip file, something else that could be done is to run winget source update, then once it's done run winget show (PackageID) -v (PackageVersion) and use this output for the package details textbox. This output could also be used for the Description column until next application start, though that will probably require text interpretation like seeing where there's "Description: " preceded by a CrLf (since it would be a good idea to turn all Cr and Lf characters into CrLf to make things easier) and take the substring until the first CrLf (we're going to replace the other characters as I said before).

(Copied from #34)

As it is now, if it takes too long to delete the temp files cache when clicking the "Refresh cache" button, guinget will start not responding.

This can be done by checking the Registry, and it may be a good idea to do a re-check after closing the "Apply changes" dialog. Maybe an option to re-install a package would be a good idea, too. The re-install could just tell winget to install it again.

This would allow people to retry installation with different settings without having to re-open the Apply Changes window.

This way the user can close it if they don't want it open. Could be helpful on smaller screens such as phones if guinget works on Windows 10 on ARM. There should also be a checkbox under View such as View>Sidebar so the sidebar can be shown or hidden on startup. This checkbox gets unchecked if the user closes the sidebar with that button, and it won't open the next time the app is started, either.

This'll make it easier to see and use all the pages.

This is kinda like how Mintbackup exports the software list. A good idea would be to allow this to be re-imported to select packages to install. An option to export as a batch file in addition to just a plain list in a text file would be a good idea as well.

As the title says, we'll start by loading the sources from a manifest in the Resources instead of them being fully hardcoded. Eventually this will allow moving to loading from a file that can be easily modified by the user and accessible to other winget front-ends that decide to use it.

This sources file can be something like,

source
  # Source ID used to differentiate between 
  # sources. Will be used in place of the "-display-name:"
  # field if that one's not available.
  id: "winget"
    # Specify whether this source should be updated and loaded.
    -active-source: "True"
    # What's shown in the "refresh cache" 
    # window. Maybe it would be a good idea to also 
    # display whether we're updating the database or 
    # the manifests at the current time. This could 
    # also be used in a sources manager program.
    -display-name: "Microsoft/winget-pkgs"
    # URLs that the manifest archive and database
    # are downloaded from.
    -manifest-archive-url: "https://github.com/Microsoft/winget-pkgs"
    -database-url: "(insert database URL here)"
    # Can't use the display name to determine the 
    # cache root directories, so we'll specify them. 
    # Getting this from the URL automatically 
    # would be a good idea.
    -manifest-archive-cache-dir-root: "winget-pkgs"
    -database-cache-dir-root: "winget-db"
    # While unlikely, it's possible that other 
    # databases could have a different filename 
    # for itself, so this is just in case.
    -database-file-name: "Index.db"
    # Some repos have all the manifests in the 
    # root rather than a subfolder, such as the 
    # mirror repo on GitHub. By default, we'll look 
    # under the "manifests" subfolder, though.
    -manifests-in-root: "False"
    -manifest-path-subfolder: "\manifests\"

source
  id: "msstore"
    # Etc.

Additionally, this will have to have a field to determine whether manifests are discovered based on package ID and version from the database (default for winget-pkgs/winget-db), or whether it has to grab the manifests from the Internet based on a path from the pathparts table (which would have to be used for the Store source). The Store database has pathparts all in one string, so that should be easy as long as it stays that way. Update: the Store source is now REST-based, rather than using a database.

Edit: The default winget source also has pathparts all in one string now too (actually, I don't think it does, and I was just confused and looking at the wrong thing), so I can just add support for using pathparts manifests from the Internet instead of having to download and extract the full repo all at once. For this to work, I'll have to save each manifest in the cache so that we don't use up the user's bandwidth too much. Not sure about how to get all the manifests with this, though.
Maybe this won't work, as I still need to figure out how to get the parent values to put the paths together properly. For example, this is the manifest for the Yukino package as shown in the top of the ids table: https://winget.azureedge.net/cache/manifests/z/ZYROUGE/Yukino/1.0.9-beta.0/9f4b-ZYROUGE.Yukino.yaml
Edit again: I think I figured it out. You get the manifest filename from the manifests table's pathpart column, then you look at the pathparts table. Look at the manifest filename row's parent column value, and go to that rowid column number. Prepend a forward-slash (/) before the manifest filename, then put in the value in that row's pathpart column. Keep looking at the parent column value and going to that rowid number and prepending the slash and the pathpart column's value until you get to the parent value saying a rowid value of 1. Then you'll go to rowid column value 1, which is just "manifests", and that's actually the subfolder in the /cache/ directory on Microsoft's server, or the "manifests" folder in the GitHub repo. That row has a parent of NULL, but I don't currently know how to deal with a null value, but once that's hit, we have the path to that specific manifest and can move on after appending it to the source URL.

The window should be resizable, and the output textbox should change its size to match the window. The file textbox next to the browse button should also change its size. Buttons should remain the same size.

Maybe do something like this for the output:

> winget validate "C:\0.1.0.1.yaml"
Validation complete.

The "validation complete" is winget's output, and the line above it is what's passed to winget, which in this case is just an example.

If there are any issues, they'd be displayed in the textbox and it would be easy to copy-and-paste them or read all of them rather than using a messagebox.

There could be a textbox with a browse button next to it, and probably below the browse button would be the "Validate" button.

Perhaps there could be a close button at the bottom, rather than having people use the X button.

GitHub Desktop added it for filter boxes, and I figured it would be useful here, too.

This would be useful in case you want to see packages under a specific ID, in case there are different versions.

Makes it make more sense and avoids using "enabled" and "disabled" in the same sub name, which is confusing and doesn't sound good.

Should be faster, I hope, since tar isn't PowerShell.

Makes it faster to apply changes since the user can just press Enter after deciding the list looks good.

Version 0.1 pre-alpha 1 is pretty old, and screenshots of 0.1.1 would be much better.

This usually happens the first time you right-click or double-click after starting the app if you move the window somewhere else first.

I forgot to increase the version number for libguinget before releasing it.

This runs winget settings.

This can be a hidden column, and it'll get the source from the sources config file at the same time it loads the manifests in that source's pkglist subfolder as they both use this source name.

Some people may want it to not be exact.

What it usually does is it just shows progress and runs automatically. In some situations like VLC and LibreOffice, the user may want to install interactively.

Probably should have interactive installation as an option in addition to the default at minimum, then maybe later add an option to hide progress.

Interactive installation uses -i and fully-silent uses -h.

Maybe these could be the radio buttons for it:
Groupbox header: "Installer visibility"

• Install silently with progress (winget install "package"; default)
• Install silently without progress (winget install "package" -h)
• Install interactively (winget install "package" -i)

Forgot to do this earlier. Probably should mention that you can resize the textbox's splitview area, too. Maybe mention the detail columns currently available as well.

Saying that each version of a package is listed as if it were a separate package for now until a window to force installing a specific version (like Synaptic) is ready is a good idea.

Both of the checkboxes in the Options window (accessible from Package list>Search options...) get unchecked when you click the Defaults button in version 0.1.2. This will be fixed in 0.1.3 since it's not that big of a problem.

"More details, though they're not as relevant to guinget:"

This is on the changelog on the Releases page.

• I'm getting tired of opening the Action menu every time.
• "Do nothing" will become "Unmark" and "Install" will become "Mark for installation". Uninstallation will follow the same pattern when it's ready.
• The "Do nothing" dropdown in the datagridview will become "Unmarked".

Documentation will have to be updated with these changes.

This'll help for when winget requires packages to offer it. Copying this issue to UXL Launcher's repo.

Ideally this would also work with a dialog box for input (or better yet, something in the configuration window, or a dialog box with a checkbox to set an input as default with stuff in the options window to ask every time or do something automatically), but a fallback is still a good idea.

CMD /k keeps the CMD window open.

https://github.com/dwmkerr/consolecontrol

It's under the MIT license, and aside from not having WaitForExit and seemingly not supporting ANSI control codes in a screenshot in one of the issues, it looks decent.

This should make it easier to transition to allowing specific versions to be selected for installation from a Properties window while also working with the current method of copying package details into the Confirm changes window.

Getting the details from the database should be able to be done by combining the package ID and package version tables together to determine the latest one.

Once that's done, the previous versions can be determined by getting the folder for the latest version's Yaml file and ignoring the file itself, just getting all the files in that folder and putting their versions in the dropdown.

Getting details from each Yaml file can be done by combining the version number with the path and ".yaml". If the yaml file can't be found, the package ID/name should be added to the front of it, as the yaml manifest may be one that conforms to Microsoft's manifest spec v0.2 (which requires the package name/ID at the front).

Version 0.1.1 added the "Interactive installation" checkbox which interacts with the settings, so it needs to be migrated.

This could be stored in a yaml file. Something like this maybe:

-Package
    - PkgId: (id)
    - Version: (marked version)
    - Action: (selected action)

If the user chooses to "Do nothing", the package's entry will be removed from the list. Could be useful to create a command-line application for this, one with the following example commands:
cli-guinget-mark.exe --action "Install" --pkgid "7zip.7zip" --version "19.0.0". The "Do nothing" action would be "Unmark".

If the user refreshes the cache or accidentally closes guinget, we'll load their selections from this file. As it is, refreshing the cache de-selects any package that's been marked for changes, and that's not really good.

Got this idea from apt-mark, though I don't really know how apt-mark works with regards to marking packages.

It'll be off by default as it takes a little while to load, there's no way to make sure the cache hadn't just been updated yet, and the loading itself is not async.

For example:

• File
  • Refresh cache (Ctrl+R)
  • (separator)
  • Install package from manifest...
  • (separator)
  • Exit
• Tools
  • Sources editor...
  • (separator)
  • Options...

Most of the rest of the menus will be more like Synaptic, though.

Version 0.1.2 migrates settings from the previous version when it's run after install, and as a result also copies all of its current settings to the config files in the %LocalAppData%\guinget folder.

Right now it's in the post-update sub.

Searches should be re-done if there's anything in the search box when the user refreshes the cache if Synaptic does it like this.

Should be handled just fine by winget, but I need to check my own code and the Apply Changes window.

This is according to their PreindexedSourceFactory.h file here:
https://github.com/microsoft/winget-cli/blob/e997f3e394e66f2389f4f33f36c58b1c2768e975/src/AppInstallerRepositoryCore/Microsoft/PreIndexedPackageSourceFactory.h#L11-L18

Here's a good page on SQLite indexes:
https://www.sqlitetutorial.net/sqlite-index/

May need to run it in PowerShell unless CMD supports using semicolons to split/join commands. The last semicolon will have to be trimmed before being passed to CMD as well.