What is the long-term plan for cross-platform control class names?

I’m working on a Xojo Web project. I want to add a control to a page.

  • The Library shows controls by their “short” name, e.g. “Button”, “ListBox” etc.
  • when I drag the control from the Library to the window layout, the control is named “Button1” etc
  • this works on Desktop, Web, etc.

Good so far!

However, other things get weird:

  • in the Inspector, the “long” name is used, e.g. Super = “WebListBox”, “WebButton”…
  • In code, you have to use the “long” name, e.g.
dim wb as Button = Button1 // Fails: can't find a type with this name
dim wb as WebButton = Button1 // works
  • documentation seems to moslty use the “long” names but not always.
  • google searches: it’s a crapshoot.

This seems like a half-way design, and probably pleases nobody fully. I’m curious if there is a end goal? It seems that API2 has moved more towards the idea of separate class names (DesktopListbox…) but I feel like that’s not necessarily the best way to go?

1 Like

The long names are an unfortunate necessity because the IDE needs to be able to have all of the controls available at all times so you can load multiple project types at the same time.

The use of short names in the library is for convenience. But you still need to use the actual long names of the classes b cause that’s what they actually are.

Instead of fixing the IDE to internally know the Class name according to the prroyect type… It was easier to complicate things for everyone :man_facepalming:t2:

4 Likes

There’s nothing to fix Ivan, it’s just the way it is. While it sounds like an easy thing to fix, they’re all all kinds of things in the ide and frameworks that are blended together that give you advantages. For instance, it allows autocomplete to work in cases where you are making code that will run on multiple platforms.

Anyone who doesn’t or hasn’t worked for Xojo is an armchair quarterback when it comes to this. You can sit there and ■■■■■ all you want about it, but the reality is that to be able to offer you guys the software that you know and love, there’s no way to easily change this reality.

5 Likes

Sure, “nothing to fix”, but the reality is that every other tools is moving to using a single class name for all the platforms and xojo is more and more lagging behind.

1 Like

The current situation is a confusing mess of bad desicions.

8 Likes

Surely there was no need to change the name of the desktop controls.
They were already different from iOS , and Mobile, without needing ‘desktop’ put at the beginning.

To be fair, I can understand the use of Web… Mobile… etc , even if I don’t like it.

2 Likes

Okay guys, I’m really trying to be nice here, but you’re not making it easy.

I worked for Xojo for 11 years and 12 days, and my time there was some of the best years of my career thus far. The engineers I encountered during that time ( Thom McGrath, Joe Ranieri, Norman Palardy, William Yu, Paul Lefebvre, Travis Hill and Javier Menendez) were some of the smartest and most talented people I had ever worked with. Over those 11 years, we discussed this problem several times, usually during our engineering meetings in the days before XDC when we were all locked in a room together, trying to figure out a way to make this all possible while keeping the framework easy and without having to rewrite the frameworks and large portions of the IDE to do it, because sure as ■■■■ if you guys didn’t like us spending time working on API 2, you’d have given us the same amount of crap about that foolish endeavor which would easily have taken years to accomplish in and of itself. I can’t imagine how much of the IDE we would have broken just to satisfy the tiny number of people who care about this, and then had to take all of the complaints about this too. This isn’t about bad decisions or bad designs. This is about a cross-platform language with an integrated visual layout editor and IDE which supports Windows, macOS and Linux on Desktop, Console and Web, along with iOS and soon Android. This is also about a small but vocal portion of our community that would rather complain about the same issues over and over and over from the peanut gallery because they think that attacking the employees is a spectator sport. Well guess what guys, there’s a team of real-life people working on this product every freaking day that are trying to make the product better for everyone.

Oh and by the way, don’t go around whining about how “all the other guys can do this” because the other guys are simply not all the things that Xojo is. if they were you’d be using those products instead of Xojo, but you’re not.

24 Likes

No comment on that.

I’m talking about confusing users. If there is a DesktopButton then FFS show that to the user. Don’t pretend it’s a Button.

3 Likes

I imagine - no, I assume and trust - that the folks at Xojo have thought this through better than anyone else here. Anyone who has ever tried to make something simpler, something “magical” that “just works”, will know how badly you can get it wrong and how quickly you can get to a point where you do say “damn, I missed that”.
Even if I personally don’t like something the way it is, I can often live with it just fine. And I don’t see myself in a position to constantly ■■■■■ about Xojo or their design decisions, let alone condemn them. +1 for Greg’s statement.

4 Likes

Many people may have thought ‘why do we need that desktop.something naming scheme?’ I could not figure a reasonable answer on my own and could not find any source of information on the subject. Would be great if Xojo could do a webinar that highlights the technical underpinnings.

1 Like

Me too, BUT I have moved on and back to working on my projects. No need to keep barking
up the same tree forever…

+1 for Greg’s statement from me.

1 Like

Right. I started working with Xojo 2021r3 and never questioned it’s necessity.
So, not barking up a tree but being curious and like to learn. :slightly_smiling_face:

That was not aimed at you primarily, if you you are pretty new, then this would not bother you as much as you have no older xojo projects that needs conversion to API2 for instance.

But for those that have, this has been a problem of course. But at one point one need to move on.

1 Like

Agreed. The library pane is resizeable and the space taken for “Push button” (and other controls) is really manageable.
I too would prefer the exact name shown, so then I can just start coding without needing to recall “Hmm… I’m in a mobile project, so this is a MobileButton… or is it an iOSButton, or just a PushButton or a button?” and then launch the documentation to answer that and finally start the code.

1 Like

The very thought of Xojo trying to address this causes my sphincter to tighten so bad. The risk to reward ratio is so out of balance. No. Just no. None of us were in the engineering meetings. I trust that they came to the right balance here. Accept what it is and move on.

2 Likes

My question is different: why hasn’t this Desktop prefix been a Desktop suffix? The goal would have been the same, but autocomplete would still be useable.
I mean, currently, you have to first complete “Desktop” before arriving to what should really autocomplete.

2 Likes

Xojo developers always tell us that we are stupid. We think that they are wasting their time and our time. I made my peace with the renaming of the functions. I still think that the renaming of the events is totally useless. The naming of the controls is also a bad idea. Pretending that a DesktopButton is a Button is also a bad diea.

3 Likes

Yeah I have to back up Greg on this one. Geoff did push us to get a unified class system, but it just can’t happen. While DesktopButton, WebButton, and MobileButton have some surface level similarities, realistically they are just too far apart. For example do you really want your Button class to have a TintColor property that only works on mobile? To me, that kind of stuff sounds like a great way to make the framework far more confusing.

Remember that Xojo is written in Xojo. Think about how you would code something like this. All these classes need to exist at the same time. To change that requirement, would (as Greg said) break a whole lot of stuff.

I’d like to go into more detail, but I’ve been asked in the past to avoid discussing IDE internals, so please, you’ll have to trust us. It’s so far outside the realm of possibility, that it’s effectively impossible. If Xojo were being built from scratch today, maybe that’d be different. But that’s not the world we live in.

As for renaming PushButton to DesktopButton, for a new user there is still some logic. I am of the opinion that control renaming shouldn’t have happened, but it doesn’t have zero merit. It helps a new user see what belongs together. For example, Dictionary is universal. Things without a prefix are universal. Except PushButton, Window, etc.? It helps define a clear set of rules for naming and organization. I don’t think it was worth the pain, but it’s not without merit.

7 Likes

Dictionary etc can be entirely implemented in software by Xojo. For the other items, Xojo is dependent on the controls provided by the OS, so Desktop, Mobile, and Web make up different groups with different characteristics.