makepad/makepad

Makepad is a creative software development platform for Rust that compiles to wasm/webGL, osx/metal, windows/dx11 linux/opengl

makepad's Issues

Newsletter subscription seems broken

👋 Hi friends! 😄

I tried to use the newsletter subscription button on "Edit" tab, but it seems to cause a 500 error:

Keep up the good work, seems like a very interesting project! 😊

UI toolkit - again

First of all, very good job guys, keep it going.

I am slowly, but surely prepping for next project and then - in the meantime - another one, and another one are in plans...
Technologically nothing fancy, just another business idea realized with technology in mind.
I was planning initially to go FE react, BE dotnet.

As I already did some experiments in Rust, I know where Rust becomes a bit of a hassle and feel that our use cases are easy enough to move forward with Rust for BE.
Story of actix-web and diesel are good enough, so we (all of us) could use Rust as backend for the most-of-the-web - I believe.

What people currently want - me included - is good frontend framework in Rust.
I did some research on this, wasm story for now is that webgl way could be the fastest but is also the hardest (capt. obv). Another approach is to go with dual engines (async DOM over some abstract layer to mitigate performance issues of wasm to DOM calls). The second approach is easier and would allow us to use some of existing tools and frameworks. Yew went that route, but made some fundamental errors in design along the way and now they try to dig their way out of a small? hole before 1.0.0.

You guys are currently frontrunners of webgl UI story, that is just a fact. If I currently were to invest fully into bleeding edge, you guys, would be the target.

I understand that problematic part of having a technology that is not a 'product' itself and how it leads to true problem - money for development of technology and no effective strategy to scale-up from just technology. I understand your focus points.

On the other hand... if you were to "release" some UI baseline - foundation of sorts - upon which we could build our own UI toolkit/s... there is a value in it for you as well. Even with your 'makepad' project, you could use community created widgets for your development. Something as technologically basic as data grid is a lot of development work, and the list goes on: date time pickers, forms, toasts, combo-boxes, menus, data-binding systems, styling, automation and so on...
I think the project is at this place - this approach is possible and we all could build upon your work if proper Cornerstones were placed.

PS. Obviously it is nicer to have eveything in single package like Material UI, but "we" as Rust frontend developers are more on the stage of "JQuery first time going mainstream". I think history proved it is a "natural" way of improving these technologies. Aaand having competition around it in UI widgets -> toolkits field proved useful in general.

Content offset when page is zoomed (Safari)

If I zoom the page using the trackpad on Safari, makepad ends up correctly sized for the zoom level, but it is offset from the actual browser window:

