search

playproject-io / playproject-io.github.io

playproject website
https://playproject.io
MIT License
5 stars 2 forks source link

Create - theme_editor #25

Open alyhxn opened 1 month ago

alyhxn commented 1 month ago

@todo

21

alyhxn commented 1 month ago

Tasks - 2024.07.17

alyhxn commented 1 month ago

Tasks - 2024.07.20

alyhxn commented 1 month ago

Tasks - 2024.07.23

alyhxn commented 1 month ago

Tasks - 2024.07.25

Worklog

worklog-222

serapath commented 1 month ago

feedback 2024.07.29

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. How sure are you that all bugs are removed and everything is working fine?

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?

alyhxn commented 1 month ago

Tasks - 2024.07.31

Worklog

worklog-223

serapath commented 1 month ago

feedback 2024.07.31

Thanks. great update.

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

  1. have the ability to expand links to "super" and "sub" entries for any entry. An entry might represent a document or a task or a component instance or anything else, depends on what app we use the "graph explorer" in.
  2. have the ability to have different types of "super/sub" links to other entries, such as e.g. "super/sub" tasks, "super/sub" documents (=inputs or outputs), etc...

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 const id is to have a unique ID for each - in this case - graph_explorer instance :-) That sounds like the same of what the css_id is all about.

id

The difference is though, that the css_id is passed as an argument, while the const id depends on the order of instantiation of a component to be the same now as in the future, when an app loads again.

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. Now on mobile there is no such thing as a right click, so there could be an icon that opens the "context menu" for any entro to trigger an action.

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. e.g. Instances: 33, [select] ------o...

That could all be below the graph explorer including the action button.

The same would be cool for the editor. Could you move the tabs and the ID (e.g. 16) bar And move that BELOW the editor? :-) Even BELOW the action buttons for as long as we have those action buttons below the editor.

example

I guess the action buttons would be right about that tab bar in the example above, layout wise.

regarding communication system

YES, 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 css_id is not deterministic, which IS a problem we need to solve, exactly because you say upon re-load it is hard to match them to what is stored in the browser storage (localStorage or indexedDB).

For example, for any module, this is deterministic: ID The module itself has a unique ID and a counter The STATE is what each module has.

Later, when we create instances, it can create an id

id

Here you see, we store it under STATE.ids[id], so the module itself with the stable ID knows all its instances.

BUT, depending on the order, the count might not map to the right data saved in the localStorage from previous page load, so that IS a problem.

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

alyhxn commented 1 month ago

Tasks - 2024.08.05

Worklog

worklog-224

serapath commented 1 month ago

feedback 2024.008.05

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.