Need Feedback for (wip) UHC-GUI

[DisasterIncarna]

Minor Feature Update Added on 10th October 2022:
- UHC-Tools devs added support to Search/Get from HVSC (C64 Music)
- updated GUI to support new addition.

As usual, new version up on main/first post if you cant wait for the upload to aminet which will ofc take a few days to go live.

[EctoOne]

Question, are you only supporting WBRun as launcher for the readme files?

Because I just found WBLoad in the CLICon package http://aminet.net/package/util/wb/CLICon which doesn't seem to require any additional libraries. I tried it on a different project where I wanted to start a tool with its tooltypes and it works fine in that case.

And I also stumbled across http://aminet.net/package/util/cli/WBLaunch some time ago which requires wbstart.library instead of parm.library.

Don't know if they are widely used but it might be worth adding support for those as well.

[DisasterIncarna]

good suggestion, ill add a few "if exists" and try and use them if they exist in the order of CLICon > WBRun > WBLaunch, ill have a play with those and make sure they work as intended.

[EctoOne]

How exactly do you open readme files?

Because I just noticed that I had a line about "using type as default" when I opened a readme, although I had set it to SYS:Utilities/MultiView in the GUI. Then I noticed that there is also the file ENV:UHC/READER which is referred for example by the uhchelp script which has this default line in it. I've not looked at the other uhc scripts but I assume you use one of those to get the readme?

If that's the case, wouldn't it be better to also set the ENV file and not just the one from the GUI when choosing a viewer? Because when I changed the READER file to also use MultiView, the message was gone.

[DisasterIncarna]

"using type as default" i think? is the default output method for basic cli output when you for example type "aminetsearch thingtosearchfor", the results are displayed via "type", i think if you set that to Multiview and did the same cli command to search for something the results would instead be displayed via Multiview? i think.

I made the GUI do its thing by trying not to mess with or change anything UHC Tools sets up, and i didnt want people to have to change anything just to make the GUI function which is why i added my own method for displaying ReadMe's.

The GUI opens ReadMe's by WBRun'ing your set Viewer, such as Multiview, it is RUN so as not to halt the GUI operation, you should still be able to use the GUI with a ReadMe open.

The ReadMe is given a temporary name that the GUI knows belongs to itsself, this is because when you actually click the button to read a ReadMe, the GUI first tries to delete previous ReadMe's that adhere to its naming method so as not to delete anything it shouldnt at the same time.

If you have a previous ReadMe actually open at the time you open a new one then thats no problem as again the program doesnt halt and wait, the previous ReadMe wont get deleted when the new one is opened because Workbench locks a file "in use", this is why the GUI tries to first delete previous ReadMe's because if one was open previously it wouldnt have been deleted because Workbench wont allow it to be deleted while its open, meaning you can have a buildup of files.

once you close a ReadMe ofc, then that can and will be deleted the next time you open a different ReadMe.

The ReadMe's temporary names are just a shortened description of the ReadMe with the filename prefixed with "UHC" then the file has 2 letters that denote the site they were downloaded from, so "Am" would signify a ReadMe from Aminet, then it has the text "ReadMe", then the number UHC Tools assigned to the selected file/readme, so if "HippoPlayerUpdate.Lha" was the 5th entry the number "5" would be appended, so you could end up with a ReadMe called "UHCAmReadMe5.txt" if that file already exists somehow, like having a previous ReadMe still open that would end up with the same name, the number is simply increased by 1 until a non existing filename is found and used.

This is so when the GUI deletes ReadMe's (and ONLY readme's it has created) they are all named in an easy to delete way, ie: Delete RAM:T/UHC#?ReadMe#?.txt wont screw up and delete things it shouldnt.

[EctoOne]

Hmm, interesting. But you're using a uhc script to fetch the readmes or why else would there be that default text viewer thing.

If I remember correctly, never really used the GUI to view the readmes though, I've seen that message before but it also disappeared without me changing anything. I might have another look at it. For me that whole READER ENV makes only sense to use it when actual text is displayed. Like the uhchelp script for example. Doesn't seem very useful to me to display search results in MultiView when using UHC from a shell.

[DisasterIncarna]

i mostly did it to avoid potentially screwing up UHC Tools in some way.

[patrik]

Originally Posted by EctoOne

Hmm, interesting. But you're using a uhc script to fetch the readmes or why else would there be that default text viewer thing.

If I remember correctly, never really used the GUI to view the readmes though, I've seen that message before but it also disappeared without me changing anything. I might have another look at it. For me that whole READER ENV makes only sense to use it when actual text is displayed. Like the uhchelp script for example. Doesn't seem very useful to me to display search results in MultiView when using UHC from a shell.

