How to load fonts embedded by lime build?

[greysondn]

Specifically for a Label.

I've tried quite the number of things:

• Setting font-family in a css file for the XML I'm loading

• Setting a style with path to the font face, relative, trying several different times

• Reaching into the label's dirty underside and setting the computed style's font to the path to the font

The font is on my asset path; it's actually the TTF for Hack. I know it's embedding properly; other parts of the project waiting for me to migrate their UI library are using it.

Little help, please?

Haxelib state in case any of them matter.

C:\windows\system32>haxelib list
flixel-addons: 2.7.1 [2.7.3]
flixel-demos: 2.6.1 [2.7.0]
flixel-templates: 2.5.3 [2.5.4]
flixel-tools: 1.4.2 [1.4.3]
flixel-ui: 2.3.1 [2.3.2]
flixel: 4.5.1 [4.6.0]
flxscrollablearea: [0.4.0]
haxeui-core: [0.0.3] 0.0.4
haxeui-flixel: [0.0.0]
haxeui-openfl: [0.0.2]
hscript: [2.3.0]
hxcpp-debug-server: [dev:c:\Users\Dorian Greyson\.vscode\extensions\vshaxe.hxcpp-debugger-1.2.0\hxcpp-debug-server]
hxcpp: 4.0.4 [4.0.8]
lime-samples: [7.0.0]
lime: 7.2.0 [7.2.1]
openfl: 8.7.0 [8.8.0]
yaml: [1.3.0]

[ianharrigan]

Hi, any chance you could create a small sample that doesnt work? That would help speed up understanding / resolution of the issue. Also, do you know how to use git versions of haxelibs? As well as git branches as haxelibs?

Cheers,
Ian

[ianharrigan]

I did manage to get this working with minimal ease:

But it may be likely that im doing it in a different way to how you are trying, and also, im on a totally different branch / version to you, so having a test project would be a great help.

Cheers,
Ian

[greysondn]

ianharringan, I'm rather not a fan of the bleeding edge (a long conversation I've had in the discord before). Given a free choice, I'd prefer not to. Regardless, I was waiting for your merge that's due in before updating things - trying to minimize the number of things that I have against a moving target.

The attached project is designed for vs-code. I've been targeting HTML for testing, but my final build target (thanks a lot, bad platform support) is Flash right now.

eli-1.zip

---

edit: What is more likely is that I failed to find documentation and have guessed, and guessed incorrectly. I hope that's the case, anyway.

Also if 9-slices work in this version (on the flixel backend), that's a second thing I'm dying to know at the moment, granting it's a different issue.

[ianharrigan]

Ok, thanks for the project, i think the issue is the name in the css font-family... it should be font-name... eg:

.label {  /* NOTE: this will change _all_ labels */
    font-name: "assets/fonts/hack.ttf"; 
}

Let me know if that is the issue, if it is then i going to start to allow font-family also, as its not the first time ive had people have issues like that. I didnt use font-face as its not html style css, but really, it doesnt make any difference, and in reality, its causing problems / misunderstandings.

9-slice may work on your version, im not 100% sure - and its hard for me to check at the moment as im on a different branch with a fair amount of files checked out. I can assure you that 9-slice does work on the branch im working on (new-component-method).

Finally, i totally appreciate you aversion to "cutting edge", im actually quite similar myself - so thats fine. But just to let you know that haxelib version you seem to be using is woefully out of date, even master branch of haxe-core is 500-and-something commits behind new-component-method, so in this case, i would personally advise that you consider switching to the new-component-method branch (both haxeui-core and haxeui-flixel - i can walk you through the process, its painless and you can always just go back to the haxelib version anytime you want).

There are more components, they are better, faster and in general, i think your whole HaxeUI experience will go alot smoother - plus keep in mind that this will become master / haxelib at somepoint (fairly soonish), so if your code does break with it, it will break when it gets to haxelib also - anyway, just my thoughts on it - the choice, ofc, is yours :)

Let me know if the original issue is fixed!

