I’m just a hobby programmer and am somewhat confused by the look of the IDE. I use Windows and Linux exclusively… don’t have a Mac, don’t have access to a Mac, and can’t afford a Mac. Don’t get me wrong; I’m not anti-Mac, but just can’t justify the cost.
Anyway, please forgive the source (Wikipedia) - I read that the Xojo IDE is written with the current version of Xojo. Where I’m confused is that I thought Xojo is supposed to produce programs that look native to the environment in which they will run. OK, so I’ve played with the tutorials and my programs look like they should on Windows and Linux. So why does my IDE look like a Mac? Yes, it is taking some time to get used to but if it was written in Xojo then why does it not look like a native Windows program on my Windows box?
They used custom controls that look like OS X controls that they draw themselves for the IDE…
Most of the regular controls they supply are native to the platform and when they are not, they are drawn using OS routines so they look at home on each platform… They did not do that with the IDE
The term native is more of a reference to an application which uses the OS’s built in controls (i.e. the OS makes available to developers various controls and UI elements to make user interfaces which are familiar to the user already)
There isn’t really anything from stopping you using “non native” controls even if Xojo’s GUI toolkit is generally geared around native controls.
That said, Xojo was originally targeted at Mac with windows being added in after and most, if not all of Xojo developers are Mac fans…
[quote=23871:@Norman Palardy]Despite what Tony claims Karen’s answer is actually correct
We use a LOT of custom controls and they are currently styled to look the way they do which happens to make them look a lot like the Mac UI[/quote]
It’s implied Xojo are using custom controls with a mac look because their mac fans lol while clarifying that even with native controls, that’s entirely optional use and doesn’t have to be native at all.
Please correct me if I have been wrong, but I do believe we both said the exact same thing.
So in essence looking like the Mac UI was just a design choice by Xojo, Inc ? Seems like a lot of work to make it look like one UI when it is designed to look like the native UI it is supposed to run on.
By no means is this a show-stopper. I figured there had to be a logical reason for this.
This brings up a second point I hadn’t noticed before (probably as I use Xojo on a Mac).
All the screenshots on Xojo.com are of the IDE on a Mac. I can’t find any screenshots of it running on Windows or Linux. I tried changing the user agent in my browser as well.
Joseph, check the Preferences dialog. From how those controls look on the Mac, I bet they look more Windows-y on Windows. Your applications that you build with Xojo can look like that on Windows. BTW, if you want an example of a Windows app that doesn’t look at all like a Windows app (to my untrained eye anyway), check out the lastest free Visual Studio. They painted it up with an extra layer of ugly in what appears to be an effort to maximize control density.
I found this out the hard way. A lot of the Native controls on Windows have transparency or flicker problems that don’t readily show themselves in the IDE, because they are using custom controls in several areas in the IDE. Then when you get your generated EXE, whoa boy… a lot of jumping through hoops and tricks to get it to look right on Windows. I guess that is part of the beauty of Xojo, you can pretty much roll your own for just about any control. But I shudder to think how many times the wheel has been reinvented by the community as we work through these issues.
It was maddening at first, until I got my head around the fact that Xojo is first and foremost a tool aimed at the Mac, then I just adapted.
It was what we happened to get designs for
So that’s how it looks
Getting the right look on XP. Vista, 7 and 8 would require 4 sets of graphics to match the different looks where they differ
Not impossible but not the highest priority on our list at this point - but it IS on the TO DO list already
And that we use Win32 directly - no built in OPS level double buffering & compositing like on OS X.
That’s one big factor.
There are things you can do to reduce it.
Don’t call refresh - call invalidate.
Dont overlap controls (that’s a BIGGIE)
We’ve discussed moving to .Net since the rendering engine is more like OS X where its fully double buffered & composited so it reduces flicker. Big job - probably on par with creating the Cocoa framework for OS X - and I think we’ll need to do it at some point.
[quote=23878:@Steve Williams]I found this out the hard way. A lot of the Native controls on Windows have transparency or flicker problems that don’t readily show themselves in the IDE, because they are using custom controls in several areas in the IDE. Then when you get your generated EXE, whoa boy… a lot of jumping through hoops and tricks to get it to look right on Windows. I guess that is part of the beauty of Xojo, you can pretty much roll your own for just about any control. But I shudder to think how many times the wheel has been reinvented by the community as we work through these issues.
It was maddening at first, until I got my head around the fact that Xojo is first and foremost a tool aimed at the Mac, then I just adapted.[/quote]The flickering and transparencies is related to double buffering and paint event hierarchy (which users can’t really change). I made a post about using an API function that can improve by forcing double buffering to be handled by the windows OS but it’s neither fool proof.
[quote=23883:@Tony Stark]The flickering and transparencies is related to double buffering and paint event hierarchy (which users can’t really change). I made a post about using an API function that can improve by forcing double buffering to be handled by the windows OS but it’s neither fool proof.
Hadn’t thought about getting the right look on WIn XP, 7 & 8. I see the challenge in that now.
I saw screenshots of the new VS and it looks rather bizarre. Nothing as to what I’m used to.
As I mentioned before I’m just a hobby programmer. I’ve got the new “Intro to Programming with Xojo” book along with Eugene Dakin’s “I Wish I Knew How to Program With Real Studio”. Hopefully between the two books I’ll get a handle on Xojo programming. Will likely have a few new versions of Xojo and bug fixes well before I reach any real level of proficiency.
[quote=23882:@Norman Palardy]And that we use Win32 directly - no built in OPS level double buffering & compositing like on OS X.
That’s one big factor.
There are things you can do to reduce it.
Don’t call refresh - call invalidate.
Dont overlap controls (that’s a BIGGIE)
We’ve discussed moving to .Net since the rendering engine is more like OS X where its fully double buffered & composited so it reduces flicker. Big job - probably on par with creating the Cocoa framework for OS X - and I think we’ll need to do it at some point.[/quote]
Right, I’ve learned all the tips and tricks and have it working pretty smoothly…just a lot of effort and trial and effort (the PushButton behaves differently than the Bevel Button which behaves differently than the Einhugur Picture button which behaves different than the MBS button, etc…). You guys have mentioned it before, so I know that the underlying issue is with no double-buffering in Win32 and that using .NET to build with would help. But if it is a years long project, just can’t see it being tackled. Just about every ZDNet article I read is we are hurdling head long into the post-PC era.
So if Xojo (eventually) moves toward using .Net to build, how will that affect Linux? Would this be done using Mono? I don’t know enough about the Mac to understand building on that platform yet.
.Net would be “Windows Cocoa” more or less.
It’s worth it - just more a matter of scheduling & resources than anything given the long list we already have
Even in “post pc era” things like .Net aren’t going away (even on Windows 8)