Reality Check?

General
1

OK, this may not be the section where I should say this (forgive me). And PLEASE this is not a commentary on Xojo, but a very brief observation. I’m not whining, I’m not complaining. I’ve used REAL/Xojo for about 16 years, I’m one of the originals. I don’t post near as much as I used to, but I lurk consistently. Point is, I know REAL/Xojo’s history and I’m fine with it all, but sometimes…

The new October Xojo news had me thinking and laughing at the same time. First, does anyone notice that the News ALWAYS has first to do with some conference or convention etc.? That’s okay, but I’m never going to one. I figure that must be part of Xojo’s revenue stream now, and probably an important one.

Also, in the linked article “The Short-Term Xojo Roadmap” some of the segments had me only laughing. Again, I’m used to how REAL/Xojo operates and it’s okay with me.

Like isn’t that ALL THE TIME with Xojo? But I know you’ve got to say stuff like this.

Maybe this is a bit more serious. So, when was it “nice to have”? I mean, if you are thinking to meet needs in the here-and-now, yeah, but for maybe a decade it was clear that 64-bit was the future. I SHOULD BE THINKING in the here-now, but the IDE-compiler provider should have that way more of a priority that me. Maybe Geoff wrote this with something else in mind.

And we aren’t talking about what the AppStore was going to accept or not accept, we are - like we should have been saying - talking about memory limits, the REAL reason why 64-bit is important. All OS’s have been saying for more than 10 years “HERE, please now write 64-bit apps, because we support it now”.

Flicker? What flicker? =) I learned long ago - it may have been 10 years ago - that if I’m going to make an app for cross-platform (which is everything I do), DON’T DON’T DON’T go to town on fancy looking widgets on graphical backgrounds. There’s one program where I did this in 2008 and boy did I pay for it. It either looks nice or it doesn’t, and REAL/Xojo just doesn’t do this well in any case on Windows, no matter how many declares or custom drawing systems you create on your own.

But like I’ve said, I’m happy that Xojo is finally getting to it. Stil, there’ s just so much irony involved.

There was a time when I would be miffed at REAL/Xojo for promising something and then delivering it years later. I don’t anymore, I just wait patiently. Gosh, it’s been forever since they’ve announced 64-bit. 6-8 years?

Everything points to this one thing that REAL/Xojo never can properly admit, and I know why: they are a small company with finite resources and better time to market could only be accomplished by hiring more expensive programmers and risking their financial model on it. It’s NOT because this stuff is hard or because the tech landscape changes or they are “waiting” on some other dependent technology to drop the other foot. (Maybe in some cases, but not on the mission-critical stuff.) And the only reason they were using that dependent technology was because they didn’t have the resources to do it in-house in the first place.

Normal WILL argue with me on this, but sorry Norman, the only other explanation is that you can’t hire aliens because NASA hasn’t found any yet.

Xojo remains the go-to cross-platform environment for everyone on this planet. I like that and I am very happy to use it. But, boy, I would have been Superman (or any Marvel guy you want to think of) if REAL/Xojo, in whatever alternate reality, would have got this stuff to market sooner. If Cocoa came when it was announced. When 64-bit came when they said. When… when… when…

Xojo also hasn’t received a cent from me in renewals for many many years. I only renew when what they have for me is done. 64-bit still isn’t done.

But all this is ultimately all right with me.

Forgive me for complaining, I obviously am, but really, not really. I just wanted to pop out of my hole for the moment and relate to all the irony that dripped from “The Short-Term Xojo Roadmap” article. If Geoff chose to have the discipline to keep his company small in order to accomplish whet Xojo has accomplished, I’m not going to second guess that; in fact, I’ll praise him. Thanks Geoff for keeping the ball rolling, even if it’s meant getting features years late.

Thanks for the hearing.

2

I’m not so much concerned by features being late, I’m MUCH more concerned by the degradation in quality.

The IDE was the crown jewel of REAL.studio. The “new” IDE isn’t a patch on it. Adding a property or method used to be a one-click operation. Why isn’t it anymore? Ah, because we can’t configure the ToolBar? Why is that? Ah, because it’s not a real ToolBar? What was that about eating your own dog food?

The original documentation was fantastic (if you can still remember the pdfs and tutorials), easily five stars. Dropping the pdfs was a pity, but the Wiki was good, and the community could fix errors, add examples, etc (and I DID contribute). The “new” documentation is an unmitigated DISASTER. It get’s one star from me, and I still mostly use the old documentation via Dash.

And let’s not get started on the long-term consequences of the Rapid Release Model. But it IS telling that Apple changed from an 18-24 month to a 12 month release cycle for its OS, and its vaunted reputation for stability and “it just works” is going down the drain fast. That the last “usable” version of Xojo for many is R2016 R3 is telling.

Maybe I’m an old “stuck-in-the-mud” or whatever. But I expected things to markedly improve over five years (2012 to 2017). If they worsen instead then something is seriously out of whack.

