Need Feedback for (wip) UHC-GUI

[EctoOne]

Oh nice, I think I'm actually using destination names in my various installation scripts but of course I just tried to copy the command and and link into a shell.

Good to know that can remove some more files from my install folder and download them instead. Now if there only was a way to get https working without the need for AmiSSL so that I can get something from github for example.

[patrik]

Originally Posted by EctoOne

Oh nice, I think I'm actually using destination names in my various installation scripts but of course I just tried to copy the command and and link into a shell.

Good to know that can remove some more files from my install folder and download them instead. Now if there only was a way to get https working without the need for AmiSSL so that I can get something from github for example.

Unfortunately, AmiSSL is the only SSL/TLS solution available on the Amiga, so unless someone develops/ports something else, it is the best we have. I presume the issue is the large binary size and memory requirements?

An unorthodox solution would be for you to setup a http://->https:// proxy to get files from github, which the Amigas could reach .

Another alternative is to make sure the github stuff you are interested in downloading is uploaded to aminet, which as a bonus would make them way easier to get for everyone.

[DisasterIncarna]

pity theres no 3rd party middleman server which can do a download using https then forward it to you over http, might be a website or docker app for that but ive never seen/heard of one.

[patrik]

Originally Posted by EctoOne

Oh nice, I think I'm actually using destination names in my various installation scripts but of course I just tried to copy the command and and link into a shell.

I have released a fixed version of aget, please give it a spin .

[EctoOne]

Originally Posted by DisasterIncarna

pity theres no 3rd party middleman server which can do a download using https then forward it to you over http, might be a website or docker app for that but ive never seen/heard of one.

Yeah, that would be useful.

Originally Posted by patrik

I presume the issue is the large binary size and memory requirements?

Yes, the size is/was my main issue. I started writing the custom installation scripts and wanted to share them as easily as possible. But then I started adding more and more and also wanted to include config files for certain programs. At one point I was able to fit it on a HD adf but then I had to include the files I couldn't download. Now I can free up some space but I don't think it will be enough. I still have the XAD 13 beta/test and updated DirOpus guide on https servers (github and sourceforge) which are pretty big. There are some other files but they are relatively small.

Originally Posted by patrik

Another alternative is to make sure the github stuff you are interested in downloading is uploaded to aminet, which as a bonus would make them way easier to get for everyone.

Huh, might be worth asking for at least XAD 13 here or on github to also put it on Aminet.

Originally Posted by patrik

I have released a fixed version of aget, please give it a spin .

Will do.

Edit: Works fine, but so did the old version when setting a destination file.

I found one more issue with files from saved websites on archive.org. I have this link: http://web.archive.org/web/200406210...er/html-dt.lzx which works as in the file gets found but it ends up as 0 byte file.

Edit 2: I just changed my scripts to use the archive.org link for the Aminet CD links and for some reason the downloads also ends up being 0 bytes. It works fine manually from the shell. I will test if has something to do that I set the url and file name as variables and use those as arguments for aget, but then why does it find the file but can't download it?
Using variables doesn't seem to be the problem. A simple test script with url/file as variable works fine. So, either my main script which runs all separate scripts is causing problems or something else is going on. But if my main script was the problem, then why do I have this only with the archive.org links? Weird...

Edit 3: For testing purposes I tried using HTTPResume from Aminet. And that one can download the html-dt link at least from the shell, haven't tried it from a script yet, because it also gets only 0 byte files for the Aminet CD files when called by script. But it also works fine from a shell. I'm so confused.

[DisasterIncarna]

new test version on the front page of the thread, added more categories and thanks to Jan/Ziphoid who gave me the info i needed to get a full music author list for rko and amigaremix, both lists should now be much bigger and complete, grabbing/copy/pasting the info caused some special characters/umlauts to fail to copy/paste properly but i should have fixed those now, list any names that display wrong or fail to search, names with ä ö ü, that kind of thing.

Also added a small category list for amigascene.org

[EctoOne]

Just out of curiosity, are you planning to integrate the Prefs directory if you update the version on Aminet? I'm asking that because the test version has Autoupdate active, which I don't like. In the end it wouldn't be an issue, I just have to adjust my custom install script. And since you fixed the issue that the Prefs directory had to be there to save the settings, it would be possible to not include the Prefs directory.
Since by default lha doesn't archive empty directories, you either have to include at least one file (I personally would suggest readview set to SYS:Utilities/MultiView) or set the lha option to archive empty directories.

Also would it be possible to scan for "old" settings in PROGDIR: and move them to Prefs? I think that would make it easier for user to update without worrying about losing their settings and/or obsolete files staying around.

Basically then I only have to add a line to my script to copy the Categories directory. And it still would work fine if an older version of the package is used.

[DisasterIncarna]

