relative image paths and custom controls

Moderators: heatherlaine, Klaus, FourthWorld, kevinmiller, LCMark

Post Reply
monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1560
Joined: Fri Jan 13, 2012 1:47 am
Contact:

relative image paths and custom controls

Post by monte » Fri Nov 15, 2013 3:21 am

The move to relative image paths presents some problems for custom control developers. I'd like to see an attempt made to resolve the relative path relative to the stackFiles of behaviors a bit like resolving an image id.

Custom controls themselves will probably need to be delivered as directories (zipped??) of a stack file + relative images. We really need a custom control scheme in the IDE as DropTools currently is only in commercial. Any progress on the stuff that was pulled from 6?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: relative image paths and custom controls

Post by LCMark » Sat Nov 23, 2013 7:01 pm

@monte: The suggestion to resolve relative image files in a similar way to id's is certainly a good idea - I've put it on the internal list to look at for 6.6.

As you say, this does start to present a problem for delivery of custom controls. From the discussion on the list, whilst extending the density mapped mechanism to use resident images (i.e. non-referenced) would help here, I don't think its practical in terms of stackfile size and memory usage. (However, the ability to set the density of a resident image would be useful - perhaps a property that is read-only for referenced images, but settable for resident ones - not also on the list for 6.6).

In terms of the custom control system that was being developed prior to 6.0, not much progress has been made on there, no. The main problem with the approach was that we were struggling to make aggregate controls robust and efficient enough - they really do require substantially more engine support than currently exists. I've actually had some more thoughts on this lately, prompted by your proposed addition of moveControl/showControl messages and my messing around on the feature-widgets branch. (Which should perhaps be the focus of a different thread - once I've figured out how to articulate the thoughts in a suitably structured manner!).

I realize packaging such entities is a slightly different from the actual underlying architecture that runs custom controls, but they are related - if we can come up with the right approach in the engine for aggregate controls, then packaging should be integrated at that level. Image resources and such and how they are searched for is a good example for this.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1560
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: relative image paths and custom controls

Post by monte » Sat Nov 23, 2013 10:15 pm

I wondered about having multiple image "texts" in imported images... The texts of an image would return an array with density keys. While I understand the memory concerns I wonder if these could be worked around by only reading the required data from the stackFile. So it doesn't read in all the texts until something requests them... For the stackFile size concerns they have always been there with imported images and it's possible to design around them.

As for the custom control stuff I'd be really interested to hear about the problems you encountered and your proposed changes when you have time. We really need a built in drag and drop mechanism in the IDE for sharing and using controls ASAP.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: relative image paths and custom controls

Post by LCMark » Sat Nov 23, 2013 10:37 pm

While I understand the memory concerns I wonder if these could be worked around by only reading the required data from the stackFile. So it doesn't read in all the texts until something requests them...
The problem here is that stackfiles are merely a serialization mechanism - they don't have to exist after the objects have been loaded from them (you can load a stackfile and delete the file for example). Admittedly this problem is only in the IDE (which does mean it is perhaps something not to be too concerned about) - it is solvable relatively easily for standalones (since once built the mainstack file is read-only)... When the standalone is built the stackfile is re-saved in a special form spitting out all the non object-hierarcy data (like image text etc.) into a separate file and the stackfile stores indices into it. The stackfile is still loaded into memory completely, but the data file is memory mapped - with references into it being fixed up when the stackfile is deserialized.

Of course, there wouldn't be a problem if stackfiles were like HyperCard - i.e. essentially a on-disk database which pages in required objects as and when needed...
As for the custom control stuff I'd be really interested to hear about the problems you encountered and your proposed changes when you have time. We really need a built in drag and drop mechanism in the IDE for sharing and using controls ASAP.
Well, I should really stop for the night... However, to give you a rough idea - the four main problems I see with the current approach to aggregate controls (because we have no choice right now) are these (all of which are well known):
  • The custom control mechanism clobbers the behavior mechanism. A custom control cannot have a behavior - this makes them very unlike engine controls and less malleable in that you lose that possibility of customizability by using them. (Less consistent with engine controls)
  • By using behaviors the custom controls 'leak' messages into the environment, and indeed things can intercept and clobber messages that they need. (More fragile than custom controls)
  • The aggregated controls (parts) which they use are visible from external scripts. (Causes fragility and inefficiency as there are more controls to sift through in any chunk operation).
  • Encapsulating them with resources is not very easy because they have to use the same resource acquisition mechanisms (e.g. image ids) as the application they are embedded in.