3

You are wrong about the toolbar Markus

Prior to 2013 all versions of the IDE used a custom canvas based one we crafted in house
Now the mac IDE uses a REAL macOS toolbar which is, in part, why its NOT configurable using normal macOS API’s

Windows & Linux still use a custom canvas one so we can support things their native toolbars dont (like variable spacing)

Using the real toolbar IS moving to eating more of our own dog food :slight_smile:

4

As another old-timer I know every time I hear about a new target/platform I say to myself it’s at least 18 months for a working beta and another 6 months until it’s usable. All along they’ve said that web wasn’t a distraction for desktop, iOS wasn’t a distraction for desktop and web, and Raspberry Pi wasn’t a distraction from others, and now Android isn’t a distraction. I call BS on all of that. Every one of those technologies requires compiler and IDE coding to get it to work in addition to whatever internal testing Xojo does.

Are we truly surprised that their new target estimates are not based in reality?

I say this as a huge fan. Heck, my business revolves around Xojo so I’m keenly aware of its deficiencies and inability to meet publicly stated deadlines. When my business starts falling behind schedule and not being able to do the jobs we want to do we seriously consider adding staff. That is not a decision to be made lightly because the last thing I want to do is have to let someone go.

The fact is that Xojo has the same number of full-timer developers now as they did 5 years ago (maybe longer?). Yet they’ve added more targets and are adding another (Android). The job the development team has done is nothing short of remarkable. But, I think it shows how small their team is and how it hurts them. If any one of their dev team gets sick, or decides to quit, how much will it hurt? I would wager a LOT and not just in new feature slipping away.

I get it: the IDE and compiler are big, complex objects. Anyone starting today will take six months to understand the complexity of the project and probably another six months before the existing developers will trust them enough with changes. That’s a year to train someone and get them up to speed and before they can contribute truly useful things.

So the question I have is not a matter of if Xojo will add another developer - it’s when will Xojo do it? Adding another target while continuing to expanding existing targets, converting to the new framework for all targets, IDE changes, etc. aren’t going to happen overnight.

Look, I’ve been saying this for years but what the hell do I know? I’m just a small business that has four full-time Xojo developers. When I start asking the question ‘how much money am I losing by NOT hiring another developer’ I definitely need to evaluate that decision. I sure wish Xojo would do that and act on it.

5

I’m suggesting to everybody who is having working experience with Xojo to make MUST BE DONE TO DO list for next update and post on forum here as new TOPIC or so.

Later, guys from Xojo team could see what is a general perception of their development community and put their hands in to make it happen, of course if they want to make that happen.

So, far I’m gratefully in general with Xojo and thanks to people who made it.

Of course they should improve product more and more by day this nice product since everything is moving forward which means also that Xojo must go forward as well!

Regarding do documentation it would be a very big help for everyone if they want to implement so called platform tags like Microsoft and other companies were doing for their technical documentation.
On top, of each page, for command, event, control and so on. or even issues and bug, should be something like ‘For platform: Windows, Linux, Mac OS, iOS’.

Now, you need to read maybe even complete content to find it out is it supported for certain platform e.g. iOS or not.

By adding this platform tags it will means a lot and make more pure documentation.

Also, document dates (when it’s created and when is last time updated) would be also nice to have!

I will stop here since right know don’t have much time to write…

After all, I wish all the best to Xojo Team and guys keep forward only!

Cheers!

6

It does make you wonder why it takes someone 1 year to become proficient. I’m only guessing but it sounds like the framework and the IDE are huge monoliths.

Maybe if they were more modular (ie: made up of components / plugins) then the risks / time involved in bringing new people on-board would be reduced as there would be less they could break.

Having the framework as plugins could potentially be a way of reducing the size of the built projects. For example, if the new framework was not used, its plugins wouldn’t be included in the build.

It would possibly also help with the overall quality of the product as in theory, you could deploy bug fixes to customers (us) much faster by providing new versions of those plugins rather than an entire new version of the product.

7

I’m not defending Xojo team and they can speak and they know to speak in their names but when you are making a RAD tool kind of products which will be used to make coding products sometimes other players on market make a problems as well which reduce your time of implementation.

Best example is Microsoft and then comes Apple, Google, RIM, CISCO and others.

So, if they are making some sort standards which should be followed then it’s hard in that game to be all the time on top since even all thous mentioned companies are also making miss products and services or they were doing dummy things by time. By time also they are also hiding some technical details too.

Also making unique RAD tool is a bit very brave movement specially when you need to provide support for different OS from different vendors which as I already say are making sometimes dummy steps.

I’m telling this from internal and under the hood point of view not from GUI part.

GUI, marketing and nice looking things are also one thing extra which makes things more to things goes on different way and put extra rock and roll to every product.

I hope that Xojo at the end will be nice tool by time to work with.

That only depends on Xojo team and their founder and/or founders.

8

Xojo - understaffed since 1998. (New slogan?)

