This would also mean that any ObjectGui subclass can also be placed directly in layouts.

This breaks usage of nil and numbers to create constant size or flexible spacing between elements. I believe this would be better off as something like:

if (in.respondsTo(\asView)) { in = in.asView };
out[0] = in;

Oh crikey, you're right. I guess, to do it properly, we need an interface for things that can belong to a layout, perhaps asLayoutMember?

Nah, it seems overboard to add another "as****" method to support one narrow case. Seems like the logic is just fine being "if we can turn it into a view, then do so, else pass it along".

If the layout should support numbers, too, then we also need SimpleNumber { asView { ^this } }. The question is if there is any systematic idea about how QT goes about interpreting different types.

It's hard coded into our implementation of the layout classes: https://github.com/supercollider/supercollider/blob/master/QtCollider/layouts/layouts.hpp#L74

I don't really love having that kind of generic typing pushed down to the C++ level, as it's much better done in sclang-lang - but there's not much to be gained by fiddling with it.

However: I definitely don't think we can do SimpleNumber { asView {} } - the .asSomething pattern is used more or less exclusively to return Something's. It's a very weird exception to have one trivial case where asView returns something that isn't a View.

I suppose the MOST clear way to express this in the Layout code would be something that made explicit the types that were expected, and allowed a chance for trivial .asSomething conversions for each. Something like:

if (not(in.isKindOf(View) || in.isKindOf(Number) || in.isKindOf(Layout))) {
   case 
   { in.respondsTo(\asView) } { in = in.asView }
   { in.respondsTo(\asLayout) } { in = in.asLayout }
   { in.respondsTo(\asNumber) } { in = in.asNumber }
   { // unknown type -- this is an error }
}

It's a bit pedantic, but it seems like it's the most correct.....

It's a very weird exception to have one trivial case where asView returns something that isn't a View.

I would tend to see this as an indication of the message asView being not correctly named. Alternatively, the specific implied types in the array that is used to specify those values within a GridLayout needs to check for different indices differently.

@scztt re your "pedantic" variant: it looks like there should be a better and more idiomatic OOP solution. Testing for those properties is a bit upside down. You'd rather implement a message in each of those classes that returns the appropriate thing.

e.g. asLayoutElement, returning this.asView etc. dependent on the receiver.

I quote:

jamshark70
commented 4 days ago
Oh crikey, you're right. I guess, to do it properly, we need an interface for things that can belong to a layout, perhaps asLayoutMember?

@jamshark70
I think I agree now. :) I'm doing too much C++ programming lately, and was thinking of .asSomething as more or less a typecasting operation. But as I think about it, it's used for more flexible kinds of argument conversion all the time (as. That's much better than the type checking thing. So, is the right thing something like this?

+Number { asLayoutElement { ^this }}
+Layout { asLayoutElement { ^this }}
+View { asLayoutElement { ^this }}
+Object { asLayoutElement { ^this.asView }}

(The last only because making non-View subclasses respond to asView is a common use case)

maybe add

+Array { asLayoutElement { ^this.collect { |x| x.asLayoutElement } }

If that makes sense.

+Array { asLayoutElement { ^this.collect { |x| x.asLayoutElement } }

It's required: arrays are used to attach stretch factors and alignment to views, according to http://doc.sccode.org/Classes/LineLayout.html#*new

Oh, that means we'll need Symbol as well.

And, Array or SequenceableCollection?

best is SequenceableCollection.

General rule, perhaps:

• Array / ArrayedCollection: either where we really want to restrict, or where primitives are in place
• SequenceableCollection: anything that supposes an order and isn't limited to some other specific collection class
• Collection: anything that supposes no order and isn't limited to some other specific collection class