I *think* the solution here is essentially to make it so that we no longer use the 'behavior' property to make aggregate controls. Instead, a custom control is created with an 'intrinsic' behavior which sits 'to the side' of the script-level message path. Its child controls would essentially live in their own message path, and not be visible from the outside; also because they live in (almost) their own world resource acquisition would be easier to define and make specific to the custom control. This intrinsic behavior would be able to completely control what messages are dispatched to the custom control's script and behavior hierarchy.

Now, there are lots of i's to dot and t's to cross but much of what is needed to do this already exists in the engine (behavior hierarchy, container - group - control etc.). Also, existing custom controls should not be at all hard to move to the encapsulated form - and the effort to do so would be more than worth it as they would become substantially more robust in doing so.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1560
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: relative image paths and custom controls

Post by monte » Sat Nov 23, 2013 11:49 pm

The custom control mechanism clobbers the behavior mechanism. A custom control cannot have a behavior - this makes them very unlike engine controls and less malleable in that you lose that possibility of customizability by using them. (Less consistent with engine controls)
Doesn't this go away to an extent with parent behaviours as you can recursively find the last behavior in the chain and set the behavior of that.
By using behaviors the custom controls 'leak' messages into the environment, and indeed things can intercept and clobber messages that they need. (More fragile than custom controls)
Before and after handlers deal with the interception. Could leakage be governed by selectGroupedControls? Arguably a behavior could trap engine messages to avoid this too.
The aggregated controls (parts) which they use are visible from external scripts. (Causes fragility and inefficiency as there are more controls to sift through in any chunk operation).
Hmm... if there isn't a way to make them visible then this could cause a problem for lcVCS. I implemented it from the start to support the custom control scheme that you were working on... objects have a class "com.runrev.engine.<object type>" and if they aren't an engine control at the moment it does nothing but eventually it would copy the current template object so as long as that mechanism worked I guess it would be fine but I worry about controls that store their data internally in some way (not as properties of the control) and don't init themselves based on their current data properly on preOpenControl.
Encapsulating them with resources is not very easy because they have to use the same resource acquisition mechanisms (e.g. image ids) as the application they are embedded in.
Hmm... how would you want this to work differently as images are already resolved against the behavior hierarchy first?

Your solution sounds great but I'm not really sure if the IDE work (at least a large part of it) wouldn't be largely the same either way. Basically we need a custom control repository, a drag and drop tool palette and inclusion in standalones. To make control development part of people's workflow a control repository manager would help. At the IDE level the system could handle regular script based controls, behavior based controls and intrinsic behavior based controls. The reality is there's plenty of custom controls that work fine with the current engine but the IDE offers nothing but an object library that nobody has looked at since version 1.0.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 996
Joined: Thu Apr 11, 2013 11:27 am

Re: relative image paths and custom controls

Post by LCMark » Sun Nov 24, 2013 1:47 am

Doesn't this go away to an extent with parent behaviours as you can recursively find the last behavior in the chain and set the behavior of that.
Well that would apply the behavior to all uses of the custom control; and making your behavior inherit from the custom control behavior means that behavior can only be used for that custom control type.
Before and after handlers deal with the interception. Could leakage be governed by selectGroupedControls? Arguably a behavior could trap engine messages to avoid this too.
You are right about before/after handlers. However, remember that behaviors trigger after the object script so the behavior can only stop leakage after that point - it can't stop messages from contained controls leaking into the object's script. The problem with controlling leakage with selectGroupedControls is that how do you decide what should pass and what shouldn't?
Hmm... if there isn't a way to make them visible then this could cause a problem for lcVCS
It would cause a problem for the IDE too - after all you need to be able to debug such controls. The point here is that (as discussed before) VCS is very much a meta operation, much like most of what the IDE does. There would have to be a mechanism to introspect into such objects for those kinds of purposes.
I worry about controls that store their data internally in some way (not as properties of the control) and don't init themselves based on their current data properly on preOpenControl.
Hmmm - surely if a control does such a thing then it isn't going to work right when you reload a stack containing it. In such a situation I'd class it not working again after export/import through VCS as a case of garbage-in-garbage-out rather than something to be concerned about. (Unless I misunderstand what you mean).
Hmm... how would you want this to work differently as images are already resolved against the behavior hierarchy first?
I'm not sure I expressed that very well. I was more meaning that at the moment the resources for a custom control have to live in the global environment, the id search means that the behavior will find them appropriately, but so could other things that don't actually want those resources (id conflicts and such).
Your solution sounds great but I'm not really sure if the IDE work (at least a large part of it) wouldn't be largely the same either way
Indeed, you are correct. I kind of went off on a slight tangent - the management of 'custom controls' at the IDE level is largely the same regardless of the form they take. Even a simple management system in the IDE now would be better than none, and at least mean we could guarantee some sort of forward compatibility with whatever developments occur in the future.

