Xojo vs Real Studio

I think that the original poster was complaining about running on Windows.

I do like your answers but this one caused a bit of an ‘eh?’ :slight_smile: I am a big Apple fan. Cocoa came about in 1997 by acquisition, .NET 1.0 was released in 2002. Sure Apple have been making plenty of changes and are not afraid End Of Line technologies such as happened in 10.6. However there has been plenty of change in the Microsoft world and RB/RS/Xojo has had 11 years to adopt .NET.

One difference is that MS continue to largely support ‘legacy’ applications and APIs so although .NET is better and huge now, Win SDK still lives on. But you are denied much of the new relevant desktop technologies such as the new Winforms, WPF, WinRT by not using the .NET framework. I wonder if one reason is that Xojo’s technology is C/C++ compiler based and LLVM is not going to help you in the .NET world? Another is that Xojo is just too Mac focussed, I have two similar apps on my Windows PC, Xojo and iTunes, they are both beautiful but look unlike most other Windows apps. They both frustrate me too because although they run perfectly and fast on a Mac, they are slower and sometimes unresponsive on Windows; and of course all of the Chrome is different in the apps even though Xojo generates a perfectly good and standard looking Win32 app.

[quote=14867:@Carl Clarke]I do like your answers but this one caused a bit of an ‘eh?’ :slight_smile: I am a big Apple fan. Cocoa came about in 1997 by acquisition, .NET 1.0 was released in 2002. Sure Apple have been making plenty of changes and are not afraid End Of Line technologies such as happened in 10.6. However there has been plenty of change in the Microsoft world and RB/RS/Xojo has had 11 years to adopt .NET.
[/quote]
And until WWDC 2006 Apple went so far as to tell people that Carbon & Cocoa would be peers - 64 bit etc.
In 2007 they changed that. Carbon is basically dead & dying and lord knows how long it will be before Apple yanks those API’s entirely.
MS doesn’t force us to update to .Net - we may do it because it’d be useful & provide many new capabilities.
But unlike Apple its not “required”

[quote=14867:@Carl Clarke]
One difference is that MS continue to largely support ‘legacy’ applications and APIs so although .NET is better and huge now, Win SDK still lives on. But you are denied much of the new relevant desktop technologies such as the new Winforms, WPF, WinRT by not using the .NET framework. I wonder if one reason is that Xojo’s technology is C/C++ compiler based and LLVM is not going to help you in the .NET world? Another is that Xojo is just too Mac focussed, I have two similar apps on my Windows PC, Xojo and iTunes, they are both beautiful but look unlike most other Windows apps. They both frustrate me too because although they run perfectly and fast on a Mac, they are slower and sometimes unresponsive on Windows; and of course all of the Chrome is different in the apps even though Xojo generates a perfectly good and standard looking Win32 app.[/quote]
Thats more an issue with how Apple got iTunes on to Windows than anything

.Net would be a nice update on the Windows side of things - again not “required” lie updating thing to Cocoa will become. But optional.

[quote=14852:@Norman Palardy]Except for maybe moving the framework to .Net there’s not a lot that MS has done that requires us to make lots of updates /changes
Certainly not on the same scale as Apples changes[/quote]

Right. Microsoft isn’t throwing curve balls like Cocoa, so why is it that the Windows side of Xojo is perennially second- or third-priority for enhancement and even usability? Look at the comments in this thread and others from Mac users saying the new IDE is fast, smooth, etc. Compare to the comments by Windows users who say the IDE is slow, flickery, etc. The IDE is self hosted, so I seriously doubt that many – if any – Xojo employees are working primarily in the Windows IDE, or it seems likely that the Windows IDE wouldn’t be so starkly different from the Mac IDE in terms of performance and usability.

[quote]Requires a new compiler before we can even contemplate this for MOST RT devices that run ARM or non-x86 CPU’s
And then there’s Metro (or whatever they call it now) which might require a new framework[/quote]