Does not occur on Chrome or Firefox (trackpad pinch doesn't zoom the page on either). Does not occur when zooming with ⌘+ keyboard shortcut in any browser.

Linux install is kinda broken

Linux != Ubuntu / Debia
Not all linux distros use apt package manager, thus, you shouldnt use apt in the linux_rustup.sh,
just add libxcursor-dev libx11-dev libgl1-mesa-dev under dependencies and let the users install them, or make a check, but as mentioned, there are a lot of package managers... soo a lot of cases.

bare_example doesn't compile to wasm

This is because of the profile_start call, which uses Instant::now(), which triggers this panic in wasm.

We could just remove the profiling call from the example. But long term we'd probably want some way to get the time for various purposes. (Though it might be too slow to make a call to JS to get the time for profiling purposes? I didn't test that, so not sure; y'all might have a better sense of the overhead involved there.)

Three crates for each application is unnecessary

Currently there are 3 versions of each app:

• The one that gets run with cargo run
• The one that gets compiled with cargo build --target=wasm32-unknown-unknown
• The app itself

Rik explained that this is done because wasm needs crate-type = ["cdylib"], which is currently not dynamically configurable.

However, wasm doesn't really need to be a cdylib. If you don't set that you just get a tiny extra start function, which we can just ignore. This adds a few kb at most, or less than 0.1% in both release and debug builds (in my testing) — I'm not even sure why it's that much instead of a few bytes.. Anyway, if you really care about that amount, it can easily be stripped after the fact (e.g using wasm-snip).

I think this is worth it for simplifying the crate structure for newcomers. We can then just have one top-level main_app macro:

#[macro_export]
macro_rules!main_app {
    ( $ app: ident) => {
        #[cfg(not(target_arch = "wasm32"))]
        fn main(){
            //TODO do this with a macro to generate both entrypoints for App and Cx
            let mut cx = Cx::default();
            cx.style();
            $ app::style(&mut cx);
            cx.init_live_styles();
            let mut app = $ app::new(&mut cx);
            let mut cxafterdraw = CxAfterDraw::new(&mut cx);
            cx.event_loop( | cx, mut event | {
                if let Event::Draw = event {
                    app.draw_app(cx);
                    cxafterdraw.after_draw(cx);
                    return
                }
                app.handle_app(cx, &mut event);
            });
        }

        #[cfg(target_arch = "wasm32")]
        fn main() {}

        #[cfg(target_arch = "wasm32")]
        #[export_name = "create_wasm_app"]
        pub extern "C" fn create_wasm_app() -> u32 {
            std::panic::set_hook(Box::new(|info: &std::panic::PanicInfo| {
                log!("Panic: {}", info.to_string());
            }));
            let mut cx = Box::new(Cx::default());
            cx.style();
            $ app::style(&mut cx);
            cx.init_live_styles();
            let app = Box::new( $ app::new(&mut cx));
            let cxafterdraw = Box::new(CxAfterDraw::new(&mut cx));
            Box::into_raw(Box::new((Box::into_raw(app), Box::into_raw(cx), Box::into_raw(cxafterdraw)))) as u32
        }

        #[cfg(target_arch = "wasm32")]
        #[export_name = "process_to_wasm"]
        pub unsafe extern "C" fn process_to_wasm(appcx: u32, msg_bytes: u32) -> u32 {
            let appcx = &*(appcx as *mut (*mut $ app, *mut Cx, *mut CxAfterDraw));
            (*appcx.1).process_to_wasm(msg_bytes, | cx, mut event | {
                if let Event::Draw = event {
                    (*appcx.0).draw_app(cx);
                    (*appcx.2).after_draw(cx);
                    return;
                };
                (*appcx.0).handle_app(cx, &mut event);
            })
        }
    }
}

2D Drawing API

Hello I've been playing around with the makepad rendering lib and was going to take a stab at a small 2d drawing api (along the lines of canvas) for something I want to try with the lib.

What would be the 'best' way to accomplish draw implementations for the render::vector lib currently the only GL primitive I see in use are Quads.

I'm still new to GL terms/methods so please excuse my ignorance, but would it best to continue to use quads as the primitive for that or implement another primitive like a GL_LINE_STRIP for the compiler.

If you dont mind steering me in the right direction I would appreciate it. Appreciate the great project

mace segfaults on post_signal

Heya, following this project with a lot of enthusiasm, very eager to see first releases of your pivot to the UI designer 😃 .

I tried running mace on an M1 Macbook Air (under MacOS) but it segfaults consistently for me, I can trace it back to cx_cocoa and the post_signal calls within mace app.rs, it seems they are 'faster' calling post_signal within their thread::spawn than the CocoaApp::init can run, so it has a zero pointer in CxCocoa post_signal fn. (when i add a couple of millis sleep before those mace app.rs post_signal calls then everything works fine.)

I don't mind trying to write a PR for it but I'm not sure about the solution direction in this case. Should the post_signals calls be buffered before the init? or just drop them when the global CxCocoaApp init() is not called yet?

Are you peeps on a public channel/discord e.g. somewhere to ask/discuss these? (i'm also fine to do it here)

ps. saw Rik last time presenting makepad at the technolution gouda rust meetup, another meetup previewing the 'new' makepad anytime soon? :-)

long files fail to display

i.e. https://github.com/makepad/makepad/blob/master/render/bind/x11-sys/src/bindings.rs
fails to even show text:

Error writing file ./edit_repo/makepad_state.json

MacOS 10.14, after running ./run_first_init.sh, and then cargo run.

I see Makepad running! It prompts me to hit F9. When I do, I get the error writing file and a blank other makepad (If i try to type anything in the new window it crashes/closes).

Is this suppose to happen? or what is? Thanks, this is awesome!

$ ls -lha edit_repo/makepad_state.json
-rw-r--r--  1 marco  staff   1.0K Aug  9 16:13 edit_repo/makepad_state.json

makepad_state.json:

{"windows":[{"window_position":{"x":804.0,"y":384.0},"window_inner_size":{"x":865.0,"y":1135.0},"dock_items":{"Splitter":{"align":"First","pos":150.0,"axis":"Vertical","first":{"TabControl":{"current":0,"tabs":[{"closeable":false,"title":"Files","item":"FileTree"}]}},"last":{"Splitter":{"align":"Last","pos":150.0,"axis":"Horizontal","first":{"TabControl":{"current":4,"tabs":[{"closeable":false,"title":"Edit","item":"FileEditorTarget"},{"closeable":true,"title":"main.rs","item":{"FileEditor":{"path":"examples/quad/src/main.rs","editor_id":1}}},{"closeable":true,"title":"cx_cocoa.rs","item":{"FileEditor":{"path":"render/src/cx_cocoa.rs","editor_id":2}}},{"closeable":true,"title":"cx_fonts.rs","item":{"FileEditor":{"path":"render/src/cx_fonts.rs","editor_id":3}}},{"closeable":true,"title":"cx_opengl.rs","item":{"FileEditor":{"path":"render/src/cx_opengl.rs","editor_id":4}}}]}},"last":{"TabControl":{"current":0,"tabs":[{"closeable":false,"title":"Rust Compiler","item":"RustCompiler"},{"closeable":false,"title":"Keyboard","item":"Keyboard"}]}}}}}}}]}

UI Toolkit crate

Hello,

I just discovered this project through : https://makepad.github.io/makepad/ and it's wonderfully fast. The description in the readme is interesting and I would like to know if there are plans to create a distinct UI toolkit crate/library that could be used as alternative to spinning up a React/Node server for frontends to rust applications.

Best!

contensizing

In README.md

contensizing

content sizing?

Incorrect text colors

Expected behavior

The colors shown on screen should match the defined hex values.

Actual behavior

Output colors deviate from the defined ones.

I set the font size to a fairly high value to ensure that this is not caused by antialiasing.

Color-values resulting from different color picking methods

• #5b9bd3 Defined and intended value (live_editor.rs, line 63)
• #74a8e3 Photoshop Screenshot Color-Picking. The file was opened with the color profile that was embedded in the MacOS screenshot. So Photoshop should not have altered anything.
• #74a8e3, 116/168/227 MacOS Metering tool, color picking the live application, native mode
• #74a8e3, 116/168/227 MacOS Metering tool, color picking the live application, P3
• #63AAE8, 99/170/232 MacOS Metering tool, color picking the live application, sRGB
• #5398E2, 83/152/226, MacOS Metering tool, color picking the live application, Generic RGB
• #7CA8E5, 124/168/229, MacOS Metering tool, color picking the live application, Adobe RGB

Steps to reproduce

• Assign syntax-highlighting color
• Color pick screenshot with Photoshop or use MacOS' live color metering tool "Digital Color Meter".

Panic after a deluge of "FILE READ FAILED!"

I think this happens when the worlds directory is missing? Is it a demo, or a necessary part of the app?

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', render/src/text.rs:411:96
stack backtrace:
   0:     0x562c81de7b80 - <unknown>
   1:     0x562c81e0e1bc - <unknown>
   2:     0x562c81de3437 - <unknown>
   3:     0x562c81de9fb0 - <unknown>
   4:     0x562c81de9cfc - <unknown>
   5:     0x562c81dea613 - <unknown>
   6:     0x562c81dea1e9 - <unknown>
   7:     0x562c81de800c - <unknown>
   8:     0x562c81dea1a9 - <unknown>
   9:     0x562c81e0bd81 - <unknown>
  10:     0x562c81e0bccd - <unknown>
  11:     0x562c81cbd3b2 - <unknown>
  12:     0x562c81c7cd96 - <unknown>
  13:     0x562c81b75f60 - <unknown>
  14:     0x562c81bd4fce - <unknown>
  15:     0x562c81bdfe2e - <unknown>
  16:     0x562c81b5df58 - <unknown>
  17:     0x562c81cd4e8d - <unknown>
  18:     0x562c81cf1600 - <unknown>
  19:     0x562c81cf0739 - <unknown>
  20:     0x562c81cec89e - <unknown>
  21:     0x562c81cdb17b - <unknown>
  22:     0x562c81b39ca7 - <unknown>
  23:     0x562c81b336f3 - <unknown>
  24:     0x562c81b33709 - <unknown>
  25:     0x562c81deaa11 - <unknown>
  26:     0x562c81b39dc2 - <unknown>
  27:     0x7f055b286152 - __libc_start_main
  28:     0x562c81b2f09e - <unknown>
  29:                0x0 - <unknown>

Master currently fails to compile on Linux

Debian latest, rustc nightly 2022-07-04. Trying to compile just the makepadworkspace onmaster` fails with many errors in render code. Other public branches and other workspaces also seem to fail or warn for various reasons. Here is a representative error:

error: reference to packed field is unaligned
  --> render/src/drawquad.rs:20:21
   |
20 |             shader: self.shader.clone(),
   |                     ^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[deny(unaligned_references)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #82523 <https://github.com/rust-lang/rust/issues/82523>
   = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
   = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)

While there's a lot of these, they look reasonably easy to fix. Would it be useful for me to do this and PR the result, along with cleaning up a bunch of other warnings? Or am I looking at an old version of the product or something?

Thanks much for any info you can provide.

(P.S. — As the architect of XCB, not sure why you're using Xlib here 🙂 . Just kidding though: by all means use whichever you like.)

<textarea> absorbs click nearby

The Web version seem to use a textarea to receive input. However, it does handle clicks and clicking anywhere near the cursor will not work.

Tested that this issue exists in both Edge Dev (Blink) and Firefox.

Q&A

Hi, this project is very interesting. I've managed to build and run the app for the Mac desktop as well as webassembly. Then I ran into your recent youtube demo which showed the IDE running inside a 3D virtual environment and was blown away. I haven't seen any code or documentation for this so thought I'd ask here. How can I set up such an environment (I understand that it is just a demo)? I know very little about WebVR/WebXR at this point so a set of steps will be very appreciated.

Opening .ttf files crashes in studio

• Open makepad_studio (on an m1 mac) cargo +nightly-2022-07-09 run -p makepad_studio --release
• Navigate to /resources/, open any .ttf file

thread 'main' panicked at 'index out of bounds: the len is 64258 but the index is 65533', platform/src/draw_2d/draw_text.rs:254:28

Compilation Error - OSX - No matching Function call to 'clamp'/'mix'

When:

commit 8caeb0706d18edb9fab99bf6805e167d593b0896 (HEAD -> master, origin/master, origin/HEAD)
Date:   Tue Nov 17 07:57:43 2020 +0100

What:

Getting an Error during a fresh clone (master) and release compilation on a OSX (Mojave 10.14.6):

$ Compilation failed: 

program_source:70:22: error: no matching function for call to 'clamp'
    float2 clipped = clamp((((mpsc_geometries.geom * float2(mpsc_instances.w, mpsc_instances.h)) + float2(mpsc_instances.x, mpsc_instances.y)) - scr), mpsc_draw_uniforms.draw_clip.xy, mpsc_draw_uniforms.draw_clip.zw);
                     ^~~~~
/System/Library/PrivateFrameworks/GPUCompiler.framework/Versions/3902/Libraries/lib/clang/902.3/include/metal/metal_integer_common:52:15: note: candidate template ignored: requirement '_clamp_enable<float __attribute__((packed_vector_type(2))), float __attribute__((ext_vector_type(2))), float __attribute__((ext_vector_type(2)))>::value' was not satisfied [with T = float __attribute__((packed_vector_type(2))), U = float __attribute__((ext_vector_type(2))), V = float __attribute__((ext_vector_type(2)))]
METAL_FUNC _O clamp(T x, U minval, V maxval)
              ^

thread 'main' panicked at 'Compilation failed: 

program_source:70:22: error: no matching function for call to 'clamp'
    float2 clipped = clamp((((mpsc_geometries.geom * float2(mpsc_instances.w, mpsc_instances.h)) + float2(mpsc_instances.x, mpsc_instances.y)) - scr), mpsc_draw_uniforms.draw_clip.xy, mpsc_draw_uniforms.draw_clip.zw);
                     ^~~~~
/System/Library/PrivateFrameworks/GPUCompiler.framework/Versions/3902/Libraries/lib/clang/902.3/include/metal/metal_integer_common:52:15: note: candidate template ignored: requirement '_clamp_enable<float __attribute__((packed_vector_type(2))), float __attribute__((ext_vector_type(2))), float __attribute__((ext_vector_type(2)))>::value' was not satisfied [with T = float __attribute__((packed_vector_type(2))), U = float __attribute__((ext_vector_type(2))), V = float __attribute__((ext_vector_type(2)))]
METAL_FUNC _O clamp(T x, U minval, V maxval)
              ^
', render/src/cx_metal.rs:878:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Unconventional arrow-key behavior in selections when not holding shift

By convention, pressing the left/right arrow key when there is an active text selection should collapse the selection and move the caret to the side of the selection range in the direction of the pressed arrow. I've observed this across macOS input controls, including code editors, and in IMGUI. I haven't had a chance to try on Windows/Linux systems, but I expect the behavior there will be the same.

In makepad, pressing the left/right arrow key currently collapses the selection but additionally moves the caret based on the position of the head of the selection (h):

1) Given:
so|me te|xt
  h     t

-> Left Arrow ->

Result:
s|ome text
 h
 t

2) Given:
so|me te|xt
  h     t

-> Right Arrow ->

Result:
som|e text
   h
   t

Compare to the following expected behavior:

1) Given:
so|me te|xt
  h     t

-> Left Arrow ->

Result:
so|me text
  h
  t

2) Given:
so|me te|xt
  h     t

-> Right Arrow ->

Result:
some te|xt
       h
       t

This is a minor defect that should be trivial to fix (probably just tweaks to move_left and move_right in textcursor.rs), but it is super annoying when selecting text in a code editor doesn't work "properly."

On a related note, I wonder if anyone has documented text editing conventions/differences between editors/OSes and which text editor first introduced the conventions of arrow key + shift + other modifier behavior. I've spent some time looking online but haven't found anything.

Compilation error building shader_ast_impl

Running ./build_release.sh with rustc 1.36.0 (a53f9df32 2019-07-03)

   Compiling shader_ast_impl v0.1.0 (/home/martin/code/rust/makepad/render/shader_ast/shader_ast_impl)
error[E0609]: no field `pats` on type `syn::stmt::Local`
  --> render/shader_ast/shader_ast_impl/src/lib.rs:47:36
   |
47 |     if let Pat::Ident(pat) = &stmt.pats[0]{
   |                                    ^^^^ help: a field with a similar name exists: `pat`

error[E0609]: no field `ty` on type `syn::stmt::Local`
  --> render/shader_ast/shader_ast_impl/src/lib.rs:51:40
   |
51 |         if let Some((_tok, ty)) = stmt.ty.clone(){
   |                                        ^^ unknown field
   |
   = note: available fields are: `attrs`, `let_token`, `pat`, `init`, `semi_token`

error[E0609]: no field `ident` on type `syn::item::ItemFn`
   --> render/shader_ast/shader_ast_impl/src/lib.rs:108:21
    |
108 |     let name = item.ident.to_string();
    |                     ^^^^^ unknown field
    |
    = note: available fields are: `attrs`, `vis`, `sig`, `block`

error[E0609]: no field `decl` on type `syn::item::ItemFn`
   --> render/shader_ast/shader_ast_impl/src/lib.rs:111:22
    |
111 |     for arg in &item.decl.inputs{
    |                      ^^^^ unknown field
    |
    = note: available fields are: `attrs`, `vis`, `sig`, `block`

error[E0599]: no variant or associated item named `Captured` found for type `syn::item::FnArg` in the current scope
   --> render/shader_ast/shader_ast_impl/src/lib.rs:112:23
    |
112 |         if let FnArg::Captured(arg) = arg{
    |                       ^^^^^^^^ variant or associated item not found in `syn::item::FnArg`

error[E0609]: no field `decl` on type `syn::item::ItemFn`
   --> render/shader_ast/shader_ast_impl/src/lib.rs:140:43
    |
140 |     if let ReturnType::Type(_, ty) = item.decl.output{
    |                                           ^^^^ unknown field
    |
    = note: available fields are: `attrs`, `vis`, `sig`, `block`

error[E0609]: no field `pats` on type `syn::stmt::Local`
   --> render/shader_ast/shader_ast_impl/src/lib.rs:170:37
    |
170 |     if let Pat::Ident(pat) = &local.pats[0]{
    |                                     ^^^^ help: a field with a similar name exists: `pat`

error[E0609]: no field `ty` on type `syn::stmt::Local`
   --> render/shader_ast/shader_ast_impl/src/lib.rs:173:41
    |
173 |         if let Some((_tok, ty)) = local.ty.clone(){
    |                                         ^^ unknown field
    |
    = note: available fields are: `attrs`, `let_token`, `pat`, `init`, `semi_token`

error[E0599]: no method named `value` found for type `syn::lit::LitInt` in the current scope
   --> render/shader_ast/shader_ast_impl/src/lib.rs:326:37
    |
326 |                     let value = lit.value() as i64;
    |                                     ^^^^^

error[E0599]: no method named `value` found for type `syn::lit::LitFloat` in the current scope
   --> render/shader_ast/shader_ast_impl/src/lib.rs:330:37
    |
330 |                     let value = lit.value() as f64;
    |                                     ^^^^^

error[E0614]: type `syn::pat::Pat` cannot be dereferenced
   --> render/shader_ast/shader_ast_impl/src/lib.rs:380:38
    |
380 |             if let Pat::Ident(pat) = *expr.pat{
    |                                      ^^^^^^^^^

error: aborting due to 11 previous errors

Some errors have detailed explanations: E0599, E0609, E0614.
For more information about an error, try `rustc --explain E0599`.
error: Could not compile `shader_ast_impl`.
warning: build failed, waiting for other jobs to finish...
error: build failed

X11 segfault on XrmGetStringDatabase

Segfault caught on X11_sys::XrmGetStringDatabase(resource_string);

in render/src/cx_xlib.rs:

pub fn get_dpi_factor(&self) -> f32 {
unsafe {
    //return 2.0;
    let display = (*self.xlib_app).display;
    let resource_string = X11_sys::XResourceManagerString(display);
    let db = X11_sys::XrmGetStringDatabase(resource_string);

full backtrace

#0  0x00007ffff7d8d6f5 in __strlen_avx2 () from /usr/lib/libc.so.6
#1  0x00007ffff7ebdb1a in ?? () from /usr/lib/libX11.so.6
#2  0x00007ffff7ebef5d in XrmGetStringDatabase () from /usr/lib/libX11.so.6
#3  0x0000555555dc4cbe in render::cx_xlib::XlibWindow::get_dpi_factor (self=0x7fffffff1d10) at render/src/cx_xlib.rs:1398
#4  0x0000555555dc2dd3 in render::cx_xlib::XlibWindow::init (self=0x7fffffff1d10, _title=..., size=..., position=..., visual_info=...) at render/src/cx_xlib.rs:1058
#5  0x0000555555c78070 in render::cx_opengl::OpenglWindow::new (window_id=0, opengl_cx=0x7fffffff5050, xlib_app=0x7fffffff4e60, inner_size=..., position=..., title=...) at render/src/cx_opengl.rs:963
#6  0x000055555572e9fb in render::cx_linux::<impl render::cx::Cx>::event_loop::{{closure}} (xlib_app=0x7fffffff4e60, events=0x7fffffff4b58) at /home/toad/repos/external/makepad/render/src/cx_linux.rs:81
#7  0x0000555555dc0ff2 in render::cx_xlib::XlibApp::do_callback (self=0x7fffffff4e60, events=0x7fffffff4b58) at render/src/cx_xlib.rs:699
#8  0x0000555555691871 in render::cx_xlib::XlibApp::event_loop (self=0x7fffffff4e60, event_handler=...) at /home/toad/repos/external/makepad/render/src/cx_xlib.rs:683
#9  0x000055555561528f in render::cx_linux::<impl render::cx::Cx>::event_loop (self=0x7fffffff51b8, event_handler=...) at /home/toad/repos/external/makepad/render/src/cx_linux.rs:28
#10 0x000055555573d94b in makepad::main () at <::render::cx::main_app macros>:7

poking around I found resource_string to be null, which, according to XResourceManagerString, "If no property exists, NULL is returned."

I'm on Archlinux 5.4.2 , very possible I'm missing dependencies ? I have libxcursor and libx11 installed.

I can't open https://127.0.0.1:8080/makepad/examples/ironfish/src/index.html

liangfangzheng@liangfzmac makepad % cargo run -p makepad-web-server --release
Finished release [optimized] target(s) in 0.03s
Running target/release/makepad-web-server
Server listening on 127.0.0.1:8080

but i can't open https://127.0.0.1:8080/makepad/examples/ironfish/src/index.html

Feature request: move the Rendering/widget crates into separate project

There isn't much gui libs around for rust and the widgets used here looks nice so I would be cool if they could be separated into a standalone crate(s)

can't build on macOS

I'm doing cargo run -p makepad --release and I get:

error: no matching package named `makepad-render` found
location searched: https://github.com/makepad/makepad.git?branch=dev
required by package `makepad-code-editor v0.1.0 (/Users/holliday/makepad/codeeditor)`

macOS 12.2 (21D49), rustc 1.58.1 (db9d1b20b 2022-01-20), cargo 1.58.0 (f01b232bc 2022-01-19)

Native panicked in MacOS

When I run ./watch_native.sh, the window appears in the bottom left corner and barely visible (I'm using two monitors). It crashes every time I try to maximize or to resize the window.

[Running 'cargo build --release && cargo run --release']
    Finished release [optimized] target(s) in 0.36s
    Finished release [optimized] target(s) in 0.10s
     Running `target/release/makepad`
get_uniform_offset blink called on invalid prop
get_instance_offset x called on invalid prop
get_instance_offset y called on invalid prop
get_instance_offset font_geom called on invalid prop
get_instance_offset font_size called on invalid prop
get_instance_offset char_offset called on invalid prop
get_uniform_offset blink called on invalid prop
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /rustc/6c2484dc3c532c052f159264e970278d8b77cdc9/src/libcore/slice/mod.rs:2539:10
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::panicking::panic_bounds_check
   9: editor::rusteditor::RustEditor::draw_rust_editor
  10: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
  11: render::cx::Cx::call_event_handler
  12: render::cx::Cx::call_draw_event
  13: render::cx_mtl::<impl render::cx::Cx>::event_loop
  14: makepad::main
  15: std::rt::lang_start::{{closure}}
  16: std::panicking::try::do_call
  17: __rust_maybe_catch_panic
  18: std::rt::lang_start_internal
  19: main
[Finished running. Exit status: 101]

It does that with either rust stable or nightly. ./server_webgl.sh works.

Keep up the good work I'm so impressed by this project 👍

Missing dependency on Ubuntu Focal (20.04)

An additional dependency is required to build makepad on Ubuntu: libgl1-mesa-dev

Before adding this package, the build fails with:

    Compiling makepad v0.1.0 (/home/chris/code/personal/makepad/makepad)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.0.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.1.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.10.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.11.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.12.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.13.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.14.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.15.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.2.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.3.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.4.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.5.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.6.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.7.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.8.rcgu.o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.makepad.23se5hv9-cgu.9.rcgu.o" "-o" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97" "/home/chris/code/personal/makepad/target/release/deps/makepad-e5e4dc6f1844ae97.48ggph01idutb1nf.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs" "-L" "/home/chris/code/personal/makepad/target/release/deps" "-L" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_hub-c48e4b010a4180bb.rlib" "/home/chris/code/personal/makepad/target/release/deps/libbincode-1c4dcc00d2af461b.rlib" "/home/chris/code/personal/makepad/target/release/deps/libsnap-a253bab84f4d813d.rlib" "/home/chris/code/personal/makepad/target/release/deps/liblazy_static-b71cb675849f244c.rlib" "/home/chris/code/personal/makepad/target/release/deps/libbyteorder-4f5cd9e562a79c07.rlib" "/home/chris/code/personal/makepad/target/release/deps/libserde_json-c5f00503ddc6578d.rlib" "/home/chris/code/personal/makepad/target/release/deps/libryu-250abc56353e4f1a.rlib" "/home/chris/code/personal/makepad/target/release/deps/libitoa-8b90c0416aaa1224.rlib" "/home/chris/code/personal/makepad/target/release/deps/libron-801d8ad2397bba33.rlib" "/home/chris/code/personal/makepad/target/release/deps/libbase64-2ed305ffdd3ae9ce.rlib" "/home/chris/code/personal/makepad/target/release/deps/libbyteorder-8dbacdfd1cfce70a.rlib" "/home/chris/code/personal/makepad/target/release/deps/libbitflags-1ce435d9d7344b5e.rlib" "/home/chris/code/personal/makepad/target/release/deps/libtoml-88a9fd4a628935ea.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_widget-c9e34d726da29adf.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_render-1cc10fb076e11da0.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_ttf_parser-1bb1641889f477df.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_font-dd4189dc20ca6e26.rlib" "/home/chris/code/personal/makepad/target/release/deps/libgl-0f17b4ea7b67103a.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_trapezoidator-e69badc99fa151a2.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_path-fccc7333bf7cb84f.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_geometry-09360df031146db2.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_internal_iter-72f87956ab26c7e8.rlib" "/home/chris/code/personal/makepad/target/release/deps/libserde-b76ecad75029ecd3.rlib" "/home/chris/code/personal/makepad/target/release/deps/libtime-6ce88697e34eb71f.rlib" "/home/chris/code/personal/makepad/target/release/deps/liblibc-c1af9ba80fb01a25.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_x11_sys-dd57e8e7f132c6fc.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_glx_sys-e4fb3feabdabfc07.rlib" "/home/chris/code/personal/makepad/target/release/deps/libmakepad_shader_ast-9603e7cbdfc5619c.rlib" "-Wl,--start-group" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-fae576517123aa4e.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-a72070139220275e.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-093434daf7d99801.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-24daf38551b7a03b.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace-36d70d9746402ce9.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace_sys-7acfc843240167a8.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-eb2e0f5fe057b8b3.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-75e9ddd83715a368.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-af51e7c6fd7d1248.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-27f2a77b2995d98c.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-ad10152c26711a1e.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-291bd2456cb6c9fe.rlib" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-fc6e9071307a3016.rlib" "-Wl,--end-group" "/home/chris/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-ebe4001ded7f33e7.rlib" "-Wl,-Bdynamic" "-lutil" "-lutil" "-lX11" "-lXcursor" "-lGLX" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: /usr/bin/ld: cannot find -lGLX
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error

error: could not compile `makepad`.

To learn more, run the command again with --verbose.

when trying to build on osx apple silicon

gennaroschiano@Gennaros-MacBook-Pro makepad % cargo run -p makepad --release
Finished release [optimized] target(s) in 0.01s
Running target/release/makepad
error: package ID specification webgl_example_wasm matched no packages

... would love to get this running!

git pull and build failed

> cargo run -p makepad --releasecar, and terminal info.

rustup show

git commit

Components, contributions

This is not really an issue but I couldn't find another way to contact.
First of all, awesome project, love the performance!

I was wondering if it's possible and if it's considered a good practise to use makepad to build components as webassembly modules for performance critical components within a web application that is not fully ported over to be built on top of makepad (yet).

My examples is a hobby glTF editor (gltf.app) which has a tree component, but it's quite hard to make it perform well with nodes over 2000 items. I tried makepad by generating 6000 items and the tree component handled it very well. It started to slow down at 20,000 items but I'm sure there's ways to optimize and I don't need those numbers anyway.
In this project it would be useful to develop just this tree component based on makepad, and keep less performance critical parts of the editor in html - at least until I get to rewrite them as well.

Multiple-cursor editing: glitches and hanging

Freeze bug

Click on one spot. Ctrl-click on the same or another character. Ctrl+A and backspace.

Glitchy multiple selections

Click on one spot. Ctrl-click on the same spot. Then try typing (characters will appear left AND right of the cursor) or pressing backspace.

Reproduction steps:

• Open https://makepad.github.io/makepad/
• Clear the document
• Type asdf
  • two asdf appear, cursor is between them
• press backspace
  • asd cursor asd (both f disappear)

Browser

https://makepad.github.io/makepad/
Firefox 67.0b17 (64-bit), Ubuntu 18.04

Unable to compile on Windows

I'm trying to run the simple example but it doesn't seem to compile.

Cargo check output:

    Checking makepad-micro-serde v0.3.0 (D:\Projects\github\makepad\libs\micro_serde)
error[E0433]: failed to resolve: could not find `unix` in `os`
   --> libs\micro_serde\src\serde_bin.rs:372:22
    |
372 |         use std::os::unix::ffi::OsStrExt;
    |                      ^^^^ could not find `unix` in `os`

error[E0599]: no method named `as_bytes` found for reference `&OsStr` in the current scope
   --> libs\micro_serde\src\serde_bin.rs:374:14
    |
374 |         self.as_bytes().ser_bin(s)
    |              ^^^^^^^^ method not found in `&OsStr`

Some errors have detailed explanations: E0433, E0599.
For more information about an error, try `rustc --explain E0433`.
error: could not compile `makepad-micro-serde` due to 2 previous errors

I'm using Rust 1.64.0 on Windows 11.

Segmentation Fault

Segmentation fault while trying to run makepad:

$ cargo run -p makepad
warning: unnecessary parentheses around type
   --> render/src/cx_linux.rs:284:25
    |
284 |     pub stop_timer: Vec<(u64)>,
    |                         ^^^^^ help: remove these parentheses
    |
    = note: `#[warn(unused_parens)]` on by default

warning: unused variable: `force_full_repaint`
   --> render/src/cx_opengl.rs:168:9
    |
168 |         force_full_repaint: bool,
    |         ^^^^^^^^^^^^^^^^^^ help: consider prefixing with an underscore: `_force_full_repaint`
    |
    = note: `#[warn(unused_variables)]` on by default

    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/makepad`
Segmentation fault (core dumped)

Rust versions tested:
rustc 1.41.0-nightly (412f43ac5 2019-11-24)
rustc 1.39.0 (4560ea788 2019-11-04)

Operating System:
Arch Linux (Kernel: Linux 5.3.13-arch1-1)

OpenGL Renderer: Mesa DRI Intel(R) Haswell Mobile

Output of glxinfo: https://gist.github.com/happycoder97/e1991c67ddf306fc6db7c15f5befd8f7

Latest dev commit is missing some files

It seems like the content of makepad/render/draw_derive has not been committed, so any attempt of compiling the latest dev version fails.

Certain .ttf-font characters are not displayed

Expected behavior

Fonts should display the full alphabet.

Actual behavior

Some fonts miss individual letters.

Steps to reproduce

Replace the current Ubuntu-UI font with IBM Plex Text:

• Put the attached font-file in /resources.
• Change the font on line 25 in /render/src/draw_2d/draw_text.rs to path: "resources/IBMPlexSans-Text.ttf"

This should result in Makepad displaying no "g"-letters in the UI.

Further comments

Higher quality fonts oftentimes feature ligatures and alternative glyphs for certain letters. The latter seems to cause this concrete issue.

Rik briefly looked into the situation already. I hope I am summarizing his findings accurately:
It seems that there are multiple indices in the font-table for 'g'. However none of them end up in font.char_code_to_glyph_index_map[unicode];.
The glyphs are parsed but the char_code_to_glyph_index-map doesn't contain the entries – probably because it's a different subtable type since there are four 'g's. It probably sits in some kind of ligature table instead.

contributing

Hi,
am very interested in your project. can I contribute to this?
If yes how to setup ?.

Thanks

Text doesn't render in Firefox 66.0.5/Mac

Text within the body and the tree control are both invisible on latest Firefox/Mac. Works fine in Safari.

Different clipboards for different cursors in multicursor mode

In most code editors which support multi-cursor mode, each distinct cursor tends to have its own clipboard. This allows a user to create X cursors (where X is some number), use them to select X words on different lines, copy them with Ctrl+C, and then move these X cursors to X new positions and then hit Ctrl+V to paste the X distinct copied values neatly into each of the X new positions.

On the other hand, in Lapce (as it stands today), copying with multi-cursor doesn't work this way. It adds X lines worth of text into the clipboard, and Ctrl+V pastes all the X lines into each of the X cursor positions thereafter. This causes a veritable explosion of text in the editor and everything is thrown aside and scattered asunder.

I am requesting the kind of multi-cursor clipboard that VSCode and Atom have. I would have done it myself, but (1) I am kinda busy these days and (2) I am an utter noob in Rust (I find it harder than C). Nevertheless, if it is absolutely not possible for anyone to find time to work on this feature, I will still be grateful if someone can point me to the portion of the code which handles copying and other actions under multi-cursor. Then I can give it a shot and see if I can build a pull request.

(Don't count on it though. Once again, I am at that point of Rust learning where I find Rust harder than C)

Roadmap? And some additional questions / comments

First, I want to say this project is brilliant. Well done. Going through the codebase, I was thrilled to see the techniques used for geometry gen, shader compilation for multiple targets, shader to rust live data binding, contained text rendering / glyph generation / etc. This has captured many objectives I was targeting myself, so using this work as a base shaves years off my dev.

A few questions / comments:

• this could become THE next gen framework for web & standalone apps. I see there is a lot of work being done on the live studio editor, but is the intention to make everything (renderer & components) modular and standalone? I am less interested in a fully functional editor with live code changes (vscode works fine for me atm), and more interested in having the simple building blocks to create an app

• it seems like there is a lot of work that needs to be done regarding usability and documentation. The renderer is brilliant. The vision for the live code editor is as well -- it's magical seeing code changes reflected so responsively. The core rendering tech & using shaders defined on a per-component basis is really what I'm after however.

• is there a publicly available roadmap? I'd like to make contributions around usability and providing a react / vue / angular-like component experience, and perhaps implementing more core components / a component library needed to make an app. My dream is being able to nearly eliminate boilerplate for UI and having absolute focus on the domain being implemented. I'd like to add more macros for generating components & declaring component dependencies with less boilerplate.

• is there a reason in particular there aren't really any deps / a lot of code & techniques were directly inserted? Example is window management for multiple platforms, instead of using winit it looks like the code was copied in? It sort of breaks the modularity / flexibility of the system when the real meat is in the rendering, so I was curious about the reasoning. Seems like not using cargo really will make common efforts hard / more complex for this project. Any plans to be more integrated with the existing cargo infrastructure, ex configurable window management, cg math choices, etc.

• plans for accessibility?

Will have more thoughts, is writing them here appropriate?

Text window doesn't scroll sideways with touchpad on Ubuntu

Error when starting makepad from another folder

When i start Makepad from any other folder than the root of the repo i get this error.

Error loading font resources/Ubuntu-R.ttf 
Error loading font resources/LiberationMono-Regular.ttf 
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/5e1a799842ba6ed4a57e91f7ab9435947482f7d8/src/libcore/macros/mod.rs:15:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Is it possible to load that files from a relative path to the binary ?

The editor won't update the status of command key after re-focused.

Step to reproduce:

1. Focus the editor
2. Hold command key, the editor will enter multi-cursor mode.
3. Keep holding and switch to another tab in your browser
4. Switch back to the editor without holding command key
5. Multi-cursor is still enabled before you press command key again

Screen record (notice the key caster)

I found that the color! macro in examples no longer exists

I found this function under this path : render\src\colors\color
But direct replacement cannot compile:

expected struct `makepad_shader_compiler::colors::Color`, found struct `makepad_render::colors::Color`

My doubt is why two different Color structures are needed...

Spaces in comment rendered as exclamation point

Steps to reproduce:

• Go to https://makepad.github.io/makepad/ on latest "selection" commit
• Scroll down to see comment
• Spaces in comments are rendered as ! until they are selected then they're rendered as bullets

super

cool

Panic on windows

Hello,

tried to run makepad on a Windows 10 machine. Compilation succeeds and the makepad window briefly pops up before panicking. Attaching verbose stack trace below.

Could this be a problem with the port (I believe its hardcoded to 2001) being already bound to something?

Also, thank you for making makepad. I believe it's currently realy underappreciated and that it has not received the attention it deserves in the Rust gui world.

Cheers,
Spiros

Stack trace:

    Finished release [optimized + debuginfo] target(s) in 0.28s
     Running `target\release\makepad.exe`
thread '<unnamed>' panicked at 'Cannot bind server address: Os { code: 10013, kind: PermissionDenied, message: "An attempt was made to access a socket in a way forbidden by its access permissions." }', src\libcore\result.rs:1165:5
stack backtrace:
   0:     0x7ff7c30edde3 - backtrace::backtrace::dbghelp::trace
                               at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.40\src\backtrace\dbghelp.rs:88
   1:     0x7ff7c30edde3 - backtrace::backtrace::trace_unsynchronized
                               at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.40\src\backtrace\mod.rs:66
   2:     0x7ff7c30edde3 - std::sys_common::backtrace::_print_fmt
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\sys_common\backtrace.rs:77
   3:     0x7ff7c30edde3 - std::sys_common::backtrace::_print::{{impl}}::fmt
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\sys_common\backtrace.rs:61
   4:     0x7ff7c304198b - core::fmt::write
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libcore\fmt\mod.rs:1028
   5:     0x7ff7c30ed017 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\io\mod.rs:1412
   6:     0x7ff7c30ecc90 - std::sys_common::backtrace::_print
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\sys_common\backtrace.rs:65
   7:     0x7ff7c30ecc90 - std::sys_common::backtrace::print
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\sys_common\backtrace.rs:50
   8:     0x7ff7c30ecc90 - std::panicking::default_hook::{{closure}}
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\panicking.rs:188
   9:     0x7ff7c30ec3e2 - std::panicking::default_hook
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\panicking.rs:205
  10:     0x7ff7c30ec3e2 - std::panicking::rust_panic_with_hook
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\panicking.rs:464
  11:     0x7ff7c30f1ff0 - std::panicking::continue_panic_fmt
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\panicking.rs:373
  12:     0x7ff7c30ff239 - std::panicking::rust_begin_panic
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\panicking.rs:302
  13:     0x7ff7c303bcbd - core::panicking::panic_fmt
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libcore\panicking.rs:139
  14:     0x7ff7c304219f - core::result::unwrap_failed
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libcore\result.rs:1165
  15:     0x7ff7c3096f30 - core::result::Result<std::net::tcp::TcpListener, std::io::error::Error>::expect<std::net::tcp::TcpListener,std::io::error::Error>
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\libcore\result.rs:960
  16:     0x7ff7c2ff11e6 - hub::httpserver::HttpServer::start_http_server
                               at E:\SugarSyncSTUFF\PROJECTS\RUST\WASM\makepad\makepad\hub\src\httpserver.rs:22
  17:     0x7ff7c2ff11e6 - hub::hubworkspace::HubWorkspace::run<closure-0>
                               at E:\SugarSyncSTUFF\PROJECTS\RUST\WASM\makepad\makepad\hub\src\hubworkspace.rs:42
  18:     0x7ff7c303090f - makepad::workspace_main::main
                               at E:\SugarSyncSTUFF\PROJECTS\RUST\WASM\makepad\workspace\src\main.rs:6
  19:     0x7ff7c3024fbd - makepad::app::{{impl}}::handle_app::{{closure}}
                               at E:\SugarSyncSTUFF\PROJECTS\RUST\WASM\makepad\makepad\src\app.rs:403
  20:     0x7ff7c2ff5331 - std::sys_common::backtrace::__rust_begin_short_backtrace<closure-0,()>
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\libstd\sys_common\backtrace.rs:129
  21:     0x7ff7c2ff5af7 - std::thread::{{impl}}::spawn_unchecked::{{closure}}::{{closure}}<closure-0,()>
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\libstd\thread\mod.rs:469
  22:     0x7ff7c2ff1009 - std::panic::{{impl}}::call_once<(),closure-0>
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\libstd\panic.rs:317
  23:     0x7ff7c2ff7ec1 - std::panicking::try::do_call
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\libstd\panicking.rs:287
  24:     0x7ff7c2ff7ec1 - panic_abort::__rust_maybe_catch_panic
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libpanic_abort\lib.rs:28
  25:     0x7ff7c2ff7ec1 - std::panicking::try
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\libstd\panicking.rs:265
  26:     0x7ff7c2ff7ec1 - std::panic::catch_unwind
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\libstd\panic.rs:396
  27:     0x7ff7c2ff7ec1 - std::thread::{{impl}}::spawn_unchecked::{{closure}}
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\libstd\thread\mod.rs:468
  28:     0x7ff7c2ff7ec1 - core::ops::function::FnOnce::call_once<closure-0,()>
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\libcore\ops\function.rs:227
  29:     0x7ff7c30fe2be - alloc::boxed::{{impl}}::call_once<(),FnOnce<()>>
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\liballoc\boxed.rs:942
  30:     0x7ff7c30ff717 - alloc::boxed::{{impl}}::call_once
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\src\liballoc\boxed.rs:942
  31:     0x7ff7c30ff717 - std::sys_common::thread::start_thread
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\sys_common\thread.rs:13
  32:     0x7ff7c30ff717 - std::sys::windows::thread::{{impl}}::new::thread_start
                               at /rustc/2477e2493e67527fc282c7239e019f7ebd513a1a\/src\libstd\sys\windows\thread.rs:47
  33:     0x7ffd7d9e7bd4 - BaseThreadInitThunk
  34:     0x7ffd7eaaced1 - RtlUserThreadStart
error: process didn't exit successfully: `target\release\makepad.exe` (exit code: 0xc000001d, STATUS_ILLEGAL_INSTRUCTION)

no window on macos

seems like starting 3d55338 makepad window doesn't appear on start

makepad on iOS

I am tinkering with makepad, wanna make it run on an iPad. So far I have setup the build system for a minimal iOS app (just printing "hello world" on the Xcode console) written in Rust, similar as it is done in winit

Is there a plan to add support for iOS ? If not, here is how I think to mess around with the codebase to make it work on iOS:

• in cx.rs I define a new non-desktop PlatformType called IOS
• I add a file cx_ios.rs which is initially mostly just a duplicate of cx_macos.rs, but imports from cx_cocoa_ios
• In cx_cocoa_ios.rs I do things the iOS way, e.g. using UIKit instead of AppKit and also the font loading or file loading in general needs to be implemented differently.

Does any of this make sense ? (I am aware that you are not ready yet for accepting external contributions and the codebase might unpredictable change anytime)

Using freed memory in xlib.rs

Hi,

I have noticed some problematic code here (and may be in a few more places)

https://github.com/makepad/makepad/blob/dev/render/src/platform/linux/xlib.rs#L116-L129

The problem with this statement: CString::new("CLIPBOARD").unwrap().as_ptr()

is that .as_ptr() will take the address of a freed pointer that was constructed o the heap, with latest nightly compiler one now gets a warning like this

125 |                 atom_targets: X11_sys::XInternAtom(display, CString::new("TARGETS").unwrap().as_ptr(), 0),
    |                                                             -------------------------------- ^^^^^^ this pointer will be invalid
    |                                                             |
    |                                                             this `CString` is deallocated at the end of the statement, bind it to a variable to extend its lifetime
    |
    = note: pointers do not have a lifetime; when calling `as_ptr` the `CString` will be deallocated at the end of the statement because nothing is referencing it as far as the type system is concerned
    = help: for more information, see https://doc.rust-lang.org/reference/destructors.html

In cases like this there is no need to construct a heap-based string and pass it down to the C API. It's possible to just do b"TARGETS\0" (or use CStr)

VR-button should exit VR as well as enter

I just tried Makepad in VR and... WOW! It was so much more immediately accessible what was happening with the "treeworld"-demo. I did find myself wanting a few things to be added: a virtual keyboard, a way to grab the code-window by the edges and stretch it to a bigger size, fatter scrollbars, tabs that can be popped out into virtual screens of their own.. lots of ideas, really. (Should I open issues for each of these?)

In any case, I think one of the fundamental rules of UI design is this: Always give the user a way out.
So, how about making that useless-in-vr vr-button a different function when in vr? It should exit vr.