The readme scripts sets UHC/READER if it is not set and that is when you see that message. Perhaps we should just remove that message and silently default to type, but we put it there to spread the knowledge that it is possible to change UHC/READER.

I have to say that am a shell/text guy, but I do really appreciate the workflow where readmes are displayed using say multiview or muchmore compared to just outputing them in the shell.

Say you do an aminetsearch, get a couple of results, then I can read several readmes in multiview, still using the keyboard (space to scroll down, esc to exit), and when exit multiview without having the search results scrolled away in the shell.

Anyway, back to the topic - UHC/READER is not used to display the search results in the shell, only the readme files or help files. The search results are printed as the come in from the search server, line by line, by the UHCSearch binary, there is no intermediate step of saving them to a file and then displaying them.

[EctoOne]

I'm not saying that it is useless to be able to set a different reader, especially when you don't have a shell without scrollbars. I was just referring to the UHCSearch, but I guess that was just a bad example and got me confused.

But is there some method that displays the default reader text just once or something? Like I said, I've seen it before but it also disappeared for some reason. Although I'm actually not sure about that, because it's been a while since I really that function and it doesn't really matter at this point, I'm just curious.

Instead of just removing the message, why not add an option to change the reader during the installation? Just use RequestFile to set the variable or if you don't want to rely on external tools, have a simple input prompt. In fact why not have a little menu to change the settings? I mean there is no obvious readme file in the installation folder, at least none with an icon AFAIK, just the Set Directory thingy. So, I personally have actually no idea what kind of ENVs there are or what they do. I think it would be better to expand the Set Directory thing to a complete Preference menu. I don't know if that would be easy to do with just shell scripts though. Maybe something like Installer could be used for that. Kinda like WHDLoadMenu does for its configuration. But yeah, thanks for the clarification.

[patrik]

I think the command uhcstatus is what you are looking for. It will show you the current state of the environment variables uhc tools cares about. The boolean ones like SHOWPROGRESS can be toggled with the uhctoggle command.

[DisasterIncarna]

Minor Feature Update Added on 14th November 2022:
- UHC-Tools devs added support to Search/Get from AmigaRemix.com
- updated GUI to support new addition.

Archive on first post updated, submitted to Aminet (Will take a day or so to appear as usual, if you have the new archive on first post you dont need the archive that will appear on AmiNet)

[DisasterIncarna]

Features Update Added on 22/Nov/2022:
- UHC-Tools devs added native support to Search/Get from RKO making old HTML scraping method redundant/obsolete.
- AmigaRemix and RKO have gained the ability to list "Recent" uploads.
- Double Clicking a file "should" download directly.

^ this version will "NOT" be uploaded to Aminet just yet as I am having issues with.....something on my machine/setup which is causing me to fully crash emulation randomly when downloading large files making testing an issue.

If someone/some people could try the updated archive in the first post and make sure everything works and hasnt broken and make sure the double click feature actually does what it should, that would be great and then I'll upload to aminet only if/when its confirmed as working.

[spoUP]

Hey that’s awesome! Double clicking for downloading! Thanks!
Another nice tweak would be if it loaded the recent files by default when switching mirror.

[DisasterIncarna]

nice idea, ill add that to my list of things to add, if theres no issues, with a bit more feedback ill upload this current version to aminet.

Also working on a revamp of the guts of the GUI which probably wont be noticed by end-users but should result in an easier to update GUI and with just cleaner/better ways of doing things. Should also make adding newer features much easier than the current way im doing things.

Basically, still plenty more for me to do

[DisasterIncarna]

currently adding features, trying to smash bugs and add features people have requested directly or indirectly when mentioning something totally different but still ended up sparking something in my tiny brain.

Throwing this picture here: https://i.imgur.com/KNb76O7.png

It's just a quick visual showing how the GUI is evolving, heres some obvious changes.

1) Added a Header Row, UHC-Tools always had a header when using shell/cli, i just skipped past it previously, because reasons..... or i was lazy.

2) a second listview is showing on the far right, this is a toggle, if you enable it you will get a listview which has the Download Sites you can simply click rather than use the cyclemenu. The cyclemenu/old method is still available if the above option is toggled off, I added this as it came to my attention that not everybody may be using a CycleToMenu hack/patch meaning manually clicking through every Site could be a total pain in the rear end without such a patch, this listview is now available as an alternative option.

3) Loads of background stuff I am still doing, making things better overall, and hopefully smashing more bugs/problems.

4) As requested by spoUP, if you switch to a different download site and if that site supports "RECENT" then the RECENT list for that site will be automagically selected.

5) Nothing any normal user would be interested in, but this currently unreleased version supports new additions the UHC-Tools devs may release (extra download sites or adding features to existing ones) instantly without requiring a GUI recode to manually support it, this is better for me and end-users and in can then concentrate more on smashing bugs/problems.

