Part 3 of my series on Xojo in the year 2017 and my thoughts on the challenges facing the tool and its framework(s) moving forward including my suggestion to help us all.
I hope this is just me not understanding this right… You’re not doing this on every single control instance, do you?
Our rule #1 is: Subclass every Control and only use subclassed Controls in projects.
This way you only adjust the look&feel 1x / Control-Type (and not on every instance on every Window).
And it’s quite convenient to place workarounds there for Xojo-version-specific issues.
#if XojoVersion <= 2016.03 then
//something for old versions
#else
//with XYZ being fixed, do that
#endif
So you PushButton-Subclass might have an Event Definition “Open”, and in the Open-Event you do your customization:
[code]Event Open()
Sub Open() Handles Open #if TargetLinux then
me.Top = me.Top - 3
me.Height = 29 #elseif TargetMacOS then
me.Height = 20 #elseif TargetWin32 then
me.Top = me.Top - 1
me.Height = 24 #else
me.Height = 22 #endif
Open
End Sub
[/code]
That way the Height’s are appropriate for every Platform, and the “big PushButton on Linux” even moves a bit up, so that it aligns appropriately with what’s left/right of it. You probably still need a couple of #if Target’s - but certainly much less, as long as you design everything “wide enough”.
We’re looking forward to that, too… I’m still more productive using the REAL Studio IDE, especially while working on Windows (the IDE has always appeared to be “smoother” on macOS). Let’s hope they combine the best of the two
But back to your Blog-Post: I’d like to add something what I like about the IDE.
It’s no issue at all to write your code in REAL Studio (in order to still provide Carbon and WinXP builds), and even use many of the newer features (such as HiDPI support) when building the “REAL Studio project” in “Xojo” (to provide 64Bit and HiDPI builds).
With Conditional Compiling (depending on RBVersion: use a single picture for build in old IDE, but create a multi-representation-picture for 2016r1+) and PreBuild-Scripts (which auto-magically toggle on HiDPI support) it’s really just a matter of clicking “compile”.
Not many hassles (if any) when migrating a project to a newer IDE such as with other products…
I wish this was just a coding bug - its not
This requires an entirely different file format where the project manifest is not required
Neither “small and subtle”
Its a long standing design decision that hampers things
[quote=339992:@Norman Palardy]I wish this was just a coding bug - its not
This requires an entirely different file format where the project manifest is not required
Neither “small and subtle”
Its a long standing design decision that hampers things[/quote]
“Small and subtle” to the user who discovers it does not work and wonders why. I claim no knowledge of why it does not work just the end user experience.
You are certainly correct about sub-classing. However it is one of those things you don’t realize you should do until its bitten you! I think a visual property palette that lets you override the settings by platform would give a subtle clue to the user that the platforms do in fact operate differently. Anyway just an idea.
overridable property palettes only deal with the smallest portion of whats required
if you make the top left button larger through one of these then you probably also need to reposition things below & to the right
and so on
autolayout is whats required since it gives you control not only of the control sizes it also gives you the ability to specify relationships between controls even when sizes & positions change
since we’ve said thats where were headed its unlikely we’d do something like you’re asking for
And you can already do some of this by using #Constant values with settings for Windows, Linux & OS X
We do some of that in the IDE
Yeah I’m thinking in terms of new user experience. The IDE does notate platform differences in some areas like build settings but in controls where differences are obvious it doesn’t. Constants is a cool way to do it but forgive me but you can’t edit the design when using constants? For a new user they won’t know they can do that nor know that the platform controls are different.
If autolayout is anything like on iOS I’m not sure how many will like it… it’s a new paradigm and not immediately obvious by any measure. My reviews try not speculate on future stuff too much as who knows when it will occur. Geoff mentioned the new Xojo plugin format on a recent virtual user group call so I know that’s coming.
You have the advantage of being a power user and having access to the code. I am looking it from the perspective of the new developer or someone hiring a developer. What gotchas will they encounter and what could have prevented it or improved it? They aren’t supposed to be fully qualified ideas just notations of deficiencies I’ve found or areas of potential improvement. Thanks for your feedback though!
At least for non-console apps this is rather simple.
“Abstract what varies” is one of the tenets of OO development. Neither your #ifs not the override are good ideas. Do platform dependent windows and abstract your code.
This is a major pain point. After having to reinstall the computer I spent hours to get my projects working again. Then I was told that this is a feature and not a bug. I wanted to hit that person.
The problem wasn’t that feedback wasn’t solicited. It was just ignored. Bugs that were found in the first alphas of the redesigned IDE were fixed 3-4 years later. I can still screw up the selected row in the navigator in under 10 seconds. Is this so hard to fix?
I did not say it was difficult I said it was a lot of work or tedious. Let’s say you are building an app for all 3 platforms. You discover you need to run some function(s) in a console helper app.
Test and flesh out the console helper app to maximum satisfaction.
Compile for all three platforms.
Now for each platform in the main application you have to use copy steps to copy in the appropriate built executable for each platform.
Now you need to use #If tags to include the correct path to your built executable. Let’s say you stored it in the “Resources” folder. On macOS the “Resources” folder is simply called “Resources” inside the .app package. On Windows though the folder is called “AppName Resources” inside the executable parent folder. SO you have to navigate to the resources differently per platform.
You then need to make sure the executable is actually there and then call to it using the shell class. Ideally in an asynchronous manner and handle the result.
My suggestion is the IDE should handle all that noise for us. We just add a “external/console/accessory/helper” (name does not matter) method, give it some simple arguments (say the same as XojoScript can handle - basic types) and click “Run”. Behind the scenes the IDE creates a sub-console project for each desired platform, builds it, and includes it in a pre-defined directory. The IDE/framework manages all the data passing back/forth, executable location, etc.
If the IDE did this it would make Xojo apps instantly more CPU-aware without all the hassle.
I am not advocating a technically superior architecture merely what the new user will experience. They won’t know they need to subclass everything or use constants or even deviate at all. The tool is sold as a cross platform development tool that quickly gets you on each platform. It’s only later in the development cycle for most do they realize it comes with many caveats. My inclination is that the IDE should do more to either abstract the differences OR present the differences in a way that is visually and rapidly configurable.
tldr; I agree the tool has several ways to handle the issue but alas to the newcomer it can be overwhelming or challenging to surface those solutions.
I think supporting code outside of the IDE would enhance the image of the language. We know they can already do it to some degree as they parse XojoScript as text and are able to execute it.
You would still need to pay for the compiler even if its executed via command line or continuous integration. The IDE would still provide a great deal of value even if its not your primary tool. For example I don’t imagine a non-Xojo IDE would have any debugging capabilities.
