Quick note on UI about slugdb HOT 6 OPEN

Hi, Thanks for looking at this humble project!
I know about ui elements but the whole css/html thing is really not my cup of tea. I feel like sooner or later I'll have to get to it though one day. The browser window is only one element though, would still need a few custom drawers, buttons, and other things...

from slugdb.

You don't have to do any XML, that is optional. I mostly just do plain C# like below, with just a little bit of css here and there when I need to, but mostly it's just reusing some that I already set up how I like within different projects. I feel it is much more like using QT with Python than anything else. No HTML required.

For example, here is part of the code to make the search field and the two pane split view from my pic.

// -------------------------------------------- Toolbar Search
var searchContainer = new VisualElement();
searchContainer.AddToClassList("searchContainer");

var searchField = new ToolbarSearchField {style = {flexShrink = 1}}; // <== You can just set your values inline and not have to do *any* css.
searchContainer.Add(searchField);

searchField.RegisterValueChangedCallback(OnSearchTextChanged);
toolbar.Add(searchContainer);
// ------------------------------------------------ End Toolbar

// ------------------------------------- Layer View Split Menu
viewSplit = new TwoPaneSplitView(0, 100, TwoPaneSplitViewOrientation.Horizontal);
viewSplit.AddToClassList("twoPaneSplitView");

layerEntryLeftSplit = new VisualElement {focusable = true, name = "LeftSplit"};
layerEntryRightSplit = new VisualElement {focusable = true, name = "RightSplit"};

layerEntryLeftSplit.AddToClassList("twoPaneSplitViewLeft");
layerEntryRightSplit.AddToClassList("twoPaneSplitViewRight");

If you did want to do CSS (which you will find, is super nice to use compared to inline styles, as you don't have to recompile to change the values)
It usually ends up being extremely simple:

.twoPaneSplitView {
    min-width: 150px;
}

.twoPaneSplitViewLeft {
    background-color: #404040;
}

.twoPaneSplitViewRight {
    background-color: #333333;
}

Once you get into it, not only is it "not bad", I actually quite enjoy it. When I was making the split window, I wanted to try to see if I could animate parts of it.

https://i.imgur.com/TKQBStS.gifv

But, as usual, one thing lead to another and I ended up making this animation demo package, lol. https://github.com/instance-id/ElementAnimationToolkit
All in all, though. It's not nearly as "web like" as it sounds/seems. They mostly just emphasized that part of it since it's new and you can do it heavily with XML and css. You definitely don't have to, though.

I have no idea where I am going with this, lol, so I will just say keep up the good work, and good luck with the project. 👍
Thanks,
-MH

from slugdb.

I must say you sparked my interest. Can I ask you how did you come across my repository ?

from slugdb.

I get asked that a lot, lol. I am very specific with my searches on github when I am trying to find examples of things, so there must have been something in your project that matched what I was trying to find at the time. I can't remember specifically, as it was the other day that I actually came across it, but I do know I was trying to find inspiration on how I could change how I was handling my scriptableobject storage, which I am using more or less as a database.

from slugdb.

Our whole static database was handled with Scriptable objects where I work (for one game at least). Resulted in many issues. I was going overboard with nesting and had a bit of a "one scriptable object per row/item" approach which results in so many assets,
long import time, people editing them and then forgetting to save the project and pushing partial changes to the repository and so on! After I decided, never again! I'm sure you'd mitigate most of these issues if each of your scriptable objects are "tables" and then contain a list of plain [Serializable] c# objects.

from slugdb.

Yeah, I definitely feel you on that. Sometimes I will stack the scriptableobject, such as the table could be the main asset then the child assets could be rows, similar to how I did here in the project view:

But, as you mentioned, that really could add up quick. For my current project, I am working on small personal streaming system and I wanted to keep track of where all of the GO's are within their subscenes, so I have been testing different ways to store the data that keeps the editor usable. I found that when trying to serialize anything custom that uses the ISerializationCallbackReceiver, the editor basically becomes unusable (at least, once you hit several thousand items) if you try to view it in the inspector unless you take those particular items and set them as [HideInInspector] and then I just make a custom inspector that only loads X amount at a time, otherwise that interface ends up getting called so much as soon as you click on it that it basically locks up the editor.

What I found that seems to be working pretty well and is relatively performant so far is I have a simple struct which I use that contains some basic fields for identifying the scene and some settings related to it, and then a List which holds a much more complex struct which has a bunch of different things and additional lists/arrays for positions and identifiers for all of the items within that scene, etc.

So the SO itself is pretty basic with just a list, and each entry in the list is a struct holding scene info and then it's own list of all the contained items data. I found that so far I have had good luck retaining the data, and its quick to iterate over as it's just a basic list.

from slugdb.