limikael / appy Goto Github PK

Currently, apx! macro:

<hello prop1="val"/>

Is syntactic sugar for:

Element::create(hello,Props_hello{prop1: "val"})

This more or less forces the use of the macro, because the code without the macro looks very ugly. As an alternative, instead of having elements just be functions that take props, they can actually be part of the struct. The way to define an element would then be slightly different. Instead of:

struct MyElement {
    pub prop1: String    
} 

#[function_component]
fn my_element(p:MyElement, c:Elements)->Elements {
}

... it would be ...

#[component]
struct MyElement {
    pub prop1: String    
}

impl Component for MyElement {
    fn render(p:Self) {
    }
}

Then, the #[component] macro could actually create a builder. Also it would add the children prop to the struct. (for this reason it cannot be a derive macro, since derive macros cannot modify the struct or add to it). It would now be possible to write:

MyElement::new().prop1("hello")

And if it takes children:

MyElement::new().prop1("hello").children(/*...*/)

And then the XML would just be syntactic sugar for the above.

Advantages:

• It is possible to create components without XML.
• The documentation will look a bit better, since now the props struct and function ends up being documented as separate things.

Disadvantages:

• The components are still function components. They are not instances, state information is still managed with use_state, etc. However, if the render function is part of a struct, it kind of makes them look like React class components, even though they are not. This might be confusing.

Something like use_spring, inspired by https://www.react-spring.dev/

On a deeper level, it isn't currently possible to get the screen to refresh, or invoke functions to run on a timer, so this needs to be added first.

it should be possible to do:

<mycomp key="blabla"/>

What should be the datatype for keys?

currently the instances leak...

The rect drawer should support:

• rounded corners
• borders
• gradients

Hi, thanks for your hard work on appy/glapp/apk-sdl, those crates saves me a lot of time, with "how to run sdl on android and stay sane" problem

Do you have any thoughts on "How to implements Glium API with SDL2?"

I checked Glium source, and it's look like I need to implement custom backed and create my own context with it

Scale factor should be taken into account. How?

I have read that glutin supports getting the device scale factor, but not SDL... can't find the resource now...

it was a noob thingy...

The appy binary, which is currently written in src/cl/bin.rs, should be its own separate crate.

That way, the dependencies of the library and those of the binary can be completely separated out, so if someone uses the Appy library in their project, they'll only need to compile these dependencies.

where should they be gotten from? bundle images with exe?

Support miniquad, https://crates.io/crates/miniquad for rendering context management.

i try to run the hello example and the compiler can't find the glapp dependency path

❯ cargo r --example hello
error: failed to get `glapp` as a dependency of package `appy v0.1.6 (/home/cargo/Repo/appy)`

Caused by:
  failed to load source for dependency `glapp`

Caused by:
  Unable to update /home/cargo/Repo/glapp

Caused by:
  failed to read `/home/cargo/Repo/glapp/Cargo.toml`

Caused by:
  No such file or directory (os error 2)

The vision is to have a use_font hook. so it would be like:

#[function_component]
fn my_comp(p: MyProps, c:Elements)->Elements {
  let f=use_font(FontSpec::new("thefont").size(10).charset(Charset::Ascii));
  f.get_line_width("blabla") // the with of a line of text
  f.get_paragraph_height("blasdf\nasdfasf",100) // the height of a paragraph, if fit into a width of 100

  apx!{
    <text text="hello" font=f/>
  }
}

currently there is a gpu cache thingy, but it doesn't work well at all. look at:

• https://crates.io/crates/glyph_brush/
• https://docs.rs/glium_text/latest/glium_text/