[rkward-devel] [rkward-cvs] [rkward] rkward: erm, ok, here are the missing files to the last commit...

[Thomas Friedrichsmeier]

On Friday 28 November 2014 16:20:10 meik michalke wrote:
> good point -- i did that, and i also renamed the file to vnd.rkward.r.xml,
> which makes it a vendor-specific MIME type declaration. that makes it
> possible for us to define that MIME type without colliding with other
> packages doing the same.

Ah, yes, that sounds much better!

> i'll try and test if this and the protocol handler also works on OS X. can
> you check that on windows?

Will try to remember. I have an inkling it's going to require adding it to the 
registry, though...

> actually, that is something that has always annoyed me a bit: i start RKWard
> and want to *open* a previous workspace, but the first thing i get is a
> question whether to *save* the workspace. good thing if that was gone.

Yes. I'll try to come up with something.
 
> do we have to care for that single .Random.seed object when one wants to
> open another workspace anyway?

No, but how to tell it apart for other, more interesting objects, reliably. I 
think the solution will have to involve something like marking the workspace 
as "clean", at an appropriate point in the startup sequence, and then only 
asking to save, if it was modified after that.

> alternatively, RKWard could ask you how to deal with the input: replace
> current workspace or add all objects to the current one. do you know whether
> there's a difference between *.RData files containing saved workspaces and
> saved R objects? if there was, we could add a <magic> section to the MIME
> type, which would cause the first bits of a file to be read to get its
> type.

I don't think so. ?save.image says: "save.image() is just a short-cut for 
‘save my current workspace’, i.e., save(list = ls(all = TRUE), file = 
".RData")". Even if you could tell how it was saved, that still doesn't tell, 
reliably, how you'd like to use it. In general, there are three options:
  - Replace current workspace
  - Merge with current workspace (potentially overwriting objects)
  - Import into a sub-environment
And then, if a .workplace-file exists to go with that, for the first two, 
there's also the question, whether to load that, and if so, whether to close 
all other windows first...

So - a whole lot of options, really. I guess a plan could look like this: In 
the menu, provide two actions: One is the current behavior. The second 
(perhaps called "Import Workspace..."?) would offer all applicable choices. If 
there is a request to open a workspace file in a running session (from 
RKWard's own filebrowser, or externally), and the current workspace is not 
empty, use that second action, too.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20141128/8b958377/attachment.sig>