I'm trying to find a way to add multiline to Textinput.
There are few post about this,
but it isn't working with new feathers.
Multiline TextInput(29 posts) (5 voices)
On desktop, use the TextArea component.
On mobile, set multiline to true on the StageTextTextEditor used by the TextInput.
thanks for replay.
I have changed
inputText.textEditorProperties.multiLine = true;
but it's not working on my phone
Thos part look like this now:
inputText = new TextInput(); inputText.textEditorProperties.multiLine = true; this.addChild(inputText); inputText.textEditorProperties.fontFamily = Const.semiboldDosis; inputText.textEditorProperties.color = 0x021c27; inputText.textEditorProperties.bold = true; inputText.backgroundSkin.alpha = 0; inputText.backgroundFocusedSkin.alpha = 0;
Don't capitalize the L.
Thanks for help, it's working now.
I didn't see "L"
I'm digging this up because I've run into a similar issue.
What I need is a multiline TextInput using a bitmap font (not a TT font, I have different effect pre-rendered in my font, doing these in real time would be an overkill).
Also, a bit different issue (but I'll leave it here for convenience) - when using TextInput with a bitmap font I can see it renders this small "gap" over its top-right corner:
BitmapFontTextEditor exists, but it only supports editing a single line of text. No wrapping or breaks are allowed. Multiline editing is a little more challenging to implement, so I haven't done it yet.
BitmapFontTextEditor also does not work on mobile.
Eh, this is just terrible news. So what are my options? Is there anything I can use with bitmap fonts?
OK, I switched to StageTextTextEditor, but, of course, it fixed one thing, but broke others:
1. The custom embedded font does not load on Android (works on Windows).
2. Text is uglily aliased on Windows (looks great on Android, though).
3. FeathersEventType.ENTER is not dispatched on Android (but works fine on Windows). What should I use on Android? Should I also use something different on iOS?
4. When in focus the text looks different then out of focus on Android, like letters are less separated when in focus (no such thing on Windows).
Is there a way to have a cross-platform text input solution with Feathers?
1. StageText cannot use embedded fonts.
2. I don't think there's anything you can do. StageText has a limited API. It's specifically meant for mobile, though, so I'm not surprised that it may look a little off on Windows.
3. FeathersEventType.ENTER is not dispatched for certain values of returnKeyLabel on certain platforms. Try out some other values of returnKeyLabel.
4. The StageText is drawn to BitmapData and converted to a texture. I guess that's just how it gets drawn by AIR on Android.
You could also try TextFieldTextEditor, which may work more consistently cross-platform. Be aware that StageText exposes more mobile features than TextField, though. You may have requirements where you have no choice but to use StageText on mobile.
Try using TT font. Copy the input text, do the appropriate filter. It's overkill but should be pretty fast.
1. So, just to be clear, I'm left with system fonts only? There's no way of using custom fonts?
2. OK, so I'll probably switch to bitmap editor on desktops.
3. All right, I'll give it a go and hopefully will find one that works.
4. Actually, there's one thing I lied about - it acts the same on Windows and Android. I think it has to be a problem on your side, probably texture is getting stretched, so everything is a bit more blurry and letters look more separated.
I'll give TextFieldTextEditor a try as well. I don't really need much, all I want is a single line of text (I don't really need multi-line editing) drawn with a custom font and a working soft keyboard.
edit: OK, I tried TextFieldTextEditor on Android and Windows, and on both it has problems as well (a different ones!). On Android, with my app in landscape orientation, when in focus a default system control covers the entire screen (half of it is covered by the keyboard, rest by a huge text input - pretty standard behavior on Android), so it's pretty useless for games. On Windows I can't use the alt key for typing native characters (like Polish "Ł" or "Ą", etc.) so useless as well.
To be honest, I'm close to being devastated by this. All I'm after is a thing so basic that with all frameworks I worked so far with I was able to achieve it in a single line of code. With Feathers I'm not only forced to configuring an editor, which is just unnecessarily complicated, but in the end it turns out none works, so it's been two days just to figure out I need to hack my way around inputting text!
And it's not only about text inputs. I'm using just three Feathers controls in my project - a button, a list and this text input and had that sort of problems with all of them. A task so common like customizing a button is often harder than it should be (touch events get messed up when button's skin is rotated or has its pivot moved somewhere else than the default location), you can never be really sure if a list is going to work (I'm yet to find an infinite validation loop with my little more than bare-bones list) and now there're these text input problems to make things even harder (and some even impossible). I really appreciate the hard work you put into this, Josh, and all of the answers you gave on this forum, but the truth is that for years Feathers had problems everybody struggles with and these have been pushed aside and never really addressed, so new features could be added (like MXML support, for example). I don't really think we need any new features with the old ones still causing so much trouble for everyone (seriously, just look at the questions being asked here - people are struggling with the basics), so please, Josh, instead of focusing on "the new", rethink and fix "the old".
PS. I know how all of this sounds and I feel terrible writing this (I deleted this post 3 times so far) but after a couple of years working with both Starling and Feathers I can't stand this enormous gap between the two. Starling is something you can approach without reading any docs and have a working project in a couple of days. With Feathers you can read the docs over and over again and still not be able to do what you were after, and I'm sure this is not what you wanted things to be, Josh.
As this is a community forum, I feel it important to add some more input for any new comers reading this. Booster, this is your experience and is valid. however, our experience is considerably different. Feathers has been a life-saver for us on several occasions. The MXML addition was also the greatest thing added IMHO, and really made the post-flexer's feel at home.
The only "issues" that we continue to run into are StageText problems, which time and time again are Adobe's lack of attention not Josh's. He's fortunately given us many options to work-around those problems and limitations, and his support is second to none when we need a little help. Find a bug? in a couple cases so far, Josh fixed it immediately and pushed it into a maintenance release ASAP.
People need to understand there's going to be trade-off when doing cross-platform, and it really doesn't get better than Feathers. These problems exist in ALL cross-platform solutions, I hear about them everyday in Cordova, Appcelerator etc.
I guess everyones experience is different. I just wanted to add that we just re-launched a feathers app that was originally built in pure as, as we needed a cross-platform solution that tied into our Flex desktop software, and every time I use it, it blows my mind how well the performance is with feathers. And with the MXML, our development speed is unbelievable.
I don't think your post sounds horrible Booster, your'e just being honest. Feathers has a bit of a learning curve, but Josh amazingly is always there to help and when you consider this entire SDK, all docs, etc have all been built by one guy.. well, that continues to blow my mind more than the performance of Feathers
If I could make TextInput easier to use, I would. I am constantly struggling with Adobe's inconsistent support for the simple task of editing text. StageText has all sorts of weird issues cross-platform, even with a super limited API that doesn't expose everything that I'd like. At the same time, it also has the most "native" features on mobile, so most developers are probably going to want to use it over TextField or my other ITextEditor implementations. I've gotten Adobe to make a lot of important bug fixes to StageText, but it's still not as good as I would hope.
so please, Josh, instead of focusing on "the new", rethink and fix "the old".
I am constantly listening to feedback about what's difficult, I spend a lot of time thinking about how to improve the architecture, and I try very hard to make changes that make things easier for everyone. The major releases 2.0 and 3.0 were focused almost exclusively on addressing community pain points. I also try to fit in many smaller improvements to what you call "the old" in every minor release too. New features are always important, but that's only half of what I do.
I'm sorry that my efforts haven't seemed to help you at all. I guess there's some disconnect in what I'm hearing from the community and what you personally think is most important to fix. I don't know how to bridge that gap in communication. I wish I did.
(touch events get messed up when button's skin is rotated or has its pivot moved somewhere else than the default location)
You might try setting the isQuickHitAreaEnabled property to false. The default value of true for this property is an important optimization that really helps performance in the vast majority of cases. It causes hit tests on the button to skip checking the bounds of children because usually they don't matter, and that means only one hitTest() function call per button instead of three or more. It was actually kind of a revelation when I discovered how much of a difference this made when I was developing an early version of Feathers. Anyway, if a child is positioned outside of the bounds of the button for any reason, isQuickHitAreaEnabled causes it to be ignored. If you have a special case where the child should definitely be touchable when it's outside of the bounds, then you want to disable isQuickHitAreaEnabled.
The button probably should account for the pivot when positioning the skin, but I'm a little surprised that you'd try to change it in the first place. Can you share some reasons? Rotation might be a bit harder to account for because there's risk of causing performance issues from the low-level bounds checking that I suspect would be required. I'd also be curious why you want to rotate a button's skin (and not the button itself, for instance).
you can never be really sure if a list is going to work (I'm yet to find an infinite validation loop with my little more than bare-bones list)
I assume that you may made a typo there, and you're saying that you frequently run into infinite validation loops. I find this interesting because I feel like List is probably one of the most solid components in the set. I've spent more time working on improving lists than many other components, and the stability and performance really shines, in my opinion.
I feel like part of the disconnect in communication is that when someone runs into an issue like this, and they finally figure out how to fix it on their own, I don't necessarily get a bug report or a heads up that it's easy to head down the wrong path. In those situations, when I don't personally run into these kinds of issues myself while building an app with Feathers, they can stick around for a long time. The sort of issue that you describe here with a list sounds like something I would want to give a high priority, but I haven't encountered it in the apps I've built, nor have I noticed any clues from what developers here in the forums or on Github have asked about.
I assume that you may made a typo there, and you're saying that you frequently run into infinite validation loops. I find this interesting because I feel like List is probably one of the most solid components in the set.
OK, but we both agree that such loops are possible and do happen. But no build-in mechanism for detecting those exists, so I'm left in the dark when it comes to finding a problem (which is "just" hard with one component, with a complex UI when something like that happens, it's close to impossible to figure out what the problem is). Same goes for layouts - they, when not used properly or because some default values give unexpected results, often set the width or height of some components to 0, which is probably never (or very, very rarely) desired, but again figuring out why something like that happened means changing things at random (in my case what seemed to fix some of these issues was changing the default values in *LayoutData classes from NaN to 100 - I still don't know why) - again, a build-in way of figuring this out would be a life saver.
Same goes for skinning buttons. It was a pretty natural thing to me to change pivot's alignment of a button's skin or to rotate it - why wouldn't it work? It works with Starling, I do that all the time and there was no indication from Feathers that I did something wrong.
This is just one of the problems with Feather, but probably the biggest one. Your framework looks like a bunch of different building blocks that the user is free to connect the way they want and expect some results. But the reality is that even those blocks connect just fine, they only work in very specific configurations and you have no way of knowing the scenario you're after is not going to work because some component was not designed to be used the way you want to use it (often they also come already connected which effectively makes customization impossible). And the path to figuring this out most often leads through writing a post in this forum and waiting for the answer from the only person who can figure it out - you
You're saying there's a disconnect between what the community says and what I say, but just look at the recent topics - people are struggling with the same problems (basic problems) over and over again. They don't ask you about complex customization or undocumented use cases. They ask about changing the size of an icon, why the displayed text is different than expected or how to change the font (and like this guy: http://forum.starling-framework.org/topic/spinnerlist-font-size they are more than surprised how much effort is needed for a task that simple). I really can't see how my complains are different from the majority of the posts in this forum. Feathers is just more difficult to use than it should be and often impossible to use without asking you a question about how it can be used.
And I'm not saying all of this as a programming rookie, through the last 10 years of my professional career I've been using many different UI frameworks - MFC, Qt, wxWidgets, Swing, Windows Forms, UIKit, even some in-house solutions made for embedded system - I can't remember another framework I had as many troubles with as I did with Feathers (OK, I can, MFC was much worse, if I'm honest). And again, I know this probably isn't something anyone would like to read about they work, but this still is my opinion, no matter how much I'd like it to be different.
or how to change the font
Trust me, I know text/fonts are more complicated than most people expect. A huge part of the issue is that displaying text on the GPU has all kinds of tricky tradeoffs. It's super easy to make things perform poorly and different use cases require different methods of rendering text. The best solution I've been able to come up with so far is to give everyone as much control as possible, but it also means that beginners may get turned off by something that "should" be easier (not necessarily knowing yet that GPU can make things way more complicated than that the easier days where everything in Flash was vectors).
I haven't given up on improving the text/font situation, though. I've been thinking about it for hours and hours for 4-5 years.
Anyway, now that Daniel has introduced the ITextCompositor interface for TextField and a generic Starling TextFormat in Starling 2, I've considered overhauling the way that Feathers handles text/fonts. With a more generic TextFormat that can be used by bitmap fonts, TTF TextFields (and possibly FTE), I could surface text format properties directly on components like Button, instead of making people go through text renderer factories. I would have never finished Feathers 3.0 if I had tried to fit it into that version, but I certainly considered it because I know it could address this particular pain point. It's going to take some serious time to prototype this change and make sure that it won't break too much. I also want to be sure that the turbo-charged low-level stuff is still possible, so there's a lot to juggle there.
Do you think this is something that I should consider a critical drop-everything task? I can do that. I like the idea of cleaning this up, but I also worry that I may go down this road to find out that it's way more difficult than it seems on the surface, or worse, that its not as beneficial as it seemed because more generic formatting is stuck with whatever the lowest common denominator can offer.
Same goes for layouts - they, when not used properly or because some default values give unexpected results, often set the width or height of some components to 0, which is probably never (or very, very rarely) desired, but again figuring out why something like that happened means changing things at random (in my case what seemed to fix some of these issues was changing the default values in *LayoutData classes from NaN to 100 - I still don't know why) - again, a build-in way of figuring this out would be a life saver.
This is exactly what I was talking about. If you run into an issue like this, please tell me about it! Otherwise, I may never know, and it simply won't get fixed. It's likely that you are using something in a way that I didn't expect, no matter how obvious it may be to you. It really can happen like that. Sometimes, it's a complete oversight, and I'll be like "okay, that was stupid of me". Sometimes, it may not be as obvious as you think. Other times, there may even be a critical reason why something has a strange default (such as way better performance for the most common situation where people shouldn't need to be experts to know to how to enable decent perfomance). There are a lot of factors that go into it, but it doesn't really matter why for each individual thing. If you spend way too long on something, I want to hear about it. Either I need to change the behavior, or if I cannot, I need to document it better.
I really appreciate your great feedback. I hope you don't mind a little in return. It sounds like you've been fighting with Feathers for a long time, and I appreciate your persistence. Like you, I just want things to be better. I hope we can continue to work together to improve Feathers.
(By the way, that LayoutData issue sounds somewhat similar to a bug that I finally fixed in Feathers 3.0. Previously, percentWidth and percentHeight didn't work if the parent container didn't have explicit dimensions (components would be sized to 0, unless they had custom minWidth/minHeight). It was a known issue for a long time, but it required serious architecture changes that really could not be fixed without a major version like 3.0. I'm sure it was frustrating for you because it definitely was for me having to wait for so long to address it. Sorry for the trouble!)
This is my understanding.
I think the issue with the difficulty with styling feathers is the vector to bitmap barrier. Text has to go through a factory, button backgrounds has to go scale 9 etc... Changing the background color of a button or font is no easy task.
To make things easier to use, there has to be a fundamental change in Air or Starling so it can render vectors cheaply.
Yes indeed. If it were easier to work with vector graphics, Feathers would be a whole different beast.
I've seen this vector graphic issue in starling for a while. I don't see a solution in sight so we have to weigh our options.
It's also ironic that flash is built on vector animation & graphics.
For the record, I'm using Feathers 2.3x and Starling 1.8x (it's for a project I that we started some time ago and it would be too risky to switch to new versions).
Otherwise, I may never know, and it simply won't get fixed. It's likely that you are using something in a way that I didn't expect, no matter how obvious it may be to you.
Yes, I agree, but still a build-in checks for infinite loops or layouts validating widths or heights to 0 would be nice (and others I can't think of right now, but I'm sure they are possible to add). Daniel did a pretty good job in this field in Starling - every time you do something that is not supported you get an exception or at least a warning is printed out. This really helps to narrow simple bugs down.
Also, in one of the previous posts you asked me, Josh, why didn't I rotate the button instead of rotating the skin. The answer is simple - it's much easier to position, scale, etc. an unrotated button (e.g, if you rotate a button 90 deg, you basically swap its width and height, so each time you want to write
button.widthyou have to remember it should be
button.height). I was not brave enough to test if layout work with rotated components
I was not brave enough to test if layout work with rotated components [:)]
The layouts won't account for rotation, but they will account for pivots.
build-in checks for infinite loops or layouts validating widths or heights to 0 would be nice
Scroller has a a built-in check for infinite loops when measuring its contents. It simply breaks out the the loop, though. You're likely to see really terrible performance in this case, which means you know something is wrong, but you app won't be completely frozen. I could throw an error, but I'm not sure what extra information I could provide that would actually be useful here. The Scroller doesn't know anything about its view port's internal state because they're loosely coupled, so it can't report about the layout or item renderers or anything like that. I can't even necessarily detect if something is being invalidated every frame because there are many valid reasons for that to happen.
List and GroupedList actually a throw an error when they detect that it's gotten into a strange state due to duplicate items in the data provider or an issue in the item renderers. You might have seen a vague "renderer map contains bad data." error in previous versions. In more recent versions, it actually explains what that means.
In the case of things having a width or height of 0, I'm not sure how to go about detecting that this is actually not the desired behavior. Much like the invalidation every frame,tThere are many real cases where you want something in the layout to be that size.
I would love to find more ways to automatically tell people that they're doing something wrong. I don't think it's always possible, though. I'm open to suggestions. Maybe there are very specific situations where I can reliably detect that some kind of infinite sizing or 0 dimensions is not expected, but I don't see them.
Scroller has a a built-in check for infinite loops when measuring its contents. It simply breaks out the the loop, though. You're likely to see really terrible performance in this case, which means you know something is wrong, but you app won't be completely frozen. I could throw an error, but I'm not sure what extra information I could provide that would actually be useful here.
Throw an error, please Do you think I'd know where to look, if I saw this terrible performance? Would it give me any information on what's wrong? And an error would take me directly to the problem's core. Errors are the way to go in situations like that.
In the case of things having a width or height of 0, I'm not sure how to go about detecting that this is actually not the desired behavior.
So just print a warning instead. I'd bet a ham sandwich on this is an undesired behavior much more often than it's not.
And as for the infinite validation loops in general, I think you should be able to deal with those on a base class level (like in FeatherControl or LayoutGroup, or something like that). I think it is quite easy to detect - things start to validate, you check a flag if they are done validating and if they are not, you throw an error.
I really think having things like these is essential with even less complex frameworks and with something as big as Feathers it's a must have - when you see an exception like that you don't waste hours going through framework's code to find what's wrong, you just fix your code (or you can clearly see there's a bug and you report it).
You must log in to post.