outside of that, i think the on the todo list canvas component is Ian's plan to have the best of both worlds for native targets

Composite here means "put together components in weird ways", right (eg the dropdown inside button example yoplala mentioned)? So the limitation of native backends would be that you can't be weirder than eg AppKit or GTK or Qt or whatever allow you to be.

non "standard" ways

native apps typically do have such limitations

and different native OS' are gonna have different limitations

but i'm not sure how haxeui/wxwidgets handles that

How is haxeui related to lime?

you have haxeui-openfl for example that has openfl as a backend ( which uses lime)

composite backends - openfl - flixel - heaps - kha - pdcurses native backends - html5 - wxwidgets - android (wip)

howdy... late to the party 🙂 ... ... so: * when using native backends (haxeui-hxwidgets, haxeui-html5-native, etc), components will be native (native to the browser in the case of haxeui-html-native5), this means things like copy, paste, passwords, scrolling, all that, will be native also * native backends are limited by the OS UI toolkit, but as mentioned, that can be a good thing, it means that you cant make "crazy" apps that dont feel "right" to the user * on the other hand, as also mentioned, it means you cant put together components in whaky, but also useful ways. Ie, in composite backends, you can put pretty much anything in a menu, you cant do that on native since the OS wont support that * password fields are implemented (mapped) on native * composite/native - maybe this will help: http://haxeui.org/api/getting-started/welcome.html ? * you cant combine backends (or native / composite really), haxeui-html5-native can, but its the only "hybrid" backend currently

hopefully that will help / make things a little clearer?

@cool-musician-79004 And the great thing about haxe-ui is the creator's reactivity . You have now the answers to your questions 😉

Yes, thank you very much

I have another hxwidgets bug. Menus that are not attached to menubar don't send event (the code was only written for menubars it seems)

package issues;

import haxe.ui.containers.VBox;
import haxe.ui.events.MouseEvent;
import haxe.ui.containers.menus.*;


@:xml('
<vbox width="100%" height="100%">
</vbox>')
class A008 extends VBox {

    @:bind(this, MouseEvent.RIGHT_CLICK)
    private function showMenu(e:MouseEvent) {
        var menu:Menu = new Menu(); 
        var menuitem = new MenuItem();
            menuitem.text = "item";
menu.onMenuSelected = function(e) {
            trace(e);  // Never called
        }
        menu.addComponent(menuitem);
            menu.left = e.screenX;
        menu.top  = e.screenY;
        haxe.ui.core.Screen.instance.addComponent(menu);
        menu.show();
    }
}

ive had context menus working for sure so maybe this is a regression

it feels like a weird way to show a context menu, but ill have to check my brain there

I’m a year late almost, but I finally have a project where I want more than a simple UI

I’ll be using heaps so I can contribute to that backend based on what I find

Oh really ? Why ?

im not sure you need to add it to screen - but maybe im talking rubbish

I think it was based on some code somewhere but I don't know how old. But I'm going to test now. 🙂

I think I remeber now it was somewhere on the forum. But indeed I don't need it ! Thanks.

i think i might be being dumb... i mean, im sure you would have to add it to screen, but i dont remember doing that for native, so might be an inconsistecy

Okay , I think you need to add it for html5, but you don't need to show it. For hxwidgets, , you need to show it, but not add it

yeah, seems like an inconsistency there

what happens if you add it to the screen in wx? I mean, if you use the same code that works on html5

Nothing happens

(it doesn't show)

right, so inconsistency there what will need to be addressed

menu.show() is kind of nicer. I wonder if there could be reason to add it somewhere than the screen instance.