Introjucer iOS project/settings (Info.plist)


#1

Don’t know if anyone has asked for these or brought these items up but there are a couple of iOS project settings items that need to be addressed unless I’m missing something.

  1. iOS icon(s), currently the introjucer has a place for two icon files, small and large. On iOS this does not work it still generates an .icns file if you give it pngs and iOS projects need pngs.
  2. Launch Image(s)
  3. Icon already includes gloss effects, we use this on various projects.
  4. Supported Device(s), currently all introjucer iOS projects generate “universal” for this.
  5. Deployment target needs to be configured as-well; 3.2 4.2 5.0 etc.
  6. Supported orientation(s) would be nice too, even though I’m just setting Desktop::getInstance().setOrientationsEnabled (Desktop::upright | etc, etc); for this now and it seems to work.

I think all of these can still be somewhere in the .plist file, I know back in the xcode 3 iOS dev days all of these were.

There’re lots of other ones too that are useful, maybe we can feed an external key value file into the Introjucer, or better yet let the user point to a user defined Info.plist then you wouldn’t have to generate it, maybe generate one initially and let the user click a checkbox that says it wil be managed by the user.

I like that.


#2

Yeah, this is all good stuff that I need to get around to. I should create a thread somewhere to collect together all the introjucer to-do items in one place…


#3

FWIW, I just ran into most myself. It also raises the issue of target specific files. For example, on iOS, you generally want a default.png in your bundle that get’s displayed while you are getting unpacked to run, and you also now generally need an Entitlements.plist file to submit to the app store.

I’ve been getting around it with git, merging a distribution info.plist after each Introjucer run, etc.


#4

Here’s a patch that adds the ability to select whether or not the .plist file is managed by the user when exporting Xcode projects. Seems to be working here on my end… Let me know how it works out.

[code]diff --git a/extras/Introjucer/Source/Project Saving/jucer_ProjectExport_XCode.h b/extras/Introjucer/Source/Project Saving/jucer_ProjectExport_XCode.h
index e1f1a90907ef5e7c2199463aa6cec89bdb66f6db…bb116629b6c38ddb33770ba42dd320bb3b378331 100644
— a/extras/Introjucer/Source/Project Saving/jucer_ProjectExport_XCode.h
+++ b/extras/Introjucer/Source/Project Saving/jucer_ProjectExport_XCode.h
@@ -110,6 +110,11 @@ public:
props.add (new BooleanPropertyComponent (getSetting (“UIStatusBarHidden”), “Status Bar Hidden”, “Enabled”));
props.getLast()->setTooltip (“Enable this to disable the status bar in your app.”);
}
+

  •    if (projectType.isGUIApplication())
    
  •    {
    
  •        props.add (new BooleanPropertyComponent (getSetting ("PListManagedByUser"), "Property List Managed by User", "Enabled"));
    
  •    }
    

    }

    void launchProject()
    @@ -341,7 +346,9 @@ private:

    void writeInfoPlistFile()
    {

  •    if (! xcodeCreatePList)
    
  •    bool xcodePListManagedByUser = getSetting ("PListManagedByUser").getValue();
    
  •    if (! xcodeCreatePList || xcodePListManagedByUser)
           return;
    
       XmlElement plist ("plist");
    

[/code]


#5

Would it make more sense to provide an introjucer setting where you can paste in your own XML plist, and then make the introjucer merge your XML with its own before writing it out? That wouldn’t be too difficult to do.


#6

That sounds good to me.


#7

That does sound good. Better even if it reads back the current plist - you usually end up in xcode working out what option you need.

Bruce


#8

[quote=“Bruce Wheaton”]That does sound good. Better even if it reads back the current plist - you usually end up in xcode working out what option you need.

Bruce[/quote]

True, but everything in that introjucer-generated folder needs to be treated as volatile, since the introjucer can just throw it all away and overwrite it on a whim. I’ve tried to structure things so that the files in there don’t contain any info that can’t be re-created from the project.


#9

Yes, but which options are set - be easiest to set it from both places. You end up in XCode experimenting, then going back to IntroJucer to try to recreate is awkward.

Plus - what if Apple adds options?

Bruce


#10

I’m sorry if I’m missing something simple, but wouldn’t it be easier to just change the Introjucer logic slightly?

Presumably the code currently builds up an object and then writes it to an XML plist. Could the logic be something like:

if (f.existsAsFile())
{
// Initialize from file
// Remove keys I’m about to write
}
else
{
// Start empty
}

That would let Introjucer write the keys it knows about, and let the all the other keys be edited in the XCode environment that understands them, instead of added an open ended XML list editor to Introjucer or editing yet another file by hand.

The same scheme seems like it work on Android with the Android Manifest.

The one that seems harder to me is platform specific files. Default.png, Entitlements.plist, etc. You might be able to use a similar scheme, but it seems like it would be better if those files were clearly shown in Introjucer.

Again, sorry if I’m missing something obvious.


#11

The only thing you’re missing is that I want the introjucer project to contain all the info it needs to completely rebuild the output files in a repeatable way. I don’t like the idea that when you hitting “save project” will produce a different result, depending on the state of some files that may or may not already exist.

My preferred option would be that after you’ve used xcode to mess about with a plist and get it right, you’d copy that plist into the introjucer’s project settings, and then there’s no ambiguity.


#12

I was thinking that Introjucer would read the options currently set from the plist and display those in the IntroJucer GUI.

It sorta works in the old jucer. Adding a simple watch on the plist to refresh IJ settings means the two would be in sync.

Bruce


#13

@Jules, what confused me was that I may have misread your original suggestion. I took it as having an external XML file that gets repeatedly merged in. To me, an external file seems like having an external file, so I suggested simply reusing info.plist as the external file, since it’s less work for the developer and easier to edit.

But, if by by ‘paste in’ you mean ‘add a list of additional XML keys to the .jucer file’, I like that a lot. Then everything needed to consistently create Builds/… is in the Introjucer world.


#14

Sure, it could have a button to pull in the current contents of the plist file, or let you browse for a plist file to load, or let you paste it in, or whatever.


#15

I’d say re-read the current plist every time IntroJucer gets focus.

Bruce