About modal: render pretty looking plugin names

[mzazrivec]

I'm proposing to extend the nice work from #4423 with presentable - looking plugin names.

Before:

After:

The plugin names with my changes in place:

irb(main):009:0> Vmdb::Plugins.versions.keys.map(&:plugin_name)
=> ["API Plugin", "Automation Engine Plugin", "Content Plugin", "GraphQL Plugin", "Amazon Provider Plugin", "Ansible Tower Provider Plugin", "Azure Provider Plugin", "Foreman Provider Plugin", "Google Provider Plugin", "Kubernetes Provider Plugin", "KubeVirt Provider Plugin", "Lenovo Provider Plugin", "Nuage Provider Plugin", "OpenShift Provider Plugin", "OpenStack Provider Plugin", "oVirt Provider Plugin", "Redfish Provider Plugin", "Microsoft Provider Plugin", "VMware Provider Plugin", "Consumption Plugin", "Classic UI Plugin", "V2V Plugin"]

Plugin PRs:
ManageIQ/manageiq-v2v#603
ManageIQ/manageiq-api#457
ManageIQ/manageiq-automation_engine#214
ManageIQ/manageiq-consumption#140
ManageIQ/manageiq-content#411
ManageIQ/manageiq-graphql#60
ManageIQ/manageiq-providers-ansible_tower#119
ManageIQ/manageiq-providers-amazon#477
ManageIQ/manageiq-providers-azure#283
ManageIQ/manageiq-providers-foreman#22
ManageIQ/manageiq-providers-google#68
ManageIQ/manageiq-providers-kubernetes#277
ManageIQ/manageiq-providers-kubevirt#113
ManageIQ/manageiq-providers-lenovo#221
ManageIQ/manageiq-providers-nuage#135
ManageIQ/manageiq-providers-openshift#107
ManageIQ/manageiq-providers-openstack#336
ManageIQ/manageiq-providers-redfish#23
ManageIQ/manageiq-providers-scvmm#83
ManageIQ/manageiq-providers-vmware#312
ManageIQ/manageiq-providers-ovirt#279
ManageIQ/manageiq-schema#261

@Fryguy @epwinchell @skateman @terezanovotna

[skateman]

[epwinchell]

@miq-bot add_label formatting/styling

[mzazrivec]

Are you guys also OK with the plugin names as I proposed them above? ("API Plugin", "Automation Engine Plugin", ...)

[himdel]

Good idea IMO :)

One possible nit-pick... in a section called Plugins, maybe we should not repeat "* Plugin" on every line.

[miq-bot]

Checked commit mzazrivec@a69ac95 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
2 files checked, 0 offenses detected
Everything looks fine. ⭐

[cben]

If we're showing low-level "master@1c00fee" in the dialog (which I think is good & valuable), perhaps it'd more useful (even if less "pretty") to use actual repo names, e.g. "manageiq-automation_engine master@1c00fee" ?

EDIT: not sure if repo name or gem name is most useful, I think in most cases they're same

[himdel]

That could be useful.

What about both? Show the pretty name in the list, and add a "raw" title? (the html attribute)

[AllenBW]

Ditto the repo name sentiment, goal of this information is to be handy, to facilitate quick accurate identification which version of what code is employed in a given instance... Pretty things are nice.. but forcing me to look for what v2v is rather than giving me the name of the repo manageiq-v2v 😢

Edit: but this is one hellofuh awesome body ah work, no two ways about it, well done! 🤗 🙇‍♀️

[himdel]

Seems like there is still some unfinished work from #4423 as the "table" (divs with spacing) view is not done yet....

Any chance we could make all that info fit?

"UI Classic" "manageiq-ui-classic" "master@deadface"

Also.. as for the raw info... seems like "ManageIQ::Providers::Whatever" is still essentially useless, and the raw text displayed should be manageiq-providers-whatever, right? (engine_name.chomp("::Engine").underscore.tr("/", "-") is what's being used for webpack pack prefixes)

[mzazrivec]

Seems like there is still some unfinished work from #4423 as the "table" (divs with spacing) view is not done yet....

My intent here (and in the PRs linked) is only to add the display names for plugins. The styling work will / should be done in separate PRs.

[epwinchell]

Seems like there is still some unfinished work from #4423 as the "table" (divs with spacing) view is not done yet....

@himdel I plan to create a styling PR when everyone else is done making changes.

[mzazrivec]

Any chance we could make all that info fit?

"UI Classic" "manageiq-ui-classic" "master@deadface"

But we don't really know what the semantics of the string manageiq-ui-classic is, do we? Where do we get the string from? What does it represent or say?

Also.. as for the raw info... seems like "ManageIQ::Providers::Whatever" is still essentially useless, and the raw text displayed should be manageiq-providers-whatever, right? (engine_name.chomp("::Engine").underscore.tr("/", "-") is what's being used for webpack pack prefixes)

Right, but like I wrote above, manageiq-providers-whatever won't say much more than ManageIQ::Providers::Whatever, right? I don't feel that strongly about it really, and I can change it that way if you'd like, though it still just seems like another arbitrary string to me.

[himdel]

Sure, I was not suggesting changing the styling here, just saying that if the plan is to have something more table-like, we may get away with the 3 fields instead of my previous idea of using a title.

Whether any of that is a good idea or not... ¯\_(ツ)_/¯ :)

[himdel]

Right, but like I wrote above, manageiq-providers-whatever won't say much more than ManageIQ::Providers::Whatever, right? I don't feel that strongly about it really, and I can change it that way if you'd like, though it still just seems like another arbitrary string to me.

Well, the one thing that goes for the second string IMO is that it's the repository name.
It may not be immediately obvious that ManageIQ::Providers::Whatever corresponds to ManageIQ/manageiq-providers-whatever on github, but manageiq-providers-whatever probably is.

That said, it's not something that we can make match in 100% cases so... that may break too..

[epwinchell]

if the plan is to have something more table-like, we may get away with the 3 fields instead of my previous idea of using a title.

@himdel As I mentioned in #4423, my plan is/was.. to use a unstyled list like the one at the top of the modal - not a table or something table-like. If that won't work, we'll need to loop UX back in.

[himdel]

OK, so.. looks like we can merge and figure out the rest elsewhere, if needed :).