When linking pictures in a single directory xnview does allways seem to follow them.. Example:
In a director "test":
007-f01b06.jpg -> ../01-Hinflug/007-f01b06.jpg
008-f01b07.jpg -> ../01-Hinflug/008-f01b07.jpg
009-f02b26.jpg -> ../02-Hotel/009-f02b26.jpg
010-f08b09.jpg -> ../02-Hotel/010-f08b09.jpg
027-f01b09.jpg -> ../03-Lemesos/027-f01b09.jpg
When starting "xnview 007-f01b06.jpg" xnview opens "../01-Hinflug/007-f01b06.jpg". The problem is, that xnview stops showing when the next file ist in an other directory. (ex. 009-f02b26.jpg -> ../02-Hotel/009-f02b26.jpg)
Im using SuSE-Linux 9.3. The programm "kuickshow" for example opens the link, so looking all linked pictures is no problem.
I haven't found any option to tell him "don't follow symbolic links".
Has someone an idea?
Greetings
Walter
Always following symbolic links?! (SuSE-Linux 9.3)
Moderators: XnTriq, helmut, xnview
-
- Author of XnView
- Posts: 44933
- Joined: Mon Oct 13, 2003 7:31 am
- Location: France
Re: allways following symbolic links?! (SuSE-Linux 9.3)
Yes a problem...walli wrote:When linking pictures in a single directory xnview does allways seem to follow them.. Example:
In a director "test":
007-f01b06.jpg -> ../01-Hinflug/007-f01b06.jpg
008-f01b07.jpg -> ../01-Hinflug/008-f01b07.jpg
009-f02b26.jpg -> ../02-Hotel/009-f02b26.jpg
010-f08b09.jpg -> ../02-Hotel/010-f08b09.jpg
027-f01b09.jpg -> ../03-Lemesos/027-f01b09.jpg
When starting "xnview 007-f01b06.jpg" xnview opens "../01-Hinflug/007-f01b06.jpg". The problem is, that xnview stops showing when the next file ist in an other directory. (ex. 009-f02b26.jpg -> ../02-Hotel/009-f02b26.jpg)
Im using SuSE-Linux 9.3. The programm "kuickshow" for example opens the link, so looking all linked pictures is no problem.
I haven't found any option to tell him "don't follow symbolic links".
Has someone an idea?
Pierre.
-
- Posts: 1
- Joined: Tue May 16, 2006 9:27 am
Re: allways following symbolic links?! (SuSE-Linux 9.3)
[quote]
[quote="xnview"][quote="walli"]When linking pictures in a single directory xnview does allways seem to follow them.. Example:
In a director "test":
007-f01b06.jpg -> ../01-Hinflug/007-f01b06.jpg
008-f01b07.jpg -> ../01-Hinflug/008-f01b07.jpg
009-f02b26.jpg -> ../02-Hotel/009-f02b26.jpg
010-f08b09.jpg -> ../02-Hotel/010-f08b09.jpg
027-f01b09.jpg -> ../03-Lemesos/027-f01b09.jpg
When starting "xnview 007-f01b06.jpg" xnview opens "../01-Hinflug/007-f01b06.jpg". The problem is, that xnview stops showing when the next file ist in an other directory. (ex. 009-f02b26.jpg -> ../02-Hotel/009-f02b26.jpg)
Im using SuSE-Linux 9.3. The programm "kuickshow" for example opens the link, so looking all linked pictures is no problem.
I haven't found any option to tell him "don't follow symbolic links".
Has someone an idea?
[/quote]
Yes a problem...[/quote]
[/quote]
------- sRiffleComment starts here ----
[b]Suggestions on handling of symbolic link[/b]s, in both WinXP and linux (or anyother BaseOS)needs re-examined, from a number of perspectives.
There are multiple types of symbolic links. Some are essentially alternative file descriptors, to another location on the same disk; Some are logical linkages based on local host tree naming; Some are based on substituting envir variables into the link file;;.. and more.
XnView appears to have limited support for this CRITICAL capability. I say critical, because when one uses symlinks, especially the latter type mentioned, one get elevated to very high level perspectives of "locating a target of a link".
In my local OS envirs, I use the latter type, almost exclusively, to free myself from remembering explicit paths, allowing changes in the envir variables, from which they are composed. Thus I would vote that XnView, alllow for such link types.
Any support of even just some of the below, would vastly improve the user friendliness of XnView.
As an intial implementation step(s) I would suggest that:
[1] BaseOS links: WinXP, Linux, MAC ... be honored as actual links to be possibly followed (navigational), depending on user settings in Options. If the net of the suggestions herein are understood, then one could implement multiple steps which would allow consecutive building of support to the various types of symlinks.
BASIC LINK FUNCTIONALITY OPTIONS
To do this, one should offer Options settings for "Action on DClicking Links" to:
[1A] follow link on DCLick;
[1B] show link as binary; which is necessary with MS WinXP type links of any type
[1C] show link path as literal; which would show how it is encoded., ie., if it is FullyQualifiedPathName, or has encoded envir params
[1D] ignore BaseOS links; (This is essentially the current setting behaviour, at least in WinXP)
From the discussion of SuSE environment, one can see that there are the context awareness of linkages issues to be dealt with.
[1E] show BaseOS links on hover (Y/N);
[1F] force RClick.FollowLInk.How(One of the options noted in the suggestions) This allows temp override of Options settings, since sometimes one needs to look at the composition of the link. The simplest case should RETAIN the "current directory", but show the content in the remote directory... The simplest settings should also be used for the less sophisticated user.
Obviously some of the above are radio buttons, some check boxes
HONORING ICONS in LINKS
[2] show the icon on symlinks,
[2.1] the icon that is encoded in the link
[2.2] the icon of the object, that the links ultimately resolves to;
HONORING ENVIR PARAMS in LINKS
[3] Operating on embedded BaseOS envirParams in links
[3A] Allowing BaseOS envir params to be embedded in links.
[3B] Not Allowing BaseOS envir params in links, ie NOT Resolving them even if they are there;
Really most BaseOS allow this(use of envir variables: WinXP has things like %USERPROFILE% ; linux allows ${Home} ...), but XnView does not honor them, or it treates links as binary mostly.
From the examples in this post, it can be seen that following multiple links from within a directory, implies remembering the primary (starting dir), AND the target dir(s), since links could be chained. This is a more difficult problem, having to do with context management during link traversal. So, implementaiton might be deferred until the prior, literal base OS links are honored.
USES
The use of links should be honored in:
[a] Setting the XnView Capture directory;
[b] Setting xnview Favourities (especially in editing them to allow inclusion of envir params)
[c] navigation of paths of linked directories and/or files
I use a web of chained folders for multi view navigation, one for photo ingest, one for icon editing ... all related to graphical envir manipulation, so links to those areas occur in my GUI_mods directory. As it now stands, with XnView, I cannot have such views... I am forced to remeber explicit paths... The same is true for Desktops, and other areas which contain various type of info, like multimedia types, or locations on a network, or in fact the web.
----end sriffle comment
[quote="xnview"][quote="walli"]When linking pictures in a single directory xnview does allways seem to follow them.. Example:
In a director "test":
007-f01b06.jpg -> ../01-Hinflug/007-f01b06.jpg
008-f01b07.jpg -> ../01-Hinflug/008-f01b07.jpg
009-f02b26.jpg -> ../02-Hotel/009-f02b26.jpg
010-f08b09.jpg -> ../02-Hotel/010-f08b09.jpg
027-f01b09.jpg -> ../03-Lemesos/027-f01b09.jpg
When starting "xnview 007-f01b06.jpg" xnview opens "../01-Hinflug/007-f01b06.jpg". The problem is, that xnview stops showing when the next file ist in an other directory. (ex. 009-f02b26.jpg -> ../02-Hotel/009-f02b26.jpg)
Im using SuSE-Linux 9.3. The programm "kuickshow" for example opens the link, so looking all linked pictures is no problem.
I haven't found any option to tell him "don't follow symbolic links".
Has someone an idea?
[/quote]
Yes a problem...[/quote]
[/quote]
------- sRiffleComment starts here ----
[b]Suggestions on handling of symbolic link[/b]s, in both WinXP and linux (or anyother BaseOS)needs re-examined, from a number of perspectives.
There are multiple types of symbolic links. Some are essentially alternative file descriptors, to another location on the same disk; Some are logical linkages based on local host tree naming; Some are based on substituting envir variables into the link file;;.. and more.
XnView appears to have limited support for this CRITICAL capability. I say critical, because when one uses symlinks, especially the latter type mentioned, one get elevated to very high level perspectives of "locating a target of a link".
In my local OS envirs, I use the latter type, almost exclusively, to free myself from remembering explicit paths, allowing changes in the envir variables, from which they are composed. Thus I would vote that XnView, alllow for such link types.
Any support of even just some of the below, would vastly improve the user friendliness of XnView.
As an intial implementation step(s) I would suggest that:
[1] BaseOS links: WinXP, Linux, MAC ... be honored as actual links to be possibly followed (navigational), depending on user settings in Options. If the net of the suggestions herein are understood, then one could implement multiple steps which would allow consecutive building of support to the various types of symlinks.
BASIC LINK FUNCTIONALITY OPTIONS
To do this, one should offer Options settings for "Action on DClicking Links" to:
[1A] follow link on DCLick;
[1B] show link as binary; which is necessary with MS WinXP type links of any type
[1C] show link path as literal; which would show how it is encoded., ie., if it is FullyQualifiedPathName, or has encoded envir params
[1D] ignore BaseOS links; (This is essentially the current setting behaviour, at least in WinXP)
From the discussion of SuSE environment, one can see that there are the context awareness of linkages issues to be dealt with.
[1E] show BaseOS links on hover (Y/N);
[1F] force RClick.FollowLInk.How(One of the options noted in the suggestions) This allows temp override of Options settings, since sometimes one needs to look at the composition of the link. The simplest case should RETAIN the "current directory", but show the content in the remote directory... The simplest settings should also be used for the less sophisticated user.
Obviously some of the above are radio buttons, some check boxes
HONORING ICONS in LINKS
[2] show the icon on symlinks,
[2.1] the icon that is encoded in the link
[2.2] the icon of the object, that the links ultimately resolves to;
HONORING ENVIR PARAMS in LINKS
[3] Operating on embedded BaseOS envirParams in links
[3A] Allowing BaseOS envir params to be embedded in links.
[3B] Not Allowing BaseOS envir params in links, ie NOT Resolving them even if they are there;
Really most BaseOS allow this(use of envir variables: WinXP has things like %USERPROFILE% ; linux allows ${Home} ...), but XnView does not honor them, or it treates links as binary mostly.
From the examples in this post, it can be seen that following multiple links from within a directory, implies remembering the primary (starting dir), AND the target dir(s), since links could be chained. This is a more difficult problem, having to do with context management during link traversal. So, implementaiton might be deferred until the prior, literal base OS links are honored.
USES
The use of links should be honored in:
[a] Setting the XnView Capture directory;
[b] Setting xnview Favourities (especially in editing them to allow inclusion of envir params)
[c] navigation of paths of linked directories and/or files
I use a web of chained folders for multi view navigation, one for photo ingest, one for icon editing ... all related to graphical envir manipulation, so links to those areas occur in my GUI_mods directory. As it now stands, with XnView, I cannot have such views... I am forced to remeber explicit paths... The same is true for Desktops, and other areas which contain various type of info, like multimedia types, or locations on a network, or in fact the web.
----end sriffle comment