properties panel for objects #68
Labels
No Label
Graphic Design Required
bug
duplicate
enhancement
feature request
heisenbug
high severity
invalid
maintenance
minor
performance
question
shiny
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Total Time Spent: 3 hours 3 minutes
Due Date
Tracy
3 hours 3 minutes
No due date set.
Dependencies
No dependencies set.
Reference: Labs/Binder#68
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
You read the title.
I want to be able to see what the file type is, resolution, file size, etc.
The idea is to have a little gear in the top right corner (I kind of don't like that for properties because it's associated with settings, where this is also informational but still), overlay the object in the viewer just like the forward and back buttons.
The would open up the a panel to the right of the object, containing juicy information goodness.
I also think it would be cool to have it open up with the "n" so that when a blender user opens it by accident they'll be happy :)
Made great progress
It now opens and closes. Of course, the info here is just a mock up and not real. Without having like object/tag history accessible, and no merging data, I'm kind of at a loss for what else to put here...
But my thinking is to have the whole thing just be scrollable, and then have the regions be collapsible.
Oh yeah, looked at properties on images on my desktop and we need modification dates, and filenames (plural!). Some day it would be nice to be able to set the preferred ones...
These properties are currently stored as tags but the reason for not using hidden properties is so that they are searchable... I'm not sure how I feel about that. Might migrate them out of tags and make search also just look at those tables as well.
But insofar as this is blocking #69 nice I don't think there is much left to do, but it's a good place to stop for the day and finish up with my morning tea before getting into something harder (theory of object merging...)
Serendipity is where I saw the kebab graphic in the icons folder (because I was looking for something to use at least as a placeholder because I didn't wanna do graphics tonight) and realized that was perfect... So probably no new graphics for this after all.
About to go to sleep but I saw this when I restarted Binder and I wanna look into it in the morning. Too tired to comment.
Fixed that uncaught error
Making steady progress, the tricky problem is going to be getting the resolution. Right now there is not real mechanism to read it. We could pull it from the img tag perhaps, but that element is elsewhere from the properties context. I also think it's kind of a hack because once #73 is closed we'll have it in memory already... But I suppose there's no harm in caching it in the database from the image tag for now and leaving a note on that issue...
So for storing the image resolution, storing it in the database is okay but then we need a change observer and needless complexity for that and it's just... Easier to store it as a state in the object viewer, and then let the image viewer update it, triggering an update in the properties panel and be done with it.
The correct solution is to handle it like mimes with "genIfNotExists" but I'm just hacking it together quick for now (or indefinitely...), there's no infrastructure to load the image on the backend and I hate putting important stuff outside of the render process (the goal is to make it easily ported out of electron, for an android build).
Yeah definitely the correct solution is to load it the same way as the mime type but this is good enough for now. It's blank while the image loads which sucks but whatever.
Happy with it for closing the issue. Adding stuff to it will fall under independent issues.