haxeui / haxeui-core Goto Github PK

When adding a Child with 100% width to a scroll view the child will get a width of 0

Expected Behavior

I would expect the child to get the content width of the scroll view this would be either

1. the width of the scrollview itself
   or
   2 the width of the widest child content of the scroll view

Test app / minimal test case

ScrollViewTest.zip

Making the parsers modular (as in part of the module.xml sub system) would be advantageous as it would allow totally custom parsers to be able to registered outside of haxeui-core. This would mean that UI definitions could be plugged into haxeui-core with any conceivable format, so long as they eventually parse down to ComponentInfo (see: https://github.com/haxeui/haxeui-core/tree/master/haxe/ui/parsers/ui)

Another added benefit of this is that this same system is used when loading UIs via runtime from strings (for example via http, etc), so this would all come for free naturally by leveraging the current parsing system.

Expected Behavior

The all current parsers (XML, JSON, YAML) be moved into haxeui-core's module.xml, that would then allow scope for new modules to be added to provide additional parsing functionality.

Current Behavior

Currently parsers are defaulted and there is no easy mechanism to create them from module.xml (see: https://github.com/haxeui/haxeui-core/blob/master/haxe/ui/parsers/ui/ComponentParser.hx#L32), there is however a register function making this change relatively trivial.

Hi!

Expected Behavior

I don't know if it is a missing feature, a design decision or I'm missing something.
The enable or disable state in some components (like Buttons, CheckBox, TextField...) are useful. HaxeUI v1 had this property.

Current Behavior

Not implemented.

Context

For example, i want to disable buttons (with the disabled state selector in css).

I installed the git version of haxe ui and the flashdevelop templates, then opened a haxe ui nme project and tried to compile that (without doing anything else).

Expected Behavior

No errors, beautiful UI.

Current Behavior

Component.hx and Screen.hx gives error in from setComponentIndex function about a missing handleSetComponentIndex function.

C:\HaxeToolkit\haxe\lib/haxeui-core/git/haxe/ui/core/Screen.hx:64: characters 12-35 : Unknown identifier : handleSetComponentIndex
C:\HaxeToolkit\haxe\lib/haxeui-core/git/haxe/ui/core/Component.hx:603: characters 12-35 : Unknown identifier : handleSetComponentIndex

Possible Solution

Removing the line did work to make it compile and run, however since I don't know anything about the internals this most likely breaks stuff (?)

Your Environment

• Version used: git
• Operating System and version (desktop or mobile): Windows

Clickng a table header does nothing

Expected Behavior

The display of data should sort based on alpha-numeric sorting by default.

Not sure if this should be included by default or left to the end developer to introduce.

Scrollview with width=auto, or no width, explodes(?) when vertical scrollbaris required
I wanted the balck area to fit the buttons width. I expect translations for the buttons at some point so their width could be variable.

Expected Behavior

if a width is set to auto then the width should match

Possible Solution

adding a fixed width resolves issue

Steps to Reproduce (for bugs)

1. run the test app in html
2. resize until a vertical scroll bar would be required

Media

Before

after

Test app / minimal test case

BlankTemplate.zip

I have to leave currently and will add to this later (Sorry, I jsut wanted to capture it for now). It appears that if you have a vbox that contains a tableview and call vbox.removeAllComponents() that the application hangs

I was testing 500 rows in the continuousTest project table.
TableView with 3 Rows takes:
27 seconds in NME Windows
8 seconds in Haxeui-HTML

Maybe related to percent based layout?
I was thinking about virtialisation. It seems that is what Flex did in their datagrid. Its main issue was variable row height in that case

Expected Behavior

a few seconds?

Possible Solution

Paging

Steps to Reproduce (for bugs)

1. Main.hx
   Line 40 change 500 to 10 for quick response

Test app / minimal test case

ContinioiusTest.zip

Expected Behavior

Should find the css file.

Current Behavior

I'm getting the warning:
haxeui-core/haxe/ui/parsers/ui/resolvers/FileResourceResolver.hx:28: WARNING: Could not find file: /main.css

App still build but obviously style isn't applied.

Possible Solution

Looks like a / is added by mistake.

Also having the ui and css stored in an asset folder fix things.

Test app / minimal test case

includeTest.tar.gz

Can also change in the main.xml line 3 from main.css to ./main.css or even ../test/main.css ("test" being the name of my folder) without success.

Your Environment

Latest git version, 12965ff

I'm currently testing on the C++ Windows target, but I'm sure it's the same for others. Basically, if you click the cross button in a popup dialog, the application will crash.

private static function showBasicDialog(view:Component, onOk:Function = null)
{
    var options = new DialogOptions();
    options.addStandardButton(DialogButton.OK);
    options.addStandardButton(DialogButton.CANCEL);

    Screen.instance.showDialog(view, options, function(b:DialogButton) {
        if (b.id == '${DialogButton.OK}')
        {
            if (onOk != null)
                onOk();
        }
    });
}

It might be the case that it really does not matter what code you use, but I have provided my example code above for this instance.

As I mentioned on Twitter quite recently, I thought that dropdowns had been properly implemented and that it just worked. Although you (Ian) mentioned that OpenFL should work, I'm getting some unusual results.

Here is the XML code I'm using:

<?xml version="1.0" encoding="utf-8" ?>
<vbox id="tools">
    <hbox>
        <dropdown id="type" style="height: 30px; width: 120px; vertical-align: bottom;">

        </dropdown>
    </hbox>
</vbox>

Now, I'm not sure if that's the correct XML for dropdown because I'm just testing things out. However, I'm having very weird issues revolving around dropdowns.

Firstly, these are the results for the above XML:

Now, I want to make sure if that above XML is correct before I start posting additional issues because it may just be the fact that the XML is wrong.

Wrapping text because of width limit doesn't re position or resize the component inside VBox. I am testing in HTML but the same is true in nme

Expected Behavior

I would expect other components in VBox below to position down in order to make room

Current Behavior

They dont

Test app / minimal test case

<?xml version="1.0" encoding="utf-8"?>
<vbox id="main">
        <button id="testButton1" styleNames="big-button" text="Click Me!  Alot of times.  I dont do anything really" width="50" />
        <label text="comp1 comp1 comp1 comp1 comp1 comp1 comp1 comp1 comp1 comp1" width="50" style="horizontal-align: center; font-size:35px; color: #888888;" />
        <label text="comp2" style="horizontal-align: center; font-size:35px; color: #888888;" />
        <text text="text box text box text box text box text box text box text box text box " width="50" />
    <text text="Nothing to add"/>
</vbox>

This problem can be reproduced in the hxWidgets backend (a complete textfield example here).

When native = true, createChildren() isn't called in Component.hx#L83. And createChildren method has the registerEvent calls (mouseDown, ....). So maybe another components have the same problem.

The new options implemented here don't work until the problem is fixed.

It would be useful a scaleMode property in the Image component.

Actually, you have maintainAspectRatio in the ImageLayout class, but it is private.
The scaleMode property can have the next values:

Example values:

Resource = 2000x2000
Image component = 200x100

• none -> the resource will be 1:1 inside of component. It maintains the aspect ratio. You will see only a partial piece of the resource. The resource will be the original size, 2000x2000.
• fill -> the image fills the component size. It doesn't maintain the aspect ratio. The resource will be scaled to 200x100.
• fit-inside -> It maintains the aspect ratio. The resource will be scaled to be visible completely, 100x100.
• fit-outside -> It maintains the aspect ratio. The resource will be scaled to fill the component completely, 200x200.
• fit-width -> It maintains the aspect ratio. The resource will be scaled to fill the component width completely, in our case 200x200.
• fit-height -> It maintains the aspect ratio. The resource will be scale to fill the component height completely, in our case 100x100.

Also, it could be interesting an imageHorizontalAlign property and imageVerticalAlign property, or something like that, to modify the resource align.

What do you think?

I can implemented it in a PR. You don't need to worry about that if you want :)

Space exists between 2 50% width inside hbox. I tested HTML5 and NME. Both have same space (5 pixels). If the width of column 1 is 100 then the left of column 2 is 105. I think the space to the far right of column 2 (which occurs very little) only appears when slowly resizing html window

Expected Behavior

No space

Media

Test app / minimal test case

BlankTemplate.zip

textfileds dont wrap at given size.

Expected Behavior

If a textfiled is given a particular width then the text should wrap when its width its that

Current Behavior

Textfiled has 1 line and just continues to right forever

Possible Solution

Wrap at width. If textfield has height also then put in scrollbar if height is exceeded (maybe give option)?

Test app / minimal test case

RC_HAXEUI_test.zip

Just click in one of the boxes and type.

Same 4 box layout. I added a tableview to the topleft with 20 items. Scrollbar does not appear for tableview. Also if you resize there is space to the far right of the columns. See image. Remove the table (xml and hx) and everything works.

Odd: Reduce to below 800 width and the scrollbar appears! but it is small?

Expected Behavior

Scrollbar should appear and squares should still work

Test app / minimal test case

ContinioiusTest.zip

Your Environment

HTML5 and NME windows tested

1. https://github.com/haxeui/haxeui-core/blob/master/haxe/ui/components/Label.hx#L20-L22

Doesn't work in Flixel because the ComponentBase doesn't extend flash.display.Sprite where mouseChildren comes from.

2. Edit: ah, there's a todo for it down here: https://github.com/haxeui/haxeui-core/blob/master/haxe/ui/components/Label.hx#L83-L86

3. https://github.com/haxeui/haxeui-core/blob/master/haxe/ui/components/Label.hx#L100-L101

textWidth comes from flash.text.TextField rather than from TextDisplay

It would be nice to improve the binding system in a more flexible way.

Current Behavior

Actually, we have:

<hslider id="widthSlider" max="280" value="200"/>
<label id="widthLabel" text="???" styleNames="valueLabel"
       bindTo="widthSlider" bindTransform="${MathUtils.round(value, 2)}"/>

Proposal

<hslider id="widthSlider" max="280" value="200"/>
<label id="widthLabel" text="{ MathUtils.round(widthSlider.value, 2) }" styleNames="valueLabel"/>

Any expr between { } should be interpreted as bindable. If the user uses a non-bindable property then a compile warning should be visible (just it will work as a simple assignation without bind).
If you think about that, it is cleaner and powerful, and it allows multiple properties with different targets. For example, you can do:

<checkbox id="labelVisibleCB" text="Label Visible"/>
<hslider id="minSlider" min="0" max="100" value="50"/>
<hslider id="maxSlider" min="200" max="300" value="250"/>
<hslider id="selectSlider" min="{ minSlider.value }"
                        max="{ maxSlider.value }" 
                        value="200"/>

<label id="sliderValueLabel" text="{ MathUtils.round(selectSlider.value, 2) }" visible="{ labelVisibleCB.value }"/>
<label text="Value > 200" visible="{ selectSlider.value > 200 }"/>

The bindx2 library could be a good start point.

I decided to give HaxeUI a whirl out of curiosity today, but I have come across a rather unusually unresponsive window.

The code I am using is a relatively simple example, similar to that in the README:

package;

import haxe.ui.components.Button;
import haxe.ui.containers.VBox;
import haxe.ui.core.Screen;
import openfl.display.Sprite;
import openfl.Lib;
import haxe.ui.Toolkit;

class Main extends Sprite 
{

    public function new() 
    {
        super();

        Toolkit.init();

        var main = new VBox();

        var btn1 = new Button();
        btn1.text = "Some Text";
        main.addComponent(btn1);

        Screen.instance.addComponent(main);
    }

}

I've narrowed down the issue to the addComponent on the main VBox object which causes the client to freeze. By commenting out that line, everything works as normal. A VBox is supposedly added to the screen, but I'm not seeing one ;) I'm assuming that is deliberate.

Let me know if you need any additional information.

Currently DataSource<Dynamic> can accept anything, however, the item renderers are expecting a "proper" anonymous object, for example: {text: "..."}. This causes problems when directly adding strings (or other "native" types).

Expected Behavior

You should be able to use myListView.dataSource.add(...) with "native" non anon object types

Possible Solution

Since it shouldnt be the responsibility of the data source to normalise this data, the listview, or table view must. It should convert Strings/Int/Float/etc values into either {text: ...} or {value: ...} (or both).

Test app / minimal test case

var listView = new ListView();
listView.dataSource.add({text: "Item 1"});
listView.dataSource.add("Item 2");
listView.dataSource.add(1);
listView.dataSource.add(1.2);
listView.dataSource.add(true);
Screen.instance.addComponent(listView);

I have some components defined in XML. During a button click I remove previous component and add new component. Both are VBox components. When new component is added nothing appears, and there are no errors. The only code that appears to get run is "v = _contents.addComponent(child);". Everything else does not apply.

In order to get it to work I change ScrollView.hx at line 100 from

if (Std.is(child, HScroll) || Std.is(child, VScroll)) {
to
if (Std.is(child, HScroll) || Std.is(child, VScroll) || Std.is(child, VBox) || Std.is(child, HBox) ) {

This, however, seems to break the Dropdown component that you added recently. I am not sure my fix is the best approach

Add codeclimate to all relevant haxeui repos.

• haxeui-core
• haxeui-openfl
• haxeui-flambe
• haxeui-kha
• haxeui-html5 - mostly working, regexp issue around method names
• haxeui-pixijs
• haxeui-nme
• haxeui-luxe
• haxeui-hxwidgets
• haxeui-xwt

There is currently an issue with haxe-checkstyle not seeming to work on CC, but working with checkstyle locally is fine until this is resolved (HaxeCheckstyle/haxe-checkstyle#320)

Using the example. Slowly resize the window. It seems to happen on window reduction. You should see a space appear on the right side. I think this only happens in JS/HTML as the CPP resize may be quicker?

Expected Behavior

Space should not appear

Media

Test app / minimal test case

BlankTemplate.zip](https://github.com/haxeui/haxeui-core/files/475194/BlankTemplate.zip)

Expected Behavior

The program should run.

Current Behavior

After compiling the app with "haxe build.hxml", and running with "neko client.n", I'm getting this error:

fulopm@pc:~/haxeprojects/client$ neko client
ThemeManager.hx:56: WARNING: could not find styles/main.css
Parser.hx:1107: Invalid value #E6E6E6 for css background
Parser.hx:1107: Invalid value #F1F1F1 for css background
Parser.hx:1107: Invalid value #C2C2C2 for css background
Parser.hx:1107: Invalid value #D4DEE8 for css background
Parser.hx:1107: Invalid value #DEE8F2 for css background
Parser.hx:1107: Invalid value #B4BEC8 for css background
Parser.hx:1107: Invalid value #FFFFFF for css background
Parser.hx:1107: Invalid value #E6E6E6 for css background
ThemeManager.hx:56: WARNING: could not find styles/default/main.css
Called from util.SharedConstants::$statics line 1
Called from Main::main line 10
Called from ui.UI::$init line 8
Called from a C function
Called from ui.UI::new line 16
Called from haxe.ui.HaxeUIApp::ready line 16
Called from haxe.ui.HaxeUIApp::init line 24
Called from haxe.ui.Toolkit::init line 46
Called from haxe.ui.Toolkit::get_screen line 69
Called from haxe.ui.core.Screen::get_instance line 35
Called from haxe.ui.core.Screen::$init line 26
Called from a C function
Called from haxe.ui.core.Screen::new line 46
Called from a C function
Called from haxe.ui.backend.ScreenBase::new line 18
Uncaught exception - Invalid field access : scaleMode

Steps to Reproduce (for bugs)

1. Use my code, and compile it to Neko target. (build.hxml)
2. Run the compiled Neko file, and you'll get invalid field access as described before.

Test app / minimal test case

Included in the "Steps to Reproduce"

Your Environment

HaxeUI is V2 of course.
OS: Lubuntu 16.04 x64
neko: 2.1.0
haxe: 3.2.1
openfl: 4.0.3-Ldfc8L
lime: 3.0.3

Its possible (and valid) for certain config files (like native.xml) to exist on the classpath, but are nothing to do with haxeui.

Expected Behavior

These files should be parsed but not cause any issue if they dont contain the correct information.

Current Behavior

Unknown - im fairly certain that they wouldnt cause issues, but this needs to be verified.

Steps to Reproduce (for bugs)

1. add a native.xml to the classpath
2. create content that isnt haxeui related

Additional

It would also be a good time to test how the failure mechanisms work; so creating malformed xml in a native.xml should also not break anything, but possibly issue a warning.

This may be related to #12
A dynamically added component cant be removed. I did not look into xml based creations. I tested in html5, nme (flash and CPP).

Clicking the click me button twice will cause browser to hang since .

Expected Behavior

I would expect that the number of childComponents would be reduced immediately if removeComponent(component) is called

Current Behavior

childComponents.length remains the same. For example 1 before removal and 1 after

Test app / minimal test case

Attaching sample project
Small.zip

It would be advantageous to allow custom layouts to be able to registered via module.xml and subsequently used in components like ScrollView and ListView.

Current Behavior

Currently layouts are hardcoded in LayoutFactory meaning adding new ones requires changes to the core. Also, once a layout is applied to a component (like ScrollView) there is no way to configure specific properties for that layout without creating a new component and adding props to it.

Possible Solution

Firstly, modules (module.xml) should be allowed to register layouts as follows (much like components section):

<module>
    <layouts>
        <layout package="foo.layouts" />
        <layout class="foo.layouts.MyLayout" alias="myOtherLayout" />
    </layouts>
</module>

Secondly, a new layoutProperties property should be added to relevant components that allow configuration of any layout without the need for creating new properties on the component.

Test app / minimal test case

In the end, things like this should be possible (assuming there is a myLayout layout registered):

MyFancyView extends ListView { // currently this is the only way to do things
    public function new() {
        _layout = new foo.layouts.MyLayout()
    }
    public function set_myLayoutProp(value) {
        cast(_layout, foo.layouts.MyLayout).myLayoutProp = value;
    }
}

<myFancyView myLayoutProp="10" />
<listview layout="myFancyLayout" layoutProperties="myLayoutProp: 10" />
<scrollview layout="myFancyLayout" layoutProperties="myLayoutProp: 10" />

Note: the "recommended" way is still the first, ie, create a custom component and add props as it leads to nicer xml, however, the other method adds flexibility - also, the two methods arent mutually exclusive either.

The reposition children in HorizontalLayout or VerticalLayout isn't good enough if the spacing = 0px.

Here the code:

<hbox width="100%" height="100%">
    <style source="../css/main.css" />

    <button text="1" width="20%"/>
    <button text="2" width="20%"/>
    <button text="3" width="20%"/>
    <button text="4" width="20%"/>
    <button text="5" width="20%"/>
</hbox>

I'm using the OpenFL backend. Possibly others backends could have the same problem.

Expected Behavior

With spacing = 0px, it should be the components together.

Current Behavior

Sometimes it has 1 spacing pixel between some components.

Possible Solution

The problem is OpenFLStyleHelper.hx. It uses the Math.fround function, and it isn't taken in account in the horizontal layour or vertical layout. So the position differs between the core and the backend.

Adding xpos = Math.fround(xpos); after HorizontalLayout.hx#L37 do the trick. But you could have problems because the sum of all width children != componentWidth.

Steps to Reproduce (for bugs)

1. Resize the window width to check the different positions.

Media

Test app / minimal test case

buttoncontainer-floor-problem.zip

Context

I'm creating a ButtonBar component (I will share with you in a PR soon) with 0px spacing by default.

Your Environment

HaxeUI git + OpenFL 4.3.0

Currently when doing things like:

<vbox backgroundColor="123456" />

You have to use an int representation of the colour.

Expected Behavior

You should be able to use colour names (ie, "red") as well as a hex values (ie, "#FF0000").

Test app / minimal test case

<vbox width="100" height="100" borderColor="red" backgroundColor="#0000FF" borderSize="5" />

Testing scale in NME, openfl. I compile the project at scale 1 and it works.

1. At 1 scale it works
2. At 4 scale it doesn't work. I was trying to get to 4 to scale for android. Which seems close

In HTML outputs (PIXI, HaxuiHtml, OpenflHTML) the scale isnt constrained to the root width/height. If you have width/height at 100% a scale of 2 scale beyond browser window

From NME crash at 2
Lib.hx:90: Error creating window: ({ width => 800, height => 600, flags => 12, title => ContinioiusTest, icon => null, color => 16777215 }) Null Object Reference Called from haxe.ui.layouts.HorizontalContinuousLayout.repositionChildren (haxe/ui/layouts/HorizontalContinuousLayout.hx line 69) Called from haxe.ui.layouts.Layout.refresh (haxe/ui/layouts/Layout.hx line 31) Called from haxe.ui.core.Component.invalidateLayout (haxe/ui/core/Component.hx line 1563) Called from haxe.ui.core.Component.resizeComponent (haxe/ui/core/Component.hx line 1044) Called from haxe.ui.layouts.DefaultLayout.resizeChildren (haxe/ui/layouts/DefaultLayout.hx line 27) Called from haxe.ui.layouts.Layout.refresh (haxe/ui/layouts/Layout.hx line 28) Called from haxe.ui.core.Component.invalidateLayout (haxe/ui/core/Component.hx line 1563) Called from haxe.ui.core.Component.resizeComponent (haxe/ui/core/Component.hx line 1044) Called from haxe.ui.layouts.DefaultLayout.resizeChildren (haxe/ui/layouts/DefaultLayout.hx line 27) Called from haxe.ui.layouts.Layout.refresh (haxe/ui/layouts/Layout.hx line 28) Called from haxe.ui.core.Component.invalidateLayout (haxe/ui/core/Component.hx line 1563) Called from haxe.ui.core.Component.resizeComponent (haxe/ui/core/Component.hx line 1044) Called from haxe.ui.layouts.DefaultLayout.resizeChildren (haxe/ui/layouts/DefaultLayout.hx line 27) Called from haxe.ui.layouts.Layout.refresh (haxe/ui/layouts/Layout.hx line 28) Called from haxe.ui.core.Component.invalidateLayout (haxe/ui/core/Component.hx line 1563) Called from haxe.ui.core.Component.resizeComponent (haxe/ui/core/Component.hx line 1044) Called from haxe.ui.core.Component.set_componentWidth (haxe/ui/core/Component.hx line 1154) Called from haxe.ui.core.Component.set_width (haxe/ui/core/Component.hx line 1186) Called from haxe.ui.backend.ScreenBase.onStageResize (haxe/ui/backend/ScreenBase.hx line 75) Called from haxe.ui.backend.ScreenBase.addComponent (haxe/ui/backend/ScreenBase.hx line 60) Called from haxe.ui.core.Screen.addComponent (haxe/ui/core/Screen.hx line 51) Called from haxe.ui.HaxeUIApp.addComponent (haxe/ui/HaxeUIApp.hx line 29) Called from Main.main (Main.hx line 30) Called from haxe.ui.backend.AppBase.init (haxe/ui/backend/AppBase.hx line 13) Called from haxe.ui.HaxeUIApp.init (haxe/ui/HaxeUIApp.hx line 25) Called from haxe.ui.HaxeUIApp.ready (haxe/ui/HaxeUIApp.hx line 16) Called from Main.main (Main.hx line 23) Called from ApplicationMain.main (ApplicationMain.hx line 182)
From OpenFL carsh at 2
Called from Main::main Main.hx line 23 Called from haxe.ui.HaxeUIApp::ready haxe/ui/HaxeUIApp.hx line 16 Called from haxe.ui.HaxeUIApp::init haxe/ui/HaxeUIApp.hx line 25 Called from haxe.ui.backend.AppBase::init haxe/ui/backend/AppBase.hx line 13 Called from Main::main Main.hx line 30 Called from haxe.ui.HaxeUIApp::addComponent haxe/ui/HaxeUIApp.hx line 29 Called from haxe.ui.core.Screen::addComponent haxe/ui/core/Screen.hx line 51 Called from haxe.ui.backend.ScreenBase::addComponent haxe/ui/backend/ScreenBase.hx line 65 Called from haxe.ui.backend.ScreenBase::onContainerResize haxe/ui/backend/ScreenBase.hx line 80 Called from haxe.ui.core.Component::set_width haxe/ui/core/Component.hx line 1186 Called from haxe.ui.core.Component::set_componentWidth haxe/ui/core/Component.hx line 1154 Called from haxe.ui.core.Component::resizeComponent haxe/ui/core/Component.hx line 1044 Called from haxe.ui.core.Component::invalidateLayout haxe/ui/core/Component.hx line 1563 Called from haxe.ui.layouts.Layout::refresh haxe/ui/layouts/Layout.hx line 28 Called from haxe.ui.layouts.DefaultLayout::resizeChildren haxe/ui/layouts/DefaultLayout.hx line 27 Called from haxe.ui.core.Component::resizeComponent haxe/ui/core/Component.hx line 1044 Called from haxe.ui.core.Component::invalidateLayout haxe/ui/core/Component.hx line 1563 Called from haxe.ui.layouts.Layout::refresh haxe/ui/layouts/Layout.hx line 28 Called from haxe.ui.layouts.DefaultLayout::resizeChildren haxe/ui/layouts/DefaultLayout.hx line 27 Called from haxe.ui.core.Component::resizeComponent haxe/ui/core/Component.hx line 1044 Called from haxe.ui.core.Component::invalidateLayout haxe/ui/core/Component.hx line 1563 Called from haxe.ui.layouts.Layout::refresh haxe/ui/layouts/Layout.hx line 28 Called from haxe.ui.layouts.DefaultLayout::resizeChildren haxe/ui/layouts/DefaultLayout.hx line 27 Called from haxe.ui.core.Component::resizeComponent haxe/ui/core/Component.hx line 1044 Called from haxe.ui.core.Component::invalidateLayout haxe/ui/core/Component.hx line 1563 Called from haxe.ui.layouts.Layout::refresh haxe/ui/layouts/Layout.hx line 31 Called from haxe.ui.layouts.HorizontalContinuousLayout::repositionChildren haxe/ui/layouts/HorizontalContinuousLayout.hx line 69

Media

Test app / minimal test case

ContinioiusTest.zip

A hbox height will grow depending on its contents. Inside an table - item renderer it does not.

Expected Behavior

I would expect it to grow the height of the row

Current Behavior

It current has 1 line of text

Media

Test app / minimal test case

I can provide test app but I would have to make it. Perhaps this is enough

<?xml version="1.0" encoding="utf-8" ?> <tableview width="100%" height="100%" id="home_recent_records"> <header style="height: auto;width:100%;"> <column id="Id" text="Id" width="150" height="100%" sortable="true" /> <column id="Name" text="Filename" width="150" sortable="true" /> </header> <itemrenderer> <label width="100%" id="Id" style="color:#000000" /> </itemrenderer> <itemrenderer width="100%"> <hbox style="width:10%;height: auto;"> <label style="height: auto;color:#000000" text="ICON" /> <label id="Name" style="height: auto;width:100%;color:#000000" text="crapsa asoasdfoisadfuoshd fshadf siadufasdfo usda fhasuodf ioasduas dhfouasdhfouasdfh iasudfh u" /> </hbox> </itemrenderer> </tableview>

I'm curious why ID is a string, when on lines 58-98 of DialogOptions set the id of each standard button with an Integer, but as a string. From a performance perspective, matching strings is slower than matching integers.

Take the following example code:

private static function showBasicDialog(view:Component, onOk:Function = null)
{
    var options = new DialogOptions();
    options.addStandardButton(DialogButton.OK);
    options.addStandardButton(DialogButton.CANCEL);

    Screen.instance.showDialog(view, options, function(b:DialogButton) {
        if (b.id == '${DialogButton.OK}')
        {
            if (onOk != null)
                onOk();
        }
    });
}

It wouldn't affect many of the comparisons, but for YES and NO there's two character comparisons instead of one since they're two digits in size.

When adding columns to a header the header disappears when all of the heights are 100%. This seems to be the case for all outputs tested

Expected Behavior

The headers fit to highest header height

Current Behavior

headers disappear

Possible Solution

Current solution is to have one column have no height defined

Media

<column id="Id" text="Id" width="50%" height=100% sortable="true" />

<column id="Id" text="Id" width="50%" sortable="true" />

Since it didnt have one before
ContinioiusTest.zip

Not sure if this is a bug though. height:auto works.

git/haxe/ui/components/TextField.hx:97: characters 16-40 : haxe.ui.core.TextInput has no field textAlign git/haxe/ui/components/Label.hx:68: characters 16-42 : haxe.ui.core.TextDisplay has no field textAlign

When adding to a datasource strings that start with numbers get truncated to number

Expected Behavior

Whole string should appear

Current Behavior

Truncated to first numbers

Test app / minimal test case

HaxeUITableTest.zip

Line 33 should add "111crapsa asoasdfoisadfuoshd fshadf siadufasdfo usda fhasuodf ioasduas dhfouasdhfouasdfh iasudfh u" to the table. Instead all you see is "111"

I just tried to position a button on the screen.

{...    
    button.left = button.top = 4;
    someAbsoluteContainerThingy.addComponent(button);
...}

This didn't work so i stepped through the code and noticed the if (_ready == false) return in Component.moveComponent. Just swapping the 2 lines in my code (addComponent() before assigning left + top) did the trick.

Expected Behavior

It would be nice to be notified about the missing layout.

Current Behavior

The code silently fails / doesn't do as i expected.

Possible Solution

Notify me if i'm being stupid or do stuff differently than expected. Adding logging/assertions would go a long way in these situations. This should probably be enabled by default for debug/development builds but also removable for release build.

public function moveComponent(left:Null<Float>, top:Null<Float>) {
    if (_ready == false) {
        usage_log('moveComponent for "${id}" requires an assigned parent container');
        return;
    }
}

Expected Behavior

Build should pass.

Current Behavior

Build fails with errors originating at multiple positions in the output source code. These errors are caused by the use and extension of several generic interfaces in component classes.

Sample error message:

<path-to-project>\HaxeUIApp\src\haxe\ui\containers\Box.java
error: IClonable cannot be inherited with different arguments: <haxe.ui.containers.Box> and <haxe.ui.core.Component>
error: incompatible types: Box cannot be converted to VBox
error: incompatible types: Box cannot be converted to VBox

Complete error log can be found here.

Possible Solution

From Java's perspective, it is illegal for a class to extend different instances of the same generic interface. Java's generics are implemented at compile time through type erasure. Extending different instances of one generic interface means creation of duplicate bridge methods, and also leads to type casting issues.

A possible solution could lie in bounded type parameters. However, this seems like a Java solution more than a Haxe one.

Issue might be related to HaxeFoundation/haxe#2280, but I'm not sure how much of this is caused by the way Java sources are generated.

Steps to Reproduce (for bugs)

1. Set up haxeui-kha.
2. Download the haxeui-kha skeleton project from the templates repository.
3. Build for Android.

Your Environment

• Version used: Latest haxeui-core and haxeui-kha
• Environment name and version (e.g. Chrome 39, node.js 5.4): Android Studio 1.5.1, JDK1.8.0_73
• Operating System and version (desktop or mobile): Windows 10 64bit

Scrollbar wont release when registrEvent MOUSE_UP applied.

Expected Behavior

When mouse up occurs the scroll should release

Steps to Reproduce (for bugs)

1. Compile sample app
2. make sure the list needs to scroll
3. click on thumnb and slide it up and down
4. release mouse

Media

After mouse is up you can see it is still highlight like it is tracking

Test app / minimal test case

BlankTemplate.zip

Some data is not copied when copying a component. 2 part issue?

1. A component needs to be added to a screen instance or the copy will not include styles. I only tested this on html
2. Data tag on a dropdown was not copied (data was in XML). Value attribute of a textfield (in xml) was not copied

Expected Behavior

All data to be copied

Test app / minimal test case

RC_HAXEUI_test.zip

Currently the DropDown always uses a ListView as the component that is shown when the button is clicked. It would be advantageous to make this a little more flexible. ListView can (and should) still be the default, however, a number of other types could also be used (for example TableView or something totally custom)

Expected Behavior

Expect to be able to use the DropDown as is and show a ListView or specify a .dropDownType property and have some type of factory system to create a component of any type.

Current Behavior

Currently it is always a ListView

Possible Solution

Firstly an interface could be created, IDropDownPopup (or similar):

interface IDropDownPopop {
    public var popupSize(get, set):Int; // way to set the number of items, ie, '4' - can be ignored if not relevant, 
}

A factory (with the ability to register new classes) could be added so things like this work:

DropDownPopupFactor.register("myCustom", MyCustomPopupClass);
var c = DropDownPopupFactory.create("table"); // would return a TableView
var c = DropDownPopupFactory.create("myCustom"); // would return something previously registered

Finally in the xml (or directly in code), this would apply:

<dropdown dropDownType="table" />
<dropdown dropDownType="myCustom" />

Note: these IDropDownPopop instances would work with datasources (if needed)

Test app / minimal test case

<dropdown />
<dropdown dropDownType="table" />
<dropdown dropDownType="myCustom" />

Note: things like listHeight, listWidth & listSize should be renamed to something more appropriate, eg: dropDownHeight, dropDownWidth & dropDownSize

Expected Behavior

Adding a stopPropagation():Void function to UIEvent (I guess) that'll prevent the event from reaching another component higher in the parenting chain.

Current Behavior

Currently when clicking on a component its parent will also receive the onClick event without possibility to stop it.

Not sure if the parent's parent also receive the event and if this only apply to components or containers also.

Context

Using this to let the user select a component to edit its properties,
currently the event will be received on the topmost parent last and it'll be like the user missed.

Expected Behavior / Possible Solution

Having an invalid name/value for a css property should raise a warning or build failure.
"property x/value y from file.css line n is invalid and will be ignored"

Current Behavior

Nothing happens, line is ignored.

Test app / minimal test case

Having the css

.selected {
  border: 1px solid green;
  foo: bar;
  color: lightgreen;
}

If the style "selected" is applied to a component it'll have a green border but the two other css lines are ignored.

testCss.tar.gz

Your Environment

Latest git version used, 12965ff and haxeui/haxeui-html5@58225bf
Tested using haxeui-html5 on firefox 47 linux 64.

Currently the haxeui Component has a clipRect property that defines a clipping rectangle, the type of which is a haxe.ui.utils.Rectangle. This however, clashes with HaxeFlixel as FlxSprite also defines this property (with a type of FlxRect) and the component inheritance would be such that:

Component extends ComponentBase extends FlxSprite

(for a haxeui-flixel backend).

This obviously causes a conflict, the path of least resistance is to rename the property in haxeui-core to something that doesnt clash. Possibilities are:

• cropRect
• trimRect
• snipRect
• sliceRect
• cutRect

If you have a table inside of a scrollview. Use the scroll wheel when over the table scrolls both the table and the scrollview

Expected Behavior

Just the table scrolls

Current Behavior

Both scroll

Test app / minimal test case

ContinioiusTest.zip

Your Environment

html5, nme

I want 2 different lays depending on the width of application. Tested in HTML, NME , and openfl

Width >= 800
4 squares with 50% width and 50% height that fill the screen.

width<800
4 stacked squares with width 100% and 50% height. This would cause 2 squares to be out of view.
I would like a scrollbar to appear in this case.

Current Behavior

Issue 1: the squares are not getting correct % height so no continuous wrapping appears.

Issue2: Resize causes crash
OpenFL Flash and NME flash
ReferenceError: Error #1056: Cannot create property percentWidth on haxe.ui.containers.VBox. at Main/resizeMe()[C:\Users\some.guy\Desktop\Haxe\ContinioiusTest\src\Main.hx:42] at haxe.ui.util::EventMap/invoke()[C:\sdks\haxe3\haxe\lib\haxeui-core\git\haxe\ui\util\EventMap.hx:47] at haxe.ui.core::Component/dispatch()[C:\sdks\haxe3\haxe\lib\haxeui-core\git\haxe\ui\core\Component.hx:826] at haxe.ui.core::Component/resizeComponent()[C:\sdks\haxe3\haxe\lib\haxeui-core\git\haxe\ui\core\Component.hx:1051] at haxe.ui.core::Component/set_componentWidth()[C:\sdks\haxe3\haxe\lib\haxeui-core\git\haxe\ui\core\Component.hx:1154] at haxe.ui.core::Component/set width()[C:\sdks\haxe3\haxe\lib\haxeui-core\git\haxe\ui\core\Component.hx:1186] at haxe.ui.backend::ScreenBase/onContainerResize()[C:\sdks\haxe3\haxe\lib\haxeui-openfl\git\haxe\ui\backend\ScreenBase.hx:80]

NME windows (openfl worked like HTML5)
`Main.hx:39: ************* resize stack ***********
Stage.hx:464: Exception: Invalid field:percentWidth

Called from Main.resizeMe (Main.hx line 42)
Called from haxe.ui.util.EventMap.invoke (haxe/ui/util/EventMap.hx line 47)
Called from haxe.ui.core.Component.dispatch (haxe/ui/core/Component.hx line 826)
Called from haxe.ui.core.Component.resizeComponent (haxe/ui/core/Component.hx line 1051)
Called from haxe.ui.core.Component.set_componentWidth (haxe/ui/core/Component.hx line 1154)
Called from haxe.ui.core.Component.set_width (haxe/ui/core/Component.hx line 1186)
Called from haxe.ui.backend.ScreenBase.onStageResize (haxe/ui/backend/ScreenBase.hx line 75)
Called from nme.events.Listener.dispatchEvent (nme/events/EventDispatcher.hx line 32)
Called from nme.events.EventDispatcher.dispatchEvent (nme/events/EventDispatcher.hx line 140)
Called from nme.display.DisplayObject.nmeDispatchEvent (nme/display/DisplayObject.hx line 160)
Called from nme.display.Stage.onResize (nme/display/Stage.hx line 493)
Stage.hx:465:`

Media

Test app / minimal test case

ContinioiusTest.zip

I personally think that the findComponent function in Component, here, should have its recursive parameter set to true by default, because I think that is generally implied when you are looking for an object within the Component you're currently searching.

Otherwise you end up in a situation where you end up with null being returned. A lot of people may miss that if they don't know the codebase of HaxeUI that well, and make the presumption that the findComponent does what you would otherwise expect.

Or, you could remove the recursive function entirely and just make it default behaviour.

Setting the width/height doesnt appear to affect the window

Current Behavior

If you change the height then the window appears taller but the buttons remain at launch position
No effect if you cahnge the width.

Test app / minimal test case

Where accountView is a VBox

var dOptions:DialogOptions = new DialogOptions();
dOptions.title = "Edit Account";
dOptions.addStandardButton(DialogButton.CLOSE);
dOptions.addStandardButton(DialogButton.CANCEL);
var d:Dialog = mainView.screen.showDialog(accountView, dOptions);

d.height = 500;
d.width = 500;

Your Environment

NME and HTML tested

If the resulting ListView of a DropDown doesnt have enough space to be fully visible then it should instead drop up; ie, the list view should appear at the top of the button rather than the bottom.

Expected Behavior

The list should drop up allowing the full ListView to be seen and used.

Current Behavior

Currently the ListView always drops down which is some cases hides parts of the ListView

Possible Solution

Calculate the available space using Screen.instance.height and display the ListView in the appropriate position.

Media

Test app / minimal test case

<?xml version="1.0" encoding="utf-8"?>
<box id="main" width="100%" height="100%" style="padding:50px;">
    <dropdown text="Select Item" width="250" style="vertical-align:bottom;horizontal-align:right">
        <itemrenderer width="100%">
            <hbox width="100%">
                <image id="icon" style="vertical-align:center;" />
                <checkbox id="value" style="vertical-align:center;" />
                <label id="text" width="100%" style="vertical-align:center;" />
                <button text="Action 1" />
            </hbox>
        </itemrenderer>
        <data>
            <item text="List item 1" value="true" icon="haxeui-core/styles/default/dialogs/cross-circle-small.png" />
            <item text="List item 2" value="false" icon="haxeui-core/styles/default/dialogs/question-small.png" />
            <item text="List item 3" value="true" icon="haxeui-core/styles/default/dialogs/exclamation-small.png" />
            <item text="List item 4" value="false" icon="haxeui-core/styles/default/dialogs/information-small.png" />
            <item text="List item 5" value="true" icon="haxeui-core/styles/default/dialogs/information-small.png" />
        </data>
    </dropdown>    
</box>

It would be nice to have the ability for haxeui core to also be able to process .less and .sass files as part of the module processing. This would mean that .less or .sass files could be used in the <themes> section and auto compiled to .css (assuming lessc or sass was available - if its not available it should fail gracefully and simply ignore the entry)

Assuming this is implemented and working the default theme should also be rewritten to use .less/.sass files, however, it should also ship with the generated .css files (for users who dont have lessc or sass installed).

Apart from variables and imports this could have quite a large impact of allowing a new theme (that would extend the default theme) to simply override a, say vars.less file which contain a list of colours and metrics (border-size, border-radius, etc) meaning a visually different theme could be created with very little effort by simply (re)defining vars in the default theme.

Ive already checked with the lessc and sass compiler and custom css attributes are totally fine (which is 100% required).

Finally, it would be important to not actually link this to either less or sass but have a generic way to run "style plugins" defined in module.xml to be run at compile time. This would allow other pre-processors not defined in haxeui-core to be run