Description

Crash attempting to run the examples.

An unexpected panic ocurred, the program has to exit.
Please report this error and attach the log file found in the directory of the executable.

The error ocurred in: $HOME/.cargo/git/checkouts/azul-dependencies-70bb1f94316762f9/c154897/tomaka.glutin#23b3b10/src/platform/macos/mod.rs at line 61 in thread main

Error information:
not yet implemented

Backtrace:

azul::logging::set_up_panic_hooks::panic_fn @ logging.rs:86
core::ops::function::Fn::call @ function.rs:69
std::panicking::rust_panic_with_hook @ panicking.rs:478
std::panicking::begin_panic @ panicking.rs:408
glutin::platform::platform::Context::new @ mod.rs:61
glutin::combined::CombinedContext::new @ combined.rs:58
azul::window::create_gl_window @ window.rs:851
azul::window::Window<T>::new @ window.rs:539
azul::app::App<T>::create_window @ app.rs:287
calculator::main @ calculator.rs:403
std::rt::lang_start::{{closure}} @ rt.rs:64
std::panicking::try::do_call @ panicking.rs:293
 @ lib.rs:87
std::rt::lang_start_internal @ rt.rs:48
std::rt::lang_start @ rt.rs:64

Version / OS

• azul version: master
• Operating system: macOS Mojave version 10.14.4

Steps to Reproduce

git clone https://github.com/maps4print/azul.git cargo build cargo run --example calculator

Additional Information

Issue seems in statement below from $HOME/.cargo/git/checkouts/azul-dependencies-70bb1f94316762f9/c154897/tomaka.glutin#23b3b10/src/platform/macos/mod.rs at line 61, which runs panic on any example from list.

if gl_attr.sharing.is_some() {
    unimplemented!()
}

Description

warning: build failed, waiting for other jobs to finish... error: build failed PS L:\R\Coding\Rust\my_first_azul_app> cargo run Compiling webrender_api v0.60.0 error[E0433]: failed to resolve: could not find 'IoReader' in 'bincode' --> C:\Users\Admin\.cargo\registry\src\github.com-1ecc6299db9ec823\webrender_api-0.60.0\src\display_list.rs:270:35 | 270 | let reader = bincode::IoReader::new(UnsafeReader::new(&mut self.data)); | ^^^^^^^^ could not find 'IoReader' in 'bincode' error: aborting due to previous error For more information about this error, try 'rustc --explain E0433. error: could not compile 'webrender_api.

Version / OS

• azul version: 0.1

• Operating system: Windows 10

• Windowing system (X11 or Wayland, Linux only):

Steps to Reproduce

cargo run

Additional Information

CMake installed, default toolchain is stable-x86_64-pc-windows-msvc, MSVC installed

Hello,

I'm very excited to give this a try and reading the guide ATM: https://github.com/maps4print/azul/wiki/A-simple-counter

But using the example code above simply shows an empty window without the label and the button:

macOS 10.14.1 Azul version: d39fde59c375c7a3a684a7c90bc8623521351e7e rustc 1.32.0-nightly (653da4fd0 2018-11-08)

I cannot build azul.

Description

When I run cargo build on powershell, my shell displays

error: failed to run custom build command for `harfbuzz-sys v0.3.0 (https://github.com/maps4print/azul-dependencies?rev=380b7e7cba8b728a3fc89fe28952e3b07aa624e7#380b7e7c)`
process didn't exit successfully: `C:\Users\Shogo\Projects\azul\target\debug\build\harfbuzz-sys-edd981c7a9cf27bd\build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=HARFBUZZ_SYS_NO_PKG_CONFIG

--- stderr
thread 'main' panicked at '

couldn't determine visual studio generator
if VisualStudio is installed, however, consider running the appropriate vcvars script before building this crate
', C:\Users\Shogo\.cargo\git\checkouts\azul-dependencies-70bb1f94316762f9\380b7e7\cmake-0.1.35\src\lib.rs:687:25
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

With VS 2019's vcvars64,

error: failed to run custom build command for `harfbuzz-sys v0.3.0 (https://github.com/maps4print/azul-dependencies?rev=380b7e7cba8b728a3fc89fe28952e3b07aa624e7#380b7e7c)`
process didn't exit successfully: `C:\Users\Shogo\Projects\azul\target\debug\build\harfbuzz-sys-edd981c7a9cf27bd\build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=HARFBUZZ_SYS_NO_PKG_CONFIG

--- stderr
thread 'main' panicked at '

unsupported or unknown VisualStudio version: 16.0
if another version is installed consider running the appropriate vcvars script before building this crate
', C:\Users\Shogo\.cargo\git\checkouts\azul-dependencies-70bb1f94316762f9\380b7e7\cmake-0.1.35\src\lib.rs:687:25
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Version / OS

• azul version: since 7add48d77f33e517d11df57d0a76366c3c51aa8e

• Operating system: Windows 10 64bit

Description

I tried to propagate errors instead of letting the program panic! with unwrap() calls:

fn start() -> Result<(), /* What to put here? */> {
    // Instantiate the app with default values.
    let mut app = App::new(DataModel::default(), AppConfig::default());

    // Create a new window.
    app.create_window(WindowCreateOptions::default(), Css::native())?;

    // Run the app.
    app.run()?
}

The example above illustrates the issue:

• app.create_window returns a Result<(), WindowCreateError>
• app.run returns a Result<T, RuntimeError<T>>

But they do not share an Into (or From) implementation. In other words: There is a lack of an Error-implementation higher in the hierarchy.

This forces the API-consumer to either unwrap all errors which:

• Causes visual clutter in the code
• Panics: Exactly the thing that the Error type should prevent

Proposed solutions

Option 1: Implement std::error::Error for all the top-level error-types in Azul

From looking at the code, that would be:

• CssParseError
• FontError
• ImageError
• ClipboardError
• WindowCreateError

I'm not sure, but I think that those are the only errors returned from functions in the library.

Option 2: Create one top-level azul::Error

The azul::Error should then be implemented by all the errors mentioned in option 1.

Which all other azul Errors can convert into. (Also see rfc-356 about stuttering names)

Option 3: Kind-of combination of option 1 and option 2

Creating one top-level azul::Error which implements std::error::Error. This allows API-consumers to use the azul::Error together with other libraries and use the errors interchangeably.

This one is my favourite :)

Is this a breaking change

I'm not sure, option 2 and 3 may be be a breaking change?

I'm willing to help and write the code if you find one of the solutions a good idea.

Great job by the way, I like the library and I think it has a big potential of becoming a widely used GUI library for Rust (which is something Rust really needs).

Description

Running the Calculator and Table example under Wayland looks "out of shape".

Version / OS

• azul version: master from this commit

• Operating system: Arch Linux 4.18.16 Gnome 3.30.1

• Windowing system (X11 or Wayland, Linux only): Wayland

Steps to Reproduce

clone from the listed commit and run cargo run --example calculator

Expected Behavior

accurate layout

Actual Behavior

glitched layout

Additional Information

Description

rustup 1.18.3 (435397f48 2019-05-22)

Version / OS

• azul version: azul = { git = "https://github.com/maps4print/azul" }

Steps to Reproduce

Trying to build

Additional Information

