Create - theme_widget #21
Comments
Tasks -
|
|
feedback Brilliant. I love it. How do you display those? Last - if you select any component, it should show the current CSS and you edit it instead of adding to the current CSS. Also - one should be able to give a name to the totality of all css of all components, changed or unchanged, and save it. Then, a dropdown should allow me to select any of the saved themes and it will apply it and also restore the css from that theme in the editor if i select the components. Finally, of course, a selected saved theme should also be deleteable (apart from the hard coded default themes) Now, an additional cool feature would be, once a theme is selected and gets changed, to keep track of all component names in the list visually where the css has been changed, until we "save" those changes under the current or a new name. The hard coded ones are the ones provided by ibrar at some point. At least the current theme fixed and an additional dark theme or night theme. |
Tasks -
|
Tasks -
|
|
feedback Good job. Excellent. Would be good to make what you have work for all components, so ibrar can start playing with it even while you are still improving things. It seems this should already be somewhat usable now. Otherwise:
Let me say something about the last option, which might sound confusing, but for example:
There is a difference between applying specific styling to a few specific button instances or applying a change to the styling in the shared stylesheet that all buttons might re-use. This needs to be addressed as well - that's maybe the biggest challenge in the changes requested above. |
Tasks -
|
|
feedback One thing - please take time to un-intermingle the components that get styled by parents please :-) When a component css is changed, great that it shows color in the tree navigation. The dropdown creates But to be honest, that is probably a UI/UX question, so maybe Ibrar can propose a remake of the theme widget. I wonder if the "theme widget" itself should be displayed in the tree navigation as well? :-) Otherwise this looks good, but what is weird now: we lost all the styling options for the instances...
We should be able to decide (or rather Ibrar) of whether individual instances or all of them receive a styling. I make a proposal at the end of this feedback. Otherwise, it looks prefect the way it works. I do think you should maybe reach out to Ibrar and share your fork of the playproject page so he can start playing and applying the new themes already and also he can provide feedback whether he can use it or not and maybe comes up with ideas about what would make things easier :-) PROPOSAL: Let's say the first editor tab is the default style element of that component. You then click Now advanced would be, if we could "re-use" some stylesheet across many different components, e.g. one that only deals with FONTS and we want it to be the same thing everywhere. There are 3 parts to this:
I think Regarding Finally, going back to my initial discord thread, We do not have an "export" feature yet, to download and save css from localStorage theme to files and we don't have an "import" feature yet, where somebody could upload a bunch of css file themes - those have to be included in the original repository at the moment in order to be displayable and selectable in the theme widget. We might consider an import/export in the following form by representing a filesystem in json: {
"css/": {
"index.json": JSON.stringify({
"rainbow": "...",
"electro": "...",
"fantasy": "...",
}),
"rainbow/": {
// ...
},
"electro/": {
// ...
},
"fantasy/": {
// ...
},
}
}The above would then just represent everything, but for details check my original discord post. This way we can import and export it to offer users to download their themes and/or upload themes. Why is it needed?THAT WAY, Ibrar can play with the theme widget and in the end export his theme files and submit them in a worklog and we can import it and then we can write a command line tool, to take such a json theme file and create the files/folder on disk and add them to the repository and commit it to the actualy repo :-) |
|
feedback Idea
One thing to keep in mind though is the "COMPONENT PATH" ... by which i mean, maybe you have the So maybe each component has to not just pass the default name or the custom theme picked name, but also, the path towards the root component to know if it is a Alternatively just having I am thinking, basically it would be good if the app had an easy way to spit out all the paths of component names/instances in uses, e.g.: for a theme widget to learn about and then know ALL components in use everywhere and where different components are used.
A designer could then write a {
"app": "css/rainbow/app.css",
"app/header": "css/rainbow/header.css",
"app/header/button": "css/rainbow/btn1.css",
"app/content": "css/rainbow/content.css",
"app/footer": "css/rainbow/footer.css",
"app/footer/button": "css/rainbow/btn2.css",
} |
Tasks -
|
|
feedback Alright, maybe it is a misunderstanding. Now i think in previous feedback i said there should be an easy way to highlight a component with a red border to make it visible and scroll to it. many shared files Now we want the ability for a designer, to select one or more components or component instances to be more specific and create a "shared stylesheet" for them. Now if a style sheet IS shared by many component instances or even multiple sheets are shared, then each comonent instance, just like our "task explorer" needs to be able to expand parent sheets to see a list of "multiple parent sheets" that are all active. expanding the sheet itself will show all the instances it applies to, regardless of where an instance is otherwise positioned in the tree. Let's just say, the sheets are similar to "inputs" of a task :-) Regarding injecting one or many sheets into the component instance, how about:
That way we can get rid of the inject button, but toggle specific sheets on/off Cypher is currently working on the wireframe of the task messenger, and maybe he can join here to help out with the UI/UX :-) codeMaybe get rid of the css folder structure for now and create under So You need to somehow capture the component instances and all the css sheets that were default or created custom. The default ones should probably be "published" by each individual component by sharing with the theme widget what it's internal default css is. a theme like // light.json
{
"app": `
:host { color: red; }
`,
"app/header": `
:host { color: red; }
`,
"app/header/button": `
:host { color: red; }
`,
"app/content": `
:host { color: red; }
`,
"app/footer": `
:host { color: red; }
`,
"app/footer/button": `
:host { color: red; }
`,
}So you make your filesystem that single json file instead of creating files and folders for now. Of course in practice json doesnt support template literals, so it would more look like: // light.json
{
"app": "\n :host { color: red; }\n ",
"app/header": "\n :host { color: red; }\n ",
"app/header/button": "\n :host { color: red; }\n ",
"app/content": "\n :host { color: red; }\n ",
"app/footer": "\n :host { color: red; }\n ",
"app/footer/button": "\n :host { color: red; }\n ",
}All in all, let's add the feature to export or download the file, so anyone, e.g. like me, could play with the css and then download the file that contains my customizations. I can then send it to you via discord and then you can import/upload that file when you have the theme widget open and it will apply my style to your page :-) |
Tasks -
|
|
feedback Thank you for the worklog 221. All feedback i could share was shared on discord during the last chaotic month which where i needed to do a lot of business related activities and visit 2 conferences. In essence, regarding feedback to this worklog:
In essence - let's move slower but without errors. By splitting the "whole problem" into independent well defined and testable modules we can implement the solution step by step and we avoid regressions. Features can be kept in github issues so we dont forget them while we work on the more basic re-usable modules we will use to implement the whole graph explorer with all features. Regarding button placement and stuff, let cypher figure out the UI/UX and how to integrate the functionality :-) You can share those "problems" with him and let's see what ideas he has. |
Tasks -
|
Tasks -
|
|
feedback Feedback as discussed on discord this time :-) |
Tasks -
|
|
feedback Small request - you used the transparency slider at minute 3:41, which made me realise, the default transparency should probably be set to ~75% to make the transparency a bit more noticable imho :-)
It is unfinished, but this wireframe here: and extend it to look like this: And then you click "nina.json" to see what you currently see when you click the component instance. Next, when you click "new" In our graph explorer, we dont just have "sub entries" like in file explorers, but we can also create new "super entries" and we can create those "input/output" entries as well, so i guess the action needs to specify what type of "new" we are going to create :-) Regarding the JSON as such - later we can think about a data verification logic and a visual form maybe generated from a defined data type - but in the current step, the raw json is probably fine and we just should make sure it is well formed :-) Otherwise, great job - and of course, we should also now have a "delete" action.
I tried to give feedback earlier.
It's also:
Or even:
The grouping is arbitrary and decided by the designer. From then on, that new or existing CSS FILE, will show up as an input for ALL of those in the selection. It is then shared by all of them. This behavior is a bit tedious or impossible to model with the current unique/shared dropdown. Regarding COMPLETE RE-ARRANGING :-) It's up to the designer to see what they can pull off using that. At the end, what can be changed depends on what the json data input to a component allows. One last thing - when we have the real data shell in the future, the "theme widget" will or might also show the javascript source files used by the different modules we require inside the app and then we can start changing those as well, but for now that is OUT OF SCOPE. |
Tasks -
|
|
feedback I noticed a few bugs in the theme widget. vs. as you can see there is a weirdly formatted
Not saying this is the final version, but one important bit is "themeability", so e.g. whether there are additional lines between icons or not should be themable. I think one thing that could help here are the css selctors: |
Tasks -
|
|
feedback 200 lines of code reduction sounds great :) I saw you often do e.g. if (data?.sub?.length) els.push(...)
//instead of
data?.sub?.length && els.push(...)They are almost the same, but the former is so much easier to read. The
.icon {
--hub-off: 📫
/* ... */
}and css allows to generate virtual dom elements using .icon::before {
content: "📫"
}Not saying exactly how and what, but maybe a designer could help here. ... but maybe we can do a round of refactoring later and keep the icons for now the way you did them. What I am missing is a In the previous worklog you can see some of the emojis used for different types of entries, e.g. themes, css files, components, etc... i do understand the issue of copy to clipboard: const style = document.createElement('style')
style.textContent = `
h3::after {
content: " rocks!";
}
`
const h3 = document.createElement('h3')
document.body.append(style, h3)
document.addEventListener('copy', handleClipboard)
function handleClipboard (e) {
const selection = window.getSelection().toString()
const { content } = getComputedStyle(h3, ":after")
console.log("the generated content is: ", content)
const newClipboard = `${content} ${selection}`
e.clipboardData.setData('text/plain', newClipboard)
e.preventDefault()
}The code above might not yet solve everything, but you can interact and intercept clipboard activity and you can read the css before/after content properties and adjust/adapt/change any specific clipboard content before it copies, so this is solvable. Thanks for talking about the data a clicked entry sends to the super component. That is helpful. I do think the main work outputs of our project in general are:
cypher works on UX details and we brainstorm features and slowly make (1.) work. But we will need to refactor many times to slowly optimize (2.) as well and then document those standards in the README. I dont have an opinion yet whether Maybe we should start by adding a database
Thats great. Is the data sent to a super entry when you click a sub entry the "meta data" ? ...how does that tie in? how would you call that data? Also - if not too much work, a short themes bughow could it happen that a themes component id was occupied.
Having an id or sid in any of those arrays means there is a LINK between the current entry and the entry behind that id or sid contained in the array of sub/hub/inputs/outputs. Of course, the corresponding e.g. sub entry would have the id or sid of the parent entry inside of their array as well. deleting a link means removing an id in both arrays.
What is confusing is, that you call the super node of "theme_widget" a entry of type "link" ... That is confusing, because in my mind i am calling the connecting lines in the graph explorer links and they are represented in the data by id's or rather sid's in arrays, e.g. Maybe what you call a link entry (e.g. 💯 cool that clicking those will jump to the original entry. problem
|
Tasks -
|
|
feedback this time provided on discord :-) |
Tasks -
|
|
feedback feedback on discord :-) |
Task -
|
|
feedback Maybe in the future - write all worklog comments first - and then use the finished tasks and descriptions as a "table of content" about what to record in the worklog video to not forget stuff :-) |
Todo
theme_widget@output📦 theme_widget_v0.0.1 from commenttheme_widget_v0.0.1@output📦 theme_widget_v0.0.1 from commentindex.jscleanup@output📦 theme_widget_v0.0.2 from commenttheme_widget_v0.0.2@input📦 theme_widget_v0.0.2 from comment@output📦 theme_widget_v0.0.3 from commenttheme_widget_v0.0.3@input📦 theme_widget_v0.0.3 from comment@output📦 theme_widget_v0.0.4 from commenttheme_widget_v0.0.4@input📦 theme_widget_v0.0.4 from commenttheme_widget@output📦 theme_widget_v0.0.5 from commenttheme_widget_v0.0.5@input📦 theme_widget_v0.0.5 from comment@output📦 theme_widget_v0.0.6 from commenttheme_widget_v0.0.6@input📦 theme_widget_v0.0.6 from commentio.jsmodule@output📦 theme_widget_v0.0.7 from commenttheme_widget_v0.0.7@input📦 theme_widget_v0.0.7 from commentstatedbto privately get data for each component@output📦 theme_widget_v0.0.8 from commenttheme_widget_v0.0.8@input📦 theme_widget_v0.0.8 from commentSTATE.jsSTATE.js@output📦 theme_widget_v0.0.9 from commenttheme_widget_v0.0.9@input📦 theme_widget_v0.0.9 from comment@output📦 theme_widget_v0.0.10 from commenttheme_widget_v0.0.10@input📦 theme_widget_v0.0.10 from commentgraph_explorer-4h30min2h@output📦 theme_widget_v0.0.11 from commenttheme_widget_v0.0.11@input📦 theme_widget_v0.0.11 from commentREADME.mdandGLOSSARY.mdin doc@output📦 theme_widget_v0.0.12 from commenttheme_widget_v0.0.12@input📦 theme_widget_v0.0.12 from comment@output📦 theme_widget_v0.0.13 from commentThe text was updated successfully, but these errors were encountered: