Create - theme_widget

[alyhxn]

Todo

• Create - theme_widget
  • Implemented communication
  • Implemented theme widget
  • @output 📦 theme_widget_v0.0.1 from comment

---

• Update - theme_widget_v0.0.1
  • @output 📦 theme_widget_v0.0.1 from comment
  • index.js cleanup
  • Load operation
  • Add operation
  • Save operation
  • Debugging
  • @output 📦 theme_widget_v0.0.2 from comment

---

• Update - theme_widget_v0.0.2
  • @input 📦 theme_widget_v0.0.2 from comment
  • Enabled IDs for components
  • Converted theme_widget list into tree
  • Enabled jumping to a section
  • Style adjustments
  • @output 📦 theme_widget_v0.0.3 from comment

---

• Update - theme_widget_v0.0.3
  • @input 📦 theme_widget_v0.0.3 from comment
  • Enabled autosave
  • Added theme control for all components
  • Debugging
  • @output 📦 theme_widget_v0.0.4 from comment

---

• Update - theme_widget_v0.0.4
• @input 📦 theme_widget_v0.0.4 from comment
  • Test and trial
  • Finding the best CSS file structure
  • Defining the logic
  • Added tabs to theme_widget
  • @output 📦 theme_widget_v0.0.5 from comment

---

• Update - theme_widget_v0.0.5
  • @input 📦 theme_widget_v0.0.5 from comment
  • Added scroll to and highlight on click for components
  • Added naming system for files
  • Added import and export functions
  • Debugging
  • @output 📦 theme_widget_v0.0.6 from comment

---

• Update - theme_widget_v0.0.6
  • @input 📦 theme_widget_v0.0.6 from comment
  • Added and integrated io.js module
  • Added inputs to graph
  • Debugging
  • @output 📦 theme_widget_v0.0.7 from comment

---

• Update - theme_widget_v0.0.7
  • @input 📦 theme_widget_v0.0.7 from comment
  • Enabled input click
  • Change instance click
  • Divided defaults data
  • Added statedb to privately get data for each component
  • Debugging
  • @output 📦 theme_widget_v0.0.8 from comment

---

• Update - theme_widget_v0.0.8
  • @input 📦 theme_widget_v0.0.8 from comment
  • Update STATE.js
  • Updated components dependent on STATE.js
  • Implemented add operation for instances
  • Added extensions to file names
  • Debugging
  • @output 📦 theme_widget_v0.0.9 from comment

---

• Update - theme_widget_v0.0.9
  • @input 📦 theme_widget_v0.0.9 from comment
  • Added json entry to graph
  • Merged uniq and shared to just CSS
  • Debugging
  • @output 📦 theme_widget_v0.0.10 from comment

---

• Update - theme_widget_v0.0.10
  • @input 📦 theme_widget_v0.0.10 from comment
  • Simplified graph_explorer - 4h
  • Changes in other files accordingly - 30min
  • Debugging - 2h
  • @output 📦 theme_widget_v0.0.11 from comment

---

• Update - theme_widget_v0.0.11
  • @input 📦 theme_widget_v0.0.11 from comment
  • Fixed links between entries
  • Transferred emojis to CSS
  • Implemented before and after copy
  • Debugging
  • Added data folder in the graph
  • Added README.md and GLOSSARY.md in doc
  • @output 📦 theme_widget_v0.0.12 from comment

---

• Update - theme_widget_v0.0.12
  • @input 📦 theme_widget_v0.0.12 from comment
  • Added type emojis and menu
  • Styling and emoji on/off logic
  • Implemented dynamic spacing
  • Debugging
  • @output 📦 theme_widget_v0.0.13 from comment

[alyhxn]

Tasks - 2024.06.17

• Create - theme_widget
  • Implemented communication - 4h
  • Implemented theme widget - 3h
  • Logged task - 2min
  • Recorded Worklog - 13min
  • @output 📦 theme_widget_v0.0.1

---