Getting this error: error: failed to run custom build command for harfbuzz-sys v0.3.0 (https://github.com/maps4print/azul-dependencies?rev=bf2933b9aac43a7003278862772250398e4fa457#bf2933b9)

Caused by: process didn't exit successfully: D:\RustProjects\azul_test\azulapp\target\debug\build\harfbuzz-sys-94af335e9d1d05e2\build-script-build (exit code: 101) --- stdout cargo:rerun-if-env-changed=HARFBUZZ_SYS_NO_PKG_CONFIG

--- stderr thread 'main' panicked at '

couldn't determine visual studio generator if VisualStudio is installed, however, consider running the appropriate vcvars script before building this crate ', C:\Users\user.cargo\git\checkouts\azul-dependencies-70bb1f94316762f9\bf2933b\cmake-0.1.35\src\lib.rs:687:25 note: Run with RUST_BACKTRACE=1 environment variable to display a backtrace.

warning: build failed, waiting for other jobs to finish... error: build failed

Hey! I pulled down Azul today to give it a shot with hello world, it's pretty great!

I did notice that there was a gigantic Git checkout at the part of my first build, so I dug around and found that all the dependencies are in one giant repo, azul-dependencies.

Why are dependencies vendored like this?

It's super strange and makes it so that there's two versions of every crate that I have in common with Azul in my executable! It also blocks the entire download/compilation step of my application with a single giant Git clone.

Description

When trying out the examples on my machine, I noticed that reproducibly the UI only shows after I force a redraw by resizing the window or clicking somewhere inside it.

Version / OS

• azul version: version = "0.1.0" source = "git+https://github.com/maps4print/azul#2068541297c8345b622a8a05c5e0ac690d1c154e"

• Operating system: Linux Ubuntu 16.04

• Windowing system (X11 or Wayland, Linux only): X11

• Rust: rustc 1.30.1 (1433507eb 2018-11-07)

Steps to Reproduce

• Create a new cargo project with azul as dependency.
• paste one of the azul examples in main.rs
• cargo run

Expected Behavior

The window opens and immediately shows the rendered example.

Actual Behavior

The window is empty and only redraws the example when resizing the window or clicking somewhere.

After clicking:

Additional Information

Description

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.46s
     Running `target\debug\guitests.exe`
[ERROR][azul::logging] An unexpected panic ocurred, the program has to exit.
Please report this error and attach the log file found in the directory of the executable.

The error ocurred in: libcore\result.rs at line 945 in thread main

Error information:
called `Result::unwrap()` on an `Err` value: CreateError(NotSupported("required extension \"WGL_ARB_create_context_profile\" not found"))

Backtrace:

backtrace::backtrace @ mod.rs:42
backtrace::capture::Backtrace @ capture.rs:88
backtrace::capture::Backtrace @ capture.rs:64
azul::logging::set_up_panic_hooks @ logging.rs:87
core::ops::function::Fn::call<fn(core::panic::PanicInfo*),(core::panic @ function.rs:73
std::panicking @ panicking.rs:482
std::panicking @ panicking.rs:390
std::panicking @ panicking.rs:325
core::panicking @ panicking.rs:77
core::result::unwrap_failed<azul::window @ macros.rs:26
core::result::Result<azul::window::Window<guitests::DataModel>, azul::window::WindowCreateError>::unwrap<azul::window::Window<guitests::DataModel>,azul::window @ result.rs:782
guitests @ main.rs:28
std::rt::lang_start @ rt.rs:74
std::panicking::try @ panicking.rs:310
panic_unwind @ lib.rs:105
std::rt @ rt.rs:58
std::rt @ rt.rs:74
 @ exe_common.inl:253

error: process didn't exit successfully: `target\debug\guitests.exe` (exit code: 101)

Version / OS

• azul version: master
• Operating system: Windows 8

Description

When I start the demo app, it is about twice as large as my screen. The font appears to be about double what it's supposed to be.

Version / OS

• azul version: 0.1.0

• Operating system: Debian linux, openbox window manager

• Windowing system (X11 or Wayland, Linux only): X11

Expected Behavior

Draw from system info that doesn't lie about the dpi or the screen size, or do some sanity checking to notice when that info is lies and do something sensible instead

Actual Behavior

Similar to Servo, everything is too huge (the problem might be upstream, but I'm reluctant to report it to servo, because in servo's case the issue is confounded with many other problems happening at the same time.)

Additional Information

This issue may have something to do with the fact I'm using a tv as a monitor. Until recently, many other apps had similar issues, either rendering text and icons way too large (most qt apps), or, strangely, in the case of openbox and tint2, rendering text way too small. Most apps, though (chrome, firefox, terminals, other gtk apps), got along fine.

While reporting this bug, though, I got around to creating a ~/.Xresources file, containing Xft.dpi: 75. This has corrected all of the offending programs I was aware of, but it has not corrected the azul demo.

Description

Upon attempting to parse the C header for azul with clang, it fails with various errors

Version / OS

• azul version: master commit a1f9c526d4a2dfb79770717f7a63539e22f18a40

• Operating system: Windows 10 and Arch Linux

• Windowing system (X11 or Wayland, Linux only): Wayland

Steps to Reproduce

clang azul.h

Additional Information

azul.h:4064:18: error: expected expression
    AzFloatValue[;20] matrix;
                 ^
azul.h:4064:17: error: expected member name or ';' after declaration specifiers
    AzFloatValue[;20] matrix;
    ~~~~~~~~~~~~^
azul.h:4064:19: error: type name requires a specifier or qualifier
    AzFloatValue[;20] matrix;
                  ^
azul.h:4064:19: error: expected member name or ';' after declaration specifiers
azul.h:4064:19: error: expected ';' at end of declaration list
    AzFloatValue[;20] matrix;
                  ^
                  ;
azul.h:4064:21: error: type name requires a specifier or qualifier
    AzFloatValue[;20] matrix;
                    ^
azul.h:4064:21: error: expected member name or ';' after declaration specifiers
azul.h:4064:21: error: expected ';' at end of declaration list
    AzFloatValue[;20] matrix;
                    ^
                    ;
azul.h:6436:13: error: expected expression
    uint8_t[; 10] panose;
            ^
azul.h:6436:12: error: expected member name or ';' after declaration specifiers
    uint8_t[; 10] panose;
    ~~~~~~~^
azul.h:6436:15: error: type name requires a specifier or qualifier
    uint8_t[; 10] panose;
              ^
azul.h:6436:15: error: expected member name or ';' after declaration specifiers
azul.h:6436:14: error: expected ';' at end of declaration list
    uint8_t[; 10] panose;
             ^
             ;
azul.h:6436:17: error: type name requires a specifier or qualifier
    uint8_t[; 10] panose;
                ^
azul.h:6436:17: error: expected member name or ';' after declaration specifiers
azul.h:6436:17: error: expected ';' at end of declaration list
    uint8_t[; 10] panose;
                ^
                ;
azul.h:9725:1: error: use of 'AzMenuItem' with tag type that does not match previous declaration
union AzMenuItem {
^~~~~
struct
azul.h:6591:8: note: previous use is here
struct AzMenuItem;
       ^
azul.h:9730:9: error: use of 'AzMenuItem' with tag type that does not match previous declaration
typedef union AzMenuItem AzMenuItem;
        ^~~~~
        struct
azul.h:9725:7: note: previous use is here
union AzMenuItem {
      ^
azul.h:12376:46: error: 'void' must be the first and only parameter if specified
extern DLLIMPORT AzRefAny AzRefAny_newC(void ptr, size_t len, uint64_t type_id, AzString  type_name, AzRefAnyDestructorType  destructor);
                                             ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

(this error log taken from linux, but happens the same on windows too)

Bumps lyon from 0.17.10 to 1.0.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps usvg from 0.22.0 to 0.24.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps resvg from 0.22.0 to 0.24.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Description

This project ships a Cargo.lock (which is good, considering that it also is meant to be build-able as binary to provide the azul-dll), which unfortunately contains a very old version of xcb. This very old version of xcb generates code into the cargo-vendor-dir, which makes it impossible to compile azul in the nix ecosystem, since the cargo-vendor-dir resides in the read-only nix store, causing any attempt to write a file to it to fail. Generally I think its also considered just wrong to write to the cargo vendor dir, there is an environment variable for where to generate artifacts (OUT I think?).

Edit: This dependency is introduced via azul-desktop/clipboard2, which hasn't been touched in the last 4 years and pinpoints x11-clipboard to version 0.3.0-alpha.1, which again is 4 years old and has reached version 0.7.0 by now. I think it would be good to update some of the transitive dependencies of the stuff involved.

Bumps strfmt from 0.1.6 to 0.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.