Bug 528 - MonoDevelop does not give all Launch Image modifiers (2.8 ALPHA)
Summary: MonoDevelop does not give all Launch Image modifiers (2.8 ALPHA)
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: iOS add-in ()
Version: unspecified
Hardware: Macintosh Mac OS
: --- critical
Target Milestone: 2.8
Assignee: Mike Krüger
Depends on:
Reported: 2011-08-29 15:18 UTC by Frank Krueger
Modified: 2011-09-01 08:13 UTC (History)
5 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Frank Krueger 2011-08-29 15:18:41 UTC
This document lists (Table 6-5) the PortraitUpsideDown, LandscapeLeft, and LandscapeRight modifiers that the MonoDevelop Application Settings does not support.

Comment 1 Mikayla Hutchinson [MSFT] 2011-08-29 19:41:13 UTC
This was a deliberate decision to match Xcode and avoid overloading the plist editor with launch images. However, it's still up for discussion.

The plist editor is just a convenience, you can still add them as content.
Comment 2 Frank Krueger 2011-08-29 19:55:22 UTC
If the plist editor is "just a convenience" then would you please add an option to disable it and give me raw keys and values? I don't mind half-baked conveniences so long as I can override them.

As it is, I don't see HOW to set these launch images because I don't know what value you are generating for UILaunchImage. Perhaps a note or a help button in the correct place in the editor?

The whole system is confusing now. When I select an image to be a launch image using your UI it brings up a file browser. What happens to the file I select? Is it added to the project as content? I don't see it.
Comment 3 Frank Krueger 2011-08-29 20:11:26 UTC
OK, on second thought, don't listen to me. I sound like a grumpy old V1.0 user. I'll figure out how to trick your build into doing what I need.

But I am really getting tired of convenience features breaking my apps. I wish you had just spent some more time on the migrator to make sure I don't have to go through with a diff program to figure everything out again.
Comment 4 Mikayla Hutchinson [MSFT] 2011-08-29 20:35:41 UTC
You can access and modify all the raw keys/values in the Advanced tab.

What I mean by the launch image pickers being a "convenience" is that they simply provide a way to add a few of the more common specially-named content files to your project, and provide a preview of those files. That's all they do. They don't modify the plist or affect the build in any way, and they don't interfere with anything you do manually. Of course, you're right that they should respect UILaunchImageFile if it's been set manually, that's an oversight that needs to be corrected, but not a big issue.

Do you have any specific problems with the migrator? We tested it pretty thoroughly, and the changes would only be visible to you if you've been editing the project file by hand.
Comment 5 Frank Krueger 2011-08-29 20:51:38 UTC
Migrator Problems:

(1) I have Default.png. When I go to Project settings, no image is shown. I click the file Default.png then it asks to overwrite. I say "yes", then it throws an exception while trying to copy. If I say "no", nothing happens. I have no idea how to set the image now.

(2) After compiling and trying to run in the simulator, I get this error:

Unhandled Exception: MonoTouch.Foundation.MonoTouchException: Objective-C exception thrown.  Name: NSInternalInconsistencyException Reason: Could not load NIB in bundle: 'NSBundle </Users/fak/Library/Application Support/iPhone Simulator/4.3.2/Applications/F2B9133D-31B7-4AC8-99D7-FC3D27D7CE8C/CircuitTouch.app> (loaded)' with name 'MainWindowIPhone'
  at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
  at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00038] in /Developer/MonoTouch/Source/monotouch/monotouch/UIKit/UIApplication.cs:26 
  at MonoTouch.UIKit.UIApplication.Main (System.String[] args) [0x00000] in /Developer/MonoTouch/Source/monotouch/monotouch/UIKit/UIApplication.cs:31 
  at Circuit.Touch.Application.Main (System.String[] args) [0x00000] in /Users/fak/Projects/Circuit/CircuitTouch/Main.cs:14 
