[Request] Tweak to Docker GUI

[ljm42]

I like the basic/advanced modes for editing Docker xml files, but I think the environment variables are too hidden.

 

Would you please consider modifying the display such that if any environment variables exist in the XML file, the environment variables section is displayed even in basic mode?

 

This would allow that section to remain hidden when it is not needed, yet be easily accessible when it is relevant.

[jonp]

I like the basic/advanced modes for editing Docker xml files, but I think the environment variables are too hidden.

 

Would you please consider modifying the display such that if any environment variables exist in the XML file, the environment variables section is displayed even in basic mode?

 

This would allow that section to remain hidden when it is not needed, yet be easily accessible when it is relevant.

 

Are there any containers that REQUIRE the environment variables in order for them to work?  I realize that some have OPTIONAL environment variables that you can set for getting beta versions of the apps or something like that, but do any containers actually require you to specify environment variables in order for them to work?  Honest question as I truly don't know off the top of my head.

[ljm42]

Yeah, Binhex's delugevpn container requires environment variables.  Case in point, here are comments from two people who had a hard time figuring out how to set them:

  http://lime-technology.com/forum/index.php?topic=38055.msg363592#msg363592

 

I've also experimented with graylog, and it requires them:

  https://registry.hub.docker.com/u/graylog2/allinone/

(as an aside, it would be great if someone could write a guide for using this  )

 

I also have some ideas to improve the plexWatch docker, since that seems to have more support requests than anything else.  If I am successful with that it will require you to put your plex username and password into environment variables.

 

 

I'd say for Dockers that use the variables, they are at least as important as the volume mappings. 

 

For instance, I use the VERSION tag for Plex so I can control exactly what version of Plex I have.  As a result, I modify that variable every few weeks.  It is strange to have to go to the advanced area to modify the only setting that ever changes.

 

A lot of Dockers don't need them, so there is no need to clutter the basic screen for those cases.  But if the xml file has any environment variables named, I request that the environment variables section be displayed in basic view.

 

Thanks!

[jonp]

Yeah, Binhex's delugevpn container requires environment variables.  Case in point, here are comments from two people who had a hard time figuring out how to set them:

  http://lime-technology.com/forum/index.php?topic=38055.msg363592#msg363592

 

I've also experimented with graylog, and it requires them:

  https://registry.hub.docker.com/u/graylog2/allinone/

(as an aside, it would be great if someone could write a guide for using this  )

 

I also have some ideas to improve the plexWatch docker, since that seems to have more support requests than anything else.  If I am successful with that it will require you to put your plex username and password into environment variables.

 

 

I'd say for Dockers that use the variables, they are at least as important as the volume mappings. 

 

For instance, I use the VERSION tag for Plex so I can control exactly what version of Plex I have.  As a result, I modify that variable every few weeks.  It is strange to have to go to the advanced area to modify the only setting that ever changes.

 

A lot of Dockers don't need them, so there is no need to clutter the basic screen for those cases.  But if the xml file has any environment variables named, I request that the environment variables section be displayed in basic view.

 

Thanks!

 

I think we need to do away with the labeling of "environment variables" as that naming alone sounds intimidating.  I think we need to update the XML schema and allow authors to specify additional fields of information.  The fact that those get injected into the run statement as environment variables in Docker is a technical detail that end-users shouldn't have to be concerned about.

 

So we basically need to support additional form fields that authors can specify for passing those parameters.  We then need an option for the author to specified "required" vs. "optional" and if optional, hide it by default, but if required, display it.  Some may have a combination of both.

 

Would that address your desires?

[sparklyballs]

I like the basic/advanced modes for editing Docker xml files, but I think the environment variables are too hidden.

 

Would you please consider modifying the display such that if any environment variables exist in the XML file, the environment variables section is displayed even in basic mode?

 

This would allow that section to remain hidden when it is not needed, yet be easily accessible when it is relevant.

 

Are there any containers that REQUIRE the environment variables in order for them to work?  I realize that some have OPTIONAL environment variables that you can set for getting beta versions of the apps or something like that, but do any containers actually require you to specify environment variables in order for them to work?  Honest question as I truly don't know off the top of my head.

 

my kodi headless container requires them as i inject the mysql information into advancedsettings.xml with variables given in the template.

