TextArea bugs

20 views
Skip to first unread message

Thomas

unread,
Aug 26, 2019, 9:47:50 PM8/26/19
to CodenameOne Discussions
Today I tried to achieve some simple (at least I thought so) UI with CN1 looking like this:

expected_form.png

but multiple bugs in TextArea (I opened a ticket on github for them) turned this into a nearly impossible task
Honestlly, all these bugs on CN1 components (including components that are used in pretty much every UI and are included into CN1 since a long time so they should be quite tested and clean now) is tiring. I yet have to find a CN1 component with no bugs... 
I really hope this year you would put most efforts into fixing and improving the CN1 UI part...

Shai Almog

unread,
Aug 26, 2019, 10:41:23 PM8/26/19
to CodenameOne Discussions
These probably aren't bugs, I explained more in the issue you posted: https://github.com/codenameone/CodenameOne/issues/2894

Dave Dyer

unread,
Aug 27, 2019, 2:34:51 AM8/27/19
to CodenameOne Discussions

In fairness, consider that the layout has a lot of moving parts, and getting the exact result
you want from generic tools is problematic at best.   Have you tried to get the same effect
using standard java/swing tools?  I bet you find it's every bit  as frustrating.

My solution, which I do recommend you try, is to define your own layout manager
and layout the components the way you want them to.  When you only have to
serve yourself, making a layout is not hard at all.

Thomas

unread,
Aug 27, 2019, 10:39:11 AM8/27/19
to CodenameOne Discussions
On Tuesday, August 27, 2019 at 4:41:23 AM UTC+2, Shai Almog wrote:
These probably aren't bugs, I explained more in the issue you posted: https://github.com/codenameone/CodenameOne/issues/2894

Exept for the TextArea prefered width, they are all bugs actually.
The bugs aren't related to layout here actually. They are linked to the TextArea default styling and behaviour when passing from an edition state to a non-edditing one and most can't really be fixed at the developper level. 
I agree Swing is far from beeing the most convenient and pleasant UI framework to use but, in my opinion, CN1 have succeded into making their UI 5 times worse...
Each time I have to switch from Flutter to CN1 (I still have one of my projects using CN1, I switched all others to Flutter) I am afflicted by how difficult it is to get a decent UI with CN1. Yet I am not a big fan of the "everything is a widget" and responsive design of Flutter. I still prefer the old fashion way with components, layouts and listeners. But the CN1 UI engine is so wrongly designed (For example, it lacks modularity, with many components beeing huge monolitic classes actually merging multiple components and actions that should be distinct, like `Form` wich contains Toolbar and animations betweens Forms in its own code rather than having clear separated (and thus easier to debug and maintain) classes and factories for example) and buggy that everytime I work on my CN1 project I think of switching it to Flutter (unfortunately I invested a lot of time developping custom components and porting some libs into java and native interfaces for this one so switching to flutter/dart would requiere a lot of work, which is why I am still asking myself if the switch would be worth it for this project). I completely understand that the CN1 team and community is an order of magnitude smaller than the Flutter one and thus, that the developpment and bug fixing in CN1 requiere more time but I think that, as a consequence, they should really focus their efforts on critical parts like the base UI (rather than developping some fancy stuff like UIfragments and CSS like syntax that might be cool but are completely unecessary to develop a good looking app). Don't get me wrong, I still think CN1 has a great potential but I am afraid that, if they don't quickly revise their priorities and define a clear development timeline for the next 2 years (they should suggest a public timeline that the community could vote for and discuss, like what they are doing for clone applications and courses) many developpers would pragmatically definitively switch to others more convincing and robust frameworks. 
Reply all
Reply to author
Forward
0 new messages