Comment 6 Mikayla Hutchinson [MSFT] 2011-08-30 08:19:32 UTC
(1), do you have a UILaunchImageFile value in your Info.plist? There's obviously also an error trying to copy a file over itself - Mike, could you fix that?

(2) do you know what's causing that error? Has MonoDevelop set an incorrect value in the info.plist for the main interface file? Is MainWindowIPhone.nib missing from the compiled bundle? Does MainWindowIPhone.xib have the wrong build action? It should now be InterfaceDefinition, not Page.
Comment 7 Frank Krueger 2011-08-30 12:23:28 UTC
(1) Yes, of course. I'm migrating an existing app so yes it already had UILaunchImageFile and UILaunchImageFile~ipad. It uses all 6 iPad Default.pngs and 2 iPhone ones. Their values were Default and DefaultIPad. Unfortunately, your migrator completely ignored my names as I see it generating Default~ipad, etc. Very very annoying.

** The general question is what to do with these PNGs now. I'm accustomed to adding them to my project as COntent. Now I don't know if I should do that. It's not documented and not explained. Do I or do I not add these files to my project?

(2) I used the project settings to manually set the XIBs. The migrator picked the right one for iPhone, but I had to manually set the iPad one (it was blank). Then this error. Sorry, I don't know anymore since I nuked that repo.

I want to be a beta tester for you, but right now I'm working on shipping an app and can't.

I recommend you test the migrator with existing apps since it seems to just make a mess of things.
Comment 8 Mikayla Hutchinson [MSFT] 2011-08-30 12:37:04 UTC
(1) What are the values of UILaunchImageFile and UILaunchImageFile~ipad? You don't need to specify them for launch images to work, they just allow you to change the "root name" from Default.png.

The launch image picker doesn't do any magic, it's just a different way to add the files to the project as content.

Regarding (2), we did test it with existing apps and it worked fine However we don't have existing apps matching every possible combination of things that can be done. The purpose of the alpha is to find these sorts of problems.
Comment 9 Frank Krueger 2011-08-30 13:03:40 UTC
I have attached my original (pre-migration) Info.plist hopefully you can use that to work out the remaining bugs.

Yes, I know the rules for when and how to use UILaunchImageFile, but thanks for the reminder. I was merely informing you that I set my "root name" to something that you're not using.

Thanks for the info on the image picker. You might want to make note of that somewhere.

Does Status NEEDINFO mean you're not going to do anything until I write more text here? I'm really sorry, but I'm not interested in playing with Alpha's right now, but I recommend you still fix these bugs.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
        <string>iCircuit Document</string>
        <string />
        <string>iCircuit Document</string>
    <true />
    <false />
Comment 10 Alan McGovern 2011-08-30 13:07:51 UTC

We had an issue in the migrator where some projects would not get migrated to the new format correctly. The common result of this bug was that a single xib file would be missing and the rest of the xib files would have their Build Action still set to 'Page' instead of changed to 'InterfaceDefinition'. This is more than likely what caused the crash in comment 5.

This has already been fixed but unfortunately we haven't made a new alpha release containing the fix. Whilest we try to make every release as bug free as possible, alpha level releases are quite likely to have regressions as they undergo a lot less testing than regular releases. They're meant as a testing platform for developers to try out our new features so they can report bugs or limitations in them. As such, your feedback has been invaluable. However if there are bugs or limitations which are affecting your ability to develop code, I would highly recommend stepping back to 2.6 and wait for 2.8 to mature and stabilise into a beta or final release.

If your code is readily available anywhere, I'd be more than happy to run it through the new migrator and ensure that everything will work perfectly for the next release.
Comment 11 Frank Krueger 2011-08-30 13:17:30 UTC
I can send you the code if you would like to use for testing purposes. Please just keep it secure and delete when you're done with it. Just let me know where to send it.

