timiz0r / ezutils Goto Github PK

Currently working on method-based one, which is first step.

For attributes

• Need to support extraction from attributes, probably just id; probably using a base class?
• Probably also need to specify the required EZLocalization data, since we can't associate it any other way

As they won't cause issues.

I feel like the chances of this are >0

The backup plan is to...

• Host some image and page on GitHub Pages
• Render this image in the package manager
• If something bad happens, update the image
• Clicking on the image goes to the page with more details

Only real potential downside is how long do we keep up the alerty message. Since a fix almost certainly involves getting a new package manager, the package manager could refer to a different path with non-alerty images.

This is to cover the scenario where a GameObject that is to be turned into a prefab has child gameobjects that also need to be turned into prefabs.

The UI probably populates a tree of the gameobjects, and the right side of that tree contains objectfields for inserting prefab assets.

Particularly useful for warnings, which may not be causing issues in practice.
gotta think about where to store them, probably in an asset. and the structure.

It's an increasingly common pattern to add a hidden field to get the binding, then, based on value changes, enable or disable a class. Plus reading the initial value with a delay. We should be able to wrap it up into a nice package.

If we can find a simple full-uxml way to do it with one control, do that. For bools it's obvious, but gotta think about other types. Hypothetically, we can perhaps test for iconvertible and convert to a bool, otherwise check for ref type and null check, or throw.

Or, or perhaps in addition, we can allow the code to decide more custom logic.

Once made, we should search far and wide for display: none controls and see if they are using this pattern, then convert them.

Pretty low prio, since there probably isn't anyone using it. Plus it's a warning-level analyzer

Unity version : 2022.3.6f1
Installed package
VRChat SDK - Base : 3.5.0
VRChat SDK - Avatars : 3.5.0
EZUtils Common : 1.0.9
EZUtils Editor Enhancements : 1.1.3
EZUtils Localization Tools : 1.0.8
VRChat Package Resolver Tool : 0.1.27

Console message :

Packages\com.timiz0r.ezutils.common\UI\TypedObjectField.cs(12,18): error CS0534: 'TypedObjectField<T>' does not implement inherited abstract member 'CallbackEventHandler.SendEvent(EventBase, DispatchMode)'

Or, rather, presumably takes longer after each extraction.

Since we won't ship extraction anywhere, it's not urgent. It'll also probably be obnoxious to debug.

Well, except we can't show displayName if the package isn't installed. Instead, enhance the description to include the display name and show that.

Then again, let's lump this under localization. There's obviously no way to localize a package.json, so let's go crazy and hard-ish code it into the package ui. If we do end up localizing, then that probably solidifies not deprecating it.

This type used to exist and cached CatalogReferences. It was removed because catalog references also contain synchronizers, and two catalog references with different synchronizers each are allowed. As such, it wouldn't be right to cache CatalogReferences.

This time around...

• CatalogReference loses its CatalogLocaleSynchronizer and is only a pointer to a GetTextCatalog
• EZLocalization owns its CatalogLocaleSynchronizer

I'm about to do a change to unify the wonky initialization requirements of CatalogLocaleSynchronizer and CatalogReference, and I may end up taking this up along the way.

If possible! It currently doesn't get as shown installed.

It does get shown in UPM window if enabling showing of dependencies, so there's hypothetically a good way.

Hypothetically speaking, we could try to query the lockfile.

Actually just looked it up, and there's a includeIndirectDependencies parameter we can pass woo

Azure Artifacts now appears to be fully UPM compatible, so there's no longer a reason to have our own package manager.

We'll probably mainly just purge it from documentation.

Perhaps we'll also try to simplify bootstrap scripts into a single pass and not two. If I recall, the main reason is that the bootstrap script itself requires the package, since we do Azure Artifacts API calls. With these no longer needed, we can hopefully remove that initial dependency. Still need a good method for adding the scoped registry, though.

We'll keep the package manager around for a while longer, just in case, including installing it as part of bootstrap.