Worklog

worklog-216

[serapath]

feedback 2024.06.16

Brilliant. I love it.
One question though.
What happens if a name repeats?
What about "nested components"?
What if e.g. "editor" would have a sub component "menu"?

How do you display those?
They should be displayed i guess.

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.

[alyhxn]

Tasks - 2024.06.21

• Update - theme_widget_v0.0.1
  • index.js cleanup - 30min
  • Load operation - 2h
  • Add operation - 1h
  • Save operation - 2h
  • Debugging - 1h
  • Recorded worklog - 10min
  • Logged tasks - 5min
  • @output 📦 theme_widget_v0.0.2

---

Worklog

worklog-217

---

Feedback

Also - one should be able to give a name to the totality of all CSS of all components, changed or unchanged, and save it.

I have implemented this but not like what we have in VScode but we can save components into specific themes individually.

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.

This is an advanced feature and needs some critical thinking about how to carry it out.

[alyhxn]

Tasks - 2024.06.22

• Update - theme_widget_v0.0.2
  • Enabled IDs for components - 1h
  • Converted theme_widget list into tree - 2h30min
  • Enabled jumping to a section - 30min
  • Style adjustments - 30min
  • Logged tasks - 5min
  • Recorded worklog - 10min
  • @output 📦 theme_widget_v0.0.3

---

Worklog

worklog-218

[serapath]

feedback 2024.06.23

Good job. Excellent.
Current github page of your fork seems to have a broken built, maybe you can take a look and fix it as well, but i saw how it works in your worklogs, which seems good.

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:

• make theme for all components work, not just "our_contributors"
• any "unsaved changes" in component themes (cached, but not saved under a name yet)
  • maybe diting css "autosaves", so refresh will still show what you changed last
  • but if you select a theme and apply changes to it, it will set a "dirty" flag in localStorage
  • when theme editor loads, it will check dirty flag for all component names and make the font, e.g. yellow, to indicate there are changes, but those have not been saved to the specific "theme name" yet. If you switch a theme name before you save, those changes will be lost and overriden by what is loaded from that new selected theme.
• needs to have a delete option for named theme
• needs a reset button to clear localStorage to go back to hardcoded defaults
• needs to have ability to inject custom default styling per component type not just instance

Let me say something about the last option, which might sound confusing, but for example:

1. we have "our contributors" with styling to layout contributors
2. we have instances of individual contributors to apply custom styling to one or many of those
3. BUT: we also have the default style shared by all instanced of a component

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.

[alyhxn]

Tasks - 2024.06.25

• Update - theme_widget_v0.0.3
  • Enabled autosave - 3h
  • Added theme control for all components - 4h
  • Debugging - 1h
  • Recorded worklog - 15min
  • Logged tasks - 5min
  • @output 📦 theme_widget_v0.0.4

---

Worklog

worklog-219

[serapath]

feedback 2024.06.24

One thing - please take time to un-intermingle the components that get styled by parents please :-)
That makes things a lot easier for Ibrar as well.

When a component css is changed, great that it shows color in the tree navigation. The dropdown creates (default-v2)
I think we should more stick to the pattern editors use.
They usually indicate it with a default* or some dot in the tab to indicate a file has unsaved changes (that's at least what vscode does) and maybe we should adopt that.

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...

• this should exist both
  1. the "contributor"
  2. the individual instances too

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:
So if you can send/inject styling to a specific component and it goes into the .adoptedStyleSheet array of it.
Then the components could be coded in a way where clicking on any component gives you an array with style sheets and you can visualize it in the theme widget, by clicking on a component in the tree navigation and then you will see one or more editor tabs for each style element in that array of the component and you can maybe add additional ones.

Let's say the first editor tab is the default style element of that component. You then click + and create another editor tab. When you click inject, they get both injected in the order they are listed as tabs (you can re-arrange those tabs), because the order matters when css decided which css rules take preceedence.

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:

1. make that inject work and also let each component share the defaults from all current style elements in it's array
2. optimize the efficiency of how we achieve this behind the scenes.
3. Optimize the user interface of the theme editor widget (maybe with Ibrars help)

I think 1 should take a tiny bit priority, so Ibrar can start and then we can optmize the code behind the scenes to make it work more effieciently and take into consideration Ibrars feedback from working with that system.

Regarding 3, it would be cool, to shift- or control-select multiple widgets in the tree and then maybe "group" them and give that name a group. Here we would probably re-use the idea of the "task tree component" (from the task messenger) to expand and see multiple parents of a component, where those would be those "groups"... but it needs additional thinking.

---

Finally, going back to my initial discord thread,
We should be able to save or store a theme in a folder with css files and then have a json to map it to components, the way i described it on discord, unless you have a comment to improve what i suggested :-) Maybe include that in the next worklog as well?

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 :-)