Anyway, in regards to the ideas expressed above, they do need more thought. The aggregate control thing is something I've been struggling with for quite a while in terms of trying to get a handle on the right architectural approach at the script level.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1560
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: relative image paths and custom controls

Post by monte » Sun Nov 24, 2013 2:02 am

runrevmark wrote: Well that would apply the behavior to all uses of the custom control; and making your behavior inherit from the custom control behavior means that behavior can only be used for that custom control type.
Ah... of course it would.. well you just insert your required behavior hierarchy between the object and the custom control behavior.. not a neat solution but workable (particularly if there's an IDE tool to do it...)
You are right about before/after handlers. However, remember that behaviors trigger after the object script so the behavior can only stop leakage after that point - it can't stop messages from contained controls leaking into the object's script. The problem with controlling leakage with selectGroupedControls is that how do you decide what should pass and what shouldn't?
Everything... if selectGroupedControls is on then the target of mouseEvents etc should be the whole object.
It would cause a problem for the IDE too - after all you need to be able to debug such controls. The point here is that (as discussed before) VCS is very much a meta operation, much like most of what the IDE does. There would have to be a mechanism to introspect into such objects for those kinds of purposes.
As long as it's not an IDE only feature because lcVCS has a CLI built with the standalone engine.
Hmmm - surely if a control does such a thing then it isn't going to work right when you reload a stack containing it. In such a situation I'd class it not working again after export/import through VCS as a case of garbage-in-garbage-out rather than something to be concerned about. (Unless I misunderstand what you mean).
Yeah... probably not worth worrying about.
I'm not sure I expressed that very well. I was more meaning that at the moment the resources for a custom control have to live in the global environment, the id search means that the behavior will find them appropriately, but so could other things that don't actually want those resources (id conflicts and such).
Ah... id conflicts again ;-)
Indeed, you are correct. I kind of went off on a slight tangent - the management of 'custom controls' at the IDE level is largely the same regardless of the form they take. Even a simple management system in the IDE now would be better than none, and at least mean we could guarantee some sort of forward compatibility with whatever developments occur in the future.
If only we could contribute to the IDE ;-)
Anyway, in regards to the ideas expressed above, they do need more thought. The aggregate control thing is something I've been struggling with for quite a while in terms of trying to get a handle on the right architectural approach at the script level.
It's a complicated issue for sure and I wonder if some of the stack view ideas come into play here too.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Simon Knight
Posts: 399
Joined: Wed Nov 04, 2009 11:41 am
Location: Gunthorpe, North Lincs, UK

Re: relative image paths and custom controls

Post by Simon Knight » Thu Jul 26, 2018 10:26 am

Bump!

Having just started to create some custom controls and not wishing to go down the Live Code Builder route did this discussion lead anywhere?
Basically we need a custom control repository, a drag and drop tool palette and inclusion in standalones. To make control development part of people's workflow a control repository manager would help.
Plus, I would suggest that a more robust or obvious method of allocating image icons would be a good idea. At present allocating an image by name may result in the wrong image being set as an icon if two or more images of the same name reside in memory.

Failing any changes to the IDE/Engine then an Edinburgh published intermediate/advanced guide to creating custom controls detailing best practise would be a start.

Simon K.
best wishes
Skids

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6044
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: relative image paths and custom controls

