Create - theme_editor #25
Comments
Tasks -
|
Tasks -
|
Tasks -
|
Tasks -
|
|
feedback One minor thing i noticed is, that the "scroll into view" feature is great, but mabe the theme widget needs a transparency slider so we can make it's alpha channel or opacity to 25-50% so it won't hide the component we want to see. I guess that could be done by using the theme widget to apply an opacity css style to the theme widget - maybe that's actually enough :-) Otherwise - super cool functionality wise. And how far are we with turning the explorer into a generic "graph explorer" component which can be re-used in the theme widget and the task messenger later on? |
Tasks -
|
|
feedback Thanks. great update. 💯 for the transparency slider, haha :-) didn't expect that. Maybe it should be set to 90% or even 95% by default to make people aware of it. Otherwise: I think the main component instances (header, datdot, editor, supporters, etc...) should also already look like the sub component instances (e.g. nina, jam, mauve, ...), because if i click to see the "super entries" of e.g. Nina, it shows "our_contributors", but in the same way we should be able to click to see the "super entries" of "out_contributors" and it should probably show "playproject.io" (the root component instance which has no "super entries" anymore). The generic "graph explorer" is supposed to:
In the case of the "Task Messenger" the graph explorer will be used slightly different from how it is used in our "Theme Widget" :-) When it comes to inputs/outputs, maybe that is a good "type" to use in our theme widget as well. Our "component instances" could be imagined as similar to our "tasks" and the "inputs/outputs" could be imagined as similar to "params/arguments/opts" passed to components and they can change at runtime. One such input might be a css theme, but in the future it could also include any other type of data, but that's out of scope for now. Now when it comes to "output", i guess components can also produce data output, but again, that would be out of scope for now. I imagine the "theme widget" itself could produce themes as output ... who knows, but as said, might not be needed for now, so if emojis can be colored, maybe we should grey out the emoji to indicate it is disabled or something like that. But generally - good update, thx :-) One open question is though, how to we show "unique" vs. "shared" css files and how do we show what theme it belongs to, etc... ...there are many slightly different ways and i guess we have to find the best one :P The intention of The difference is though, that the Regarding the actions inside or outside the "graph explorer". Usually file explorers allow you to "right click" a file or folder to do anything with them. But I do agree, selecting one or multiple entries in the graph explorer and then clicking some sort of action button would work. One thing i would prefer though is, if the "menu bar" is BELOW the file explorer. That could all be below the graph explorer including the action button. The same would be cool for the editor. I guess the action buttons would be right about that tab bar in the example above, layout wise. regarding communication systemYES, i am interested in knowing more about the communication system :-) Regarding security/safety rules, we will need to do another iteration on that when we come back to the task messenger and update that inside the "data shell" i am working on (or should be working on if i wasn't so busy with business work at the moment). https://serapath.github.io/task-messenger Is where you can see my current "work in progress" when it comes to data shell (i know, super confusing), i will explain it when ready and hopefully we can then run the task messenger inside of it. Ideally i want to also run playproject inside of it as well. Both use the graph explorer, which will then use the communication system provided by the data shell, so that is what i mean by refactor - but don't bother at the moment. Let's first make the system work the way you currently have it, but please make a video recording that system. One thing you say is that the For example, for any module, this is deterministic: Later, when we create instances, it can create an Here you see, we store it under BUT, depending on the order, the Essentially it feels, what is needed, is loading things FROM the localStorage in the first place and then during runtime, save any changes and ID's to the localStorage and then on page reload, load things based on whatever is saved in the localStorage. This might have quite some implications for HOW we need to code and design and load our component and component instances in the first place. I invite you to think about it and see what suggestions you can come up with :-) I see no problem with saving ID's id's css_id's, etc... in the localStorage as well |
Tasks -
|
|
feedback The explorer is still buggy, but maybe let's discuss it on github. I think it needs more work to make it fully functional, but it is an improvement. The communication system you explained is nice, thanks for the explanation. I do think the usage of it can be refined over time when we improve the graph explorer. Maybe we need to discuss it a bit, let's continue on discord. |
@todo#21
theme_editor@input📦 theme_widget_v0.0.6 from comment@output📦 theme_editor_v0.0.1 from commenttheme_editor_v0.0.1@input📦 theme_editor_v0.0.1 from comment@output📦 theme_editor_v0.0.2 from commenttheme_editor_v0.0.2@input📦 theme_editor_v0.0.2 from comment@output📦 theme_editor_v0.0.3 from commenttheme_editor_v0.0.3@input📦 theme_editor_v0.0.3 from comment@output📦 theme_editor_v0.0.4 from commenttheme_editor_v0.0.4@input📦 theme_editor_v0.0.4 from commentlocaldbmodulegraph_explorermodule@output📦 theme_editor_v0.0.5 from commenttheme_editor_v0.0.5@input📦 theme_editor_v0.0.5 from comment@output📦 theme_editor_v0.0.6 from commenttheme_editor@output❓theme_editor_v0.0.?The text was updated successfully, but these errors were encountered: