Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Resolved Internal properties in VisualElement and inherited classes?

Discussion in 'UI Toolkit' started by CxydaInno, Sep 5, 2020.

  1. CxydaInno

    CxydaInno

    Joined:
    Sep 5, 2017
    Posts:
    14
    Hey guys !
    First of all i recently got into UiElements and i have to say I got a BIG FAN of it ! Great job!

    Now that i'm digging deeper into it and i'm creating my own (complex) VisualElements i find myself more and more restricted by the (heavy) use of the internal keywords in the VisualElement class or for example the ListView class. Why is that? Didn't you guys expect that other developers actually use those classes and try to build upon your great work you already did? Or is there a way around it i just did not see?
    In my current case i'm trying to build a GridView ... quite similar to the ListView but not as a vertical list only. Since it does not seem that I can change the bahaviour of the existing ListView to the behaviour I need i tried to create my own class inheritting from ListView, but due to the interal access modifier in that class i cannot do that ... Then i decided to reinvent the wheel and copy & paste the content of ListView and change what i need to change and then... guess what ?!?! INTERNAL keywords in VisualElemet class block me from finishing my job .. why ? JUST WHY??

    This really drives me crazy and makes me insanely sad! I hope that i just did not see the solution right in front of me. Would be great if one of you guys can enlighten me.

    Thanks in advance.
    Best Cxyda
     
    benoitd_unity likes this.
  2. antoine-unity

    antoine-unity

    Unity Technologies

    Joined:
    Sep 10, 2015
    Posts:
    771
    Hello,

    Can you quickly share which internal APIs are actually blocking you from implementing your own ListView?
     
  3. CxydaInno

    CxydaInno

    Joined:
    Sep 5, 2017
    Posts:
    14
    Hi antoinde-unity! Thanks for your response!

    Code (CSharp):
    1. ListView class:
    2. internal int m_ItemHeight;
    3. internal override void OnViewDataReady();
    4.  
    5. VisualElement class:
    6. internal bool isCompositeRoot;
    7. internal void SaveViewData()
    8. internal void OverwriteFromViewData(object obj, string key)
    9. internal string GetFullHierarchicalViewDataKey()
    10.  
    11. private class RecycledItem
    12. internal enum PseudiState
    Maybe there are more which I did not see on first sight. I honestly don't see the benefit of making things internal (or support classes private) for a module which is ment to be used and extended. There are also lot's of private methods which could actually be protected virtual which would be a big help.

    Hope that helps, thanks again for your response I really appreciate it! Let me know I can be of further help.

    Thanks!
    Best Cxyda
     
    Last edited: Sep 9, 2020
  4. antoine-unity

    antoine-unity

    Unity Technologies

    Joined:
    Sep 10, 2015
    Posts:
    771
    Public vs. internal is a trade-off for Unity. There is a lot of extra work to put into making things public (discussions, design, testing, documentation, etc.) and sometimes it gets in the way of delivering something like a good out of the box ListView.

    Keep in mind that once we make something public, we generally can't change it anymore, so we're very considerate about what goes public.

    Clearly ListView is not mean to be inherited from and extended like that. I would say that looking at the existing code and adapting bits and pieces you actually need is a good approach. Then if there are actual roadblocks we can have a look at making them public.
     
    CxydaInno likes this.
  5. CxydaInno

    CxydaInno

    Joined:
    Sep 5, 2017
    Posts:
    14
    Thanks ! And i agree its always a tradeoff... we could argue about listview is not ment to be extended.. i think this a very handy and complex component but also has very important core functionality like pooling.. therefore i'd say it should be public.

    The Visual element on the other hand is the very core element in this whole system and should offer the full power of the system to the people without resticting them. (just my personal opinion)

    Thanks, Best Cxyda