Cheers,
Ian

[greysondn]

That doesn't seem to be a fix in HTML5.. or in Flash... However...

Can I slam my head against a desk and concede defeat? I'd rather keep with Haxelib versions... but it seems this isn't going to be a sustainable option for the way haxeui's release cycle is working. (Well, I'd call it a release cycle; it may be fair to say that's not the model it's working under. I wouldn't know.)

If I can at least lock to a specific git commit, I'll try a version you believe is stable on both counts out of your repos. Even if that's the current one. Mostly, I don't want to have a codebase that doesn't show what it's linked against - would drive me crazy if I ever had to look backwards for any reason.

I'll probably also be able to finally upgrade Haxe to 4.0 and get my autocompletion hooks back, the way Gama11 was talking before. I'm still on 3.something-or-other. Edit: Guess what else isn't in stable release status...

---

The cause of that choice - as opposed to, for example, font-face or font-name (my brain tried to go font-face, for the record) - is due to what I can only guess is the built-in autocompletion suggestions for CSS in vs-code.

That scrolls down a little further, but at any rate...

Well, no, that's not all. It even complains about using a compliant name!

[greysondn]

With haxeui-flixel:new-component-method and haxeui-core:master

> Executing task: lime test html5 -debug <

C:/HaxeToolkit/haxe/lib/haxeui-flixel/git/haxe/ui/backend/ScreenBase.hx:8: characters 7-32 : Type not found : haxe.ui.events.MouseEvent
The terminal process terminated with exit code: 1

Terminal will be reused by tasks, press any key to close it.

With haxeui-flixel:new-component-method and haxeui-core:new-component-method

> Executing task: lime test html5 -debug <

C:/HaxeToolkit/haxe/lib/haxeui-flixel/git/haxe/ui/backend/ComponentBase.hx:216: characters 2-23 : Class<haxe.ui.events.MouseEvent> has no field MOUSE_OVER
C:/HaxeToolkit/haxe/lib/haxeui-flixel/git/haxe/ui/backend/ComponentBase.hx:217: characters 2-22 : Class<haxe.ui.events.MouseEvent> has no field MOUSE_OUT
C:/HaxeToolkit/haxe/lib/haxeui-flixel/git/haxe/ui/backend/ComponentBase.hx:218: characters 2-23 : Class<haxe.ui.events.MouseEvent> has no field MOUSE_DOWN
C:/HaxeToolkit/haxe/lib/haxeui-flixel/git/haxe/ui/backend/ComponentBase.hx:219: characters 2-21 : Class<haxe.ui.events.MouseEvent> has no field MOUSE_UP
C:/HaxeToolkit/haxe/lib/haxeui-flixel/git/haxe/ui/backend/ComponentBase.hx:220: characters 2-18 : Class<haxe.ui.events.MouseEvent> has no field CLICK
C:/HaxeToolkit/haxe/lib/haxeui-flixel/git/haxe/ui/backend/ComponentBase.hx:221: characters 2-23 : Class<haxe.ui.events.MouseEvent> has no field MOUSE_MOVE
C:/HaxeToolkit/haxe/lib/haxeui-flixel/git/haxe/ui/backend/ComponentBase.hx:222: characters 2-24 : Class<haxe.ui.events.MouseEvent> has no field MOUSE_WHEEL
The terminal process terminated with exit code: 1

Terminal will be reused by tasks, press any key to close it.

I read haxelib's docs on how to set to git version. No commit pinning still makes me sad.

[ianharrigan]

Those errors are strange... WRT to the commit pinning, just dont use the haxelib git... do something like:

haxelib dev haxeui-core path/to/my/haxeui-core/folder

Then you can just use git outside of haxelib and checkout a specific commit that way.

Ill take a look at those errors, im using it right here now (new-component-method) branch on both core and flixel and all works fine.

[ianharrigan]

also, font-name isnt a 'correct' css property, so vscode would complain, but it shouldnt stop any compilation, anyway, as i mentioned, im going to add font-family also, as this has come up before.

