I like the idea of the archive being separately searchable instead of showing up in completion and search. As far as the conflict issue, I think if we consider that once Foo is moved to the archive, a newly created item Foo would be considered a different item, so it should be moved as Foo_2. Similarly, if we move Foo to the archive, then it and all sub-pages/attachments would be moved. A later page Foo:Bar would still be a subpage of a new Foo page, so moving Bar to the archive should ideally create Foo_2:Bar.
But the question is, what happens if after moving Foo:Bar to the archive, I then decide to also move Foo to the archive. In this case, Foo should be moved in such a way that it is the parent of the old Foo:Bar that was moved to the archive. Similarly, what happens if we create a page Foo, then move it to the archive. Then create another page Foo, then move it to the archive. Then create a page Foo, a subpage Bar, then move Foo:Bar to the archive, then move Foo to the archive. 1st move -> Archive:Foo 2nd move -> Archive:Foo.2 3rd move -> Archive:Foo:Bar or Archive:Foo.2:Bar or Achivive:Foo.3:Bar? (where Archive:Foo.3 isn't a page just an empty namespace) 4th move -> Arhive:Foo.3 or Archive:Foo.4 Perhaps, for situations when such conflicts exist a dialog could be presented to ask the user. In the 3rd move, the user could select to move Bar to Archive:Foo, Archive:Foo.2 or to create a new namespace Archive:Foo.3. In the 4th move, the user could select to overwrite an existing Archive:Foo, to move it to the empty Archive:Foo.3 (if Bar was moved here in the third move) or to create a new namespace page. Another idea may be for each archive to be timestamped in a manor of speaking, such as 201508171422 However, each directory is just called Foo and displayed as Foo in the GUI. So the directory structure would be: Archive/ f...@201508171422.txt Foo/ b...@201508171422.txt Then later if we archive another Foo, it would be placed as Archive/f...@201508231842.txt. If it had any sub-pages, they would be archived similarly: Archive/ f...@201508171422.txt f...@201508231842.txt Foo/ b...@201508171422.txt b...@201508231842.txt b...@201508231842.txt Then later if we archive another Foo:Bar, it would be placed under Archive/Foo. The GUI would need to respond specially when selecting to view items in the archive. Each time an item in the archive is selected a list would need to be seen to show/select which time stamp to view. Links would work the same. That is Archive:Foo link to Bar would link to Archive:Foo:Bar, and if there is more than one, show the first one (or one with a matching time stamp of the current selection) with a list to select the others. The above idea may work fine, but what about attachments. If I move a page Foo:Bar which has an attachment "image.jpg". We could perhaps rename the attachments, but this may break if two attachments somehow depend on each other to have specific file names. We could have specific attachment directories which contain attachment files only, not actual pages: Archive/ f...@201508171422.txt f...@201508231842.txt Foo@201508231832/ (only attachments, not sub-pages) Foo/ b...@201508171422.txt Bar@201508171422/ (only attachments, not subpages) b...@201508231842.txt b...@201508231842.txt Brian Allen Vanderburg II On 09/13/2015 03:47 AM, Jaap Karssenberg wrote: > I have been drafting a blueprint how archive should work before. > > Personally I keep a big "Archive" namespace and move stuff there to > get it out of the way.One thing that bothers me now is that all these > archive results show up as well in page name completion and when > searching. Ideally I would want this namespace to be special in the > sense that I can search it, but it is not included in the default > results. ( Maybe in the search dialog towards the bottom there could > be a button "show X more results from the archive". ) > > One question though: to make it fully automatic we should also think > about name conflicts. E.g. if I archive "Foo" it moves to > "Archive:Foo" - if I later create a new page "Foo" and archive it > again, I can not move it to "Archive:Foo" again. We can solve this > e.g. by appending a timestamp of the archivation. > > More difficult is the case where we archived "Foo" before, so > "Archive:Foo" exists, but now we created a new page "Foo:Bar" and > archive that one. Do we move it to the existing "Archive:Foo", do we > create a new "Archive:Foo_1", or do we just move "Bar" to the toplevel > in the archive creating "Archive:Bar". > > Which of these options does most justice to the history in which these > pages are archived ? > > Regards, > > Jaap > > > > > On Fri, Sep 11, 2015 at 9:46 AM, Vlastimil Ott <li...@e-ott.info > <mailto:li...@e-ott.info>> wrote: > > Dne 19.8.2015 v 13:45 Jaap Karssenberg napsal(a): > > > For delete, I don't see the use case to have a zim specific > trash can. > But if you think more about archiving, I can see a potential > feature there. > > > +1 Would be nice > > -- > > Vlastimil Ott > > www.e-ott.info <http://www.e-ott.info> > www.opensourceblog.cz <http://www.opensourceblog.cz> > @vlastimilott > > > _______________________________________________ > Mailing list: https://launchpad.net/~zim-wiki > <https://launchpad.net/%7Ezim-wiki> > Post to : firstname.lastname@example.org > <mailto:email@example.com> > Unsubscribe : https://launchpad.net/~zim-wiki > <https://launchpad.net/%7Ezim-wiki> > More help : https://help.launchpad.net/ListHelp > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~zim-wiki > Post to : firstname.lastname@example.org > Unsubscribe : https://launchpad.net/~zim-wiki > More help : https://help.launchpad.net/ListHelp
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~zim-wiki Post to : email@example.com Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp