Re: Creating More Than 1 Of The Same Element/control
Re: Creating More Than 1 Of The Same Element/control
- Subject: Re: Creating More Than 1 Of The Same Element/control
- From: Michael Crawford <email@hidden>
- Date: Thu, 23 May 2013 14:07:32 -0700
I've never found Auto Layout to work well for me. I far prefer ZooLib's
method, despite having to do my design in C++ source.
Erica Sadun his a nice method for handling autorotation for the cases where
Auto Layout isn't going to work. You create two extra views in your nib
just for use as templates, one portrait the other landscape. There is a
numeric field in each Cocoa Touch view that is not used much, called id I
think, but in the templates you give each view a unique id number. Then
you use a method called I think RepositionSubviews that adjusts the layout
coordinates of each on-screen view to be the same as the view with the
corresponding template.
It's in her book The iPhone Cookbook. I recommend it highly.
This enables your portrait windows to be laid out completely differently
from your landscape windows. For example in my App Warp Life, a Conway's
Life game, the user can set the size of the cell grid in the Settings
window. In portrait, the width UITextField is above the height, in
landscape the height is to the right of the width. AutoLayout can't do
that.
On Thu, May 23, 2013 at 1:50 PM, Jay O'Conor <email@hidden> wrote:
> Does Auto Layout not address this issue for you?
>
> Interface Builder Help: Auto Layout: Understanding Constraints<http://developer.apple.com/library/ios/#recipes/xcode_help-interface_builder/articles/UnderstandingAutolayout.html>
>
>
> Regards,
>
> Jay O'Conor
> email@hidden
>
> On May 23, 2013, at 10:44 AM, Michael Crawford <email@hidden>
> wrote:
>
> It is distressing to me that Interface Builder uses explicit, fixed
> coordinates for positioning and sizing its widgets.
>
> That means that, for localization for example, to accomodate the different
> numbers of characters in the various languages, you have to create
> different nibs for each locale.
>
> ZooLib (http://www.zoolib.org/) doesn't have a visual design tool, so your
> UI has to be laid out with explicit C++ code. But it has a very ingenious
> layout mechanism which quite fluidly and intelligently adjusts for changing
> sizes, as well as window resizes.
>
> Harmony, give ZooLib a try. It's a cross-platform application framework.
> It runs in particular on OS X and iOS.
>
> It hasn't had a tarball release in eons. That doesn't mean its development
> has been abandoned, just that all its users get the code from revision
> control.
>
> It's on both sourceforge and github. I haven't tried the github stuff, but
> that will be more current I think. The tarball on sourceforge, while quite
> old, is quite stable.
>
> Best,
>
> Mike Crawford
> email@hidden
>
>
> On Thu, May 23, 2013 at 9:47 AM, Jens Alfke <email@hidden> wrote:
>
>
> On May 22, 2013, at 11:19 PM, Robert Vojta <email@hidden> wrote:
>
> On Thursday, 23. May 2013 at 2:03, Thomas Davie wrote:
>
> I'd really very strongly suggest that you just use Interface Builder.
>
> Your user interface is essentially data, not code. I doubt (and hope) very
> much that you don't write code to fill up a buffer with image data at
> runtime, rather than storing images in data files. The same logic applies
> to your UI – store your archived objects in a nib file, and use IB to edit
> them.
>
>
> I'd very strongly argue with this statement … Personally, I do use IB
>
> just for common things like preferences window with standard controls, etc.
> […] It's not that IB is horrible, but it's about personal taste,
> development speed and lot of other things. For example - try to precisely
> edit auto layout constraints in IB. Sorry, but this is nightmare - mouse
> heavily involved, … I'm much faster with my macros like …
>
> For most developers I’d agree with Thomas, although Robert is right that
> there are valid reasons for not using IB. I just find that in most cases it
> saves me time and frustration. Also, if you work in a team, it makes it
> possible for non-coders to edit the UI: this can be a big time-saver when
> working with UI designers, when instead of telling you to move something up
> 3 pixels they can just open the xib and do it themselves.
>
> However, people are forgetting that the OP, Harmony, has visual
> impairments that make it very difficult for him to use GUIs. And (so I’m
> told) Interface Builder has poor accessibility, particularly around crucial
> actions like wiring up outlets and actions. Back when he started here a few
> months ago he was having a terrible time trying to drive it with VoiceOver,
> and the consensus advice was to put IB aside and create interfaces using
> code instead.
>
> —Jens
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
>
>
> --
> Michael David Crawford
> mdcrawford at gmail dot com
>
> Custom Software Development for the iPhone and Mac OS X
> http://www.dulcineatech.com/custom-software-development/
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
>
--
Michael David Crawford
mdcrawford at gmail dot com
Custom Software Development for the iPhone and Mac OS X
http://www.dulcineatech.com/custom-software-development/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden