relative path

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

relative path

Benny Malengier
Jim

where you serious about the fact you would try on the relative path problem?

If so, let me know. I now added to database a method to set and get the media path, an entry to the gramps preference dialog to set this, and export/import of this field to xml.

Next that should happen, and will take a while if I have to do it alone:

1/Everywhere where the database method  .get_save_path() is used, this must be researched. We probably best do a wiki page for that, so we can tick of what is done or not. The save path is now in ~/.gramps/grampsdb, and the user should never be directed there. We should use const.HOME_DIR in most places, and for images the media path, and if that is not set the const.HOME_DIR. In some places where this method is used we probably should make a config key, eg on which dir the AddMedia dialog opens would best be the last used directory.

2/In AddMedia, we must look up how to set relative path. Do we keep the check box on that dialog to set it?

3/On import of data, we must resolve conflicts.
I now just pop up an error dialog on xml read, but perhaps something more sophisticated is needed. Note that I removed the copy of images with relative path on xml import. As the relative path is kept on import, I fail to see why images must be copied that can be several 100Mb large.
Again, something more sophisticated might be in order.

4/gpkg import is special, we should set the relative path to where the images are extracted. However, if database has a relative path, what to do? Again, same problem, ask user intervention, do automatic, ... ?

5/operating systems. Path has the seperator in it ('/'). I don't remember if that is the same on windows. Anyway, windows can have a drive letter added, which must be discarded for linux, or added again for windows.

6/manage media files tool for renaming media file paths. This tool probably needs to be checked in howfar it corresponds to the new way of doing relative path.

If somebody else would start on above points, I could concentrate on adding some of the last things missing in xml so that export/import of 2.2.x data retains all relevant database information.

Benny

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

jgsack
Benny Malengier wrote:
> Jim
>
> where you serious about the fact you would try on the relative path problem?

Yes, I would like to help. I will first have a look at your
notes/outline and see if I can get an overall picture, then get back to
you, but probably not before 24 hours or so.

> <snipped outline>

Regards,
..jim

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

jgsack
James G. Sack (jim) wrote:

> Benny Malengier wrote:
>> Jim
>>
>> where you serious about the fact you would try on the relative path problem?
>
> Yes, I would like to help. I will first have a look at your
> notes/outline and see if I can get an overall picture, then get back to
> you, but probably not before 24 hours or so.
>
>> <snipped outline>

I am anxious to help here, but I'm afraid I still don't _really_
understand just what the problem is. No doubt, a big part is my relative
newness to details of the UI (and maybe development history).

Plunging in regardless...It seems in cases like this, a common
difficulty is that the terms, assumptions or objectives are unclear, and
so I thought it might help (at least me) if I try putting down some some
background ideas, use-cases/user-stories, and remaining questions as I
envision the system interface and behavior.

If this is worthwhile, maybe it should go on a wiki page. If this is all
 irrelevant to the present task, then somebody just tell me I'm looking
in the wrong direction, and I'll stop wasting (everyone's) time.

Anyway, here are some statements of media handling background
assumptions and requirements, as I see it (meaning, of course, subject
to discussion, correction, negotiation, etc).

  Forgive me if I belabor some things which are fairly obvious
  .. I believe this _is_ going somewhere. ;-)

 a1. media objects are not "part of" the Gramps-managed (and perhaps of
most genealogy) databases, rather each media object ultimately refers to
the content of some file in the category commonly called "media", eg, an
image file, a sound file, etc.

 a2. Gramps data does include information about the media, including
(usually) an association with some genealogy entry (eg, a person), and
also (usually) the location of the media file within the computer's file
system.

 a3. location data is sometimes called (filesystem-) "path", or maybe
simply "link".

 a4. Gramps can and will display certain media objects -- at present,
most types of images show as thumbnail images. Full-size display or
presentation of other types of media objects, in general, require
appropriate media tools provided as applications or operating system
components. Furthermore, the media files may be accessed (and
manipulated) directly via usual operating system tools without Gramps
participation in that process. In particular, media files may be erased,
renamed, moved to different locations by operations external to Gramps.

 a5. Media objects can become "missing" by being erased or moved from
the location Gramps has in it's records. And the Gramps location data
may be edited by the Gramps user as desired (including erasing the
location).

==> all the above are possibly useful in a user manual, even though they
    are likely obvious to gramps developers as well as non-novice
    users[0]. (see "Notes", at bottom of email)

==> from the user viewpoint, the handling of media file location is
    somewhat of an unimportant detail (so long as the user can see the
    thumbnails and/or launch an application). I am not even sure there
    are any questions needing user decision on export. I do think there
    are a number of questions to be resolved when it comes to
     importing genealogy data accompanied by media.

==> following is a simplified list of user actions involving paths

 u1. specify path upon media object creation (addmedia)

 u2. change paths for various reasons (media props editor, other?)

 u3. ("batch") change paths by string replacement (media manager)

 u4. export a database with media references; database only, no files

 u5. export a package of database plus media files (WritePkg)
     (respect tree structure seems advisable if not mandatory)

 u6. import database containing media references but no media files

 u7. import a package of database plus media files (ReadPkg)
     (in general, from another computer; another filesystem)
     (where to put these files -- perhaps the big question)
     (handling overwrite is another big concern, I would think)


I can think of additional interesting features/requirements, but this
may be enough to start -- or have I omitted something essential?


==> Technical details that start to make sense and raise questions

 q1. exporting gpkg -- respect tree structure (ok. std archiving [1])

 q2. export empty dirs and leading dir-chain -- keep or prune & trim

 q3. importing gpkg into virgin database -- seems like gpkg extraction
might be easier and more versatile if creation always produced a top
level dir containing all the media files. Then, for instance the extract
operation might more easily extract those media files directly to some
final target location determined via say user-choice.[2]

 q4. importing gpkg into database having live media objects -- need a
policy: overwrite, rename, ask-user.[2][3]


Discussion
----------

In q3, I have injected a personal preference that media should be rooted
in it's own dir within gpkg, so that gpkg always looks like:
  data.gramps
  mediadir
If for no other reason, this appeals to me because mediadir is like a
stand-alone archive that might offer handling or visualization benefits.
To continue my biases, I think I would prefer that any leading empty
dir-chain be trimmed from the tree stored under media, thus the media
dir should have at least one media file and optionally have directories.
I'm also inclined to think that there should normally be no empty leaf
directories. This would be _my_ normalized media tree. I don't know
what, but the gpkg might conceivably contain additional metadata not in
gramps.data or in the media tree.

in q4, I have identified the tarfile module which I would like to study
some more, and maybe write a wrapper and/or some tests once we decide
what the operational overwrite policy should be.

In my way of looking at things, I don't really encounter a relative
versus absolute path question. Perhaps it's because I haven't thought it
through to lowest detail?



- - -
Notes
- - -
[0] I can envision the need and value of advice to the user on how he
might consider organizing his media files. In particular, pointing out
possible organizational benefits when he chooses to import or export things.

[1] standard archiving practices have evolved some security conventions
that I consider sensible and important.  By default, extracting an
archive should not produce any results above the current working
directory, either via absolute paths, backtracking(via "../") or (say)
with symlink tricks. As part of this convention, both the archive
creating and extracting convention strips leading absolute path root
("/") and backtracking-dots (unless told to preserve them). This is how
the *nix tar and similar archivers work. I think many experienced
sysadmins would feel uncomfortable absent that convention. The python
tarfile module seems to operate in -P (preserve absolute paths) by
default, at least in creating archives. I think I'd like to look more at
it to see if I need be worried. ;-)

[2] python module tarfile is presently used for extraction, I believe I
would want to explore whether the overwrite behavior could be
modified/controlled  (or pre-checked for user approval). It's possible
some customization or custom wrapping might be needed to achieve
whatever overwrite behavior we decide to use.

[3] ask-user would seem a friendly option. I might envision either a
pre-scan to get a list of files that would overwrite to get an ok (or
maybe selective checkbox ok?), or a dialog that has a "yes/no" as well
as a "repeat this choice on all further files" option.


So, does any of this make sense?

Regards,
..jim

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

Benny Malengier
Jim,

all makes sense.

Let me give you the use-case of relative/absolute path:

1. I am Benny and have my images in /home/benny/genealogy/images
2. I send John my data, I do not use gpkg because I send him the pictures myself in a zip file, after removing manually images I don't want him to have. (many users are not aware of what gpkg means by the way)
3. John imports the .gramps in a family tree, and extracts the images in C:/blabla/MyDocuments/genealogy.
4. I import the data myself in a family tree so as to discuss with John by only importing the .gramps file, having all images still in their original position.

If I send him my database with absolute paths, all paths are wrong. The media manager tool can solve this but many people don't know that off course. If I set the absolute path to /home/benny/genealogy/images, the images only have a relative path, and on import John can be notified the base path does not exist and how he want to resolve this.
John, being a noob, sets the path of images to C:/blabla/MyDocuments/genealogy, and thinks 'this is a great software'.

The problem of absolute/relative path is solved in gramps by the media manager tool in trunk, but that is a response to a problem after the problem arose, and means many people must be directed to this tool. The tool can also easily do more than you want it to do, making it something less advanced users might feel daunted to use.

We could of course say, don't export to .gramps, always use .gpkg, but obviously this would lead to a revolt.

Benny



2007/12/3, James G. Sack (jim) <[hidden email]>:
James G. Sack (jim) wrote:
> Benny Malengier wrote:
>> Jim
>>
>> where you serious about the fact you would try on the relative path problem?
>
> Yes, I would like to help. I will first have a look at your
> notes/outline and see if I can get an overall picture, then get back to
> you, but probably not before 24 hours or so.
>
>> <snipped outline>

I am anxious to help here, but I'm afraid I still don't _really_
understand just what the problem is. No doubt, a big part is my relative
newness to details of the UI (and maybe development history).

Plunging in regardless...It seems in cases like this, a common
difficulty is that the terms, assumptions or objectives are unclear, and
so I thought it might help (at least me) if I try putting down some some
background ideas, use-cases/user-stories, and remaining questions as I
envision the system interface and behavior.

If this is worthwhile, maybe it should go on a wiki page. If this is all
irrelevant to the present task, then somebody just tell me I'm looking
in the wrong direction, and I'll stop wasting (everyone's) time.

Anyway, here are some statements of media handling background
assumptions and requirements, as I see it (meaning, of course, subject
to discussion, correction, negotiation, etc).

  Forgive me if I belabor some things which are fairly obvious
  .. I believe this _is_ going somewhere. ;-)

a1. media objects are not "part of" the Gramps-managed (and perhaps of
most genealogy) databases, rather each media object ultimately refers to
the content of some file in the category commonly called "media", eg, an
image file, a sound file, etc.

a2. Gramps data does include information about the media, including
(usually) an association with some genealogy entry (eg, a person), and
also (usually) the location of the media file within the computer's file
system.

a3. location data is sometimes called (filesystem-) "path", or maybe
simply "link".

a4. Gramps can and will display certain media objects -- at present,
most types of images show as thumbnail images. Full-size display or
presentation of other types of media objects, in general, require
appropriate media tools provided as applications or operating system
components. Furthermore, the media files may be accessed (and
manipulated) directly via usual operating system tools without Gramps
participation in that process. In particular, media files may be erased,
renamed, moved to different locations by operations external to Gramps.

a5. Media objects can become "missing" by being erased or moved from
the location Gramps has in it's records. And the Gramps location data
may be edited by the Gramps user as desired (including erasing the
location).

==> all the above are possibly useful in a user manual, even though they
    are likely obvious to gramps developers as well as non-novice
    users[0]. (see "Notes", at bottom of email)

==> from the user viewpoint, the handling of media file location is
    somewhat of an unimportant detail (so long as the user can see the
    thumbnails and/or launch an application). I am not even sure there
    are any questions needing user decision on export. I do think there
    are a number of questions to be resolved when it comes to
     importing genealogy data accompanied by media.

==> following is a simplified list of user actions involving paths

u1. specify path upon media object creation (addmedia)

u2. change paths for various reasons (media props editor, other?)

u3. ("batch") change paths by string replacement (media manager)

u4. export a database with media references; database only, no files

u5. export a package of database plus media files (WritePkg)
     (respect tree structure seems advisable if not mandatory)

u6. import database containing media references but no media files

u7. import a package of database plus media files (ReadPkg)
     (in general, from another computer; another filesystem)
     (where to put these files -- perhaps the big question)
     (handling overwrite is another big concern, I would think)


I can think of additional interesting features/requirements, but this
may be enough to start -- or have I omitted something essential?


==> Technical details that start to make sense and raise questions

q1. exporting gpkg -- respect tree structure (ok. std archiving [1])

q2. export empty dirs and leading dir-chain -- keep or prune & trim

q3. importing gpkg into virgin database -- seems like gpkg extraction
might be easier and more versatile if creation always produced a top
level dir containing all the media files. Then, for instance the extract
operation might more easily extract those media files directly to some
final target location determined via say user-choice.[2]

q4. importing gpkg into database having live media objects -- need a
policy: overwrite, rename, ask-user.[2][3]


Discussion
----------

In q3, I have injected a personal preference that media should be rooted
in it's own dir within gpkg, so that gpkg always looks like:
  data.gramps
  mediadir
If for no other reason, this appeals to me because mediadir is like a
stand-alone archive that might offer handling or visualization benefits.
To continue my biases, I think I would prefer that any leading empty
dir-chain be trimmed from the tree stored under media, thus the media
dir should have at least one media file and optionally have directories.
I'm also inclined to think that there should normally be no empty leaf
directories. This would be _my_ normalized media tree. I don't know
what, but the gpkg might conceivably contain additional metadata not in
gramps.data or in the media tree.

in q4, I have identified the tarfile module which I would like to study
some more, and maybe write a wrapper and/or some tests once we decide
what the operational overwrite policy should be.

In my way of looking at things, I don't really encounter a relative
versus absolute path question. Perhaps it's because I haven't thought it
through to lowest detail?



- - -
Notes
- - -
[0] I can envision the need and value of advice to the user on how he
might consider organizing his media files. In particular, pointing out
possible organizational benefits when he chooses to import or export things.