[serapath]

feedback 2024.06.25

Idea

• Every component is encapsulated in it's own shadow dom.
• Thus we can write css for them without thinking about the rest of the page when writing css
• So being able to maybe have a folder ... like e.g. css/ in the repository
  • ...and then inside that folder a css/index.json with an array of names of themes
  • and then css/<theme-name>/... for each theme name
  • and then inside those folders, maybe we could store one file per component we use and theme
    • e.g. css/<theme-name>/button.css
  • And then when the page loads, it will always check for css/index.json
  • and then enable a "theme picker" component to list all possible themes mentioned in the json file
  • And then lookup the selected theme under css/<theme-name>/...
  • and because the app knows all component names it uses ....it could look up those theme files
• Or each component will know about the <theme-name> it uses
  • and then looks up it's own custom theme file and applies it to itself.
  • It also needs a listener function to notice via communication
  • for when the theme picker selects a different theme, so it can switch

One thing to keep in mind though is the "COMPONENT PATH" ... by which i mean, maybe you have the button component being used in the header and the footer, but the footer/button wants a different theme than the header/button, even though it's technically uses the same button component code. Even if you decide to use a counter to use integers as id's, debugging is easier if we can have a mapping to path names to know what component we are talking about.

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 footer/button or header/button in the component tree which is the app.

Alternatively just having css/<them-name>/<component-name>.css isn't good enough.
Instead we need to take care of css/<them-name>/footer?/<component-name>.css or css/<them-name>/header?/<component-name>.css as well, which makes things complicated.

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.:

- app
- app/header
- app/header/button
- app/content
- app/footer
- app/footer/button
... and so on

for a theme widget to learn about and then know ALL components in use everywhere and where different components are used.

• e.g. the button is used in header and footer

A designer could then write a <theme-name>.json files, where he does not define the theme or style, but he can define those component paths and map them to css files for the components, e.g. rainbow.json

{
  "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",
}

[alyhxn]

Tasks - 2024.06.29

• Update - theme_widget_v0.0.4
  • Test and trial - 5h
  • Finding the best CSS file structure - 2h
  • Defining the logic - 2h
  • Added tabs to theme_widget - 30min
  • Recorded worklog - 15min
  • Logged tasks - 10min
  • @output 📦 theme_widget_v0.0.5

---

Worklog

worklog-220

---

Feedback

The tree mentioned just above this comment is inefficient and complex to implement. I tried and almost built it but things were getting out of hand. Here are the reasons:

• For simple operations, like accessing a specific CSS file, multiple loops were required everywhere making the code dirty.
• For project folder, addresses like app/header/button are fine but for JSON extra functions for reading and editing are needed.
• This approach makes CSS unusable for other components, For instance, app/header/button can never be used by the footer whereas list does not force this.
• Long CSS file names. For the website, every CSS file needs to have a different name in many cases for which I was forced to use full file address while list is built on unique names or IDs.
• I want to add a preference of an instance whose address is app/header/button/very/long then I will need to first check along the way if every ancestor is present there, if not then add. I mean it's a very expensive operation.
• There are countless more drawbacks that almost forced me to give up. Yeah, it looks fancy from far away but it's implementation is a mess. Just like storing the tree of task-messenger into a tree data structure got things complicated, this is a similar case. List is far better.

