Should Xojo ditch the TextArea and TextField?

… and use one of the HTML or MarkDown based solutions instead? After all, the TextArea is very limited (limited RTF support, pictures, tables, etc), but all those limitations would disappear, and disappear for all platforms.

no!

1 Like

for once I agree with Christian… NO!

These are (or should be) native controls (althought I know the UIKit and AppKit versions are vastly different).

What’s the difference? What makes it “native” when it isn’t even supporting superscript/subscript etc that ARE available on all platforms?

“Native” seems like a “golden cow” to me, but I’m happy to be lectured on why native is better.

because if Apple/Microsoft etc decide to change the “skin” of their OS (and yes it has happened a few times already), the native controls change for “free”…
Other wise the vendor (ie. Xojo) has to expend more resources to “catch up”.
Now that is less of an issue with these two controls, since they appear as blank rectangles…
Add new features? sure… but I think there are already 3rd party controls that are available and won’t tax Xojos already non-existant resources.

As does the HTML display of WebKit etc in Safari etc so I still don’t see the advantage.

As I said, it applies LESS to these controls from a visual POV… but even Swift/ObjC doen’t offer TextView/field controls the import/export HTML/Markdown etc… Those features can be added in subclasses just as they can for Xojo.
The other reason (in my opinion) is that you (and your users) are going to want/expect consistent operation. And trust me… recreating a Text (view or field) control is not a small task. It would be much better (and easier) to extend the functions of the existing native controls. This way the basic operations are the same in your app, and any other.

The underlying controls that Xojo uses are far more powerful than what is exposed by Xojo. TextArea for instance can read and write RTFD with images and far more styles. It’s just that Xojo went with LCD when implementing functionality.

As for the future… platform vendors want to support the latest web technologies, but at the same time they also want some form of lock-in to keep customers using their products. At one time (because Apple was the underdog), they worked hard to create a feature rich environment to attract developers and customers.

LOL, NO!

The native contros are ok, the problem is Xojo doing a crappy work implementing them.

If this controls need a change is to make TextField (with multiline support) and a RichTextField.

It is bad to load another system control ad waste all the rich text capabilites if you just want multiline unformated text. On windows, the textarea even have a different apearence than the native multiline textfield.

This is PAINFULLY evident in “Xojo for iOS” they just left 90% of what makes iOS unique out completely…

So the basic argument is “No, because the native control has a lot of cool features that we can use with platform-specific declares or plug-ins like pictures and tables and extra formating!” even though you can get the same features without plug-ins AND cross-platform?

So far I haven’t seen a feature that only the native TextArea gives me (especially cross-platform), but a LOT of features that will likely never come to the Xojo TextArea or require hoops to jump through / money to spend.

So I’m still waiting to be convinced.

1 Like

They already exist, eg gHTML Editor - Xojo Add-Ons, based on CKeditor

THAT is what I want from a TextArea, and cross-platform.

As it is I can’t get a bog standard super/subscript on Linux even from MBS - it’s Mac & Windows only!

That is were you are very wrong.CKeditor is a WYSIWYG HTML editor, not a “TextArea” A specialized control is NOT a replacement for simpler ones.

It is like saying Xojo should replace the canvas with control with better capabilities, it already exists https://www.adobe.com/mx/products/photoshop.html

but even worst because your example is web based. If you really want that, maybe you could use HTMLviewer to have it in xojo.

Did you actually try the Desktop version at gHTML Editor Desktop Edition - Xojo Add-Ons?

You don’t modify the source code behind the scenes - you just write, select, edit as in a standard TextArea.

So if it looks like a duck and quacks like a duck … maybe it is a duck?

What I’m saying is that the current TextArea is very limited, especially when it comes to cross-platform features. Even MBS can’t give me a bog standard super/subscript on Linux.

On the other hand there are solutions that have all the features a user desires, work LIKE a TextArea, and are fully cross-platform.

So I ask why keep the TextArea, and if it wouldn’t make sense to ditch the TextArea - after all when did it get the last meaningful upgrade? Does anyone expect Xojo to improve it? In many cases it simply is not fit for purpose, and while I can often make it fit for purpose with the help of plug-ins like MBS, that does not even apply across the three desktop platforms.

So much for “cross-platform”.

As “counter arguments” I get “No.”, “You are wrong.” , “That’s web based” (what does that even mean? It works offline, so what if it uses web technologies?), “You are very wrong” … but not a SINGLE argument.

Come on guys, surely you can do better. I’m a Scientist. I’m open to arguments. I’m waiting to be CONVINCED.

But I’m decidedly unimpressed by just being told I’m “wrong”.

And the same change would happen in the web controls, also for free. Or do you see a difference between entering text in Safari vs TextEdit?

Only if you need to create it from scratch, not if you base it on existing technologies, eg https://ckeditor.com. After all that is what gHTML Editor Desktop Edition - Xojo Add-Ons is doing (and I’m pretty sure there is another one).

ROFL

It is what I said. If you want it, you can implement it in a HTML viewer adding the extra 90Mb of the cromium engine.

Thanks for making my point about “arguments” :roll_eyes:

The demo app is 23.4 MB compiled … :stuck_out_tongue:

Naaa, that is because it is very funny your “argument” of it is not an argument because said so.

That 90Mb estimation was JUST for the main CEF engine. If you want presicion, the HTML Editor adds to a windows compiled app:

548 files (9Mb) in resources and
73 files (131Mb) of libs

Increasing app size 140Mb, increasing memory usage, ading hundreds of files, adding dependencies to 3rd party javascript libs, just for those 0.1% cases wen a text control could use more than plain text in an app. Sure, really cientific thinking :wink:

Actually yes. I’ve reported an issue with Apple Mail that’s persisted since 10.14, I was informed that Mail is not using a NSTextArea, but something else (probably designed by the kids who designed Big Sur). So when I double click a word and start typing it replaces not only that word, but also the surrounding spaces.

You’re not wrong, its just a difference of opinions. I disagree with you, but that doesn’t make you wrong.

The 90s called, they want their interface back. Reminds me of Windows 98 where word had so many toolbars, you had enough space to see two lines of your work.

:roll_eyes: would that something else be more “web based” … :innocent:

:wink: … I agree, but it’s not about the toolbars, it is about the features I need cross-platform. And for me that means Mac/Windows/Linux - and the TextArea is severely lacking there even though I have MBS, Einhugur, and a few others.