[1] standard archiving practices have evolved some security conventions
that I consider sensible and important.  By default, extracting an
archive should not produce any results above the current working
directory, either via absolute paths, backtracking(via "../") or (say)
with symlink tricks. As part of this convention, both the archive
creating and extracting convention strips leading absolute path root
("/") and backtracking-dots (unless told to preserve them). This is how
the *nix tar and similar archivers work. I think many experienced
sysadmins would feel uncomfortable absent that convention. The python
tarfile module seems to operate in -P (preserve absolute paths) by
default, at least in creating archives. I think I'd like to look more at
it to see if I need be worried. ;-)

[2] python module tarfile is presently used for extraction, I believe I
would want to explore whether the overwrite behavior could be
modified/controlled  (or pre-checked for user approval). It's possible
some customization or custom wrapping might be needed to achieve
whatever overwrite behavior we decide to use.

[3] ask-user would seem a friendly option. I might envision either a
pre-scan to get a list of files that would overwrite to get an ok (or
maybe selective checkbox ok?), or a dialog that has a "yes/no" as well
as a "repeat this choice on all further files" option.


So, does any of this make sense?

Regards,
..jim

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

jgsack
Benny Malengier wrote:

> Jim,
>
> all makes sense.
>
> Let me give you the use-case of relative/absolute path:
>
> 1. I am Benny and have my images in /home/benny/genealogy/images
> 2. I send John my data, I do not use gpkg because I send him the pictures
> myself in a zip file, after removing manually images I don't want him to
> have. (many users are not aware of what gpkg means by the way)
> 3. John imports the .gramps in a family tree, and extracts the images in
> C:/blabla/MyDocuments/genealogy.
> 4. I import the data myself in a family tree so as to discuss with John by
> only importing the .gramps file, having all images still in their original
> position.
>
> If I send him my database with absolute paths, all paths are wrong. The
> media manager tool can solve this but many people don't know that off
> course. If I set the absolute path to /home/benny/genealogy/images, the
> images only have a relative path, and on import John can be notified the
> base path does not exist and how he want to resolve this.
> John, being a noob, sets the path of images to
> C:/blabla/MyDocuments/genealogy, and thinks 'this is a great software'.
>
> The problem of absolute/relative path is solved in gramps by the media
> manager tool in trunk, but that is a response to a problem after the problem
> arose, and means many people must be directed to this tool. The tool can
> also easily do more than you want it to do, making it something less
> advanced users might feel daunted to use.
>
> We could of course say, don't export to .gramps, always use .gpkg, but
> obviously this would lead to a revolt.

OK, thanks for the clear example. Let me chew on that a little, and
maybe restate it in my own words which helps me be sure I understand.

Regards,
..jim

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

Benny Malengier
In reply to this post by Benny Malengier
2007/12/3, Dave Walton <[hidden email]>:
Benny Malengier wrote:
>
> 2. I send John my data, I do not use gpkg because I send him the
> pictures myself in a zip file, after removing manually images I don't
> want him to have. (many users are not aware of what gpkg means by the way)

I would argue that your example user needs to learn about the private
flag, as well as gpkg.  :)


One can say that. However, consider this: you send John information two weeks ago, a gpkg of 300 Mb. Now you have found some errors and changed some data.
Do you want to send him another gpkg, or do you send only the .gramps xml, for him to import into a new empty database?
Most people will not want to send the same media files twice

Benny


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

Dave Walton-3
In reply to this post by jgsack
James G. Sack (jim) wrote:
>
> I am anxious to help here, but I'm afraid I still don't _really_
> understand just what the problem is. No doubt, a big part is my relative
> newness to details of the UI (and maybe development history).
>
>  u5. export a package of database plus media files (WritePkg)
>      (respect tree structure seems advisable if not mandatory)
>  q1. exporting gpkg -- respect tree structure (ok. std archiving [1])

Yes, please.  This affects GEDCOM export as well.
http://bugs.gramps-project.org/view.php?id=1143

> In q3, I have injected a personal preference that media should be rooted
> in it's own dir within gpkg, so that gpkg always looks like:
>   data.gramps
>   mediadir
> If for no other reason, this appeals to me because mediadir is like a
> stand-alone archive that might offer handling or visualization benefits.

That is exactly how I am set up, though my directory is named 'media'.
In essence, we are (manually) maintaining a media library specific to
that particular database, which only contains files relevant to it.
Among other benefits, it minimizes the significance of the
relative/absolute issue, by making all paths relative to 'media'.
Unfortunately, gramps also needs to take into account the people who
have references to media files all over their drives, which is where
things get messy, and absolute paths come into play.

> To continue my biases, I think I would prefer that any leading empty
> dir-chain be trimmed from the tree stored under media, thus the media
> dir should have at least one media file and optionally have directories.

I'd suggest that 'empty' be defined as 'containing only a single
directory'.  That way the trimming would stop at a directory containing
more than one subdirectory, even if there are no files in it.  Otherwise
the contents of those subdirectories could collide.  So the media dir
would have either one or more files (and optional directories) or two or
more directories (and optional files).

> In my way of looking at things, I don't really encounter a relative
> versus absolute path question. Perhaps it's because I haven't thought it
> through to lowest detail?

I suspect the biggest factor is that your 'mediadir' setup mostly
eliminates the issue for you.  If everyone managed their media that way,
then absolute path wouldn't even need to exist in gramps.  But they
don't, so it does.

Dave




-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

Dave Walton-3
In reply to this post by Benny Malengier
Benny Malengier wrote:
>
> 2. I send John my data, I do not use gpkg because I send him the
> pictures myself in a zip file, after removing manually images I don't
> want him to have. (many users are not aware of what gpkg means by the way)

I would argue that your example user needs to learn about the private
flag, as well as gpkg.  :)

Dave



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

Dave Walton-3
In reply to this post by Benny Malengier
Benny Malengier wrote:

> 2007/12/3, Dave Walton <[hidden email] <mailto:[hidden email]>>:
>
>     Benny Malengier wrote:
>     >
>     > 2. I send John my data, I do not use gpkg because I send him the
>     > pictures myself in a zip file, after removing manually images I don't
>     > want him to have. (many users are not aware of what gpkg means by
>     the way)
>
>     I would argue that your example user needs to learn about the private
>     flag, as well as gpkg.  :)
>
> One can say that. However, consider this: you send John information two
> weeks ago, a gpkg of 300 Mb. Now you have found some errors and changed
> some data.
> Do you want to send him another gpkg, or do you send only the .gramps
> xml, for him to import into a new empty database?
> Most people will not want to send the same media files twice

Yes, true, my comment doesn't change the point of your example.  I just
had to point out the private flag, because it wasn't all that long ago I
was doing exactly what you describe, before I stopped to think about the
implications of that private data checkbox on the export form.

Dave



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

