LiveCode Forums.

In getting closer to having a standalone I like I have begun to replace my stand-in buttons with icons/graphics.
As I begin this I have been importing them as controls on a card at the back of my main stack.
I am quickly discovering though that I need a lot of graphics! Not only enabled-not enabled versions but different sizes too.
I have now hit over 40 images and still have a way to go. If I decide to move the app from desktop to tablet, I can see this will further blow out the sheer number required.

My question is: is there a best practice for storing these resources?
The options I see are as follows.
1. Keep using cards at the end of my main stack, adding them as required.
2. Move all image resources to a separate substack.
3. Move all image resources to a separate library stack.
4. Keep all images in a folder within my package and reference them.

So, anyone care to offer the best practice solution with perhaps any pros or cons (why did you choose this particular solution.)

James

Hi James,
I've recently been working with liveCode graphic objects and am pleased with what I can do One of the columns is images one is a liveCode graphic objects, can you tell which one?

My answer to you would be never use images
probably not very helpful, if your icons are pictures ... of say a dog.

Just a small warning, I know graphics are images but it's helpful to use the word "image" when you are talking about an imported or referenced image or icon. It gets confusing with liveCode graphic objects. ummm... one of the columns is just made up of filled rectangles with graphic effects added.

But a button image should only be a couple of k so 80 k isn't bad for mobile.

Simon

Thanks Simon,
If I was using simple "buttons" I would agree and use the graphic effects as you demonstrated.
Perhaps I should have used the term pictograph to describe the images I am using.
I am placing my pictographs as icons on the buttons.
An example being a triangle pointing to the right for "next item" and a triangle pointing to the right but pointing to a vertical bar for "last item". These are probably the simplest examples, but I have icons for such things as; next page, open book, table of contents, find, expand tree, collapse tree, help, clear, search, search history etc.
Having normal (albeit graphically enhanced) buttons simply takes up too much space.

Have you checked out the font collection that comes with the revitalised version of MOBGUI? If it has what u want then a really quick and efficient way to build what u need!

Btw I am building for OSX not iOS.

I have no vested interest in mobgui, but the icons are useful for desktop as well as mobile. If any of the following look like what you need then you may want to investigate further.

cheers

Not quite what I want. But that's ok I am drawing my own for the most part.

My question remains, is there a best practice for where to keep them?

jameshale wrote:My question remains, is there a best practice for where to keep them?

For small images like icons I use your #2 above, putting them into a substack. I often name the substack something like "<appName>RSRC" so it stands out in my stack list in the Project Browser. I also use my *RSRC stack for things like behaviors and other elements needed throughout the project but not directly visible to the user.

If I have a lot of large images I'll often put those in a separate folder along side the app, but I try to avoid that when I can to keep the deployment as simple as possible. But since everything in a stack file is loaded into memory when a stack is opened, using external image files when lots of large images are needed is the only way to avoid having all of them in memory at once.

Thanks Richard,
I was tending this way.
I expect all my images will be small and so a substack with appropriately named cards seems a neat way to both contain and,organize the little beasties.
Hadn't thought of placing behaviours there but it makes sense.
It would also make it easier to manage while in the IDE as there is enough going on in the mainstack.

James