It does not apply to you “poor win doze people” as “win doze” computer do not have RETINA displays (HighDPI is another story)
but but but
I am building on windows for a target MAC with Retina
so I’d really like the script to run, pretty please!
[quote=92722:@Mike McPherson]Call DoShellCommand("/usr/bin/defaults write " + App + "/Contents/Info ““NSHighResolutionCapable”” YES)
[/quote]
If you’re running on windows, there is no “/usr/bin/defaults” command.
You can however edit the info.plist file to add the key.
add
<key> NSHighResolutionCapable </key>
<true/>
into the info.plist file inside the app bundle… not sure if there is a way to do it via shell commands (not a dos guy) 
Don’t add those lines in any place. Do it before like:
<key>NSHighResolutionCapable</key>
<string>True</string>
</dict>
</plist>Well, as long as it doesn’t break the plist format which is a simple XML format… You could put it after the initial tag also and be safe…
You must know that I explained that way to avoid this kind of thing:
…
NSHighResolutionCapable
Or who knows what else people can make if not instructed in details, like inserting between another key/value lines or a deeper level.
Totally right. Windows doesn’t have blurry text!
Indeed if it comes after the then it will not be loaded as the Core Foundation functions will stop reading after that point, you may even be able to crash the function as it wasn’t designed to operate in that manner.
Xojo includes XML tools, maybe someone should considering making a utility to add this information to the XML plist file correctly. A world of warning however, there are various formats that a plist file can be in. not just XML.
According to the Xojo blog it does… http://www.xojo.com/blog/en/2013/11/writing-high-dpi-aware-windows-apps.php
Point taken - On Windows you can choose to screw the UI on OSX it comes screwed!
What really comes from this is that there are ways for Xojo to xplat handle the problem but aren’t. This seems to be a recurrent theme for example the dropping of video editing due to quicktime issues - AVkit partially supported because it’s not xplat. I get the feeling that the push for iOS has come at the expense of keeping the existing product current.
Luckily I’m predominantly a commercial developer, so how the product looks doesn’t matter too much.
So this
Which to my mind looks like absolute crap is apparently acceptable - All Native Controls.
Unfortunately this isn’t quite so any more, the new MS Surface Pro 3 has a ‘Retina’ type display, where non-ms apps are all blurry. One review said even Photoshop was. I think both Acer & Asus also do ‘Retina’ displays on their laptops now… It’s slowly coming to Windows.
I own a Sony Vaio with a ‘Retina’ screen, it runs Windows Vista, where the interface is all squashed up in the top left hand corner (like some of the examples on the Xojo blog), except for the standard MS apps.
Looking at the blog, making a Windows app Retina ready is also a lot more work than making on ready on the Mac. Once Xojo’s framework is 100% Retina compliant, we’ll no longer need to add the plist option.
Yeah, I agree there…
Apple is, how Apple is, it’s either a good thing or a bad thing. For instance it’s a royal PITA for us older developers who’re used to functionality. For newer developers, AVKit is more consistent with other modern Obj-C APIs, so it’s easier for them. It also reduces security loop holes and on the plus side, it means in a few years people will be forced to upgrade your software.
Sometimes, I’d like a break however, from the ever changing race of keeping up with Apple… Then again, I do love getting more functionality for my app.
But Xojo isn’t Apple. Xojo is xplat and shouldn’t reduce functionality to the lowest common denominator. Instead the argument should be similar to the reason for Web Edition - providing a high level environment while Xojo takes care of the nuts 'n bolts.
But this has been discussed elsewhere & I’m just feeling a little out having had to fight the IDE all day trying to get container controls to have a tab panel parent.
Sure, but Xojo were relying on third party technology for video editing, and now that technology no longer exists. The replacement from the vendor, only caters to the vendors OS platforms.
It would seem that this does leave Xojo in a difficult position, they now have to write and maintain several large chunks for code for different media interfaces. Apple being Apple, only notified us, by rejecting apps from the App Store.
If there’s enough demand, I’m sure that Christian or someone else could step in and fill this gap.
I am an Apple fanboy and have been for a very long time, yet there are situations where Apple does indeed piss me off.
And when a toolkit that helped us make those nuts & bolts dies ?
MS tends to never deprecate or get rid of anything (which has its own downsides).
Ubuntu is doing their own thing in many ways on the UI side but Linux is reasonably consistent.
Apple is really pushing hard to get everything on Cocoa, using 64 bit capable API’s, and to finally get developers off of Carbon.
I’m given to understand that there are / were still some big name apps that weren’t Cocoa and have no idea if/when that might change but Apple is reall trying to get off of Carbon (despite it actually being a pretty decent API for what we do).
They DID say “Use QTKit” several years ago - which we did.
A few years ago they said “You should move to AV Foundation etc” but never gave a drop dead date for anything.
This years WWDC kind of scares me.
What if this guy gets it right (Rich is one of the makers of BBedit) If Apple stopped accepting Carbon & 32 bit Cocoa apps in the store
. ick
Like the guy from BBEdit, I think the new OS will be exclusively 64 bit and that Apple will soon allow only 64 bit apps on the store. Every year at the WWDC, I’m scared about Apple’s announcements. Which SDKs will they deprecate or which UI bits will they change. But until now, I managed to survive. If they release a 64 bit only system, It’s almost the end for my app.
[quote=92904:@Rick Araujo]You must know that I explained that way to avoid this kind of thing:
…
NSHighResolutionCapable
[/quote]
You’re right, I realized that I should have been clearer.
Yes, but I’m 99% sure that Xojo didn’t embed Apple’s binary plist (Core Foundation) libs in the win32 IDE, so I think you could be fairly confident that it will consistently be in plaintext/XML in this case…
Replace the toolkit or write your own. Yes I know you’ve got a heap of stuff on your plate, but we the punters have purchased and are paying maintenance to keep functionality. We are not funding iOS or WE - that’s an extra that we have to pay for and then fund maintenance.
So we should have created a toolkit to make our Win 95 support perpetuate ? or Classic Mac OS so OS 8 or 9 support kept going ?
And still support PPC’s and maybe even the 68K series ?
At some level trying to keep the past alive is infeasible.
There is no replacement and trying to recreate what Quicktime did in a cross platform way would seriously have meant it never happened. It took Apple years, millions of dollars & a team of engineers to create
And nothing happening was a problem for us, and our customers since it restricted them from being able to sell in the app store.
WHile it might not be a big deal for your specific case we heard this loud & long from a lot of our Mac customers that this was a deal breaker in many ways.
There are some playback libraries (libvlc) - but none that have a license that is amenable to our use.
GPL of any kind would bind us & you into GPL which we won’t do as it would mean our customers are bound into it and be forced to release their (your) work as GPL. Thats problematic. The rules out VLC and XBMC and several others right off the bat.
BSD and its derivatives would be nice.
Whether you think you are or not every customer is paying both for current products & maintenance as well as for work on future products. This is true of every customer of every company on the planet. Every company uses current purchasers money to invest in creating new products. It’s how businesses create new things - they don’t usually go to the market place to raise new money for a specific new product they want to create. That would tip off competitors to their plans.
That we got NO notice from Apple about this & had to do “something” in very short order put us in a really tough spot.
MS for all their bumps warts & what not doesn’t do this and it makes life on the Windows side of things pretty boring (boring is nice)
But once we get a few of our projects off our list I’d guess we’ll turn our attention to updating the Windows frameworks to leverage .Net since its now something we can rely on being present on the entire supported Windows base.
And at that point I have no doubt that we’ll go back to the days of Mac users complaining about how we’re too focused on Windows And yes that happened years ago when the UI was made more amenable to Windows & MDI - the single pane UI we had from 2005 onwards.
Holy shit! If they enforce 64-Bit… We’re stuffed! We’re about 2 weeks away from shipping an app!
Oh I know it’d be a real killer to a lot of things
But since they don’t say anything about WHEN or IF they are chafing them it’s problematic
We’re all guessing and then reacting when/if they do change the rules
At that point we’re all in the same boat