[serapath]

feedback 2024.07.05

Alright, maybe it is a misunderstanding.
I'm not sure i understand what you are saying.
I imagine, every component and/or component instance needs a unique ID and can be added to a list. That is ok.
I just think, with every ID, there should be an associated path where that instance sits inside that tree.

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.
THe scroll to it would still be cool, but the highlight would probably just work by actually adding a border: 1px solid red; to the css for an instance, so no need to add extra features for that. It's already possible for a designer to do it.

---

many shared files
yes, that is needed.
usually, every component has probably one shared file for all it's instances and the option to have a specific extra style sheet per instance.

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.
Editing that shared style sheet will update ALL the instances.

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:

1. let's make each sheet shown as a tab visible in the "active instance explorer" too.
2. distinguish between component instances and sheets similar to how we distinguish between tasks and inputs/outputs
3. allow a toggle button next to each sheet to inject or not inject it

That way we can get rid of the inject button, but toggle specific sheets on/off
Also other buttons could be action buttons shown based on the specific item in the tree that is selected.

Cypher is currently working on the wireframe of the task messenger, and maybe he can join here to help out with the UI/UX :-)

---

code

Maybe get rid of the css folder structure for now and create under css/ just theme files light.json, dark.json, rainbow.json, etc... which are mean to be structured in whatever ways you can export from your theme editor widget.

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.css can have an object with the pathnames or whatever you need and at some point, it includes the actual css source that can be stored.
maybe just as a simple dictionary, e.g.

// 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 :-)

[alyhxn]

Tasks - 2024.07.10

• Update - theme_widget_v0.0.5
  • Added scroll to and highlight on click for components - 1h
  • Added naming system for files - 3h
  • Added import and export functions - 2h
  • Debugging - 4h
  • Logged tasks - 5min
  • Recorded worklog - 30min
  • @output 📦 theme_widget_v0.0.6

---

Worklog

worklog-221

[serapath]

feedback 2024.07.29

Thank you for the worklog 221.
I know my feedback now took some time and things have to moved on since then. Looking forward to the next worklog.

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:

• explorer should become a generic graph explorer component
• all buttons in editor should move into a menu below the explorer (currently wireframed by cypher) :-)
• all tabs can be shown in explorer and names can be edited in explorer and e.g. unique vs shared just means how many "super" or "sub" entries a css file has, if it has only one, it is unique, if it has more than one, it is shared ...we have to set/edit connections of an explorer entry in terms of how many "super" or "sub" entries it has.

In essence - let's move slower but without errors.
Let's make everything we build stable and reliable - maybe as a separate component or module and then use it to build the next step on top once we are ready.

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.

[alyhxn]

Tasks - 2024.08.07

• Update - theme_widget_v0.0.6
  • Added and integrated io.js module - 6h
  • Added inputs to graph - 2h
  • Debugging - 2h
  • Logged tasks - 5min
  • Recorded worklog - 10min
  • @output 📦 theme_widget_v0.0.7

---

Worklog

worklog-225

---

Feedback

In the worklog, I meant I don't know your ideas about what operations we need to do on theme entries in the graph. I guess we can open the theme file upon clicking and all files inside a theme upon theme entry click.

[alyhxn]

Tasks - 2024.08.11

• Update - theme_widget_v0.0.7
  • Enabled input click - 2h
  • Change instance click - 1h
  • Divided defaults data - 2h
  • Added statedb to privately get data for each component - 2h
  • Debugging - 1h
  • Logged tasks - 5min
  • Recorded Worklog - 10min
  • @output 📦 theme_widget_v0.0.8

---

Worklog

worklog-226

---

Feedback

One point I missed: In data.json, super instances point to their subs using their sid.