[rkward-devel] Provide a UI for CRAN mirrors

[Prasenjit Kapat]

Hi,

On Thu, Nov 26, 2009 at 8:54 AM, Thomas Friedrichsmeier
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
> Hi,
>
> On Thursday 26 November 2009, Prasenjit Kapat wrote:
>> This has been a very long standing itch of mine - to get rid of the
>> ugly (and very minimally informative) Tcl/Tk box to choose the CRAN
>> mirrors (one that pops up during install.packages or update.packages
>> or ...). Basically, to set options(repos=c(CRAN=....)) with an actual
>> url instead of '@CRAN@'.
>>
>> I've added a combobox (see attached image). But there is a bug:
>>
>> Every time rkward is started, the repos url is set to "" (empty). Once
>> you go to Settings > R-packages  and set a 'CRAN download mirror' and
>> click apply, only then the repos url is set properly.
>
> I have not done any testing, yet. I believe the bug is that you save the index
> position of the list. When loading the settings, this is not resolved to the
> corresponding url, so you get an empty string, instead. I think the best
> solution is to simply store the url in the config. This is also less error-
> prone if / when the list changes one day.

Yes, I agree on the idea of storing the url itself. Two things that
was on mind here: (1) To me the descriptive Host names in the combobox
make an easier read (in terms of which mirror is nearest to me) than
the raw urls - so I had to use two QStringList vairables one for the
host names, and one for the urls. (2) If the urls are stored, then
we'll have to do an indexOf(...) search for the hostname combobox,
everytime the settings dialog is loaded.

If the general idea is acceptable (read below), then I'll give this a try.

> Another thing: Are you aware of getCRANmirrors()? I guess it does most of what
> you do in CRAN_mirror_list.R in a way that is less likely to break in the
> future.

But the only difference (for better) would be to read the mirror list
from getCRANmirrors() instead of the hard coded file on disk, right?

> On a more general note: I don't like the hard-coding involved, and would
> rather like to see a more generic solution. If the main issue is the Tcl/Tk
> dialog, we could (and should) get rid of that in general by overriding menu().

I knew this was coming ;) I felt it that way too.

But remember that the hard coding is done for a specific version of R.
If R changes, then we anyway have to recompile rkward. And as I
commented in the code, my "ideal" solution is to create a .h file
during the configure/make process (using CRAN_mirror_list.R) and this
.h file will just contain the definition of two QStringLists (or even
one list may work actually). Now, I do not know how to trigger the
creation from either configure/make. But if you can give me a working
.h file containing the two lists (hard coded) then I can modify
CRAN_mirror_list.R to generate this .h file dynamically.

So, this would still be hard coded for the runtime part of rkward. But
it would not be hard coded before the configure or make process,
instead it would be generated from the upstream mirror list released
with R during compilation.

> Steps involved in that approach:
> 1) Change menu() so that if "graphics" is TRUE, something like
>      .rk.do.call ("menu", c (choices, title))
> will be called. The default behavior otherwise. NOTE: Need to use
> assignInNamespace() to override the menu function in the utils namespace.
> 2) The call would be implemented in RInterface::processREvalRequest() (where
> there are many examples of the basic idea).
>
> Of course this does not store the mirror-setting permanently, so you would
> still be prompted for a mirror each session. But it would be with a "nice"
> dialog instead of the tcl/tk one. Want to give that a try?

Few things:
(1) My C++/Qt knowledge is embarrassingly minimal! I just look for
"similar" codes to what I want to do and then tweak it accordingly...
(2) I like the idea to give the user more readable choices, like the
ones in the combobox (Country, State, City, Hostname), rather than the
"choices" offered using the Tcl/Tk menu box.
(3) Also, being able to store the choice is a plus point, I think.
(4) Over riding menu() with .rk.do.call() will be, as you say, nice,
and also be a generic solution to replace all Tcl/Tk menu boxes. But,
in the this example of CRAN mirrors, I think, using the combobox (or
some such native hard coded solution) we can provide a better UI to
the user (see (2) above).

Regards,
-- 
Prasenjit