[RkWard-devel] RKWard 0.2.6 /bug?

[Thomas Friedrichsmeier]

Hi Daniele,

thanks for compiling this list. I'll try to remember working those into the 
next release. A few comments:

> Other typos:
> Settings -> Plugins:
>  s/avaiable/available/g
>  s/Prefer recommended option/Default options/    (1th place for that)
>  Logfiles: "Changes will take effect only restarting RKWard."

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?

> TIP: many buttons are organized in that form
>
> "[OK][Apply]         [Cancel]"
>
> IMHO the right order sould be
>
> "[Cancel]               [Apply][OK]"
>
> (usability issue)

I guess the real solution will be to use KDialogs in order to always be 
consistent with the rest of KDE. I'll have a look into how this is done.

> TIP: the names of the various windows are too strange or complex! You sould
> change these in:
>  "RKWatch-Window" -> "Console"
>  "RKOutput-Window" -> "Results"
>  "RKObjectBrowser-Window" -> "Explorer" (like SAS) or "Objects" or split
> the notebook views for type ("Data", "Functions", "Misc" ...ect). This last
> sould be prefered when people work with many objects because it's an
> implicit organization.

Sounds reasonable.

> You sould set default windows size on startup.

You mean of those additional windows like the object-view windows?

> What you mean with "e.g. format" and "e.g. category" in the data header?
> Why didn't call these simple "Format" or "Category"?

'Cause their really just bogus for now. Whatever you type in there will be 
lost, and it will not be used in any way so far. I just don't want to convey 
the impression, these fields should actually do something already.

> You could try this way to handle data with/without header info (look at the
> mockup attached).

I guess I'll try what that looks like.

Thomas