zastrowm / friendly-engine Goto Github PK

See https://github.com/jamiebuilds/tinykeys; it seems to have better control over the scope of the shortcuts.

There are specific controls that take more advanced data structures, such as trees or lists, and we need to design how we expect those controls/structures will be edited and rendered in a way that provides flexibility but doesn't include make it overly complex for non-coding users.

Longer term, we should consider whether templates would solve enough use cases (see https://sheetui.com/ for inspiration) or whether we can incorporate a "mini-instance" of the designer for each sub-item.

We started with stencil.js because of the hot-reload and fast development cycle, but some of the choices made conflict with how we'd like to architect the application. Specifically:

• (major) Requiring async methods on elements even when we know that elements should be loaded and available
• (medium) delaying attribute sets until later (looks to be batched updating/re-rendering)
• (minor) making JSX the primary way to render
• (minor) not allowing base class for elements

We think that we could mimic the hot-reloadness and use raw custom elements (maybe with some TS decorators), allowing more control over the framework.

I, as a user, would like to be able to add controls other than buttons, so that the user can provide other types of inputs like numeric values or textual values.

Possible list of controls:

• Textboxes
• Numeric up downs
• Labels
• Drop downs
• Checkboxes

Eventually it would be nice to support:

• Group boxes
• Images
• Radio buttons

Currently, the editor is the only surface available for the controls, but the end result is supposed to be an hostable app that accepts data from an external source. We need to enable this at some point.

We should get this in from the beginning before we get too far; architecturally it'll need to be thought out.

Tasks

• Create Command Layer
• Hook up keyboard shortcuts

We should be able to support the following on all controls that have simple-text:

• Horizontal Alignment
• Vertical Alignment
• Bold/Italics/Underline
• Text Size
• Text Font

At least for development, this will speed up trying things out

We need to determine how we plan on testing the framework & actually write said tests

Open issue meant to document interesting products that have a similar focus or can serve as inspiration

I, as a user, would like multiple controls to be selectable & resizable at once, so that I can more quickly adjust the layout of multiple items at once.

Currently, they're absolutely positioned from the top-left, but the layout system needs to be able to specify the position as relative to whatever size the user specifies.

The canvas area (currently checker boarded) should be selectable and allow its properties (like the background color) should be editable. Ideally the size would also be editable

Currently, all controls have drag handles but ideally we should be better about when we show them

Rather than requiring a fixed layout of all the controls, it'd be better to use a docking framework and allow the user to customize where panes appear.

Status issue to serve as an indicator of the progress of the move to react.js

• Scaffold of application moved over
• Ability to add controls
• Ability to edit/move controls
• Layout save/load/reset
• Undo/Redo
• Property editing
• Script property editor
• Keyboard shortcuts
• Root Panel
• Auto-Layout load/save
• Radio Button for exclusive buttons

We're inconsistent on how default property values should behavior. For instance, BackgroundColorProperty returns '' when no value is set, but may have a default value set by the theme. On the other hand, HorizontalAlignmentProperty returns the computed value by default (center, but is settable via theme) and doesn't really support returning "I'm using the default value"; FontSizeProperty behaves sort of in the same way as HorizontalAlignmentProperty.

We need to determine if we want computed values to be returned by getValue. Perhaps we need both getAppliedValue and getCurrentValue; where the former is explicitly set values, and the latter is the the value, even if it's computed from the current theme.

We should also consider if this is only a problem for "layout" properties, because of theming, or if it's a generalized issue.

General issue to gather thoughts on how the winform behaves.

Snapping to other controls

Multiple at Once

Snapping to sides

No side drag handles when resizing

Text drag alignment

Not showing edit controls until selected (issue #1)

Multi-Select

The subsequently selected have black dots instead of open-white ones:

Resizing multiple controls merely resizes each as if individually

Drag select does not select container-children

Containers cannot be moved like non-containers

They have to use the drag handle:

Non Actives can be moved on mouse-down

But not resized - containers don't support mouse-down drag:

Moving Z-Order (edit handles are on top)

Selection Z-Order

Deleting a control switches focus to the top-most element

After the switch away from stencil.js (see #5), we lost a couple nice benefits like hot reload, TS decorators. This issue serves as the milestone tracker for getting back the niceties that we lost.

• Allow using JSX for defining elements (#7)
• Implement hot-reload of elements (#13)
• Add TS decorators to simplify custom elements (related to #10)

I, as a user, would like to be able to change the properties of controls so that I can customize controls to fit my needs.

We should be able to adjust things like:

• the text of the control
• the color of the control
• how the control is aligned (e.g. from the left, from the right)

Eventually these are things that would be nice to have as well:

• The ability to specify what happens when I click a button
• The ability to set the color/style of controls
• The ability to change what the controls are bound to
  • e.g. dynamic updates

Current Plan

• A property descriptor provides a list of properties for a specific type of control
• The property panel is simply a list of names to editable controls; all of the properties that are editable for the currently active control
• Each property provides the control that can edit it - this control is what's shown in the property panel
  • This allows the property panel to remain agnostic of how the properties are implemented
  • Eventually, we should expose more rich controls; for example, for text-alignment and other text related properties, instead of the grid of controls, we could expose more of the traditional buttons/rich-text controls like a button for bolding/italicizing/alignment. This is more of an eventual stretch goal than required for MVP
• Some controls need to have the concept of a "debounce"; we shouldn't always be updating all of the properties instantly - we need to take into account if the properties are being sent across the network.
  • this may be more of a concern for runtime-editing than design-time

Binding

Eventually we'll need a plan for binding. At the moment we could envision two types of binding:

1. Each property independently boundable
   • Ideal for when you have the concept of "variables" or "expression" for computing something
   • Also ideal for one-of bindings
2. A binding "context" where multiple properties are bound at runtime, depending on what's provided
   • Ideal for when something else can specify multiple properties (e.g. a spreadsheet cell) that can be adjusted at runtime. It would be a PITA to do (1) for each property that you want to bind, but perhaps if we provide a convenient way to start the properties bound, it would be acceptable.

We will probably implement (1) initially and potentially implement (2) as an app-specific thing. The important thing about (2) is that we expose a way to indicate the properties are overridden/sourced from elsewhere.

JSX is much more concise than using document.createElement directly; it'd be nice to be able to start using it again to define elements, even if it's only for a single element.

As mentioned in #19 and via comment on #9, we need to support additional layout containers for cases where users don't want to use absolute positioning.

We need to consider the use cases and how different frameworks solve them.

Some general containers known to other UI technologies:

• StackPanel (WPF) - for straight lists of items
• Grid (WPF) - for more dynamic layouts where each row or column can be independently resized and the items are laid out in cells; similar to TableLayoutPanel in WinForms (which provides a better designer IMHO)
• WrapPanel (WPF) - lists of items that wrap onto the next row; similar to flexbox in CSS

Came across this when implementing #20

Steps to Reproduce

1. Select the root element
2. Focus a property editor - for example, change the background color
3. Click the root element (e.g. the canvas)
4. Notice that document.activeElement points to the document.body resulting in keyboard shortcuts no longer working

As denoted by #6 (and #5) we need to implement hot-reload functionality.

This issue shall serve as a tracker and as a place for research to be placed.

Research

The prototype branch (specifically 4c7256c) contains some code related to HMR.

HMR Api

The webpack HMR Api documentation is @ https://webpack.js.org/api/hot-module-replacement/

In 4c7256c I determined that we can have custom elements auto-reload, but it does look like parent modules also are required to accept the updates - I looked into this via Aborted because parent is not accepted and couldn't find a way around it.

Plan

Current plan of approach:

• typescript decorator to insert module.hot.accept into custom element files
• replace the custom-elements functions with the new ones (if needed - maybe with a string-compare?)
• remove and re-insert the affected custom elements

Seems like an easy item to add; right now you can't simply copy an existing control to make a copy of it.

User feedback along the lines of "I didn't know I could add multiple components because it's blank by default".

For newly added controls, we should include default text

Certain controls could benefit from an auto-height or auto-width. Specifically with the label control, you change the text then need to change the size right after to match.

For #6, it would be ideal if we had typescript decorators/transformers to cut down on some of the boilerplate for custom elements.

This issue serves as a placeholder for the research/links about transformers.