Hi, On Fri, 22 May 2015 15:35:01 +0000 (UTC) Jan Wort <d_...@ymail.com> wrote: > Issue 1: Deleting data > > > What kind of warning do you have in mind? "You are about to clear X > > cells of data. Are you sure? --- Don't ask again --- Clear / Don't > > clear"? > > Yes along this lines but that might be annoying. > > > > It should be very, very obvious, how to switch from read-only to > editable and back. […] Probably a KMessageWidget shown… > > What about utilizing the top toolbar? It already adapts to the type > of data, and for editable data it could offer a lock button. It would > do the same as the option in the Edit menu. > > Thus we could keep the current behaviour but offer an easy to find > protection too.
indeed, good idea. I'll take care of that. One small follow-up, though: What is actually the best way to design such a button in the toolbar, from a usability perspective? - Show a lock that can be toggled between open and closed. But then, should it show the closed lock when the data _is_ read-only, or when clicking on the lock will _make_ it read-only? - A lock symbol somehow combined with a checkbox? - A lock symbol as a toggle button (not changing the symbol between open and closed)? - Something else? From your other mail: > Minor addition: At least in my version of RKWard (0.6.3 KDE Dev > 4.13.3) there is no visual separator between the > "workspace-buttons" (Open, Create, Save) and the "Object-buttons" > which change according to the active content (e.g. Clip/Copy/… for > dataframes or back/forward for documentation) It is just a small line > to add, but this may help users to predict the results of pressing > the toolbar button. True. But I'm not sure how to do that, technically. (Actually the "workspace buttons" and the "object buttons" are on two separate toolbars, internally. Separators at the start / end of either will likely be stripped, automatically. May have to change this). Could you add this to either https://community.kde.org/RKWard or the feature request tracker, so it won't get lost? > Issue 2: Workspace > > >"Data" did not look entirely right to me (e.g., is .Random.seed > >data?) > Indeed. I would assume that for the user .seed is is more like a > function (something tool-like that R provides for me), though > technically it is not. > > > > Here's some background: […]Environments:You are not the first to be > > puzzled … > Thanks! That makes it clearer to me. > > > > So one idea (good or bad) might be to separate these into two > > distinct tool windows, one for "My Objects", one for "Package > > Objects" (or whatever the names). > > Sounds good to me. > > I can prototype some ideas and send them to the list to discuss > how/what we can improve here and consider the information on > environments and your usecases. Possibly I’d test them with some > people too to get preliminary feedback; It sounds like a meaningful > thing to improve. That would be highly welcome! It's certainly a rather essential control. I'll add a few more thoughs: - If going with two separate tool windows, these would likely still end up looking pretty similar: Essentially the same controls, icons, and tool tips make sense, and also some actions (view, copy). This similarity _could_ be confusing, in case you mis-click and activate "Package Objects" instead of "My Objects"? - Note that essentially the same control is also used in plugin dialogs (the "varslot" where you select objects from). So that may or may not be affected by a re-design. - Also note that this "varslot" currently allows you to switch to showing all package environments (via RMB menu) and selecting objects e.g. from package:datasets. Not sure whether anybody else is using this (I do, at times, for testing purposes). - Not sure any decent solution is to be found along these lines, but to outline another approach: It would also be possible to re-arrange the item tree a bit (while showing "All environments"): E.g. we could add a pseudo-item "Package Objects" as a sibling of ".GlobalEnv", or even simply next to the regular user objects, i.e.: -- My Objects / .GlobalEnv \-- my.data.x \-- my.data.y -- Package Objects \-- package:base \-- [...] - or - -- my.data.x -- my.data.y -- Package Objects \-- package:base \-- [...] Regards Thomas
pgpZ_h0Q__e7l.pgp
Description: OpenPGP digital signature
_______________________________________________ rkward-devel mailing list rkward-devel@kde.org https://mail.kde.org/mailman/listinfo/rkward-devel
