It certainly seem that technical discussion were at a much higher level in the past and have been diminishing since about the change from Real* to Xojo. It was really valuable to me way back when.
If what Tim posted on TOF about Geof removing much of the documentation on inheritance because it’s an advanced topic most do not need to know is correct, there is no hope of things changing for the better.
now its buried way at the bottom - WAYYYYYY at the bottom
And since all pages are now one giant long list of everything when I say “way at the bottom” I mean a LONG scroll down
Open the link above and scroll and scroll and scroll
and easy to overlook - even if you KNOW what youre looking for
the breadcrumbs at the top of the page are “category” crumbs that have nothing to do with inheritance etc
Just what section of the guide things exist in
I don’t recall if it was Web 1.0 Labels or Buttons, but one of them you could not style the text due to how Xojo built the html. So annoying. I’m not sure it was ever fixed.
When I noticed the documentation was missing inheritance information, I reached out to talk about it. He clearly didn’t understand inheritance himself, and proceeded to tell me it was an “advanced topic” and that users wouldn’t need to know about it.
Apparently he had a similar discussion with Julian.
Oh sure NOW I know where it is
When I first was looking for it I never dreamt that it would be put at the END of the pages
So I couldnt find it
And then the styling makes it less than obvious
The layout is so bad its harder to read than ever
There’s almost NO distinction between header and body text in many cases
The old docs will serve me well for a long time - even for NEW stuff
Lol THAT’s an advanced topic that it’s not fundamental to understand? You’re right, we’re screwed. By that logic they should remove inheritance from the product as well.
If OTOH they’ve decided that inheritance is a “given” that is prerequisite knowledge to using it, which is obtainable elsewhere, and so they aren’t going to cover it in the docs, that’s at least a coherent, if misguided position (particularly misguided if they are focusing now on non-professional devs, who would greatly benefit from being shown how inheritance works in Xojo so they don’t have to map it from some other language example somewhere out in the ether).
By what I am reading in this thread, the deprecation of Text, instead of fixing its performance issues, could be attributed to the fact that Xojo does not have a compiler specialist.
Lets just say that users bitched abut having two types (that did different things well)
And the new Xojo framework had a CLEAR split between bags of bytes (using memory blocks) and TEXT. String is both - with pros & cons in each
Which upset some who tried to port their entire lives to the new set up and ran into speed issues.
IF you used BYTES to mean “textual data” and expected to manipulate UTF encoded text as “runs of bytes” then yes TEXT was NOT going to save you a thing
DONT MOVE to it
There was NO requirement to do so
The entire Xojo framework was OPTIONAL with means to convert between things IF needed
This was another victim of “OMG there’s something new I MUST move to using it immediately” where there was NO compelling reason to make such a change
Now its been deprecated an the things TEXT did well will eventually be dropped in favour of String and its set of incorrect behaviours
While I didn’t express my thoughts about it, back then, I fairly recall iOS didn’t used strings, and sharing classes between desktop and iOS was a nightmare just by needing “characters” in the class (unless you’d use an array of integers to represent code points, but what a workaround!).
At those times, I really wanted both types to merge or become compatible with each other.
I’m not saying the text type had to be removed, but I understand why some users disliked and didn’t understand the need for both, because, again back then, having them both broke items sharing while adding “little enhancement” (vs a break)).
Yes sharing code between iOS and any other target was definitely challenging
The Xojo framework, required on iOS, could be used elsewhere
It just never got expanded - in part because of the push back by a very vocal users who hated on it which was listened to
code points ARE integers - when you look up anything in the UTF-= 8 charts you see the “code point” (character number whatever you want to call it) which is just an indexed number
The BYTES that represent that code point are entirely different in most cases(except in the case of the original <128 codes which are ASCII)
If you consider “working right” a little enhancement well
Strings have lots of odd behaviours we have all just dealt with over time
But they do lots of things wrong - and they LET you do wrong things (adding a nil encoded string to one that has an encoding and NOT giving you any indication that this is rather nuts to do for TEXTUAL data)
Text fixed those weird things and made it obvious when you tried to do silly things
The goal was to help YOU write better more correct code from the outset
Something string doesn’t to
Not sure it can subsume TEXT under the hood to be text when there is an encoding and string, with all its ugliness, when there isnt one since TEXT represent TEXT completely differently than STRING
Either way its moot
I doubt anyone there will invest the kind of time & effort it would take to do that change