jgsack
In reply to this post by Dave Walton-3
(I have another post in-edit replying to Benny's last reply to me)

Here's my reply to DW

Dave Walton wrote:

> James G. Sack (jim) wrote:
>> I am anxious to help here, but I'm afraid I still don't _really_
>> understand just what the problem is. No doubt, a big part is my relative
>> newness to details of the UI (and maybe development history).
>>
>>  u5. export a package of database plus media files (WritePkg)
>>      (respect tree structure seems advisable if not mandatory)
>>  q1. exporting gpkg -- respect tree structure (ok. std archiving [1])
>
> Yes, please.  This affects GEDCOM export as well.
> http://bugs.gramps-project.org/view.php?id=1143

Thanks for pointing this out, I think it's a good additional requirement
 to my starting list.

I'm just now beginning to understand that I missed the part of the
problem dealing with the path specification in the exported database --
which gives the absolute vs relative discussion a little more meaning. =-O

>
>> In q3, I have injected a personal preference that media should be rooted
>> in it's own dir within gpkg, so that gpkg always looks like:
>>   data.gramps
>>   mediadir
>> If for no other reason, this appeals to me because mediadir is like a
>> stand-alone archive that might offer handling or visualization benefits.
>
> That is exactly how I am set up, though my directory is named 'media'.
> In essence, we are (manually) maintaining a media library specific to
> that particular database, which only contains files relevant to it.
> Among other benefits, it minimizes the significance of the
> relative/absolute issue, by making all paths relative to 'media'.
> Unfortunately, gramps also needs to take into account the people who
> have references to media files all over their drives, which is where
> things get messy, and absolute paths come into play.

Well, sure. I expect there's no way to sidestep the possibility that
some particular user will reference media files spanning his entire
filesystem tree. I do think that offering suggestions may help those
people avoid some headaches.

>
>> To continue my biases, I think I would prefer that any leading empty
>> dir-chain be trimmed from the tree stored under media, thus the media
>> dir should have at least one media file and optionally have directories.
>
> I'd suggest that 'empty' be defined as 'containing only a single
> directory'.  That way the trimming would stop at a directory containing
> more than one subdirectory, even if there are no files in it.  Otherwise
> the contents of those subdirectories could collide.  So the media dir
> would have either one or more files (and optional directories) or two or
> more directories (and optional files).

Yeah, I misspoke when I said that there would always be a media file in
my "mediadir", as there might instead be multiple subdirs but no files.

>
>> In my way of looking at things, I don't really encounter a relative
>> versus absolute path question. Perhaps it's because I haven't thought it
>> through to lowest detail?
>
> I suspect the biggest factor is that your 'mediadir' setup mostly
> eliminates the issue for you.  If everyone managed their media that way,
> then absolute path wouldn't even need to exist in gramps.  But they
> don't, so it does.

I picture mediadir as an internal packaging anchor. Creating the package
gathers the media files from wherever and puts them in a tree under
mediadir.

And if I have my preferences, with no unnecessary leading dirchain such as
  /home/jsack/docs/genealogy_media/
or
 c:\Users\jsack\documents\genealogy_media

  (Which is not to say that that information might be provided
   as metadata, in case in might help in subsequent import.)

On import, I envision that files from the package would be extracted to
a base location specified by the user (perhaps using default settings).
This part is handwaving, because the code does not exist.

Ahhh, now I see that I've been assuming that the adjustment of database
paths upon import "just happened" (without thinking in terms of code
details). I'll have to give that part a little more thought.

I still picture the import of files being simply that the file-tree gets
plucked out of mediadir and planted at some (single) graft location on
the user's filesystem. Now I have to add .. and the db paths adjusted
accordingly.

I appreciate your response, and welcome further suggestions and comments
you may have.

Regards,
..jim

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

jgsack
In reply to this post by Benny Malengier
OK, now I see what I've been missing. More detail is interspersed and at
the bottom, but (somewhat) briefly, I've been envisioning (imagining?):

- export causing all media links to be re-written to be relative to some
conceptual base, say "MEDIABASE", a symbolic token in my mind, but
perhaps an actual filesystem path in the exported database. Then again,
maybe it should be a token like MEDIABASE?

- the exported media files (if included) being collected into a tree
stored in the package at say "mediabase"

 XXX.gpkg
   data.gramps
   mediabase
     ..files and dirs..

- and upon import, I've been envisioning a) determining what path the
user wants associated with MEDIABASE in the database he's importing
_into_, and b) extracting the media files (if included) from the package
tree mediabase to user's path equivalent to MEDIABASE.

Another way of saying this is that I've been focusing on the media files
themselves and (quasi-) ignoring the data in the database .. duh!

==> ..read on, but a new general question is "is there merit in how I
have been picturing things working?"


Benny Malengier wrote:
> Jim,
>
> all makes sense.
>
> Let me give you the use-case of relative/absolute path:
>
> 1. I am Benny and have my images in /home/benny/genealogy/images

Sorry, I can't help that ;-)

> 2. I send John my data, I do not use gpkg because I send him the pictures
> myself in a zip file, after removing manually images I don't want him to
> have. (many users are not aware of what gpkg means by the way)

"home/benny/genealogy/images" is clearly meaningful to the exporting
system but is likely not meaningful to the importing system -- although
knowing that the exporter used that path might(?) be useful (metadata?)
in helping the importer decide where to put things on his system.

Handwaving operations warning: in the exported database, the common
dirchain prefix to all media references, here for example
  home/benny/genealogy/images
  (conceivably just "/" for some users!)
is replaced by a dummy path, or maybe just the token "MEDIABASE" (?)

I envision your database (as exported) containing media paths
  MEDIABASE/file1
  MEDIABASE/file2
  MEDIABASE/dirA/fileA1
  MEDIABASE/dirB/fileB1
  MEDIABASE/dirB/fileB2

I envision your zip file containing (say)
    file1
    file2
    dirA
      file A1
    dirB
      file B1
      file B2

> 3. John imports the .gramps in a family tree, and extracts the images in
> C:/blabla/MyDocuments/genealogy.

I would advise John, when he asks where to put the files, to put them in
his own favorite genealogy_images directory, of if he doesn't have one
of those, or doesn't want to mix your stuff in with his, to create a
directory (maybe) c:\Users\John\MyDocuments\bm_images for the purpose.
In either case, you might need to instruct him on the unzip operation.

Handwaving warning here also:
Upon importing the database, John would have to specify where the media
references should be mapped to  -- that is tell where _his "MEDIABASE"_
for this database should be (eg, "c:\Users\John\MyDocuments\bm_images").

> 4. I import the data myself in a family tree so as to discuss with John by
> only importing the .gramps file, having all images still in their original
> position.

On import, you specify _your MEDIABASE_ the same as it always was (or
maybe that's your default, and you just check the "use default" box)

>
> If I send him my database with absolute paths, all paths are wrong. The
> media manager tool can solve this but many people don't know that off
> course. If I set the absolute path to /home/benny/genealogy/images, the
> images only have a relative path, and on import John can be notified the
> base path does not exist and how he want to resolve this.
> John, being a noob, sets the path of images to
> C:/blabla/MyDocuments/genealogy, and thinks 'this is a great software'.
>
> The problem of absolute/relative path is solved in gramps by the media
> manager tool in trunk, but that is a response to a problem after the problem
> arose, and means many people must be directed to this tool. The tool can
> also easily do more than you want it to do, making it something less
> advanced users might feel daunted to use.

So my problem is that I was imagining a mapping operation upon the media
path values occurring on export and import. I guess I realized that the
current code does no such mapping, but was somehow arguing that it
should be and therefor it will be -- sortofa cartesian QED? ;-)

