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:[EMAIL PROTECTED] > Sent: Saturday, 17 December, 2005 13:40 > To: [EMAIL PROTECTED]; 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 > _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution