Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relative paths and option to copy pictures and linked files into data directory #163

Open
jendrikseipp opened this issue Mar 20, 2017 · 27 comments · May be fixed by #469
Open

Relative paths and option to copy pictures and linked files into data directory #163

jendrikseipp opened this issue Mar 20, 2017 · 27 comments · May be fixed by #469

Comments

@jendrikseipp
Copy link
Owner

jendrikseipp commented Mar 20, 2017

Originally reported by patrick-kudos at https://bugs.launchpad.net/bugs/855443 (2011-09-21T11:05:21Z):


Currently it is not possible to "migrate" a journal to a different location on your harddrive without loosing the correct link information to pictures and files. If you insert a picture and/or file, an absolute path is inserted into the journal source text.

Would it not be possible to:

  • support relative links
  • provide a choice between relative and absolute paths.

Regards,

Patrick.

@jendrikseipp
Copy link
Owner Author

Original comment by jendrikseipp (2011-09-21T13:10:22Z):


Thanks for the report. It is planned to copy all linked files into a
RedNotebook subdirectory and save the links relatively.

@jendrikseipp
Copy link
Owner Author

Original comment by patrick-kudos (2011-09-21T13:42:29Z):


Hi Jendrik,

Great to hear :-)

Regards,

Patrick.

@jendrikseipp
Copy link
Owner Author

Original comment by jendrikseipp (2012-12-26T14:43:46Z):


Recently a new feature has been added that allows adding links relative to the journal directory:

[My notes from december ""2012-12.txt""]

[A file in the journal directory ""myfile.pdf""]

@jendrikseipp
Copy link
Owner Author

Original comment by patrick-kudos (2012-12-28T08:25:36Z):


Using RN 1.6.5: the relative link option does not work for inserted images, only files. It makes sense to support it for both types.

@jendrikseipp
Copy link
Owner Author

Original comment by jendrikseipp (2012-12-28T10:36:36Z):


Could you please post an example link that doesn't work

@jendrikseipp
Copy link
Owner Author

Original comment by patrick-kudos (2012-12-28T11:10:55Z):


Here are some examples. The first one works (it displays the picture inlines, the other ones do not:

[""file:///C:\Users\patrivdv\Documents\Journals\Dummy\sample-4"".jpg]

[""sample-4"".jpg]

[""sample-4.jpg""]

[test ""sample-4"".jpg]

[test ""sample-4.jpg""]

in Preview mode it looks like:

[sample-4.jpg]

test

test

@jendrikseipp
Copy link
Owner Author

Original comment by jendrikseipp (2012-12-28T12:20:37Z):


Thanks, I forgot to handle images...

@jendrikseipp
Copy link
Owner Author

Original comment by jendrikseipp (2013-01-11T10:57:48Z):


This is now fixed in the development code.

@jendrikseipp
Copy link
Owner Author

Original comment by jamato-krym (2013-02-04T20:11:50Z):


I am using version 1.6.6
Under Windows XP still not work relative link to file, for example:

[test.txt ""file:///full_path_to_diary_folder/files/test.txt""] work in Ubuntu
[test.txt ""file:///full_path_to_diary_folder\files\test.txt""] work in Windows

[test.txt ""files/test.txt""] work in Ubuntu
[test.txt ""files\test.txt""] not work in Windows

but relative link to image work in Windows:
[""files\my_picture"".png]

@jendrikseipp
Copy link
Owner Author

Original comment by patrick-kudos (2013-02-19T12:42:49Z):


I can confirm this behaviour Windows 7 also: relative paths to images work now, but it is broken to ordinary files. Can this be fixed because it used to work!

@jendrikseipp
Copy link
Owner Author

Original comment by jendrikseipp (2013-02-28T01:26:06Z):


Relative links should now work on windows (at least in unreleased dev version).

@jendrikseipp
Copy link
Owner Author

Original comment by entrup (2013-03-05T14:29:46Z):


Test with RedNotebookPortable 1.7.1 on WinXP.
Relative links work fine now. I tested the following cases:

  1. Files in the notebook directory
  2. Files in subfolders of the notebook directory
  3. Accessing files with ..<folder><file>
  4. Images at the notebook directory
  5. Images in subfolders of the notebook directory
  6. Accessing images with ..<folder><image>

@jendrikseipp
Copy link
Owner Author

Original comment by jendrikseipp (2013-03-05T15:09:31Z):


Thanks for your tests! The next step will be to allow users to copy the
files relatively when inserting them.

@jendrikseipp
Copy link
Owner Author

Original comment by naimzard (2013-03-27T10:06:38Z):


Hi Jendrik,
The relative path is enough. No need to have Rednotebook copy all the files to a subdirectory.

If someone cares about keeping the relative path, then they can easily create a folder and put in it their media files.
They even can separate them in different folders and sub-folders as they wish, ex: Audio, Text, Images etc.

What do you think?

@jendrikseipp
Copy link
Owner Author

Original comment by jendrikseipp (2013-04-03T20:50:09Z):


That's true, however an option (not the default) should be added.
Otherwise nobody will notice the new feature.

@jendrikseipp
Copy link
Owner Author

Original comment by dseifert (2013-07-24T09:26:14Z):


Though relative links are supported, they are not added automatically. I.e. I copy all files I want to be part of my journal into the journal directory, but when I insert any of them they are added as relative.

Wouldn't it be a sensible idea to have RNB detect that a file is within the journal directory (data_dir) and convert to a relative link automatically?

@jendrikseipp
Copy link
Owner Author

Original comment by l-t (2015-06-07T15:04:09Z):


Hi there, and sorry if I dig out this old feature request.
But I have to disagree with Naim Zard!

Having Rednotebook copy all drop down files to data directory is an essential feature in my eyes!

I think, it has been agreed on, that having relative links is good, in order to make RB "portable" between different (file) systems. But as long as there is no easy way to sync all media data included with the journal, this is essentially useless and not user friendly.

Longer explanation:
The data directory is usually hidden (and might be integrated in AppData on Windows), so normal end users will never browse there manually. They want to put in files into the journal easily. And they should show up in the journal, so that they can view/access them with 1Click (or integrated for images). This should also work across synchronized systems, thus synchronising added media data is important. The expected complaint of the average user would be: "I added this picture to my journal at my home-PC and synced it with my notebook. Why is the picture not showing up on my laptop?" And than try to explain what symbolic links are, and how they work...
Moreover the expected behaviour form most users would be, that the program is self-consistent / -sufficient / -contained. Again the average user example: Downloading a picture to Downloads folder. Than dragging it to the program. After that, cleaning up the Downloads folder and thereby deleting the picture. And than asking the question: "Why is the picture I added to my journal not showing up any more? I added it to the program!"
I hope these two examples illustrate the problems I have, not copying media files to the journal directory!

As the journal is grouped by month, I would suggest to do the same for the media data. For every yyyy-mm.txt there should be a yyyy-mm folder where media goes to (if files are present). This way it would be easy to share/sync/archive/work on parts of the total journal.

Of course there should be options in the config-menu, where I can select the default behaviour. Optional a question box on drag&drop would be good (like "always ask what to do").
What is the best default behaviour, is clearly a matter of debate and opinion!
To me it always seems, that the average user sees a program as a closed thing, which is not referring to content outside of it ("I added it to the program!"). So in my eyes the "copy in data folder and set a relative link" should be default, to give the expected behaviour to the normal user.

It is my hope, that I could convince you, that saving drag&drop files to the data directory and adding symbolic links, would be an essential addition to RB! As you proposed this feature in reply 1, it is my feeling, that you are aware that this addition would make your program interesting for a wider audience.

@jendrikseipp
Copy link
Owner Author

Let me try to sum up the status of this issue. It has been a while since I last worked on this, but I'm fairly certain that most of the work for the relative paths is done. The main remaining work items are

  1. choose a good destination for files in the journal directory
  2. copy the file or picture into the journal directory when it is inserted via the insert menu

Regarding 1., I like the solution proposed in the last comment: "For every yyyy-mm.txt there should be a yyyy-mm folder where media goes to (if files are present). This way it would be easy to share/sync/archive/work on parts of the total journal."

Regarding 2., the relevant code is in rednotebook/gui/insert_menu.py. The methods on_insert_pic and on_insert_file need to copy the picture or file into the appropriate directory (and create it if it is not present).

I agree with the last commenter that copying files into the journal should be the default and would go so far as to say that we don't need the old behaviour of linked files and pictures outside the journal anymore.

@mrinterestfull
Copy link

  1. Which code we need to update to copy the file that was dragged into the window?
    (I know the path is already there when I drag, we just need to trigger a copy function?)

  2. Since rednotebook uses yearmonth.txt then we should create folder 201803 and place files there in the same spot where rednotebook files are stored. What is the variable name that holds that path?

  3. Lastly if you could point to the file in git repo where this code should be placed?

Thanks
Lucas

@jendrikseipp
Copy link
Owner Author

It's probably a good idea to add a method add_file(self, filename) to the Journal class. The Journal object knows the currently visible date and can create the correct folder and put the file in there and then return the relative filename.

  1. The relevant code is in gui/editor.py in the function on_drag_data_received. You probably have to move the on_drag_data_received to MainWindow, register it there to get called for drag events and call Journal.add_file(filename) from there, since the Editor class has no access to the Journal object.
  2. When a file/picture is inserted, call Journal.add_file(filename). The current date is in Journal.date.
  3. Should be answered by 1. and 2. If you need helper functions have a look in rednotebook/util.

@ruhugu
Copy link

ruhugu commented Jan 2, 2020

I am interested in working on this. Has there been any progress since the last comment?

@jendrikseipp
Copy link
Owner Author

@ruhugu that's awesome! There hasn't been any progress on this since my last two comments above. Please don't hesitate to ask if you need help.

@jendrikseipp
Copy link
Owner Author

@ruhugu Could you make progress? Anything I can help you with?

@ruhugu ruhugu linked a pull request Jan 19, 2020 that will close this issue
@jango
Copy link

jango commented Dec 28, 2020

hi, just wanted to check on the status of this one @jendrikseipp, anything I can help with to move @ruhugu patch forward?

@jendrikseipp
Copy link
Owner Author

Hi @jango, thanks for reaching out! Let's see what @ruhugu responds and then decide how to move forward.

@qerne130
Copy link

Any progress on this feature?

@jendrikseipp
Copy link
Owner Author

There's a pull request, but it needs to be updated. As far as I know, nobody is currently working on this. Would be cool if somebody would continue the work on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants