Design - popoverContainer

[Mehrabbruno]

@todo

• Design - popoverContainer_0.0.1
  • popover header
    • Title
    • Number of children
    • Close button
  • popover body with min-max height of 156px
  • pop footer
    • search input to search for children content in the body
  • @output 📦 popoversContainer_v0.0.1 from comment
    • next Design - applicationPopover #116
    • next Design - permissionPopover #117
    • next Design - actionsPopover #118
    • next Design - historyLogsPopover #119
    • next Design - fileExplorePopover #120
    • next Design - collapsedTabsPopover #121
    • next Design - bookmarksPopover #122
    • next Design - collapsedBookmarksPopover #123
• Split of popoverContainer_0.0.1 component
  • Discussion on the structuring of popOverComponents and how the task and time should be logs
  • @input 📦 popoversContainer_v0.0.1
  • @output ❓ [popoversContainer_v0.0.2]

@info

This is the skeleton design component to house all the popover components

[Mehrabbruno]

Worklog

worklog-1

---

Tasks

• done Design - popoverContainer_0.0.1 - 20min
  • done popover header
    • done Title
    • done Number of children
    • done Close button
  • done popover body with min-max height of 156px
  • done pop footer
  • done search input to search for children content in the body
  • @output 📦 popoversContainer_v0.0.1

[serapath]

feedback 2022.10.31

Worklog

worklog-1

Tasks

• done Design - popoverContainer_0.0.1 - 20min

  • done popover header

    • done Title
    • done Number of children
    • done Close button

  • done popover body with min-max height of 156px

  • done pop footer

  • done search input to search for children content in the body

  • @output package popoversContainer_v0.0.1

Thanks for the work. looks good.
You also share how the design was quick to be done, but updating all the issues was a lot of work.

I think it is ok to log all that time on the popover task instead of dividing it on all the tasks that were updated, but i would recommend that the popover issue get's a task about "updating all components" to use the popover compponent and log that long time chunk there.

The other task would then be just designing it which would use little task.

---

It made me think if it is worth doing that update because it took so much more time than actually designing it.
I concluded it is worth it and we should continuously look for ways to reduce overhead for the updating process, but it is necessary.

The difference in output is:

1. a lot of designs that exist next to each other and it is hard for anyone or even ourselves when we come back to it at a later point in time to make sense of it
2. vs. leaving the entire project and stop working on it for 3-6 months and then coming back to it and know exactly how things are related and where we stopped working.

There is TWM1 and TWM2 where it wasn't as thouroughly organized and a lot of work is lost, or was now re-done or duplicated by you, exactly because it was almost impossible to pick things up where they were left, because things were messy, so this extra time went into designing the overall architecture and how things relate and that is important too - it is part of the task of designing something that should be part of a "bigger picture".

[Mehrabbruno]

Worklog

Worklog - 79 [2022 Oct 22]

---

Tasks

• Split - popoverContainer_0.0.1
  • Discussion on the structuring of popOverComponents and how the task and time should be logs - 25min

---

Proposal Task

• Split header into a separate component
• Split footer into a separate component

---

Feedback

I think it is ok to log all that time on the popover task instead of dividing it on all the tasks that were updated, but i would recommend that the popover issue get's a task about "updating all components" to use the popover compponent and log that long time chunk there.

Since the changes are already made, do I still go ahead and create the task "updating all components" now?

Above I wrote the proposal task for splitting the header and footer but I'm a little confused about structuring the contents in the popOverContainer as we discussed yesterday over the call. If you could explain it here I will keep that in a log too. Just to be sure we are on the same page and I don't make any mistak

[serapath]

feedback 2022.11.05

1. 👍 yes do it (updating components in that way) with/after the next updates you make.
   • meaning logging time and doing it in only one issue - keep it easy.
2. please add done labels and time logged on the tasks in your worklog above.
3. component structure must never be a component embedding other components.
   • if we ever do that, it must be a very special case and exception
   • the tiling windo manager (TILE Component) might be literally the only component where we probably have to do it (probably even utilizing the <slot> element)
   • otherwise - we never make generic components that embed other components
   • instead - we always make as many specialized components as needed to be composed from more basic ones.

So it would be

1. make some sort of "header title component"
2. make some sort of "footer input component"
3. make many specific content components (e.g. file explorer, list, etc...)
4. make many popover components by requiring as a dependency in each:
   • the header title component and pass some params
   • the footer input component and pass some params
   • the specific content component (e.g. file explorer) and pass some params
   • ==> that will compose from these a specific popover component
     • which will be independent (=not related) to any other popover component.
     • means: it can be independently changed without caring about other popover components