>
> We could of course say, don't export to .gramps, always use .gpkg, but
> obviously this would lead to a revolt.

I'm not sure what you mean there -- perhaps I'm missing some humor?

Recap:
=====
I think I have to add some assumptions, user requirements, and questions

a6. exports and imports may be performed on databases with or without
accompanying media files.

a7. Upon transfer (export/import) of databases between users, between
computers (filesystems), or simply between local databases, the media
locations before export and after import need not be identical, although
they will have matching structures (or at least a common subset in their
filesystem tree structures).

u4a. export in any database format should preserve media location
structure and anticipate the need to map media links onto some unknown
point in the import filesystem.

u6a. import from any database format should allow the user to choose how
to map media locations to fit the needs of his local system and current
database. The terms "graft" and "overlay" come to mind.

u6b. on import, matches in fully-resolved media filepaths with existing
files could conceivably be either intended or accidental -- the user
should be able to specify handling of such collisions.

q1a. export (any) database format: a mixture of absolute and relative
media paths seems potentially troublesome for the user to cope with upon
import or preprocessing.

q1b. exporting media paths (without a mapping step on import) seems like
it might cause problems whether the path is relative ("relative to
what?") _or_ absolute (path does not exist or no write perms).

q1c. Of course we can't solve problems for other apps, but if we have an
export policy (or policies?) and are consistent, then maybe we can
suggest preprocessing recipes to the users of the foreign apps.

q1d. There is still the open question of how to re-write the media paths
with a MEDIABASE place-holder. Above, I wrote
 - "MEDIABASE/..."
but other possibilities might be:
 - "/MEDIABASE/..."
 - "$MEDIABASE/..."
(what else?)

Where ... means the rmaindeer of the filepath to a media file (eg
relative to MEDIABASE). One might argue, how about replacing
"MEDIABASE/" with "./", and I suppose that suggests my thinking may be
maybe-equivalent to lobbying for the "relative" camp, but I still like
an explicit, noticeable, and suggestive token that facilitates import
(or import preprocessing recipes).

  To wander further afield, one might even consider that Gramps
  should use a token (eg a python variable) in its internal data.
  Then (conceivably) export mapping could be dispensed with
  altogether. A complication to this is that adding new media "above
  the base" requires special action (changing the base?). Ugh, nah.

q1e. I don't have current experience here, but I understand that Windows
tolerates "/" in pathspecs. But what ends up in the database in a
Windows environment? And does it matter to us? Hmm, guess I should go
off to read some code.

q2. further remarks: I would argue that the longest dirchain prefix,
that is  dirs that contain no files or multiple subdirs (branch-points),
should be defined as the effective MEDIABASE of the exported-database. I
suggest that this policy makes it easiest to explain to someone how to
adjust the location of things (in the database or in installing
separately transmitted files). If someone thinks the actual value of the
exporter's MEDIABASE might be of value to the importer, then perhaps
that data should be added as a gpkg metadata item?

q4. further remarks: I believe that import is where the toughest
problems lie; where the user's purposes have to be carefully examined,
and maybe divided into sub-cases.

So, does my restatement help any? In the meantime, I will look at the
WritePkg and ReadPkg code a little more to see how my "envisioning"
might relate to the real world.

Regards,
..jim

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

Benny Malengier
2007/12/4, James G. Sack (jim) <[hidden email]>:
OK, now I see what I've been missing. More detail is interspersed and at
the bottom, but (somewhat) briefly, I've been envisioning (imagining?):

- export causing all media links to be re-written to be relative to some
conceptual base, say "MEDIABASE", a symbolic token in my mind, but
perhaps an actual filesystem path in the exported database. Then again,
maybe it should be a token like MEDIABASE?

Yes, Mediabase as you call it is now in trunk, as mediapath of the database, and exported in the header of the .gramps file

- the exported media files (if included) being collected into a tree
stored in the package at say "mediabase"

XXX.gpkg
   data.gramps
   mediabase
     ..files and dirs..

- and upon import, I've been envisioning a) determining what path the
user wants associated with MEDIABASE in the database he's importing
_into_, and b) extracting the media files (if included) from the package
tree mediabase to user's path equivalent to MEDIABASE.

Yes, but we don't want to nag the user, or have computer illiterate users be daunted. We must avoid technical questions on import, and do things without nagging if possible.

Another way of saying this is that I've been focusing on the media files
themselves and (quasi-) ignoring the data in the database .. duh!

==> ..read on, but a new general question is "is there merit in how I
have been picturing things working?"

There is merit

> 2. I send John my data, I do not use gpkg because I send him the pictures
> myself in a zip file, after removing manually images I don't want him to
> have. (many users are not aware of what gpkg means by the way)

"home/benny/genealogy/images" is clearly meaningful to the exporting
system but is likely not meaningful to the importing system -- although
knowing that the exporter used that path might(?) be useful (metadata?)
in helping the importer decide where to put things on his system.

Indeed. I envision many local import/exports. John exporting to a .gramps as backup, and then reusing it later. Then the base path is important as it will not have changed.

Handwaving operations warning: in the exported database, the common
dirchain prefix to all media references, here for example
  home/benny/genealogy/images
  (conceivably just "/" for some users!)
is replaced by a dummy path, or maybe just the token "MEDIABASE" (?)

I envision your database (as exported) containing media paths
  MEDIABASE/file1
  MEDIABASE/file2
  MEDIABASE/dirA/fileA1
  MEDIABASE/dirB/fileB1
  MEDIABASE/dirB/fileB2

Not really needed. We have this in the present code:
file1
dirA/fileA1
means a relative path, wheras
/home/benny/file1
C:\Users\benny\dirA\fileA1
means an absolute path. os.path python module has methods that return true for absolute path, false otherwise

You need to then store at one place what the base path must be for relative files. In 2.2.x that base path is the database save path, but that is no longer possible in trunk, so we add a new metavariable mediapath.

I envision your zip file containing (say)
    file1
    file2
    dirA
      file A1
    dirB
      file B1
      file B2

ok, and containing in the .gramps what the base mediapath was on original system, so as to be able to reuse it if possible

> 3. John imports the .gramps in a family tree, and extracts the images in
> C:/blabla/MyDocuments/genealogy.

I would advise John, when he asks where to put the files, to put them in
his own favorite genealogy_images directory, of if he doesn't have one
of those, or doesn't want to mix your stuff in with his, to create a
directory (maybe) c:\Users\John\MyDocuments\bm_images for the purpose.
In either case, you might need to instruct him on the unzip operation.

Handwaving warning here also:
Upon importing the database, John would have to specify where the media
references should be mapped to  -- that is tell where _his "MEDIABASE"_
for this database should be (eg, "c:\Users\John\MyDocuments\bm_images").

Indeed. That is why I say, the .gramps he imports has a mediapath, if it exists, one could reuse that, if it does not exist or conflict, a dialog can be given to select a media directory.
So my problem is that I was imagining a mapping operation upon the media
path values occurring on export and import. I guess I realized that the
current code does no such mapping, but was somehow arguing that it
should be and therefor it will be -- sortofa cartesian QED? ;-)

For gpkg the code will do some mapping and change media paths in the data. Also GEDCOM does this I think.

Recap:
=====
I think I have to add some assumptions, user requirements, and questions

a6. exports and imports may be performed on databases with or without
accompanying media files.

yes

a7. Upon transfer (export/import) of databases between users, between
computers (filesystems), or simply between local databases, the media
locations before export and after import need not be identical, although
they will have matching structures (or at least a common subset in their
filesystem tree structures).

u4a. export in any database format should preserve media location
structure and anticipate the need to map media links onto some unknown
point in the import filesystem.

u6a. import from any database format should allow the user to choose how
to map media locations to fit the needs of his local system and current
database. The terms "graft" and "overlay" come to mind.

u6b. on import, matches in fully-resolved media filepaths with existing
files could conceivably be either intended or accidental -- the user
should be able to specify handling of such collisions.

yes, an overwrite box, with possiblity don't ask again.

q1a. export (any) database format: a mixture of absolute and relative
media paths seems potentially troublesome for the user to cope with upon
import or preprocessing.

yes. For export to .gramps I would allow it. For export to gpkg or GEDCOM, i would do a mapping to new location, with all paths relative, so no longer absolute paths. That is, we specifically identify GEDCOM and gpkg as the data formats for interchange between researchers, whereas .gramps is for interchange, backup, quick overview, ...
If the media manager tool allows to change in the database all absolute paths to relative paths the same way as export to gpkg does it in the exported .gramps, then one can make a .gramps export datafile identical to the .gramps file in the .gpkg exported file.

In other words, I would change in trunk from working standard with absolute paths, to working standard with relative paths set against the global media path.

q1b. exporting media paths (without a mapping step on import) seems like
it might cause problems whether the path is relative ("relative to
what?") _or_ absolute (path does not exist or no write perms).

for backward compatibility import of a mix will be needed.
yes a mix can be a problem, we could however always work with relative on the export _without_  moving files, so eg
../../strangeplace/fileA
which is a relative path that gramps will have no problem working with.

q1c. Of course we can't solve problems for other apps, but if we have an
export policy (or policies?) and are consistent, then maybe we can
suggest preprocessing recipes to the users of the foreign apps.

other apps are GEDCOM. For import of GEDCOM in GRAMPS, we should assume no mediapath is given, and ask for it, perhaps first check if the mediadir is in the directory where the GEDCOM is.
Other applications will work the same, they will assume the media to be relative to where the GEDCOM is, so if you make a GEDCOM zip with media files, after extraction of the zip, import of GEDCOM should just work.

q1d. There is still the open question of how to re-write the media paths
with a MEDIABASE place-holder. Above, I wrote
- "MEDIABASE/..."
but other possibilities might be:
- "/MEDIABASE/..."
- "$MEDIABASE/..."
(what else?)

so not like this, but as we do now. In the header of .gramps, in the metadata of grdb a media path. For other formats (GEDCOM, geneweb) we assume the mediapath is the savepath of the GEDCOM file. Then in the data, the images are depicted with relative paths, so without root or without drive letter for windows.

Where ... means the rmaindeer of the filepath to a media file (eg
relative to MEDIABASE). One might argue, how about replacing
"MEDIABASE/" with "./", and I suppose that suggests my thinking may be
maybe-equivalent to lobbying for the "relative" camp, but I still like
an explicit, noticeable, and suggestive token that facilitates import
(or import preprocessing recipes).

  To wander further afield, one might even consider that Gramps
  should use a token (eg a python variable) in its internal data.
  Then (conceivably) export mapping could be dispensed with
  altogether. A complication to this is that adding new media "above
  the base" requires special action (changing the base?). Ugh, nah.

q1e. I don't have current experience here, but I understand that Windows
tolerates "/" in pathspecs. But what ends up in the database in a
Windows environment? And does it matter to us? Hmm, guess I should go
off to read some code.

I see some places where os.sep is not used, but hardcoded "/" instead. I would think it hence works as I see no bug reports against those tools/modules.
We would have to try to know for sure.

q2. further remarks: I would argue that the longest dirchain prefix,
that is  dirs that contain no files or multiple subdirs (branch-points),
should be defined as the effective MEDIABASE of the exported-database. I
suggest that this policy makes it easiest to explain to someone how to
adjust the location of things (in the database or in installing
separately transmitted files). If someone thinks the actual value of the
exporter's MEDIABASE might be of value to the importer, then perhaps
that data should be added as a gpkg metadata item?

I added it in trunk to .gramps, so gpkg also.
However, there is no check if it is the longest dirchain.
We could add the following too:
1/in addmedia, on adding a path, give a warning if the path is outside the mediapath of the database
2/media manager: add option to set the optimal mediapath of the database, so search for longest dirchain prefix

q4. further remarks: I believe that import is where the toughest
problems lie; where the user's purposes have to be carefully examined,
and maybe divided into sub-cases.

Yes, we need some if statements here, that's for sure.

So, does my restatement help any? In the meantime, I will look at the
WritePkg and ReadPkg code a little more to see how my "envisioning"
might relate to the real world.

Ok to look there, but this mediapath change will influence all existing importers and exporters. And we must maintain backward compatibility in .gramps format.

Benny

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

Dave Walton-3

Most everything in the last couple of posts has sounded pretty good.  So
rather than commenting point by point, just pretend I said "yup" and
nodded a lot.  Just two comments, below...

Benny Malengier wrote:
> 2007/12/4, James G. Sack (jim) <[hidden email]
> <mailto:[hidden email]>>:
>
>     u6b. on import, matches in fully-resolved media filepaths with existing
>     files could conceivably be either intended or accidental -- the user
>     should be able to specify handling of such collisions.
>
> yes, an overwrite box, with possiblity don't ask again.

I'm sure this is obvious, but I want to emphasize the need for great
care when importing media files from a .gpkg.  Except in the case of
importing a newer version of a previously imported database, overwriting
media files is probably not the desired behavior (and perhaps sometimes
not even then?).  There is a very real possibility of overwriting a file
that shouldn't have been, especially if the imported relative paths
happen to have '../' in them.

> for backward compatibility import of a mix will be needed.
> yes a mix can be a problem, we could however always work with relative
> on the export _without_  moving files, so eg
> ../../strangeplace/fileA
> which is a relative path that gramps will have no problem working with.

As noted above, that sort of relative path brings risk.  Even without
overwriting, it could leave files strewn around where they shouldn't be.
 So please be careful.  :)

Dave





-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

Eero Tamminen-3
In reply to this post by Dave Walton-3
Hi,

Some comments without reading all of previous posts carefully through...

On Monday 03 December 2007, Dave Walton wrote:

> James G. Sack (jim) wrote:
> > I am anxious to help here, but I'm afraid I still don't _really_
> > understand just what the problem is. No doubt, a big part is my
> > relative newness to details of the UI (and maybe development history).
> >
> >  u5. export a package of database plus media files (WritePkg)
> >      (respect tree structure seems advisable if not mandatory)
> >  q1. exporting gpkg -- respect tree structure (ok. std archiving [1])
>
> Yes, please.  This affects GEDCOM export as well.
> http://bugs.gramps-project.org/view.php?id=1143
>
> > In q3, I have injected a personal preference that media should be
> > rooted in it's own dir within gpkg, so that gpkg always looks like:
> >   data.gramps
> >   mediadir
> > If for no other reason, this appeals to me because mediadir is like a
> > stand-alone archive that might offer handling or visualization
> > benefits.
>
> That is exactly how I am set up, though my directory is named 'media'.
> In essence, we are (manually) maintaining a media library specific to
> that particular database, which only contains files relevant to it.
> Among other benefits, it minimizes the significance of the
> relative/absolute issue, by making all paths relative to 'media'.
> Unfortunately, gramps also needs to take into account the people who
> have references to media files all over their drives, which is where
> things get messy, and absolute paths come into play.
>
> > To continue my biases, I think I would prefer that any leading empty
> > dir-chain be trimmed from the tree stored under media, thus the media
> > dir should have at least one media file and optionally have
> > directories.
>
> I'd suggest that 'empty' be defined as 'containing only a single
> directory'.  That way the trimming would stop at a directory containing
> more than one subdirectory, even if there are no files in it.  Otherwise
> the contents of those subdirectories could collide.  So the media dir
> would have either one or more files (and optional directories) or two or
> more directories (and optional files).
>
> > In my way of looking at things, I don't really encounter a relative
> > versus absolute path question. Perhaps it's because I haven't thought
> > it through to lowest detail?
>
> I suspect the biggest factor is that your 'mediadir' setup mostly
> eliminates the issue for you.  If everyone managed their media that way,
> then absolute path wouldn't even need to exist in gramps.  But they
> don't, so it does.

What if Gramps would go through all the media files, check whether
the paths are under a suitable media dir, and if not, ask user whether
the images should be copied or moved there (with possibly an option
to have checkbox list to select this per file)? This might also be a global
Gramps configuration option.

The reason why I started to think about this is the problem of "exporting"
the database with images and then importing it back.  If you don't have
images in specific paths, how you know whether the image is new or already
exists?  With MD5 sums?


The differences between .gramps and .gpkg (and CD) exports seem a bit
contrived to me.  Couldn't the differences be just checkboxes:
   [x] Include media files
?
(using tar.gz for .gramps instead of .gz seems to me something that
Gramps could handle in a compatible way and transparently to user.)


        - Eero

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

jgsack
Eero Tamminen wrote:

> Hi,
>
> Some comments without reading all of previous posts carefully through...
>..
>
> What if Gramps would go through all the media files, check whether
> the paths are under a suitable media dir, and if not, ask user whether
> the images should be copied or moved there (with possibly an option
> to have checkbox list to select this per file)? This might also be a global
> Gramps configuration option.
>
> The reason why I started to think about this is the problem of "exporting"
> the database with images and then importing it back.  If you don't have
> images in specific paths, how you know whether the image is new or already
> exists?  With MD5 sums?

I agree that it's important to anticipate various corner cases in
general. Inefficiencies or strange (to us) organizations perhaps to some
degree should at least be discussed, and mitigated to the extent it
doesn't require program "heroics". I also like the idea of giving advice
to the user in the manual or help form.

I also believe we must continually ask whether any of these activities
constitute a danger of getting too far away from our primary (genealogy)
mission. For example, even if it's easy, I might be inclined to avoid
adding ("unnecessary") file management features.

Having said that, I'm thinking that such "how about" questions are great
brainstorming and especially valuable if composed in a user story format:

 User wants to: ... (objective)
  by: ... (interaction)
 User expects Gramps to: ... (results)
... (discussion, as required)

I don't mean to criticize your suggestion, but to clarify it in my mind.
sorry if I missed the point.

And, my words on avoiding of file management operations was kind of a
oh, by-the-way, "I've been meaning to preach about this" thought that
your suggestion triggered. :-)

>
> The differences between .gramps and .gpkg (and CD) exports seem a bit
> contrived to me.  Couldn't the differences be just checkboxes:
>    [x] Include media files

I do this is a point worth additional discussion .. maybe later, though?

> ?
> (using tar.gz for .gramps instead of .gz seems to me something that
> Gramps could handle in a compatible way and transparently to user.)

I would say .gramps is more like .gz, and .gpkg like a .tar.gz (or .tgz)

As I remember, there has been something like a project policy (or maybe
a working practice) decision on this question -- I'm not sure
where/when. To me the current policy/practice seems ok and not in any
danger of setting precedent that cannot be reexamined should there be a
strong case for change.

Regards,
..jim

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

Dave Walton-3
James G. Sack (jim) wrote:

> Eero Tamminen wrote:
>>
>> The differences between .gramps and .gpkg (and CD) exports seem a bit
>> contrived to me.  Couldn't the differences be just checkboxes:
>>    [x] Include media files
>
> I do this is a point worth additional discussion .. maybe later, though?
>
>> ?
>> (using tar.gz for .gramps instead of .gz seems to me something that
>> Gramps could handle in a compatible way and transparently to user.)
>
> I would say .gramps is more like .gz, and .gpkg like a .tar.gz (or .tgz)

This isn't later, but since I may or may not be around later, figured
I'd just pipe up now.  Feel free to come back and read this in the
archive later. :)
Eero has a very good point here, from a simplicity of user experience
perspective.

When the user wants to export their database, they really aren't
interested in .gramps vs .gpkg or .gz vs .tar.gz.  They just want to do
an export, with or without media.  Understanding and selecting a file
format is a distraction, when Gramps could just do the right thing
without bothering them with such details.

When Gramps imports a file, it could automatically determine whether the
file is .tar.gz or .gz, and whether it contains media files, and act
accordingly.  So why do there need to be different menu options and file
extensions?

Imagine that Gramps always exports to a .gpkg file, and that file
happens to be a .gz or .tar.gz, depending on whether media is included.
 Or perhaps it always needs to be a .tar.gz for backward compatibility,
but might contain just the data file and no media.  Either way, you then
have a single file type (from the user's perspective, at least), and the
UI is reduced to the single checkbox Eero mentions.  Nice and simple.

> As I remember, there has been something like a project policy (or maybe
> a working practice) decision on this question -- I'm not sure
> where/when. To me the current policy/practice seems ok and not in any
> danger of setting precedent that cannot be reexamined should there be a
> strong case for change.

True, it's not broken, so it's low priority.  But there's certainly room
for usability improvements when someone has the time.

We now return you to your previously scheduled absolute/relative path
discussion...

Dave



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: relative path

jgsack
Dave Walton wrote:

> James G. Sack (jim) wrote:
>> Eero Tamminen wrote:
>>> The differences between .gramps and .gpkg (and CD) exports seem a bit
>>> contrived to me.  Couldn't the differences be just checkboxes:
>>>    [x] Include media files
>> I do this is a point worth additional discussion .. maybe later, though?
>>
>>> ?
>>> (using tar.gz for .gramps instead of .gz seems to me something that
>>> Gramps could handle in a compatible way and transparently to user.)
>> I would say .gramps is more like .gz, and .gpkg like a .tar.gz (or .tgz)
>
> This isn't later, but since I may or may not be around later, figured
> I'd just pipe up now.  Feel free to come back and read this in the
> archive later. :)
> Eero has a very good point here, from a simplicity of user experience
> perspective.
>
> When the user wants to export their database, they really aren't
> interested in .gramps vs .gpkg or .gz vs .tar.gz.  They just want to do
> an export, with or without media.  Understanding and selecting a file
> format is a distraction, when Gramps could just do the right thing
> without bothering them with such details.
>
> When Gramps imports a file, it could automatically determine whether the
> file is .tar.gz or .gz, and whether it contains media files, and act
> accordingly.  So why do there need to be different menu options and file
> extensions?
>
> Imagine that Gramps always exports to a .gpkg file, and that file
> happens to be a .gz or .tar.gz, depending on whether media is included.
>  Or perhaps it always needs to be a .tar.gz for backward compatibility,
> but might contain just the data file and no media.  Either way, you then
> have a single file type (from the user's perspective, at least), and the
> UI is reduced to the single checkbox Eero mentions.  Nice and simple.
>
>> As I remember, there has been something like a project policy (or maybe
>> a working practice) decision on this question -- I'm not sure
>> where/when. To me the current policy/practice seems ok and not in any
>> danger of setting precedent that cannot be reexamined should there be a
>> strong case for change.
>
> True, it's not broken, so it's low priority.  But there's certainly room
> for usability improvements when someone has the time.
>
> We now return you to your previously scheduled absolute/relative path
> discussion...

I like to see these remarks. Did not intend to convey any moderating
influences (even if I had any <heh>).

I wish someone would start a "Warts and Gripes" wiki page...

Regards,
..jim

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Mobile data

Dave Walton-3
James G. Sack (jim) wrote:
>
> I wish someone would start a "Warts and Gripes" wiki page...
>

Tempting.  But isn't that what feature requests in the bug tracker are for?

But speaking of warts, I'm wondering what the status is of one
particular wart that I am currently facing.

The database in 2.2 has the well-known problem of storing the data in
two locations:  The location you specify to save the file, and the
.gramps directory.  I've been using a loaned computer from work, which I
have to turn back in this week.  Knowing this was coming someday, I've
saved the database and media files on an external drive, but there's
still the data in .gramps that goes with the computer.  I've backed up
all the necessary files, but when I restore them to the new computer,
I'll be tying the data to that computer again.  And I'd really rather
not have any personal data on the main drive of the new computer.

The wiki has a nice explanation of how this situation is being improved
in 3.0 with the new Family Tree Manager.  But it says this is done by
moving the whole database into .gramps, which still leaves the data tied
to a particular account on a particular computer.

The ideal solution, in my little dream world, would be to have Gramps
and all its dependencies and data installed standalone on a removable
drive (USB flash drive, iPod, cell phone, whatever).  So I could connect
the drive to any computer, run Gramps and do what I need to do, then
shut it down and remove it, leaving no traces on the host computer.
That would be really awesome when visiting relatives, and I could store
the drive with all my data in a fireproof lockbox when not in use.

An alternate solution would be to have Gramps installed on the host
computer, but be able to tell it to use the removable drive for all data
instead of the user home directory, so that when the drive is removed,
all data on it is intact, and there is nothing of value (or personal
details) left on the host.  I am hoping that this solution will be
possible in 3.0.

So the question is...  What is the current status and future plans for
database handling in regard to these scenarios?

Thanks,
Dave


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mobile data

Don Allingham-3

On Tue, 2007-12-04 at 18:37 -0800, Dave Walton wrote:

> The database in 2.2 has the well-known problem of storing the data in
> two locations:  The location you specify to save the file, and the
> .gramps directory.  I've been using a loaned computer from work, which I
> have to turn back in this week.  Knowing this was coming someday, I've
> saved the database and media files on an external drive, but there's
> still the data in .gramps that goes with the computer.  I've backed up
> all the necessary files, but when I restore them to the new computer,
> I'll be tying the data to that computer again.  And I'd really rather
> not have any personal data on the main drive of the new computer.
>
> The wiki has a nice explanation of how this situation is being improved
> in 3.0 with the new Family Tree Manager.  But it says this is done by
> moving the whole database into .gramps, which still leaves the data tied
> to a particular account on a particular computer.

You are misinterpreting the situation.

In 3.0, all databases are saved in a directory. By default, this is
~/.gramps.

However, in the preferences, you can change this location to anything
you like. If you put it in a shared location, multiple people can access
it (but only one person at a time).

Don



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Mobile data

jgsack
In reply to this post by Dave Walton-3
Dave Walton wrote:

> James G. Sack (jim) wrote:
>> I wish someone would start a "Warts and Gripes" wiki page...
>>
>
> Tempting.  But isn't that what feature requests in the bug tracker are for?
>
> But speaking of warts, I'm wondering what the status is of one
> particular wart that I am currently facing.
>
> The database in 2.2 has the well-known problem of storing the data in
> two locations:  The location you specify to save the file, and the
> .gramps directory.  I've been using a loaned computer from work, which I
> have to turn back in this week.  Knowing this was coming someday, I've
> saved the database and media files on an external drive, but there's
> still the data in .gramps that goes with the computer.  I've backed up
> all the necessary files, but when I restore them to the new computer,
> I'll be tying the data to that computer again.  And I'd really rather
> not have any personal data on the main drive of the new computer.
>
> The wiki has a nice explanation of how this situation is being improved
> in 3.0 with the new Family Tree Manager.  But it says this is done by
> moving the whole database into .gramps, which still leaves the data tied
> to a particular account on a particular computer.
>
> The ideal solution, in my little dream world, would be to have Gramps
> and all its dependencies and data installed standalone on a removable
> drive (USB flash drive, iPod, cell phone, whatever).  So I could connect
> the drive to any computer, run Gramps and do what I need to do, then
> shut it down and remove it, leaving no traces on the host computer.
> That would be really awesome when visiting relatives, and I could store
> the drive with all my data in a fireproof lockbox when not in use.
>
> An alternate solution would be to have Gramps installed on the host
> computer, but be able to tell it to use the removable drive for all data
> instead of the user home directory, so that when the drive is removed,
> all data on it is intact, and there is nothing of value (or personal
> details) left on the host.  I am hoping that this solution will be
> possible in 3.0.
>
> So the question is...  What is the current status and future plans for
> database handling in regard to these scenarios?

Hmmm, have you tried something like starting gramps  with some
environment variable help?

In *nix, it should even work as from the command line:
  HOME=/dev/sdb1/GDB gramps

Or on Windows, maybe a .bat file (some guesswork here -- not tested!)
  oup=%USERPROFILE%
  set USERPROFILE=e:\GDB
  gramps
  set USERPROFILE=%oup%
This probably needs more help. Maybe pass the drive letter as a parm.


Anyway, the idea is that the database and preferences would both be in
the GDB dir of the removable device.

Regards,
..jim

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12