i only have autoupdate enabled as default because of the prefs file included which enables it, on the test version i forcibly added a number of options just so certain features would appear as default rather than letting the user figure out they existed then enabled them, as the "test" features are what i was interested in feedback wise i just forced a load of stuff to enable themselves, the update part was just to make sure people were up to date for any/all features needed.

When tests are a bit more thorough (WB3.1 isnt playing as nice with me as 3.2) and i upload the test version to Aminet, those forced prefs wont be enabled, it will be up to the user(s) to enable what they want, instead the usual Readme will simply tell what was added recently.

The test version i think will remain named as Test even on Aminet, that way i will have the "Current" working version still there for users to fall back to should the test version give them massive issues and due to the new Prefs on the test version it wont mess up prefs on the older version.

moving old prefs to new is certainly doable, i just asumed people would keep the "Current" and "Test" versions separate to avoid issues that might spring up with the test version.

Any glaring/obvious issues with the test version btw? as usual for me, its a case of "works for me, no problem", i still have the odd random problem with OS3.1 where i get no text output in the GUI with nothing "seemingly" going wrong, tho that might just be my actual OS3.1 setup, i might just try a fresh install instead of using 1 of my very old setups.

[DisasterIncarna]

to clarify my current reason for not already uploading the test version to Aminet, all is well for me on my OS3.2.x setup, but on OS3.1, for reasons that currently evade me and everything i am testing/messing with to find the reason, but "sometimes" not always, UHC output isnt being redirected to a text file so the GUI can read it.

the UHC guys added an option to their search scripts to redirect output to a file without having to use the usual "> FILENAME", instead they added a SEARCHRESULTTO option so you can specify something like SEARCHRESULTTO RAM:TEST.TXT and output is redirected by the UHC script itsself

I have been relying on this redirection method since it was added and again on OS3.2.x that works perfectly and for OS3.1 or at least my current OS3.1 it works "usually", but sometimes my output is blank and i dont know why, so im trying to bugsquash/bugfind that problem, which might just be something wrong with my OS3.1 given that it usually works.

I deem it a big enough problem that i need to find out the reason for this before i upload something that could be an obviously major issue for others as well.

[EctoOne]

Originally Posted by DisasterIncarna

Any glaring/obvious issues with the test version btw?

I actually didn't spend much time with the test version since I was trying to get the aget problems figured out I posted. Luckily and thanks to patrik, those issues are of the table.

I just took a quick look at at the beginning to check the new features and this morning to see if/how I need to change my script. Besides the, already fixed, saving settings issue I've not noticed anything else so far.

[Foxman]

UHC-GUI Test is great piece of Software
Works like a charme @A4000D/BFG060/OS3.2.1

[DisasterIncarna]

Originally Posted by Foxman

UHC-GUI Test is great piece of Software
Works like a charme @A4000D/BFG060/OS3.2.1

thanks for the feedback, its hard to tell if all is well for others without the occasional reply now and then, as i mention on my first post in this thread "it works for me" but sometimes not so lucky for others who arent using a similar setup to me, so its nice to hear nothing major went wrong

[EctoOne]

Sorry to bring this up again but I just noticed a difference in the Test version. Although it might have changed earlier but I never noticed it.

It seems that you switched to get WBLaunch instead of WBRun.
So what exactly is the order now for those types of tools?
I still think the best order would be WBLoad (WB 3.1.4 and WB 3.2 and a possible full installation of CLICon), WBRun (WB 3.9) and then download WBLaunch for when nothing is found.

And I don't know if WB 3.5 has any of those, since I've never used it.

[DisasterIncarna]

Originally Posted by EctoOne

Sorry to bring this up again but I just noticed a difference in the Test version. Although it might have changed earlier but I never noticed it.

It seems that you switched to get WBLaunch instead of WBRun.
So what exactly is the order now for those types of tools?
I still think the best order would be WBLoad (WB 3.1.4 and WB 3.2 and a possible full installation of CLICon), WBRun (WB 3.9) and then download WBLaunch for when nothing is found.

And I don't know if WB 3.5 has any of those, since I've never used it.

hmm, i might have screwed up somewhere then, it "should" see if WBRUN exists first, if so it should use that, if that doesnt exist it should then look for CLICON and use that, and if none of those exist it looks for WBLAUNCH last. I was considering just adding a menu option to toggle whichever you want from a list it finds, but i think i might just have a menu option that pops up a file requester asking you to pick the command you want, that might make it far easier.

[EctoOne]

If you put it in a prefs file when choosing a command from a file requester, it would be easier for someone like me to update my install script and set it beforehand.

I still don't quite understand why not look for the most common (any command already included in a basic Workbench installation) first. But what do I know, I'm no programmer.

Btw It downloaded WBLaunch on 3.1.4 when I noticed it. Don't know if that matters and/or idoes that on any other version.