Yet iOS is already scheduled, and last I checked the iPad’s processor uses the ARM instruction set. At this rate, Xojo will support iOS, Cocoa, Carbon, etc. while still only providing the platform-generic parts of the framework to Windows and Linux desktop developers.

I can access Mac OS resource forks through the framework, to access NTFS alternate data streams I must resort to declares. I can manipulate the Mac OS Dock directly with the DockItem class, yet to add a tray icon on Windows requires either that I use declares or use the Tray Plugin which has limited functionality and hasn’t been updated in seven years. This is to say nothing about the mountain of features added in Vista and newer versions which Xojo simply doesn’t address.

If I want an app to present a UAC dialog to the user, I have to edit the EXE’s manifest manually; if I need to enable or disable security tokens I have to use declares; if I want my to make use of the desktop compositor’s non-default features I have to use declares, etc. etc. ad nauseum. Xojo can target Win32, yes; but it acts like Windows XP is still the standard.

[quote=14875:@Andrew Lambert]Yet iOS is already scheduled, and last I checked the iPad’s processor uses the ARM instruction set. At this rate, Xojo will support iOS, Cocoa, Carbon, etc. while still only providing the platform-generic parts of the framework to Windows and Linux desktop developers.
[/quote]

A Xojo target is “processor architecture + framework”. They’ve said in the past that with the move to LLVM, the processor part won’t be impossibly difficult, but porting the framework remains serious work for each Xojo target. #NotTrivial

What was the original title?

It was along the lines of “worst program”

1984?

[quote=14875:@Andrew Lambert]Right. Microsoft isn’t throwing curve balls like Cocoa, so why is it that the Windows side of Xojo is perennially second- or third-priority for enhancement and even usability? Look at the comments in this thread and others from Mac users saying the new IDE is fast, smooth, etc. Compare to the comments by Windows users who say the IDE is slow, flickery, etc. The IDE is self hosted, so I seriously doubt that many – if any – Xojo employees are working primarily in the Windows IDE, or it seems likely that the Windows IDE wouldn’t be so starkly different from the Mac IDE in terms of performance and usability.
[/quote]
Actually we DO have engineers that use it primarily on Windows
And some of the issues regarding flickering etc we are dealing with
Some would be much easier to deal with IF we moved to .Net - we just dont HAVE to move like we do to Cocoa

OLE only works on Windows as do the Office components

Deprecated

[quote=14875:@Andrew Lambert]to access NTFS alternate data streams I must resort to declares. I can manipulate the Mac OS Dock directly with the DockItem class, yet to add a tray icon on Windows requires either that I use declares or use the Tray Plugin which has limited functionality and hasn’t been updated in seven years. This is to say nothing about the mountain of features added in Vista and newer versions which Xojo simply doesn’t address.
[/quote]
FR’s ?

Just ask Mac users about adding exported UTI’s, adding help etc
There’s lots that requires declares or poking at the plist on OS X as well

Well IF we dropped support for XP I bet you can hear the howls.
Until 2011 XP was the “standard” - it had a higher percentage share than Windows 7 - we wont talk about Vista :slight_smile:
Its still very high - so we do have an issue if we decide to drop support or try to move to something newer as “the standard”
We still need to deploy back to XP

Well, Xojo on Windows 7 won’t even let me backspace in the IDE except for one character at a time (holding down backspace doesn’t start deleting the rest of the code within the line) which is highly annoying and not productive for me. This one issue is a show-stopper for me, and I won’t renew a license until it’s resolved. I also am sticking with an older version of RealStudio until the IDE gets some proper and much-needed lovin’ on the Window’s side.

EDIT: Actually, just went to Control Panel -> Keyboard -> and changed the ‘Repeat Rate’ from ‘Fast’ to about 3/4 over and the Backspace in the IDE is now working as intended!? Hmmmm… very odd.

