treewide: add testbed option for running command in UI

[Flameopathic]

changes:

• removes stylix.testbed.application.enable option
  • it is now assumed that, if the option is set, the application should be run
  • removes repeated lines
• moves stylix.testbed.application to stylix.testbed.ui.application
  • if any options are set under stylix.testbed.ui, the UI configuration is set
• refactors all existing application testbeds reflect the above two changes
• adds stylix.testbed.ui.command.{text,useTerminal}
  • if the option is set, the command should be run
  • functions similarly to stylix.testbed.ui.application except can take any arbitrary command
  • has an option to run the command in a terminal
    • useful for terminal applications which require a terminal emulator for their full functionality

related: #319

Things done

• Tested locally
• Tested in testbed
• Commit message follows commit convention
• Fits style guide
• Respects license of any existing code used

Notify maintainers

[Flameopathic]

@trueNAHO do you have time to give this a quick review? I'd like to add some more application testbeds, but I am holding off until this has merged so that I don't have to do the same work multiple times.

[danth]

Just having one option which passes an attrset directly to makeAutostartItem would require less code (unless I've overlooked something), and potentially support more use cases

[trueNAHO]

I'd like to add some more application testbeds

Thanks helping out :)

but I am holding off until this has merged so that I don't have to do the same work multiple times.

Good idea.

Note that stacked PRs or simply well-structured patchsets allow progressing on dependant unmerged commits. AFAIK, this is common Git practice (at least in the Linux Kernel, which is arguably the intended way of using Git), although the GitHub interface neither supports nor really encourages this workflow. Keep in mind that this workflow requires frequent git rebases when commits in the patchset need to be changed, which is fairly difficult if you are not comfortable with git rebase merge conflicts.

[trueNAHO]

This if-else construct implies that only one of them has an effect, with config.stylix.testbed.ui.application being prioritized. Either both being non-null should cause their consequences to be merged, or we explicitly disallow this with an

!(
  config.stylix.testbed.ui.application != null &&
  config.stylix.testbed.ui.command != null
)

assertion to prevent silently ignoring config.stylix.testbed.ui.command declarations.

Although merging the consequences is the most extensible, simply adding an assertion is also fine since we currently do not need this functionality. I leave the decision up to you.

Just having one option which passes an attrset directly to makeAutostartItem would require less code (unless I've overlooked something), and potentially support more use cases

Simply delegating pkgs.makeAutostartItem arguments is also an option, especially since the config.stylix.testbed.{command,ui.application} distinction is not directly apparent. Otherwise, the names could be somehow improved.

[Flameopathic]

Just having one option which passes an attrset directly to makeAutostartItem would require less code (unless I've overlooked something), and potentially support more use cases

Simply delegating pkgs.makeAutostartItem arguments is also an option, especially since the config.stylix.testbed.{command,ui.application} distinction is not directly apparent. Otherwise, the names could be somehow improved.

Small correction: config.stylix.testbed.{command,ui.application} is actually config.stylix.testbed.ui.{command,application}, which may make their distinction slightly clearer (or maybe less clear), though I agree that it is hard to immediately understand the difference from their names. I am not sure what names would better differentiate them, though, and I believe that their option descriptions do a fair job of explaining what each does.

From what i can grasp about pkgs.makeAutoStartItem from its definition, it would require this set be duplicated with only one or to arguments being changed across every application testbed which runs an arbitrary command.

Also, doesn't the current upstream implementation already basically just pass the set directly to makeAutoStartItem?