Blender Git Commits

Merge branch 'master' into asset-experiments

Add name/description fields to entries themselves too.

This allows us to greatly simplifies sorting (and avoid recomputing UI name each and everytime!).
Also, correctly free entries/variants names/descriptions.

Spread (future assets) uuid over entries/variants/revisions.

Makes more sense this way, and will probably save memory in the end even.

Merge branch 'master' into asset-experiments

Merge branch 'master' into asset-experiments

Filelisting: switch from mere arrays to listbases.

Was not sure about that (adds two pointers to entries, variants **and** revisions :/ ),
but with the incremental process of listing we are using now, it makes things sooooo
much easy to handle (and also avoids tons of (deep)copy and mem (re)alloc), that it's
definitively worth it.

And since most (if not all) of 'public' access to filelist is done through filtered ones,
we can easily keep this a mere array of pointers, and hence keep quick index lookup.

Also, quite noticiably simplified the whole listing code (less functions, less levels of subcalls...).

Note: for now we stick to mere alloc, we may benefit from either memarena or mempool,
but those are not threadsafe (which means we could not so easily pass mem from worker
thread to main one), so not quite sure it would be worth it.

Note: thumbnail stuff is to be reworked from scratch too, have the feeling it's not yet
100% thread safe, and using a job here is probably way overkill, since we do not show
any progress in UI.

Merge branch 'master' into asset-experiments

Merge branch 'master' into asset-experiments

Merge branch 'master' into asset-experiments

Move back path, image etc. to FileDirEntry.

Also, reduce revision's uuid to 64bytes, should be more than enough!

Thing is, we can expect tens (if not hundreds) of thousands of revisions from a
big assets repository with history storage (vcs). So we want that struct
to be as small as possible.

Also, we do not expect to handle several variants/revisions of a same asset within
a same 'context' (there is always only one active variant & rev). So storing
path & co at entry level shall be enough. And helps make code simpler/nicer.

Get rid of abspath storage, this is storing twice the same data, not nice memory-wise.

We may suffer a little performance loss here, but would not expect it to be really important,
since rebuilding a full abspath is not needed that often.

Restore size/date sorting.

Also, get rid of modes/owner crap, this is quite advanced UNIX fs info, not much to
do in our filebrowser imho, and takes time, UI space and Mem space!

Merge branch 'master' into asset-experiments

Merge branch 'master' into asset-experiments

Merge branch 'master' into asset-experiments

Filelisting: First step of sanitanization...

Move typeflag and selflag back to FileDirEntry, and add blentype there too,
this will be needed by asset engines, and avoids rechecking lib ID types over and over!

There's much more to do here though. Also, FileDirEntryRevision is going to be
used quite higly, we want to keep it as light as possible (much lighter than
its current state for sure!). Think we can move back to FileDirEntry paths
(and try to get rid of abspath on the run, too), but also most likely
preview (we won't store a preview for all possible revisions anyway),
owner/permissions, etc.

Rev should probably only have its uuid, and date/time.

Also, simplified filetype generation (from extensions for real files, and BLO helpers
for libdata), now it's nicely encapsulated into each reading callback.

Merge branch 'master' into asset-experiments

Merge branch 'master' into asset-experiments

Merge branch 'master' into asset-experiments

Big refactor of filelisting in filebrowser - decouple os/fs-related direntry from actual blender listing.

Main idea is that direntry had quite a bit of things already absolutely useless
in the mere 'file listing' context (image pointer, void 'data' pointer, etc.).

On the other end, to handle future asset stuff, we need *more* 'meta data' for our 'files'
(tags, variants, revisions...).

Further more, we need all this to be easily usable through RNA, i.e. we need it to
be defined in DNA.

So instead of trying to use direntry in DNA, mixing low-level system stuff like stat
where we do not want to see it, we define our own 'file' representation,
with only what we really need (who cares about chars or block or dev files in filebrowser?
we only need to know whether it's a regular file or a directory, period).

That way, low-level dirlisting remains clean, and we can easily extend our own
data as needed.

Note this new code works, does not crash (so far...) nor memleak, but it
needs quite a bit of work still, we are still storing useless stuff in direntry
(all those strings representing modes, size etc.!), and mem handling
during dir/lib listing is confusing at best (would like to use a memarena
or mempool here, but it's not that easy).