On the other hand, they’re still here, still in business.

The IDE has some problems.

On the other hand, have you tried competing IDEs? Some of them will make you beg for Xojo back.

They consistently miss public goals for major features, most recently Android.

On the other hand, they don’t have to talk at all. I mean, literally, they could just stop talking to us. When they tell us what’s coming up and give us a rough timeframe, I’ve learned to pretty much ignore the timeframe part and simply take on board the direction of where the product is going, and I hugely value you that roadmap, as vague as it may be.

I’m not at all trying to say that Garth and Bob et al don’t have good points. They absolutely do. But I just want to play a little devil’s advocate because, honestly, I think we’re often spoiled by Xojo. I know, first hand, that there are some things that other development environments do better. But there’s still nothing out there to match the value of the complete Xojo package.

9

Question for the one that sold software (that are created using Xojo):

Will you be able to do that if MBS and other plugin vendors does not exists ?

10

Short answer: Yes.

Long answer: it may take much longer to reach the goal. If I have to program my own PDF library, it will take a while. I am certain @Dave S would concur. Same with everyone else who created add-on classes.

11

You are absolutely right. We are spoiled by Xojo and that’s part of the problem, I guess. Apple, Microsoft, Google doesn’t tell us jack about the next thing they’re working on either.

Frankly, XDC (and other dev conferences) might be their biggest ‘problem’ because that’s the only time they give us any idea on what’s next and, as with XDC and the MBS conference, gave us quarterly targets with some surety. And that you get some ■■■■ with a blog that broadcasts that information and the next thing you know it’s a ‘promise’. :slight_smile:

The flip side is that without that information the Geoff keynote address at XDC would be pretty short and you pay good money to get that information.

12

Personally i like the new docs a lot, it’s available online in all it’s glory, available completely as a pdf:
https://dzf8vqv24eqhg.cloudfront.net/userfiles/1539/2321/manual.pdf
and as a superfast built-in. Although you will find some things missing or harder to find, i find it in general phenominal what Paul (docs mainly) and Norman (built-in version) have realized. If you realize that they have to gather the information from several persons and present that in a efficient and tastefull manner to all of us, i take off my hat for that giant task they fullfilled.

13

Amen to that!!!

14

Are-you programming iOS ?

15

I personally am with Markus on concern for quality control. I demonstrated those concerns in my review series and I continue to do so when glaring issues occur that should never get out of QA.

It is apparent to many now that the recent Direct2D changes were rushed out. The GTK3 changes while obviously beneficial may have benefited from more testing as well.

I cannot complain about deadlines slipping because lord knows I miss deadlines. Software development is hard and I’m with Gavin and Bob that we have been spoiled.

However if you are to take your time and charge for it then quality must be there. I’m not saying that Xojo’s vision or plan or long term goals or even implementation are wrong. However it is not always understood why some elements are kept so secret when they can have such dramatic effect on the end product.

Why not flip a switch to use Direct2D like you can with 64-bit?

Why do bugs identified after 2.0 but before 2.1 that get resolved not released with 2.1? Well they might say “the point fix is only to fix regressions” but if you have an opportunity to fix something then why withhold it? If a post 2.0 fix is resolved and verified but withheld to release 3 and it turns out it is still broken then the customer has to wait and hope 3.1 actually fixes it.

I can see no logic in regressions only point releases except to encourage active subscriptions and I don’t want to believe that is the motivation.

Every bug is a regression even if not tagged as such in source control or bug tracker. Every bug is something a customer has to work around or wait for. Why the wait?

I see three options:

  1. Release constantly so we have more choice as to which build of nuanced features and bugs is best for the project at hand.
  2. Keep current pace but do better QA and better beta cycles.
  3. Separate the IDE and frameworks so I can use new IDE with older frameworks. Separate frameworks into plugins so I can mix and match as needed.

Currently it’s a cluster cause so much good comes out with so much bad and it rarely aligns with what your project needs today.

16

@Markus Winter the new documentation site wouldn’t be so challenging if Xojo did not have 3+ concurrent frameworks.

17

No, for me that’s not an interesting platform.

18

So, I do not understand how you can love the new documentation.$$Nearly each and everytime I try it, I get iOS answers. And since I do not need them… :frowning:

That said, the new documentation is nice (colors).

19

If Geoff needs money for the company, I have no problem to buy a share.
And I know a few other people who heavily depend on Xojo and could invest as much.
So throwing in 50 grand for a part of the company would maybe help to hire another developer and improve things.
I know that adding shareholders may have some legal changes required, but it may help the company to grow.

20

[quote=353240:@Emile Schwarz]So, I do not understand how you can love the new documentation.$$Nearly each and everytime I try it, I get iOS answers. And since I do not need them… :frowning:

That said, the new documentation is nice (colors).[/quote]
Emile, get the pdf as mentioned in my answer, in there the complete documentation of everything in Xojo is available including the userguide.