[NAS]

I think the question should really be "Is it best practice to pass information in using ENV variables" which I believe it is.

 

e.g.

https://docs.docker.com/reference/run/#env-environment-variables

 

If that isindeed  the case it seems a necessity to support it.

[trurl]

I think we need to do away with the labeling of "environment variables" as that naming alone sounds intimidating.  I think we need to update the XML schema and allow authors to specify additional fields of information.  The fact that those get injected into the run statement as environment variables in Docker is a technical detail that end-users shouldn't have to be concerned about.

 

So we basically need to support additional form fields that authors can specify for passing those parameters.  We then need an option for the author to specified "required" vs. "optional" and if optional, hide it by default, but if required, display it.  Some may have a combination of both.

 

Would that address your desires?

So there could be an XML node for environment variables, but the contents of that node would be additional nodes totally up to the developer, and the developer could name their environment variables whatever they wanted. The environment variable names would appear on the form with a place for the user to fill in the value, instead of an environment section where the user has to fill in both the name and the value.

 

Is this what you had in mind?

 

[ljm42]

I think we need to do away with the labeling of "environment variables" as that naming alone sounds intimidating. 

 

My main concern with this is that we might be getting too far away from standard Docker.  This will make it harder for non-unRAID users to use our dockers and vice-versa, since the terminology and instructions won't match.

 

Would that address your desires?

 

I'm not following 100% (although trurl's comments helped!) but I trust you

 

I just want it to be easier to use environment variables for those Dockers that have them defined.

 

Thanks!

 

[binhex]

I think showing env variables in the webui if defined is the simplest approach, I also think keeping them labelled as environment variables is also my preference, I really don't think users care what they are called as long as they can define them easily.

[sparklyballs]

 

 

I think we need to do away with the labeling of "environment variables"

 

transient input injectibles ?

[sparklyballs]

 

 

I think we need to do away with the labeling of "environment variables"

 

transient input injectibles ?

 

more seriously though.

 

how about

 

input variables ?

 

more descriptive than environment.

 

[jonp]

I was going to say there is really no need to even label them like this universally.  Environment variables to me seem like they are for additional configuration options that would be specific to the container/application in question.  For example, if edge=1 is to get latest version of app (not necessarily tested version), then maybe the author really just needs a checkbox that says "get latest app (beta)".  Then when the user toggles from basic to advanced view, we can still display all the environment variables for developers / advanced users that want to see all that.

 

My point is that "environment variables" are specific to docker, and not a concept that I would expect users to take the time to understand.  Instead, we should interpret their use for our users and find a way to present the controls for modifying them in a more simplistic manner.  E.g., if edge=0 means no beta and edge=1 means beta app, then it's just a checkbox.  If there is a form field for the user to enter in their e-mail address for something else, we don't need the user to type "[email protected]" in the environment variables field.  We just need the template author to specify the variable side (e.g. emaddr) and then provide a descriptive label for that in the xml schema that matches (e.g. E-mail Address).

 

That's what I really meant by getting rid of the concept of environment variables.  I really should have said "masking" the concept for users as opposed to developers.

[NAS]

I like that clarification it makes sense now. From a user perspective all fields are just variables with a description and a content of a certain type.

 

Users dont really need to know the terms volumes, environmental variables or anything else. This is not to say we need to hide these terms or reword them they will just fade into he background when a variable name and description exists in a consistent manner.

 

On that note i suggested a long time ago now every single field in the XML should have a description. The general XML description section contains far to much field specific content now and its inelegant.

[ljm42]

I've caught the vision, this would be an excellent enhancement!

 

I've taken a stab at the types of form inputs we'd need to support and how they could be specified in the xml.  I'm not 100% sure on my use of xml attributes vs elements.

 

Text input

 

This would be displayed to the user as a standard text input box.

 

<Variable>
  <Properties type="text" password="[T|F]" required="[T|F]" />
  -- if password is true, mask the input
  -- if required is true, can't save the form without inputting a value for this field
  <Name></Name> -- name of the env variable that will be submitted (not shown to users)
  <Value></Value> -- value the user entered into the text box (or a default value provided by the author)
  <DisplayText></DisplayText> -- this is what the user sees rather than the "Name"
  <HelpText></HelpText> -- this displays if the help button is active