---

If anyone can think of some useful quality of life features, now is a good time while I am gutting/rebuilding the guts of the GUI, still got a fair few things to change to make the GUI work properly as it did before i started improving it in a big way, it pretty much already works properly, just the new way i made it work broke automatic handling of archives, once thats fixed up i can release this much newer version.

Cheers...

[EctoOne]

Originally Posted by DisasterIncarna

4) As requested by spoUP, if you switch to a different download site and if that site supports "RECENT" then the RECENT list for that site will be automagically selected.

If possible make this optional please. I assume it will slow down the initial start if such site is selected. Which is why I'm personally not interested in this feature.

But would it be possible to add some indicator that a site does have a RECENT list? Normally this would be probably done by disabling the button for sites which don't have such option but I don't know if that is possible with this type of GUI.

[DisasterIncarna]

Originally Posted by EctoOne

If possible make this optional please. I assume it will slow down the initial start if such site is selected. Which is why I'm personally not interested in this feature.

But would it be possible to add some indicator that a site does have a RECENT list? Normally this would be probably done by disabling the button for sites which don't have such option but I don't know if that is possible with this type of GUI.

my current unreleased version is far more clever than the original, previously i had to manually tell the GUI what features/download sites are supported, this newer unreleased version scans all the commands in UHC tools and are matched against a file the UHC-Tools devs kindly added to their package which lets my GUI match commands against what they support. Previously yes, i only had the Readme button show support by enabling/disabling.

This means the GUI knows what sites are supported even without a recode of the GUI, and because i now scan all the files directly i know exactly what features are supported, Recent/Get/Search/Readme/etc, the new GUI already enables/disables both the Recent and Readme button if the currently selected Download site supports that function.

Quick Preview how it looks/works atm: [ Show youtube player ] as always the new mechanics/improvements/rewrites are work in progress, such as also needing to make the Auto/Get/Extract gadget smart and various other unseen bits and pieces that need to be made "smart" using the new mechanics.

Also yes, that could be annoying for some, so i'll make the "Auto Recent" a toggle option.

[DisasterIncarna]

Opinion time:

So, after using the GUI a lot more during testing the new upgrades, and before i just throw in the feature I'm thinking of, i thought I'd ask first.

It's making "more" sense to me to keep the current system of downloaded GET/EXTRACT files going to the place we set them to, default being RAM: or whatever you manually set it to. However I'm thinking, esp after downloading a load of MP3 files from RKO/Amigaremix and then archives from Aminet, that having different download locations could be useful.

So im thinking that IF we click the "Set Destination" button to change the download location from RAM: to somewhere else, then perhaps that destination should be specific to the site we are using at that time, IE: Click set Dest while using AmigaRemix, set my destination as SYS:Music/MP3s and that destination is now set just to AmigaRemix and saved/remembered as such if saving prefs, if i click back to Aminet, it would still be set to download to RAM: unless ofc we manually change that as well.

This is because the first thing i end up doing when downloading a load of stuff, is that i end up firing up FileMaster3 and moving things to the same old locations, my MP3's to SYS:Music/MP3s, my SID tunes from HVSC to SYS:Music/SIDs, etc etc, you get the idea.

Thoughts on each Site having its own custom download location if changed from the default of RAM: remember this would only be saved/persist if you manually use "Save Current Prefs" or the Save on Exit feature, so this would not really be permanant unless you want it to be?

[EctoOne]

The new smart GUI looks sweet.

Having a the ability to test which UHC features are available makes me actually think about how easy it is to remove certain features. For example, I don't need uhchelp and since it also comes with the huge amount of single text files I kinda wish there was a good way to completely remove this feature. That would probably also help if the UHC disk gets full because of the new additions. Haven't tried it lately if it still works. Also removing that feature directly after extraction would probably speed up the disk installation. Maybe I should ask for something like that over in the UHC thread...

As for the separation of download folders, I personally don't need them. I also have running a file manager to manually sort files and I don't really use UHC for anything else besides Aminet downloads.
I probably would prefer it to set a default location which applies to all sites unless I set a specific one.

[EctoOne]

I just stumbled across another setsockopt error, which doesn't seem to be suppressed.
This time I'm able to reproduce it. I've seen it before but wasn't able to do so. Because it doesn't show up when using a random search term.

I've mentioned it in the UHC thread but since it is the GUI that suppresses the error and I don't know how often you check that thread, I decided to post it here as well.

Search for clixon (instead of clicon)

RAM:> aminetsearch clixon
setsockopt(): Numerical argument out of domain (33)
# Filename Path Size Description