[Scribus] How to update a link?

[Louis Desjardins]

>Bonjour Louis,
>
>Louis Desjardins schrieb:
>
>>>
>>>What do you other guys think?
>>
>>
>>  I am with you, Christoph. Users can expect Scribus to leave things as
>>  they were on the last save.
>>
>>  In response to Frank Cox's suggestion, I am with Craig. I don't think
>>  we need a specific dialog for that.
>>
>>  Nonetheless, this raises an issue about updating links for images.
>>  IMO, the dialog "? la Quark" is half way good and should not be taken
>>  as a model. What we really need is a feature that would search images
>>  not only at the first level of a folder (like it does in Quark) but
>>  within any element within a (user) designated folder (so, folders
>>  within folder - at any depth). That way, if images have been moved
>>  around for *any* reason, links could easily be recovered "at once",
>>  without the need to check manually for each and every image as it is
>>  right now (unless of course the images are not within that
>>  arborescence). The reference could be the time of modification and/or
>>  other info that devels know better than I do to determine wether an
>>  image was actually modified since it was imported and fitted into a
>>  Scribus page.
>
>I think what you describe is not only Quark's behaviour, but most, if
>not all desktop applications do more or less the same. They will either
>search in the last known directory, the default directory or another
>previously opened directory. The reason is the developers can't know
>which is the best solution and IMHO there is none. Much depends on the
>user's preferences, and it's a matter of taste.

Let's take a real life example. You have a book and for each chapter 
a set of images. These images are stored into an arborescence, 
chapter per chapter. Say you move the mother folder. All your links 
will be lost. To restore them, you'll have to go to every 
subdirectory and relink. It will be fastidious. If you have a 
subdirectories link capacity, it's going to be a breeze. If all 
programs work like that *so far*, well, isn't it time their devels 
know there is a need for better?!

>As for searching in subdirectories, I'm not sure what will be the
>appropriate criteria for deciding if an image is the "right" one. At
>least on Unix-like systems "find" has a universe of opportunities to
>search for files, but which to apply? I think Craig's suggestion to use
>dimensions, resolution, and, perhaps, the image name will be enough.
>Dimension and resolution are reasonable criteria, IMHO, because even if
>another image will be imported, the settings chosen for the previous one
>still make sense. What do you think?

As everybody else, we rely on the folder's belonging and the 
date/time of last modification. This usually work in most cases. I 
can't say for sure what I prefer it to be. What I know for sure is it 
has to be a solution fitted for "human" beings! The name of the file, 
with the date, or the creator, and/or the resolution... This all 
makes sense to me. Adding the arborescence capability would only make 
this work better from the user perspective. The program will not be 
asked to search for a pic anywhere, unless you select your home 
directory... So an organized user will always be well suited with 
such an approach. I think.

To you!

Louis

>
>Christoph
>
>>
>>  Louis
>>
>
>_______________________________________________
>Scribus mailing list
>Scribus at nashi.altmuehlnet.de
>http://nashi.altmuehlnet.de/mailman/listinfo/scribus