Post by FourthWorld » Thu Jul 26, 2018 3:34 pm

Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Simon Knight
Posts: 399
Joined: Wed Nov 04, 2009 11:41 am
Location: Gunthorpe, North Lincs, UK

Re: relative image paths and custom controls

Post by Simon Knight » Thu Jul 26, 2018 3:56 pm

Hi Richard,

Thanks for the link. I had seen the thread and have visited Ken's web site. However, the thread is dated 2011 and the community does not seem to have embraced the concept, or at least don't seem to be talking about it, which is a pity.

I think that encapsulation of custom controls should be part of the language rather than a third party add on.

best wishes

Simon K.
best wishes
Skids

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6044
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: relative image paths and custom controls

Post by FourthWorld » Thu Jul 26, 2018 6:55 pm

Simon Knight wrote:
Thu Jul 26, 2018 3:56 pm
Hi Richard,

Thanks for the link. I had seen the thread and have visited Ken's web site. However, the thread is dated 2011 and the community does not seem to have embraced the concept, or at least don't seem to be talking about it, which is a pity.
A pity indeed, because this is not an uncommon need, and Ken worked with dozens of developers to draft that spec.

The need hasn't gone away. Ken was just years ahead of his time.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Klaus
Posts: 10171
Joined: Sat Apr 08, 2006 8:41 am
Location: Germany
Contact:

Re: relative image paths and custom controls

Post by Klaus » Thu Jul 26, 2018 7:19 pm

This just came up on the use-lc mailing list and I don't thin BN will mind if I post his awesome solution here.
----------------------------------------------------------------------------------
I think the easiest way would be to copy the images your custom control uses
to the custom controls. then add this code to the group (it is for one button "bOne" and two images
"greenRound" and "redQMark"

Code: Select all

on newGroup
  resolve image "redQMark" relative to button "bOne" of me
  if it is not empty then 
     set the hilitedIcon of button "bOne" to the short id of it
  end if
  resolve image "greenRound" relative to button "bOne" of me
  if it is not empty then 
     set the icon of button "bOne" to the short id of it
  end if
end newGroup
"NewGroup" is a message that the custom control gets when you paste it.
That way the custom control is self contained and when you paste it into a
new stack it will assign the ids of the images to your buttons.

Kind regards
Bernd

That way they are contained in your custom control and the custom control
can be self contained, i.e. can be reused in a different stack.
-----------------------------------------------------------------------------------

bn
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3223
Joined: Sun Jan 07, 2007 9:12 pm
Location: Bochum, Germany

Re: relative image paths and custom controls

Post by bn » Thu Jul 26, 2018 11:21 pm

unfortunately I made a mistake in the code snippet. I should read

Code: Select all

on newGroup
  resolve image "redQMark" relative to button "bOne" of me
  if it is not empty then 
     set the hilitedIcon of button "bOne" of me to the short id of it
  end if
  resolve image "greenRound" relative to button "bOne" of me
  if it is not empty then 
     set the icon of button "bOne" of me to the short id of it
  end if
end newGroup
note the "of me" part in "set the icon of button "bOne" of me to...

This mostly works (not so well if you multiply the custom controls on the same card/stack).

After further fiddling with this Simon and I decided it is most robust to "hard code" the setting of the icons for goups/custom controls that are intended for reuse by copy and paste. Again this assumes that the images you want to use for the icons are contained in the group/custom control and are uniquely named within the group/custom control.

Code: Select all

on newGroup
  set the icon of button "bOne" of me to the short id of image "greenRound of me
  set the hilitedIcon of button "bOne" of me to the short id of image "redQMark" of me
end newGroup
Kind regards
Bernd

Simon Knight
Posts: 399
Joined: Wed Nov 04, 2009 11:41 am
Location: Gunthorpe, North Lincs, UK

Re: relative image paths and custom controls

Post by Simon Knight » Fri Jul 27, 2018 8:36 am

Hi,

Just wanted to say a big thanks to Bernd for the two lines of code quoted above. Originally I failed to discover the syntax that allowed the line to specify exactly which image to use.

Code: Select all

....to the short id of image "greenRound" of me
Simon K.
best wishes
Skids

Post Reply

Return to “Engine Contributors”