[rkward-devel] [rkward-users] Call for testing: RKWard 0.5.3-pre1 / Release schedule

[Prasenjit Kapat]

Hi,

On Sun, Apr 18, 2010 at 3:14 PM, Thomas Friedrichsmeier
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
>
> On Saturday 17 April 2010, Prasenjit Kapat wrote:
>> 1. File browser (Alt+1)
>>
>> 1a. Single click and double click: shouldn't it honor the default KDE
>> settings? Double clicking on a filename opens the files thrice (when
>> KDE default=single click) or twice (when KDE default=double click),
>> neither of which is correct.
>
> Indeed. It's a bug in kdelibs, though, and it would be very hard to work
> around this. Does anybody have a KDElibs 4.4.x installation at hand? Could you
> check, whether the double-click behaviour is still the same, there?

Well, 4.4 is not in Debian yet :( I may give Kubuntu in a VM a try
sometime, but I don't think I'll be able to do that in time for the
release.

BTW, is kate's 'Filesystem Browser' different then? This doesn't seem
to happen there. (Its 'tab bar' is completely different, a bit weired,
if I may.)

>> 1b. Can we save the view mode (Short view / Detailed view)? The "short
>> view" seems almost unusable with large number of files and/or large
>> filenames.
>
> Implemented in SVN. Please test (another preview release will also follow some
> time next week).
>> (I miss the List view from KDE3!)  (1b can be targeted after 0.5.3)
>
> Added an icon for tree view (which is pretty similar, IIRC).

Thanks. This looks and works great now, very much usable. The 'icon
view' is gone now? (I won't miss it!)

>> 2. Shortcuts
>>
>> 2a. (Although this is specific to my setup, but can occur to others as
>> well.) Some of my codes are named blah.0.blahblah.r,
>> blah.1.blahblah.r, ..... As a reproducible case, create two (or 6)
>> script files: a0.R, a1.R (..,.a6.R) and open them. Now, Alt+0, Alt+1 (
>> ..., Alt+6) become ambiguous ;) If this is tied to katepart, then at
>> least having an option to disable script tab shortcuts will be useful!
>> (For some reason this does not happen on KDE3's katepart) Sometime, at
>> this stage, a crash may occur - I haven't been able to
>> deterministically reproduce a crash.
>
> Indeed. I see the problem, but don't know how to fix this, yet (other than to
> assign different shortcuts). BTW, the katepart is not to blame. It's the tab-
> bar that assigns shortcuts to the tabs, apparently without taking existing
> shortcuts into account.

Hmm.. well... at least now the shortcuts are configurable.

>> 2b. In the absence of Previous (or Next) Window, hitting Alt+< (or
>> Alt+>) inputs  "," (or ".") character into the script - which is
>> obviously dangerous. Ideally, the key combination should be disabled
>> in such situations.
>
> I can see the problem, but don't know what to do about this, either. I suppose
> the problem could be side-stepped, if "previous" would wrap around to the most
> recent, and "next" to the first window, so that there is always something
> reaction to the shortcut. How does that sound?

It may get a bit confusing, but far better than messing up the code!
It is one thing to see this happening in a blank script file and whole
another thing when it happens is a big R code and you save it w/o
realizing what was modified... A wild goose chase, when the code
doesn't run the next day!  So, yeah fine by me.

Someday someone may ask why the two different (Alt & Ctrl)  window
cycles? We'll have to come up with some answer, till then....

>
>> 2c. Window Left and Right are always disabled for some reason!
>
> Indeed. Will investigate.

Looks fixed now, thanks.

>
>> 2d. "Run all" shortcut:
>> Has anyone done the mistake of hitting Shift+F9 instead of Shift+F8
>> (F9 and F8 are close enough)? My suggestion would be to not have any
>> default shortcut for "Run all" and let the user set one, if he/she
>> needs.
>
> Hm, I use "Run all" a lot, personally, and that makes me reluctant to remove
> the shortcut. What does everybody else think / use?

Again, not a problem at all... I can disable the 'Run all' shortcut
easily, so fine by me!

>
>> 3. make plugintests
>>
>> 3a. Existence of R2HTML should be checked before starting any tests.
>> Otherwise it is really not any useful - all tests are skipped!
>
> You have a point, there...
>
>> 3b. The default size of output buffers (Command log / R Console) are
>> too small for plugintests' output. Can we call sink(file = ...) before
>> and after running the tests? (Or will every plugin need to be modified
>> for this?)
>
> Should be possible, somehow. BTW, the tests are just a bunch of R scripts
> (make plugintests basically sources rkward/tests/all_plugins.R; see also
> http://sourceforge.net/apps/mediawiki/rkward/index.php?title=Automated_Plugin_Testing),
> so maybe you would like to take a look, yourself?

Updated all_plugins.R using sink(). Do check it for any obvious errors.

>
> On another note: I meant to write about this, earlier, but forgot: I modified
> your solution for the CRAN mirror settings, as discussed some months ago. This
> removes the hard-coded list of mirrors, but also replaces the tcl-dialog with
> an "rkward native" dialog. What do you think of the current state?

Yes, I remember the commits in svn. The whole thing is much better
integrated now.

Although, for some reason I never liked the minimalistic menu of
chooseCRANmirror(), so I took the liberty to modify the
rk.select.CRAN.mirror() in public.R. This is basically, the
chooseCRANmirror function, but with the only difference of paste(m[,
1L], m[, 5L], sep = " - ") instead of m[, 1L] (you can see it in the
cvs list).

Of course, if you feel that this will not get due testing before the
release then, I can revert back to the old chooseCRANmirror() and we
can get back to this after the release.

-- 
Prasenjit