hi, Am Freitag, 16. Juni 2017, 13:12:41 CEST schrieb Thomas Friedrichsmeier: > > Am Sonntag, 4. Juni 2017, 16:47:37 CEST schrieb meik michalke: > Huh? Did not see that one. Also not in the list archive.
hm, strange. > That's actually intentional, and I don't think it's new in KF5 (did not > bother to check, though). The idea is that a workspace is more like a > project, including all related files, and if you close it, the > corresponding files are closed, too. but that is assuming that those files are always complete workspaces. but they can just as well be the result of saving individual R objects (e.g., using the export dialog), or sample data in an R package. opening one of those clearly should not reset everything you were just working on. it would be nice if RKWard checked if opening the file would overwrite existing objects and offer to cancel the operation, but that is another feature request. for now, RKWard should not automatically close all open files when loading saved objects. > Clearly, this isn't desirable > _all_ the time, but simply keeping all current windows open is not > universally a good idea, either, and can even become confusing in some > cases (suppose you have two different projects, containg R scripts by > the same name, but different contents. Perhaps something like > "preparedata.R"; I believe we even had a bug report about this one day). > > The _exception_ is that if a workspace is opened via DBus (i.e. from > file browser, with --reuse), it does _not_ replace the current > workspace. i think it's rather confuding if RKWard behaved differently depending on whether you klick on a dataset in RKWard's file browser or the very same file in dolphin. i'd rahter have RKWard ask me what to do i any case: replace the current workplace with that data (also close all open tabs) or add the objects to the current workspace (keeping files open, and probably warning if existing objects are replaced, probably even offering auto-backup in the current workspace). > I've changed this so the frontend will actively cd to the same dir on > startup. Of course WD changes (also for instance, if configured to > change directory to current script file) will _not_ be totally > synchronous at any rate. However, usually the backend is going to be > idle, and so no delay will be noticeable. great, can't wait to test it :-) btw, i've also been working on rkwarddev the past few days, especially enhancing the plugin2script() method, it should now be able to produce running code from much more plugins and transforms *.xml, *.rkh and *.pluginmap files. reason is i've started working on a new plugin for bayesian statistics, starting with t-tests, and wanted to "quickly" generate script code from the t-test plugin... you know how that always ends... ;-) viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf
signature.asc
Description: This is a digitally signed message part.
