Hi,
With Toolkit.scale set to 1 Tooltips appear close to the mouse, everything is good.
When I set Toolkit.scale to 2 Tooltips appear way off. It gets worse the further you get away from 0,0.
Could it be scale gets ignored in the toolkit positioning?
Cheers!
That sounds likely - defo sounds like a bug… my guess, since they get further away is that the position is being (incorrectly) multiplied by the scale - ill have a proper look when i get back from honeymoon (week or so im afraid).
Cheers,
Ian
No problem, have a great honeymoon!
So this should be fixed by this PR: Adjusted tooltip positions to account for scale by turdparty · Pull Request #458 · haxeui/haxeui-core · GitHub - which i suppose is you?
If so, thanks a bunch. If not, it should be fixed in git version of haxeui-core 
Cheers,
Ian
Yes that was me. I’m hoping to get enough time to properly integrate the main git with my own modified version. I’m not used to github but this test seems to have been successful.
There might be some more changes, like core/TextDisplay.get_textHeight(). I always remove the height=0 there because I never want empty labels to be less tall than a label with text. That makes for a very chaotic gui in my opinion. But it was added explicitly so perhaps it has a use I don’t understand. Or perhaps my issue only shows up in an openfl html5 build.
Do you happen to know if it’s possible to use conditional compilation with haxelibs but for names instead of version numbers? Like #if (haxeui_core == “git”) instead of “1.4.0”.
I figured it was - either that or a mind reader of some kind - thanks!
I dont think thats possible (i could be wrong) - im not sure it would help that much either as git would always be changing, maybe it would be more useful against a certain git sha - but i dont think thats possible either (again, i could be wrong). Whats the rational for wanting that?
Can you point me to where that is exactly? It could be a “left over”, i dont think that class has changed in ages - but ill need to review / test before being sure
Do you have a list of changes? I dont really like the idea of forks floating about fixing issues that could / should be in core. Not saying “you shouldnt”, but just its not ideal imo that you have to use a fork for one reason or another - haxeui tends to move fairly fast to having a fork can very quickly mean you are very out of date.
Cheers,
Ian
EDIT: you could also just point me to your fork(s), that could give me a fairly decent heads up also
I’m very out of date, the fork is not in a public vcs. But I’ll try to get the modifications in asap, maybe today. It’s not that much, probably a lot has already been fixed.
For software development I needed a gui-base that wouldn’t change, thus the fork.
The idea behind the git specific compilation is that I’m able to quickly switch back to my very out of date code and make updates for the software, while I’m trying to catch up to the latest version.
You could always just use “haxelib git … …” and then manage that repo manually via git, ie, what commit you want to stay on, dont update it until you are happy, etc - ie, you can pull haxeui commits one by one. Its basically what i do, except i use "haxelib dev … … " and then point to a manually managed git folder. That said, ofc, that doesnt work / makes sense if you have changes you need in core (which it sounds like you do - so id be very interested in what they are and why ).
Cheers,
Ian
Right, I’m still learning git. Never been a fan. Command line interfaces should stay in the past imho, trying github desktop now.
I used haxelib git, but then if you ever type haxelib upgrade, it updates the git libs as well. That’s not great.
I’m in the process of making git work for me. I’ve been very happy with perforce and tortoise-svn, so I’m sure it’ll work out.
Since I’m so outdated I just need to catch up, there are always things that aren’t quite right and probably have been fixed.
For instance there seem to be different mousewheel/touch scroll speeds when in a normal windows vs a dialog window.
I use GitKraken, which i really like:
There shouldnt be - do you mean a haxeui scrollview scrolls at a different speed in a haxeui dialog? There is certainly no “special” code to do anything like that - a scrollview is a scrollview regardless where you put it - i guess maybe minimal repros should be made for each issue you encountered and thus needed your fork - they can then be fixed (or not) on a case by case basis
I might wanna switch to gitkraken, looks nice
Right you are. I’ll get on issues an repro cases as soon as I’m done with the changes.
Ah! I’m noticing listviews no longer show any text? Perhaps not on all build though…
Would you rather have each separate fix as a separate commit, or all in one? Should be less than 10 files.
I guess this depends how out of date you are, it used to be “value”, now its “text” by default in the datasource, if its not that, then must be something else.
I guess it depends on what it fixes, ideally (i suppose), it would be nice to have a minimal “reproduction” test app that shows the problem in current haxeui-core/backend - but i appreciate that might be more effort than its worth. So i guess, lets just wing it
Hm, it’s not a listview but a tableview. Does a Column still have an id? Or did that change?
Yeah repro cases are gonna be a bit much… How about I post a few screenshots before and after the fix?
I’m about done with the changes, they’re small.
Yeah, sure, just describe the issue, screen shots, etc… whatever really - we’ll work it out from there
FYI, the is a haxe discord that has a #haxeui channel, may be easier for this, or here, your call
Alright, so here is the TextDisplay change.
I think the labels without text should be the same height as the ones with text.
The Stepper and Numberstepper changes are just guards against null values.
Scrollview is harder to illustrate though as the scrollbars have gotten smaller and it requires me to stop scrolling the moment a hscroll was created with a vscroll present… You’d end up with a piece of the view falling below the scrollbar.
ok, this feels like it could be a haxeui-openfl issue: Builder - HaxeUI
Tell you what… can we open a new forum post for each one? This will get noisy otherwise.
EDIT: sorry, thats wrong, it does show the issue - im not sure which is better behaviour though… they both seem valid
Sure there can be a discussion about how it looks.
But apart from that it’s very hard to actually click on the component, in case you would want to enter text. So I can’t see it being very practical… except for maybe as a display, still I don’t see the tiny size being helpful, not in this way at least.
Ok, you want separate forum posts? Or issues on github?
This is pretty much the last one…
The issue is that the last line of a multiline label won’t get displayed. It does increase the height, but not quite enough. In the upper label it should show “some more text\n123”. With some extra space it does.
Yeah, lets go with GH issues - will be easier to discuss things there, and show code, etc. Ive seen the PR - looking through it - but if you could open issues, that would be great!
Cheers,
Ian
So i think im coming around to your way of thinking:
vs
I think im going to hide the old behaviour behind a flag: haxeui_zero_height_labels (open to suggestions for better names)
Great!
It looks so much more consistent, especially when there’s a lot of user input stuff.
The flag is a clear description 