[ianharrigan]

im using haxe-rc1 also, i wonder if that could be the issue? I dont see why though, this stuff was all working fine on haxe 3 and nothing has changed around that area.

[ianharrigan]

@MSGhero - is this similar to the things you noticed? I dont understand why it started all of a sudden and why it doesnt happen with me.

[MSGhero]

I had a lot more errors. Like “Component is unavailable at this time.”

[ianharrigan]

Any resolution to what your issue was, or even, any idea what @greysondn issue might be? I dont understand what the difference is between your two and mine (and others whos's are working fine)

[greysondn]

Before going to sleep last night, I disabled my compilation server so that the object cache would (hopefully) be less of an issue. Still no luck. I'm baffled when it comes to things like this. About all I've got is a willingness to throw myself against a brick wall until it gives.

You seem to assert it should work in at least one of those versions... can you tell me which ones you have set on your system, @ianharrigan , so I can shorten my search space? Namely, which branches of haxeui-flixel and haxeui-core should I be trying?

[greysondn]

Some absurd progress.

First, the distinction between the long list of errors and the short one in my previous comment seems to be related to which version of haxeui-flixel was presently in use; I simply moved the two non-git ones and it started complaining that it couldn't find it, which led me to .current inside my haxelib folder and the fact it was ignoring me and setting itself to 0.0.4 for some reason.

Setting that - by hand - to git made it go from the short list of errors to the long list.

However, it still complained it couldn't find the members in MouseEvent, so I dug into it. Yes, they're there. Okay. So I then dig in my code. Invalidate the cache. No luck. Okay. Must be haxe.

Updated to Haxe 4 RC1... partial success!

You can just barely see the strikes on the zeroes.

Current haxelib for those two seems to be new-comopnent-method. You are not entirely compat with Haxe 3.x in your development version, apparently. I'm unsure of cause.

Next is trying to get that field's width fixed, of course.

[greysondn]

Okay, I'm to dev versions of Flixel, Haxe, and the two HaxeUI libraries.

@ianharrigan can you please take a look at the XML from that code sample and see if you can figure out why it wants text to be so narrow?

[greysondn]

Alright. I've got it about figured, I think, at this point. I don't know what notes you could need that I haven't already given, save one.

No way of trying to set the width in CSS or the XML seemed to work. But if I - in the code in playstate.hx, do this redefinition of a method:

    private function buildUI():Void
    {
        // init ui bg elements
        var bg:FlxSprite = new FlxSprite(0, 0, "assets/ui/css/classic/state-bg-faked.png");
        this.add(bg);

        // init ui loader
        Toolkit.init({ container : uiGroup });
        this.add(this.uiGroup);
        var _ui = ComponentMacros.buildComponent("assets/ui/playstate.xml");
        uiGroup.add(_ui);

        var cout:Label = _ui.findComponent("cout", Label);
        cout.width = 770;
    }

It finally works right. Well, that width can be anything (and I'm going to tweak it a little, I think), but the point is I have to reach into it and actually adjust it manually. For whatever reason, it's not set correctly to parent via XML and macros, or via CSS and macros. In fact, removing part of the XML helps fix the "all run together narrow" problem.

Here is a final, working version of this.

eli-1-fixed.zip

C:\Users\Dorian Greyson>haxe --version
4.0.0-rc.1+1fdd3d59b

C:\Users\Dorian Greyson>haxelib list
flixel-addons: 2.7.1 [2.7.3]
flixel-demos: 2.6.1 [2.7.0]
flixel-templates: 2.5.3 2.5.4 [2.5.5]
flixel-tools: 1.4.2 [1.4.3]
flixel-ui: 2.3.1 [2.3.2]
flixel: 4.5.1 4.6.0 [git]
flxscrollablearea: [0.4.0]
haxeui-core: [git] old
haxeui-flixel: 0.0.0 [git]
haxeui-openfl: [0.0.2]
hscript: [2.3.0]
hxcpp-debug-server: [dev:c:\Users\Dorian Greyson\.vscode\extensions\vshaxe.hxcpp-debugger-1.2.1\hxcpp-debug-server]
hxcpp: 4.0.4 [4.0.8]
lime-samples: [7.0.0]
lime: 7.2.0 [7.2.1]
openfl: 8.7.0 [8.8.0]
yaml: 1.3.0 [fix-your-shit] git

If there's any data you feel I may have in my environment that would be useful to you, don't be afraid to ask. Otherwise... I guess that solves the issue's titular problem, anyway.

[ianharrigan]

Oh, fantastic, so sounds like you got it sorted. Ill look at the other issue (width) shorty. To, just to summarize, the issues was:

1. haxelib wasnt actually using the git versions, even though it said it was
2. haxeui isnt haxe3 compatible, even though i thought it was

That about cover it? This is helpful information for sure - thanks!

Ian

[greysondn]

Ill look at the other issue (width) shorty. [...] That about cover it? This is helpful information for sure - thanks!

I mean, with the obvious caveat that this width thing, haxeui not seeming to do styles properly in at least the flixel backend re:that, is a potential third issue, that sounds correct.

I realize you've probably had a flurry of notifications. I basically set my head to beating against the brick wall until there was nothing but a blood-stained pile of rubble left XD

[ianharrigan]

heh heh, well, i appreciate the brain damage you sustained! Its certainly helpful information, im looking at the width issue now - as for the haxelib issue, i would use haxelib dev, i feel like the git stuff in the haxelib client is a little iffy - ofc this will be less of an issue when new-component-method becomes master and a 1.0.0 release is made (ie, official).

And i was pretty convinced haxeui was haxe3 compatible, i was using it a few weeks ago with it, not sure about haxeui-flixel though - either way, ill either downgrade to 3 or use lix to see about sorting all that...

thanks again!

Ian

[ianharrigan]

Ok, i can confirm - seems some strange things happen in haxeui-flixel with label when it comes to wrapping / width. Im going to try and isolate it and get a minimal example that shows just that issue.

@MSGhero - is this something you can help with? Your knowledge about flixel (and indeed haxeui-flixel) will be useful here in diagnosing / fixing the issue.

Edit: it seems specific to the haxeui-flixel backend btw, my initial tests all seem to work fine on other backends.

[ianharrigan]

Ok, heres the most minimal sample i could create:

<vbox>
    <label id="label1" text="This is fine" style="background-color: green;" />
    <label id="label2" width="100" text="This is still broken, but setting the width in code will make this work (wrap) correctly - this should happen without needing that extra step" style="background-color: yellow;" />
    <label id="label3" width="100" text="This is broken" style="background-color: yellow;" />
    <label id="label4" width="100" text="This is also broken when it should wrap an the height should increase appropriately" style="background-color: red;" />
</vbox>

Then a little code for label2:

var label2 = main.findComponent("label2", Label);
label2.width = 101; // note, needed to set it to 101 simply because the width is 100, so setting it to 100 means it wont update

Output is:

For reference, here is the exact same app using haxeui-html5:

[ianharrigan]

Ok, good news! I can fix it pretty simply:

The issue at the moment is just that i have alot of files checked out (refactoring some things) so wont be able to commit this change until after that, the change is just to remove the if (!tf.autoSize) { check in haxe.ui.backend.TextDisplayBase in the haxeui-flixel backend. eg:

	override function validateDisplay():Void {
		//if (!tf.autoSize) {
			if (tf.textField.width != _width) tf.textField.width = _width;
			if (tf.textField.height != _height) tf.textField.height = _height;
		//}
	}

Ill make this change asap, or in fact, its already changed locally for me, but as i mentioned, it will take a little time to make it into the branch as there are other things im currently working on.

@greysondn - i guess this doesnt bode well for your "pinned commit" methodology... :(

[ianharrigan]

Also, @greysondn - i couldnt resist but i took the liberty of messing around with your app layout, mainly to see if there were any other surprises in store, but i figured i would share the layout i came up with as it may help "expose" a little more the api to you. There is nothing wrong with using <absolute /> of course, but since haxeui has a pretty decent layout system it may be easier to just leverage that and let that do the heavy lifting for you. (Note, this uses the fix i have for the label width stuff):

<vbox id="stagebg" width="850" height="640" style="padding: 16px 9px">
    <style>
        .label {
            color:#000000;
            font-size:16;
            font-name: "assets/fonts/hack.ttf";
        }
    </style>
    <vbox id="container" width="100%" height="100%" style="spacing: 0;">
        <hbox id="header" width="100%" height="56">
            <label text="12:220pm" style="font-size: 32" verticalAlign="center" />
            <spacer width="100%" />
            <label text="27/02/2019" style="font-size: 32" verticalAlign="center" />
        </hbox>

        <vbox id="txtoutput" width="100%" height="100%">
            <scrollview width="100%" height="100%" contentWidth="100%">
                <vbox width="100%">
                    <label id="cout" width="100%">
                        There was just lorem ipsum text here before.

                        Hack has struck zeroes. The Flixel font does not. 0000. and do we know how to wrap? testing testing this should be long enough to wrap

                        There was just lorem ipsum text here before.

                        Hack has struck zeroes. The Flixel font does not. 0000.

                        There was just lorem ipsum text here before.

                        Hack has struck zeroes. The Flixel font does not. 0000.

                        There was just lorem ipsum text here before.

                        Hack has struck zeroes. The Flixel font does not. 0000.

                        There was just lorem ipsum text here before.

                        Hack has struck zeroes. The Flixel font does not. 0000.

                        There was just lorem ipsum text here before.

                        Hack has struck zeroes. The Flixel font does not. 0000.

                        There was just lorem ipsum text here before.

                        Hack has struck zeroes. The Flixel font does not. 0000.

                        There was just lorem ipsum text here before.

                        Hack has struck zeroes. The Flixel font does not. 0000.

                        There was just lorem ipsum text here before.

                        Hack has struck zeroes. The Flixel font does not. 0000.

                        There was just lorem ipsum text here before.

                        Hack has struck zeroes. The Flixel font does not. 0000.
                    </label>
                </vbox>
            </scrollview>
        </vbox>

        <hbox id="txtinput" width="100%" height="56">
        </hbox>

        <hbox id="controls" width="100%" height="128" style="spacing: 10px;padding: 10px;">
            <grid columns="3">
                <button text="Button 1" />
                <button text="Button 2" />
                <button text="Button 3" />

                <button text="Button 4" />
                <button text="Button 5" />
                <button text="Button 6" />

                <button text="Button 7" />
                <button text="Button 8" />
                <button text="Button 9" />
            </grid>
            <vbox>
                <checkbox text="Check 1" />
                <checkbox text="Check 2" />
                <checkbox text="Check 3" />
            </vbox>
            <vbox>
                <optionbox text="Option 1" />
                <optionbox text="Option 2" />
                <optionbox text="Option 3" />
            </vbox>
            <vbox>
                <switch text="Switch 1" />
                <switch text="Switch 1" />
                <switch text="Switch 3" />
            </vbox>
        </hbox>
    </vbox>
</vbox>

[greysondn]

XD It's not that I don't appreciate having the example - and I'm sure I'll be back here again to look over it more carefully. It's mostly that I'm a massive control freak when it comes to laying out UIs. So having exact control over where things go is one of those properties such people exhibit.

I tend to layout the UI long before I actually write the code for it. But what's morbidly hillarious is that you're pretty close to the actual intended layout that will end up with. (It's actually an engine rewrite/port of an explicit text-based adventure game. I've a bad tendency to work in adult sectors for some odd reason XD.)

So that's entertaining XD. And now... I sleep. Hard.

[MSGhero]

I’ll try to remember why I had the condition there in the first place, but yeah it’s fine to change it if it makes stuff work as expected.

The other thing though is that perhaps autosize isn’t being set properly and the condition is correct. I’ll have to see.