[RkWard-devel] Re: RKWard 0.2.7

[Thomas Friedrichsmeier]

Hi Daniele, hi all,

One thing first: Your feedback is very valuable to me. However, I feel I start 
getting difficulties keeping up with everything and maybe I've already 
forgotten several useful suggestions you've sent in.
You could do me a favour by adding your suggestions to the tracker:

feature requests:
http://sourceforge.net/tracker/?atid=459010&group_id=50231&func=browse

bugs:
http://sourceforge.net/tracker/?atid=459007&group_id=50231&func=browse

If I set it up correctly, items you submit there, will also be mailed to the 
list.
Of course, you can still write to the list directly, and for both simple items 
like spelling corrections and items which you feel might require further 
discussion on the list, that is probably still the most reasonable thing to 
do.
By adding your reports to the tracker, however, you can make sure that I won't 
forget about them.

> I write a mail directly
> because sf.net has blackholed my smtp server and 2-3 mail was trashed in
> the last days.

You had the mailing list CCed on this mail (and in fact it looks like the mail 
never arrived), so I'm sending a copy there, too.

> # Labels
> Object window
>  - s/Class(es)/Class/      ...I dislike plural form inside ()

Likely reasonable. Note that some objects may have more than one class.

>  - Is "update" button usefull? I think an auto-updating state could be more
>   usefull for users and show the exact state of the workspace in real time.
>   Yes, this could be a ls() function execution continuosly, but think about
> it

The update-button is useful for now, but ideally, it will be removed. By now 
operations inside RKWard should change the object-list immediately, so no 
manual updates are needed for that anymore. But the real problem is of course 
to find out, when a user-command changed something in the R workspace. Note 
that this is not just about the plain list of objects and their properties, 
but also about changes in the data. If an object is modified, which is opened 
for editing, that change should somehow get transferred.
I guess we'll need to require the user to signal such changes explicitly. 
Something like:

x <- y
rk.sync (x) # tell RKWard that it should re-get the data for this object (if 
opened)

For now, the update button is still a useful thing to have - if only for 
debugging purposes.

> New command editor
>  - Line numbering option enabled by default
>  - On "Run all" and "Run selection": why differentiate these?
>   Like SAS do you sould use the "F3" key for that and..
>    1) run all by default
>    2) run selected code if "selected"

Not sure on this. Personally, I'd rather prefer a "Run" command which I always 
know what it does. I'd rather dislike a "Run" command that changes behavior 
depending on whether something is selected or not. Hence, I think your 
suggestion is a useful addition, but I'll still keep the "explicit" options.
Oh, and of course, key-bindings will be made configurable sooner or later.

>  - You could cut the "Run", "Settings", "Help" menu entries:
>    1) the first one could be unified as "Run" (F3) and placed in "File"
>    2) "Settings" and "Help" could be centralized in main menu option.

1) Given the above, I guess, a separate "Run" menu is still a good idea.
2) I think users rather expect a separate help menu? Note, that in the long 
run, both menus will be populated with several items, e.g.:

Settings:
 - Configure editor / fonts / highlighting
 - Configure keybindings
 - Configure toolbar
 ...
Help:
 - Help on RKWard in general
 - Help on Command-Editor usage
 - Help on R syntax / R reference
 ...

Both menus may be kind of underpopulated right now, but this will change in 
the long run.

> General
>  - Set a default console font and default size. Actually is too big.
>   You sould use Bitstream Vera Sans Mono 10 (default in every Linux distro)

Hmm, interesting. The first thing I did, after I added access to the 
configuration dialog for the katepart, was to increase the font size, 'cause 
for me it was tiny by default...

>  - Use Kdialog to handle button position, margin and other setting from kde

Yes, this will have to be done.

>
> The following reply didn't arrive in list so I cu'n past it here.
>
> > Actually, that's not quite what it is supposed to mean. The idea is
> > rather, that plugin-authors may "recommend" one type of interface over
> > the other. For instance, for very simple actions with few settings, it
> > may make sense to use the dialog even to inexperienced users. Still an
> > additional wizard-interface may be present. That's also, why the option
> > is in the middle: The first option gives you a wizard-interface whenever
> > available, the third a dialog interface, the second is somewhere in
> > between. I think I'll rename it to "Prefer recommended interface". Does
> > that convey the idea?
>
> it is a way..
>
> another one could add a "More options" on the plugin basic
> interface/gui and leave this choice by-work, by-moment. Instead "global
> difficulty level" this second one respond with "local difficulty level".

The technical thing behind this is to find a good way for plugins to store 
some of their state permanently. This could of course also include, whether 
you last switched to a dialog or wizard interface (you are aware, that for 
those plugins that acutally have both interfaces, there's already a 
"switch"-button? What's left to be done is to store the setting).

Thomas