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: "Jay O'Conor" <email@hidden>
- Date: Thu, 23 May 2013 13:50:21 -0700
Does Auto Layout not address this issue for you?
Interface Builder Help: Auto Layout: Understanding Constraints
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
_______________________________________________
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