Re: [IB] Cells vs Controls in the Library
Re: [IB] Cells vs Controls in the Library
- Subject: Re: [IB] Cells vs Controls in the Library
- From: Christiaan Hofman <email@hidden>
- Date: Tue, 24 Aug 2010 17:05:19 +0200
On Aug 24, 2010, at 14:45, Stéphane Sudre wrote:
>
> On Aug 24, 2010, at 1:27 PM, Christiaan Hofman wrote:
>
>>
>> On Aug 24, 2010, at 13:07, Stéphane Sudre wrote:
>>
>>>
>>> On Aug 24, 2010, at 12:05 PM, Christiaan Hofman wrote:
>>>
>>>>> [...]
>>>>> To remove some clutter from the Library so that you can find the object you're looking for faster.
>>>>
>>>> You would not get that. The cells are generally setup in a far different way than the controls, because it should be appropriate for a table rather than a stand-alone control. So you would still need two objects. Gain nothing, lose a lot of information, and in fact confuse things because you now lose the context of cells when you need a cell, but get a larger number of "controls or cells."
>>>
>>> Library != Inspector
>>>
>>
>> I AM talking about the Library. Objects in the Library are not classes, they are instances of classes setup in a particular way. For instance you have a bordered text field, and a borderless text field cell. With your change you would still have essentially that.
>
> It's not because it's written it's a cell or a control that this is directly a cell or a control. These are "proxy" objects.
>
What you see are proxy object. In the end it's a real object. For the rest, I don't see what your point is.
>> However you lose the ability to categorize the cells separately, you would just get one huge category of Controls/Cells.
>
> I'm not sure this would change anything except removing the cells section in the list.
>
Isn't your whole point about organization of the Library? And again, it's not removing, it's replacing by something less organized, that's my point.
>>>> Well, that's my point. The drop target knows what to accept because it is told what to expect in the drop and therefore can choose whether to accept. Now you're saying to confuse and remove the information about what it's getting from the drop (is it a cell? is it a control? it's superman!) and it won't be able to make that choice anymore (there's no NSMaybeCellOrControl object, they're in very different parts of the object hierarchy, and see my remark below).
>>>>
>>>>>> It is generally a very bad idea for generic operations (like dropping an objects) to require knowledge about specific peculiarities (like this thing about controls and cells.)
>>>>>
>>>>> Last time I checked, it was possible to add multiple representations of an object in the pasteboard for a drag operations. So would there be something really bad about having for instance both the cell and the control representations in the pasteboard and then let the layout controller decide which one should be used?
>>>>>
>>>>
>>>> Because the layout controller may not be able to make the choice, as I said below.
>>>
>>> See the last part.
>>
>> Where? I don't see anything that invalidates my statement.
>
> You have not provided an example in IB where the layout controller would allow a NSView or NSControl object would be accepted as a drop on a NSControl.
Why would this be relevant? Not every drop is on an NSControl. And I certainly shouldn't need to provide this particular example, because it should be obvious that this CAN be done and is VERY generic: it adds a subview.
>
>>>> Moreover it's not supported by the generic way the IB plugins work.
>>>
>>> That's quite possible. But this is what updates are for.
>>>
>>
>> AFAICS it would be a rather fundamental change, probably making lots of plugins invalid.
>
> Not necessarily if you assume that in 99.99% of cases, a custom control would only accept cells and a custom view would not accept cells.
>
I am talking about the API that would be incompatible.
Also note that dropping multiple items is considered dropping ALL, not dropping ANY. Inconsistency for you.
>>>>>> Moreover, the drop target could in fact accept both controls and cells, and you'd be screwed, for instance when you want it to be a top level object (which is really not such a weird thing.)
>>>>>
>>>>> I would be interested by a good example. For instance, AFAIK, you would need to use a custom view said to be a NSImageView to have a NSImageView accepts a NSButton as a subview in IB.
>>>
>>>> A top level object that can be swapped in using code. There are many cases where this may be useful. Generally, if you don't use it it does not mean it doesn't exist or is not useful.
>>>
>>> Code is not a valid example in my opinion as this is outside IB scope.
>>
>> I think you did not read the word "can," it implies that I am referring to a reason for doing this. The example is "a top level object, which is very much in IB's scope. Or do you refuse to acknowledge that you can or should add top level objects?
>
> If by top level object, you mean an object that is directly instanced in the .xib/.nib document window, I see what you mean. I incorrectly thought you were referring to subviews hierarchy.
>
> But, in practice, I put cells there instead of NSView subclasses as often as I use a 3.5" floppy disk on Mac OS X.
What you do or don't is not relevant. The point is you make something impossible, or at the least making it extremely difficult.
Other examples are in NSTableView and NSMatrix, on which you (essentially) can drop both views and cells, but these drops behave very differently.
Christiaan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden