oil-lang / oil-rs Goto Github PK

http://oil-lang.github.io redirects to a 404 page. It's regrettable, as it's the project's homepage on crates.io.

Add the following functions to DataBinderContext

• get_iter
• register_iter

Implement the Frame logic to render:

• Simple text (look up -> compute new size -> update associated LayoutBox)
• <repeat> tag

Add a wrapping rule at the style level defining the focus behaviour for the following situation:

• focus_left is called but there's nothing on the left
  • if wrapping is none, the focus does not change
  • if wrapping is loop, the focus goes to the rightmost node

Store node states in a separate buffer.

Add support for font and text rendering.

With PR #12 focus is now using a cursor strategy to find the choose the next node when changing the focus. It works well on the shop_inventory example.
However, we can still build example that might be counter intuitive when switching the focus, consider the following case:

+------+   +------+
|  A   |   |  B   |
+------+   +------+
           +------+
           |  C   |
           +------+
+------+
|  D   |
+------+

Assuming you start at D with the cursor centered on D, if you do a focus_up, you'll end up on C. And if you do again focus_up, you'll end up on A.

Replace all println!("WARNING ...) by appropriate log call.

This will be required to implement the overlap style property.
It requires a bit of work because the resulting RenderBuffer is a collection of small trees which do not map to any sub tree from the original tree (in the general case).

As suggested during the conversion on #15, we should start sketching the interface for Actions.
The first approach should offer:

• A way to register an action handler that will be called when the associated action is emitted by any ui element from the ui. It will receive as parameters:
  • the name of the action
  • the original user event
  • the value of the data binding or None if no argument was provided to the action.

This first approach is quite simple but should help seeing the impact on the rest of the code and would also be a base for further discussion to design the action architecture.

Hi there,

I am no expert here, but I think it might be useful to add a layer behind the UI one, where it is possible to draw things (basically, the game). A good behavior should be that UI catches keystrokes first, then if it can do nothing with it, gives it back to this layer.

Thus, in “HUD UI”, arrows are transfered. But when Escap is hit, it switches to menu and arrows are catches. That way, character is not longer moving.

Is something like that already existing in OIL?

I want to write a PoC client and I need something like that!