[quote=14890:@Norman Palardy]
we wont talk about Vista :)[/quote]
Agreed and, by the same token, Metro (or whatever it’s called now) too!

Your other points are also well taken. Though, I’ve not been able to accomplish much using the OLEObject. Not for lack of trying: I simply can’t figure out how it’s supposed to work.

What I’m trying to express is the sense that Xojo, Inc has not added much value for its Windows customers in the last few years. Indeed, from my perspective it was the enormous effort to get Cocoa done that led to the infamous breaking of the 90-day update cycle in favor of the “when it’s done” cycle. That’s been a net loss for anyone but developers targeting Mac OS X.

I’d just like to see the Windows side get a little of the same treatment.

This is absolutely false.

Perhaps it is. I merely said that’s what it looks like from my perspective.

[quote=14893:@Andrew Lambert]
What I’m trying to express is the sense that Xojo, Inc has not added much value for its Windows customers in the last few years. Indeed, from my perspective it was the enormous effort to get Cocoa done that led to the infamous breaking of the 90-day update cycle in favor of the “when it’s done” cycle.[/quote]
Actually not. We had intended to ship the NEW IDE in 2012 and IT was not ready - that’s what broke the 90 day cycle.

We’re discussing .Net to get more modern capabilities & that would be the “Cocoa” for Windows I expect

The reality is that our TO DO list is already long & we just cant tackle that at the same time as 64 bit, LLVM & native linkers.
And all of this has benefits to everyone on every OS.

.NET would be a welcome addition :slight_smile:

OK. But this doesn’t really refute my whole point, given that the IDE works better under Mac OS X than Windows…

Wow, so which part is false. I’ve been quietly watching most of this conversations as I really do not consider myself a power-user (in fact I know I’m not). But I’ve developed a number of very useful small applications for my company in very short time using RS (XOJO now). And for that I am extremely happy. But XOJO in Windows is not better, than RS. And honestly I was not expecting it to be; because for the last two years all I’ve heard is about all the cool improvements XOJO was bringing to make it fully Cocoa. So how exactly is it that the 90-day cycle was not broken to bring it the full functionality of Cocoa? Believe me, I get it, new IDE, new framework, this will lay the foundation for a better tomorrow. I won’t ever argue that, but XOJO today is extremely good for Cocoa applications, I don’t think there is any question. I just hope (and seems some others as well) that Windows will now get a little loving so the disparaty is not as much. And if that doesn’t happen so be it. I was happy before, and will continue to be happy (could be happier though :slight_smile: ). But to say the last year or so was not almost exclusively dedicated to Cocoa just doesn’t seem to match the results. Anyways, I’ll go back to my little cube and keep to what I do best (which unfortunately is not coding - but I do enjoy it, and also enjoy RS).

I promise not to complain for at least a whole year once these get finished!

The part I quoted:

The Cocoa framework’s progress had no effect on the release cycle. Cocoa had been improving with each release done in a 90-day update cycle and would have continued to be done in that manner until it was complete. As Norman said, it was the time taken to get the new IDE shipped that delayed the cycle.

Once upon a time, there was an IDE/compiler that yielded to the impulses of the .Net hype and all it’s loyal user base got insanely angry and began abandoning the platform. So they decided to go back, and separate the native compiler from the .Net part. They got 2 IDE/Compilers. It took few years. Their user base, got confused. They lost many people from the user base of that marvelous native compiler who created very fast and small executables and them became an slow weird elephant, and the guys who wanted a .Net thing gave up that platform and learned C#. Their product got seriously damaged. True story. The End.

And that’s why I prefer a native OS API dependent compiler instead of a second fat layer dependent compiler.

The part that is false is

There’s NO truth to that

The CLR is quite a piece of engineering. I wouldn’t dismiss it so quickly.

As for targeting the native API, Win32 is holding us back in terms of what features we can provide. It also comes with a few quirks like flickering (which, as far as I know, is our number one complaint on Windows).