Search Unity

Why is Popup and EnumPopup in Editor and not Runtime, and more?

Discussion in 'UIElements' started by MoruganKodi, Oct 23, 2019.

  1. MoruganKodi

    MoruganKodi

    Joined:
    Feb 11, 2015
    Posts:
    20
    Title pretty much sums it up, this my seem a bit rant-ish but I always appear to sound agressive, it's just my nature (when I don't sleep for 2-3 days at a time). (Apologies ahead of time).

    This is intended to get an unterstanding of what seems to be an odd choice (as usual) in namespace placement for certain controls, especially if we expect to use the same UI builder to also create layouts for runtime UI in the future.

    Popups/Dropdowns qualify as common controls in most UX environments, so why would these not be included in the runtime namespace for a UI Library which is expected to replace UnityEngine.UI, are there plans for moving these or creating Runtime variants?

    Then there is: "// Note: PopupField has no UXML support because it is a generic type."

    Couldn't you just create inherited Non-Generic versions for common valuetypes which inherit from this, so we can actually user it in the UIBuilder? As far as I am aware serialized values arrays of generic types do work within unity, if they are not a mixed type array, so this doesn't seem to make much sense.

    Code (CSharp):
    1.  
    2. public class IntPopupField : PopupField<Int>
    3. {
    4.     // ... and relevant constructors and methods
    5. }
    6.  
    7. public class StringPopupField : PopupField<string>
    8. {
    9.     // ... and relevant constructors and methods
    10. }
    11.  
    .. including the usual SetOptions, AddOptions, RemoveOptions implementations?

    We would have multiple additional popup types in the UIBuilder, but at least we can use them in UXML this way. What would be preventing this from becoming a reality, as it would save us from reinventing the wheel.

    It seems ot me that EnumPopup could have also easily inherited from Popup<T>, and be initialized from `Enum.GetValues` and `Enum.GetNames` (which is also possible in UGUI implmentation for IntPopup),
    however with the idea of provifing a more complete set of UI components out of the box.

    Wouln't it make sense for all runtime-possible controls to just exist in UnityEngine.UIElements instead of UnityEditor.UIElements, instead of limiting use to the same basic set (or less than which) exists in UGUI?

    The same question can be posted for "Mask" popups. This could also be a runtime control (while Tag, LayerMask, and Layer cannot due to being very specific).
     
  2. sebastiend-unity

    sebastiend-unity

    Unity Technologies

    Joined:
    Nov 9, 2015
    Posts:
    31
    Hi,

    I understand the frustration. UIElements for runtime is a recent thing. Initially UIElements was editor-only; all controls started out as part of the UnityEditor.UIElements namespace. We are in the process of bringing them into the UnityEngine.UIElements namespace as we progress with the Runtime and UIBuilder packages, so lookout for more UnityEngine-available controls soon!
     
  3. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    4,474
    Could you please make sure you actually move them, and not keep two copies?

    The current editor UI system has this legacy of once having been runtime UI system, so there's a ton of methods that exist both in GUI and EditorGUI or both in GUILayout and EditorGUILayout. It's super-annoying, and it'd be really great if you could avoid repeating that mistake.
     
  4. sebastiend-unity

    sebastiend-unity

    Unity Technologies

    Joined:
    Nov 9, 2015
    Posts:
    31
    Controls are moved from Editor to Engine, not copied, as part of the process. No confusion there :)
     
    brunocoimbra and Baste like this.
  5. Garrafote

    Garrafote

    Joined:
    Jun 13, 2013
    Posts:
    2
    +1 for having PopupField compatible with UIBuilder.

    Any plans on that?
     
unityunity