The migrator is also messing up my document icons (doesn't set them), but, aside form the copying bug, I should be able to reset manually once all that is fixed.

Yes, I keep 2.4 and 2.6 and github/master MD so that I can dev.

However, I am awfully confused with three versions in the works: 2.4, 2.6, 2.8. I would like to be able to edit XIBs in Xcode 4 and don't know if I need 2.6 or 2.8 to do that. Anyway, that's a different topic.
Comment 12 Miguel de Icaza [MSFT] 2011-08-30 13:19:12 UTC

Frank, if you want to share the code with us, you can email it to me, I will make sure it stays secure.

As for our releases, the only one that will have XCode 4 support is 2.8;   2.6 is just 2.4 with Git and a couple of other changes.
Comment 13 Mikayla Hutchinson [MSFT] 2011-08-30 18:51:42 UTC
I fixed the migration of the main interface file for iPad.

Regarding the launch image choosers, I did some digging. I believe we should be mostly replicating the behaviour of Xcode's launch image choosers. Alan/Mike, here are some notes that should help with fixing and improving it.

The primary issue that's affecting Frank is that the image choosers should respect UILaunchImageFile and UILaunchImageFile~ipad. If these keys are set, the choosers should use them as the stem name for reading/writing the launch images instead of "Default.png". iphone launch images should use UILaunchImageFile, ipad launch images should use UILaunchImageFile~ipad but fall back to UILaunchImageFile. Of course they should respond to changes in the plist value too - as with Xcode, if the plist value changes, it should just clear the choosers and try to re-load them using the new stem.

It also sounds like there's an error in the move/copy operation. We should investigate that. It probably also needs to be audited to be properly handle copying/moving of images that are already in the project, and to use the "virtual paths" so that it can handle linked files.

Finally, unlike the icons, the size restriction on launch images isn't actually a hard requirement, it's a recommendation. Apple allows any size, but renders a little warning icon and adds a tooltip explaining the size mismatch. This would be nice.

Another thing  Apple's plist editor does is to display the iPhone's launch image in the portrait ipad chooser, if an iPad portrait launch image hasn't been set, because the choosers reflect the fallback that will happen on the device.
Comment 14 Frank Krueger 2011-08-30 19:45:21 UTC
Great information Michael. Thanks for looking into it. I look forward to trying out any fixes you come up with.
Comment 15 Alan McGovern 2011-09-01 08:13:57 UTC
First, your solution migrated perfectly with the changes we made several days ago to the migration process. The next MonoDevelop alpha should not cause a problem for you when upgrading your solution. Secondly I'll just update you on some changes which have been made to the handling of launch images which will (hopefully) be in the next release.

Essentially, things work exactly as described in the documentation you linked when you first created this bug report. If the "UILaunchImageFile" is not set, all you have to do is add files files called 'Default.png', 'Default-Landscape.png', 'Default-PortraitUpsideDown.png' to the root of your project and they will automatically be used when you compile and launch your application. You do not need to add any other information anywhere.

If you set a UILaunchImageKey, things still work exactly as the document describes. Suppose you set the key to "MyLaunchImage.png", in this scenario iOS will look for images called MyLaunchImage.png, MyLaunchImage-Landscape.png, MyLaunchImage-PortraitUpsideDown.png in the root of your project and use them as the launch images. You do not need to set any other plist keys or modify any other part of your project for this to happen, you just have to add images with the correct names and they'll be used.

Finally, MonoDevelops PList editor now respects the UILaunchImageKey and will display images that exist in your project in the corresponding places. So if your project has a file called 'MyLaunchImage.png' in the root of the project, the PList editor will automatically display that in the placeholder for the iPhone launch image. If you have one called 'MyLaunchImage@2x.png", that will display in the Retina placeholder. It also respects device specific images, so if you have a file called MyLaunchImage~iphone.png, it will only display in the iphone placeholder and will not automatically be used for the ipad placeholder like MyLaunchImage.png would. This reflects what would happen on device.

I think this covers everything. If there is something missing from this workflow that you require, do let us know. I think pretty much everything will be displayed correctly and handled correctly at this stage.