[ANN] Renumbering Images with new IDs

MisterX b.xavier at internet.lu
Sat Dec 17 08:19:19 EST 2005


Alex,

truly insightful ;)

I do use this tool all the time one way or another even If I don't use it
directly... My palettes, my stack's button bars, all use a unified media
stack after a bugzilla by the number of 2449... And it was Tuv's idea too ;)

http://support.runrev.com/bugdatabase/show_bug.cgi?id=2449

I knew it wouldn't be easy a stack to do because images cross lots of
workflow lines in my day to day use of runrev... including development which
is why I think it's worthy of release for it's practical use... Not to
mention the many example scripts inside demo'ing rev's capabilities...

I know the value of simple stacks and do use them myself as possible...
Chipp's stack is inspiration for me too, im not boasting... He gave me an
idea I hope will be as helpful - where as Chipp's stack will prevent id
changes, mine will tell you where the conflicts are - better to be proactive
than sorry ;) 

Now, either I do this before I leave on hollidays or it will be first thing
to do in 2006 or Chipp will free me of the trouble :)

But the real solution would be if images could be or not shared across
stacks... maybe an idea to solve this runrev's image id crisis...

Like stacks, images share an area of conflicts between IDs and names. Stacks
can't have similar names (even if there's a unique ID per stack and damn you
if your substack is the same name as another without warning - hope you read
that Chipp! 

Why should this be a problem when similar fields can coexist?. ID's of
images should be made unique within the engine internally but the problem
persists with duplicate ids at the user level - usually with a crash - not
nice... And the rev icon/pattern chooser doesn't show all images if
duplicate ids exist or where opened before, etc...)... This is a deeply
rooted and antique problem in Rev and MetaCard... 

If stacks and images could be finally addressed as easily as fields (by name
OR ID), it could be easier for everyone... that was the issue with 2449...

To resolve the issue I had to arm myself with XOSMediaLib... Stacks in this
case are another issue... but not unmentioned...

cheerios
Xavier
http://monsieurx.com/taoo - because automating development is possible with
a little programming


> -----Original Message-----
> From: Alex Tweedly [mailto:alex at tweedly.net] 
> Sent: Saturday, 17 December, 2005 13:40
> To: x at monsieurx.com; How to use Revolution
> Subject: Re: [ANN] Renumbering Images with new IDs
> 
> MisterX wrote:
> 
> >[ ........ ] no doubt but I prefer to
> >have features united under a concise manager than having 10 
> disparate 
> >tools to do the same job - usually workflow related jobs in my case.
> >
> >  
> >
> Whereas I generally prefer to have "single-purpose" tools, so 
> that when I need one, having not used it for 6 months, I can 
> read a small doc and know just what it can do.
> 
> If I have a tool I use all the time, then it can be (should 
> be) one of those more powerful, "multi-capable" tools, 
> because in using it all the time I have it to hand and 
> remember how to use it.
> 
> >xosmedialib is a conglomerate of image browsing, editing, id fixing, 
> >conflict finding and more! It's easy to make and fix a little stack 
> >like yours, but limits show up fast. This is what I want to resolve 
> >under one roof...
> >  
> >
> Of course, you use xos and xosmedialib all the time, so a 
> fully integrated set of features is just what you need. I 
> might well find that if I used it all the time, I would love 
> it. But without a compelling need for some feature or 
> capability, there is nothing to carry me through the learning 
> curve of installation and initial usage of a large tool.
> 
> The larger and more powerful a tool is, the more need it has 
> for simple (though complete) documents, tutorials, walkthroughs, etc.
> 
> 
> -- 
> Alex Tweedly       http://www.tweedly.net
> 




More information about the use-livecode mailing list