Ciao Scott and Mark Mark S. wrote: > > Hello Scott, > > It's possible that you are our entire user base ;-) >
lol! A few footnotes to Mark's replies ... On Thursday, August 1, 2019 at 5:18:16 PM UTC-7, Scott Kingery wrote: >> >> * Are you planning to allow the launch of a wiki from within the menu? >> > > Would that be helpful? If there's 20 wikis, would the user need to select > and launch? > I been looking at and thinking about this. It would be very easy to launch from Polly. The issue is what is launched and how. Say you had one settings file (you could have several for different situation) with, say, 4 wiki listed and they all got launched on a menu choice or, say, a -run mode of "launch"? Launch would be in the default browser. Is that the kind of thing you mean? Would that do it? Being able to launch individual wiki by single selectable choice? Not so sure on that. I think it could over-complicate Polly. FWIW, I been looking at whether you can relaibly set a non default different browser and launch. The way different browsers launch have some variations (though Chromium and Geko browsers work pretty much the same on launch commands) which, overall, may make selected Browser launch with Wikis more difficult. But I'm still experimenting to see if we could get a unified launch mechanism for other than default browser. > > >> * Instead of using C:\Users\joeuser\downloads I'd love to be able to use >> system variables like this: %userprofile%\downloads >> > > Have you tried this? I'm wondering if it might accidentally work already. > That should be quite easy to do. One approach is if you leave "downloaddir" $null it will revert to the Env variable for current users profile? Mark, would you like me to try that approach? > > >> * Also appears relative paths don't work today. Like if I have c:\polly >> and my wikis are in c:\polly\tiddlywiki I was thinking I could do >> .\tiddlywiki\mywiki.html but that doesn't work. Actually, this tries to >> work but I think it looks for a path relative to the downloads folder. >> > > We probably need to do a refactor to make this possible, though I never > envisaged that anyone would want to run from the polly directory. > That is maybe *my bad* as I, I think, set it that way without thinking it through. At the moment the first part of script runs in the app dir. The second half runs in downloads. That breaks portability and relative addressing. I definitely think its something we should address and fix so that the script always runs in the app dir. Mark, could you look into that? I ask because changing to always run in app dir will effect the "Restore" section most. That's where the change would have to be? > >> * Another enhancement would be to check for the existence of the backup >> and parrots folders and create it if it doesn't exist. >> >> > Some of that is already happening for the sub-directories for backup and > zip. > > It's making directories all the way down that worries me. > > I cringe a little, because what if a user accidentally specifies a path to > some place unintended? It's likely they'll complain that their > backup directory is empty, while meanwhile the actual backup is filling up > their USB drive or something. Or filling up a "download" directory instead > of a "downloads" directory. > I agree with Mark. I'd be nervous of auto-creating the top level in a hierachy of folders because of the potential for unanticipated results. But any sub-dir below an existing directory I think is fine. So, for instance we maybe could eventually create sub-folder structure for parrots--provided the top dir exists? Scott, great questions! Thanks. TT -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ee914163-1c8d-4a30-a13e-0bd2d69b685f%40googlegroups.com.
