Add projectUrl at the end of the description in the package selection

[sara-rn]

Add projectUrl at the end of the package description if it contains a valid URL to the package selection window
closes #708

[sara-rn]

@Ana06 , as per #708 (comment) this is the only way I figured out to make this work but the linter complains

[sara-rn]

Space between package description and URL cannot be extended, I modified the Y position as per the comment in the issue #708 (#708 (comment))

[Ana06]

[nitpick] why is this a PsCustomObject instead of a normal hash table? 😕

Suggested change

	$packageObject = [PSCustomObject]@{
	$packageObject = @{

[Ana06]

Do not duplicate code:

Suggested change

	# Check if $projectUrl contains a valid URL
	if ($projectUrl -match "^http") {
	$packageObject = [PSCustomObject]@{
	PackageName = $packageName
	PackageDescription = $description
	PackageUrl = $projectUrl}
	}else{
	$packageObject = [PSCustomObject]@{
	PackageName = $packageName
	PackageDescription = $description}
	}
	$packageObject = @{
	PackageName = $packageName
	PackageDescription = $description
	}
	# Check if $projectUrl contains a valid URL
	if ($projectUrl -match "^http") {
	$packageObject.PackageUrl = $projectUrl
	}

[sara-rn]

It's better to create PSCustomObject entries from the hashes for several reasons, including better readability and a more structured data format. Also the code is simpler and easier to read in the function Get-AllPackages (here) where we need to get a flattened array of only entries with property PackageName.
Additionally this is what Gemini responds to the question:

Hash vs. PSCustomObject
It's generally a better practice to use PSCustomObject entries instead of raw hashes for several reasons:

Property Access: You can access properties with the dot notation (e.g., $entry.PackageName), which is cleaner and more readable than hash notation ($entry["PackageName"]).

IntelliSense: In many PowerShell editors, PSCustomObject provides IntelliSense for its properties, which makes writing and navigating code much easier.

Object-Oriented Structure: They behave more like objects, which is often a more natural fit for representing structured data like your package entries.

Cmdlet Compatibility: Many PowerShell cmdlets are designed to work seamlessly with objects, making it easier to pipe and process your data.

While hashes are flexible, converting them to PSCustomObjects is a recommended practice for better code structure and compatibility.

[Ana06]

The reason Gemini is providing are IMO not relevant for this simple code and not even correct. For example you can use the dot notation for a simple hash table too:

> $hash = @{ name = "value" }
> $hash.name
value

While I think AI is a useful resource that can speed your code writing, I advise you to be careful with trust it blindly and always rely on official documentation and testing the code on your own.

I think it is overkilled to use an object for this use of case. But if you think the code in Get-AllPackages is simpler, I have no strong opinion (note the suggestion of using a hash was a nitpick, only the code duplication was not, which is already solved.

[Ana06]

[nitpick] Why are you using [system.Diagnostics.Process]::start instead of the PS functionStart-Process? This is already used in other links in the installer and I would change it there too.

[sara-rn]

no particular reason, I asked Gemini and I think it is better to use the built-int cmdlet Start-Process generally but for this particular case it makes no difference and it seems slower. I changed it in the rest of the links as well

Feature	[System.Diagnostics.Process]::Start()	Start-Process
Type	.NET Framework Method	PowerShell Cmdlet
Speed	Generally faster; direct method call.	Slightly slower; involves command parsing.
Parameters	Limited to method overloads (e.g., arguments).	Extensive, with options like -NoNewWindow, -Wait, etc.
Error Handling	Uses standard .NET exception handling.	Integrates with PowerShell's error handling system ($ErrorActionPreference).
Output	Returns a System.Diagnostics.Process object.	Returns a System.Diagnostics.Process object by default, but can be suppressed.
Use Case	Ideal for simple, high-performance tasks within a GUI where you just need to launch a process.	Better for complex scripts where you need fine-grained control over the process, manage output, or use other PowerShell features.

[Ana06]

@sara-rn what do you mean that it seems slower? We should use the fastest option if this is noticeable for the user.

[sara-rn]

I didn't experience any difference myself, this is what Gemini responded and maybe it's worth testing it

[Ana06]

I think performance shouldn't be an issue for such a simple task (opening a link) and as long as we are using it consistently I have no strong opinion (note I added it as nitpick), but please test that there is no performance difference locally or double check this information in official documentation.

[sara-rn]

I agree for this case, like I said I didn't notice any performance issue

[sara-rn]

Thanks @Ana06 for the review, I addressed some of the requested changes, see my comments above.

[Ana06]

Why not just the code I proposed (simpler and more readable)?

Suggested change

	Add-Member -InputObject $packageObject -MemberType NoteProperty -Name "PackageUrl" -Value $projectURl
	$packageObject.PackageUrl = $projectUrl

[sara-rn]

This is because I am using the PsCustomObject, see my comment #714 (comment)
That doesn't work when using a PsCustomObject, see error : ForEach-Object : Exception setting "PackageUrl": "The property 'PackageUrl' cannot be found on this object. Verify that the property exists and can be set."

[Ana06]

I think performance shouldn't be an issue for such a simple task (opening a link) and as long as we are using it consistently I have no strong opinion (note I added it as nitpick), but please test that there is no performance difference locally or double check this information in official documentation.