behavior object properties set prop/get prop

[monte]

Hmm... looks like @mwieder is skim reading again

Pete I think if somebody has made a field pretend to be an option button then they are on their own

There's lots of things we can do to break the IDE and plugins if we want to. Most of the time we don't want to though.

I started on this journey mainly because I wanted to be able to handle engine setprops so a custom control could respond in a reasonable way to changes to properties of that object. Then I realised that when we have a group pretending to be a button we will be able to use this to give it the standard button properties. The only missing thing then is to be able to cast the group as a button so that people could actually refer to it as a button. Not sure if that's possible but it would be cool.

The goal here is to move custom controls closer and closer to being first class objects. Yes the IDE and plugins will need to evolve to deal with that. But in the end if someone has done everything required to make a field an option button then it shouldn't break your plugin because your plugin would be right in treating it as an option button as is presumably the authors intent. It will be some time before we can return true when testing if a control is a button when its a field though

[phaworth]

Not really. The docs are written that way.
If you want to read a read-only property, nothing is preventing you from doing that. You just can't get that property by parsing "the properties".

Ummm, I'm not following you Mark - style and menumode aren't read only are they?

Pete

[mwieder]

Hmm... looks like @mwieder is skim reading again

Hah! No, I really did read the whole thing. Just fixated on the read-only part.

@Pete-

OK - I want to stand behind Monte's post here.

Trying to determine exactly what a control is from a limited palette is a feasible task. Extending that to custom controls starts getting dicey. The knob custom control I've got really should be treated as a scrollbar. It's not one, but if I could subclass a group object from a scrollbar object that's exactly what I'd be doing. So I would explicitly like to fool your plugin into thinking that my custom control is a scrollbar in whatever way I can. While working on it I can treat it as a group of graphic objects, but when I release it into the wild I want it to publish itself as a scrollbar.

I've got a frontscript that allows you to double-click on a label field to edit its contents without having to bring up the property editor. I think the IDE should do this itself, and when we're able to submit pull requests for the IDE I'll be on that one. But I identify a label field by various properties: is it a field, is it locked, etc. I think this is similar to the approach you're taking with your plugin: classification of objects by their properties. I don't necessarily expect this to break with the addition of property overrides. But if it does then the onus is on the custom control developer to ensure that if a control advertises itself as something else, it needs to emulate the something-else's interface to the point where it doesn't break other things.

[phaworth]

Hmm... looks like @mwieder is skim reading again

Hah! No, I really did read the whole thing. Just fixated on the read-only part.

@Pete-

OK - I want to stand behind Monte's post here.

Trying to determine exactly what a control is from a limited palette is a feasible task. Extending that to custom controls starts getting dicey. The knob custom control I've got really should be treated as a scrollbar. It's not one, but if I could subclass a group object from a scrollbar object that's exactly what I'd be doing. So I would explicitly like to fool your plugin into thinking that my custom control is a scrollbar in whatever way I can. While working on it I can treat it as a group of graphic objects, but when I release it into the wild I want it to publish itself as a scrollbar.

I've got a frontscript that allows you to double-click on a label field to edit its contents without having to bring up the property editor. I think the IDE should do this itself, and when we're able to submit pull requests for the IDE I'll be on that one. But I identify a label field by various properties: is it a field, is it locked, etc. I think this is similar to the approach you're taking with your plugin: classification of objects by their properties. I don't necessarily expect this to break with the addition of property overrides. But if it does then the onus is on the custom control developer to ensure that if a control advertises itself as something else, it needs to emulate the something-else's interface to the point where it doesn't break other things.

Hi Mark,
While I understand the concept of what you want to do, to me the correct way to do it is to provide a way for a Livecode scrollbar object to have any shape, not to artificially coerce an object that isn't a scrollbar into thinking it is one. Maybe that's something coming with the custom control module?