</Variable>

 

 

Select Single

 

This would be displayed to the user as a dropdown list, where they could choose a single option.

 

<Variable>
  <Properties type="select" multi="[T|F]" required="[T|F]" />
  -- if required is true, can't save the form without choosing a value for this field
  <Name></Name> -- name of the env variable that will be submitted (not shown to users)
  <DisplayText></DisplayText> -- this is what the user sees rather than the "Name"
  <HelpText></HelpText> -- this displays if the help button is active
  <option value="" display="" /> -- this repeats as needed
  <option value="" display="" /> 
</Variable>

 

Select Multiple

 

The XML is the same as "Select Single", with multi="T".  I don't have a use case in mind for this, it may not be needed.

 

There are two options for displaying this to the user:

- as a <select multiple> field

- as a series of checkboxes all tied to the same Name

 

Toggle

 

This would be displayed to the user as a True/False statement, where checking the box is equivalent to True.  This may not be needed since the "Select Single" type could handle it.

 

<Variable>
  <Properties type="toggle" />
  <Name></Name> -- name of the env variable that will be submitted (not shown to users)
  <TrueValue></TrueValue> -- value of the env variable if box is checked
  <FalseValue></FalseValue> -- value of the env variable if box is not checked.  If this is empty and the box was not checked, the env variable should not be passed to docker.
  <DisplayText></DisplayText> -- this is what the user sees rather than the "Name"
  <HelpText></HelpText> -- this displays if the help button is active
</Variable>

 

Would that cover it? 

 

[jonp]

I've caught the vision, this would be an excellent enhancement!

 

I've taken a stab at the types of form inputs we'd need to support and how they could be specified in the xml.  I'm not 100% sure on my use of xml attributes vs elements.

 

Text input

 

This would be displayed to the user as a standard text input box.

 

<Variable>
  <Properties type="text" password="[T|F]" required="[T|F]" />
  -- if password is true, mask the input
  -- if required is true, can't save the form without inputting a value for this field
  <Name></Name> -- name of the env variable that will be submitted (not shown to users)
  <Value></Value> -- value the user entered into the text box (or a default value provided by the author)
  <DisplayText></DisplayText> -- this is what the user sees rather than the "Name"
  <HelpText></HelpText> -- this displays if the help button is active
</Variable>

 

 

Select Single

 

This would be displayed to the user as a dropdown list, where they could choose a single option.

 

<Variable>
  <Properties type="select" multi="[T|F]" required="[T|F]" />
  -- if required is true, can't save the form without choosing a value for this field
  <Name></Name> -- name of the env variable that will be submitted (not shown to users)
  <DisplayText></DisplayText> -- this is what the user sees rather than the "Name"
  <HelpText></HelpText> -- this displays if the help button is active
  <option value="" display="" /> -- this repeats as needed
  <option value="" display="" /> 
</Variable>

 

Select Multiple

 

The XML is the same as "Select Single", with multi="T".  I don't have a use case in mind for this, it may not be needed.

 

There are two options for displaying this to the user:

- as a <select multiple> field

- as a series of checkboxes all tied to the same Name

 

Toggle

 

This would be displayed to the user as a True/False statement, where checking the box is equivalent to True.  This may not be needed since the "Select Single" type could handle it.

 

<Variable>
  <Properties type="toggle" />
  <Name></Name> -- name of the env variable that will be submitted (not shown to users)
  <TrueValue></TrueValue> -- value of the env variable if box is checked
  <FalseValue></FalseValue> -- value of the env variable if box is not checked.  If this is empty and the box was not checked, the env variable should not be passed to docker.
  <DisplayText></DisplayText> -- this is what the user sees rather than the "Name"
  <HelpText></HelpText> -- this displays if the help button is active
</Variable>

 

Would that cover it?

 

Haven't read this post in depth, but saw that you took a stab to propose XML schema and just wanted to say THANK YOU!  This kind of stuff really does help us because when we're ready to implement, we'll already have a basic template to work off of from someone who took the time and care to put something together.

[sparklyballs]

As an addition to the idea here, can the various inputs for local storage either be renamed by docker author or at least the tooltips be set to match the nature of mapping etc...