I feel that the suggested change breaks a basic design aspect of Livecode which is bound to cause problems, and that using a custom property is a perfectly acceptable way to do it without causing any problems. So I guess we're just going to have to agree to disagree. But that's OK, I suppose that's the beauty of open source!

Pete

[mwieder]

using a custom property is a perfectly acceptable way to do it

Here's where I disagree with that: if I use a custom control (sticking with my faux-scrollbar control) then I have to say

Code: Select all

set the uThumbPosition of...

While that in itself isn't a hardship, it breaks polymorphism.

What if I made a custom progressbar that looked like a rocketship zooming along a straight track, and was otherwise just like a scrollbar?
Now I have to document the fact for users of this control that they have to say "uThumbPosition" instead of "thumbPosition" even though otherwise it's a progressbar.
Packaging documentation with the custom control isn't that big of a chore in this instance, but would get more onerous with more complicated faux controls.
And the worst part is that the user/developer has to think about the name of the custom property instead of using what should be the default property.

For me polymorphism trumps phylogeny. YMMV.

[phaworth]

For me polymorphism trumps phylogeny. YMMV.

Too many long words for me to understand!

I don't disagree with your concept Mark. I don't even disagree with the ability to set a thumbPos property on something that's not a scrollbar. It's the ability to set *any* built in property on any control that concerns me for reasons previously stated.

Once again though, this is the open source world and anyone can do anything they like. I didn't agree with some things RunRev have done in LC in the past so it's no different, except now there's a public forum for me to express my concerns

Pete
PS I'd love to give your circular scrollbar a look.

[monte]

Pete it might be that runrevmark wants me to wind this back so it's only groups that can handle engine properties and that they can only be handled in the group script and behavior. I'd still be happy with that because that covers the core use case. Either way I still don't understand your concerns. Actually I would think those keen to develop IDE plugins etc would welcome the idea because it would make it easier to support custom controls. You create one ui to edit the thumbPosition an it can be reused on the custom control and the regular scrollbar.

[mwieder]

The group case would take care of most things, I think.

I think I do understand Pete's concerns here (yeah, finally, huh?)... he's got an alternate app browser, and in that plugin stack he looks at each control and tries to identify its type by looking at key properties. In the example he gave, if he's looking at an option menu then maybe there are some read-only properties that can quickly identify the button as an option menu. If another control passes itself off as an option menu but is actually a grouped custom control then his control tree will give the wrong information. It *is* a valid concern, even if it's got a pretty narrow scope. I do think there are workarounds for it, although I'm equally sure that there are pitfalls ahead.

That said, I still would back this in the interest of polymorphism.

[phaworth]

Limiting it to groups would be good I think.

I've mentioned the future custom control module that I think is onRunRev's list a couple of times - does anyone know anything about it? I'm just wondering if it may include anything that would help with this situation.

Pete

[monte]

Yeah I'm still confused because if someone has made a control that advertises itself as an option button then the IDE should treat it as an option button. Imagine a custom control that's developed for mobile.. it would be very cool if the IDE presented the option button UI for it. That would give the best user experience.

[mwieder]

I agree ...but it *would* make it a bit harder to work on developing a control while the IDE keeps insisting it's something else, no?

Example: let's say I'm creating a new control called... I don't know... how about a DataGrid.
Inside it's a group of a bunch of grouped controls.
But externally it's a type of field, so I'll have it publish itself as a field.
Now I go back to work on it and... where did all the grouped controls go?

[monte]

well... you're assuming we will one day be able to cast a group as a field... I don't think that's the same as this change.. perhaps remotely related

[mwieder]

I'm sorry... isn't that what you said with

if someone has made a control that advertises itself as an option button then the IDE should treat it as an option button.

[monte]

I'm probably getting a little carried away... I think this comes down to the is type of class stuff (is a datagrid) we were discussing the other day.

[mwieder]

Yeah, merging these streams of conciousness across multiple forum threads is getting confusing