[ANN] 2018 Call for Grant Proposals

ruby-talk
21

Marvin >>>>>>>>
I see a lot of lamenting in this thread. If all of you who complain on this mailing list about ruby-tk not being maintained would form a group and dedicate your time to fixing ruby-tk [...]
<<<<<<<<

Nicola >>>>>>>>
I wish Tk would not be a gem, because, as experience proves, it is left behind => Ruby does not have a default GUI => this is a big problem.
<<<<<<<<

Clearly if you want Tk (or any other GUI) _as part of the Ruby standard_, then you absolutely need a concerted, organised, official effort, as opposed to a few blokes coming together to hack something.

Also, please note Marvin: the reason many of us don’t just knock something up to make Tk work again is, either we don't have the skills (and presumably you don't think the only people on this list should be Ruby gurus?) or, we have paid jobs and don’t have the time!

The point of this thread was **funding**, yes?

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>

Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.

22

gem install tk

Done.
+1 on all other items

Tk is the only cross-platform GUI toolkit to consider, IMO. Fx does not run on Mac and Gtk/Qt have other issues that have been documented.

If you can’t make a sophisticated UI with Tk, that speaks to your design capabilities rather than the toolkit. See Delight in Your Desktop for a Ruby Tk GUI that runs on Mac and Windows. Written by me.

···

On Aug 6, 2018, at 11:46 AM, Nicola Mingotti <nmingotti@gmail.com> wrote:

-] The discussion about which GUI framework to adopt it is not central in my
perspective, I will not enter into it. But, i reccomend "Tk" because it is,
1] well documented
1.2] *cross platform*
2] known to many many people
3] stable
4] mature
5] still improved today aka not dead.
6] tons of examples on StackExchenge, (in Python mostly)
7] If we do not have human resources to keep Tk updated then looking
at something more large/complex, or less known, or less mature, is an hopeless
effort and we would rool back here talking Ruby not having a GUI in the next 5 years.
8] Very liberal license: Tcl/Tk Licensing Terms
9] It is more or less the GUI all scripting and non scripting languages support, I am
sure of: Python, Perl, Common Lisp, R, Node, (of course Tcl)

23

Marvin >>>>>>>>
I see a lot of lamenting in this thread. If all of you who complain on this mailing list about ruby-tk not being maintained would form a group and dedicate your time to fixing ruby-tk [...]
<<<<<<<<

Nicola >>>>>>>>
I wish Tk would not be a gem, because, as experience proves, it is left behind => Ruby does not have a default GUI => this is a big problem.
<<<<<<<<

Clearly if you want Tk (or any other GUI) _as part of the Ruby
standard_, then you absolutely need a concerted, organised, official
effort, as opposed to a few blokes coming together to hack something.

I am in support of this point. There is no way to get it back into the
stdlib if there's not somebody who maintains it. It was specifically
removed from the stdlib because the existing maintainer didn't continue
maintaining it[1][2].

I didn't propose "lone wolf" uncoordinated hacking. I haven't said
that. What I said was:

dedicate your time to fixing ruby-tk instead of writing to this
mailing list about it

My interpretation as a non-native speaker of the verb "dedicate" is to
thoroughly work on something for a longer period of time. And that's
what I meant to suggest.

Also, please note Marvin: the reason many of us don’t just knock
something up to make Tk work again is, either we don't have the skills
(and presumably you don't think the only people on this list should be
Ruby gurus?) or, we have paid jobs and don’t have the time!

Contributing does not usually require to be a "Ruby guru". Libraries are
normal code after all. Ruby-tk may be specific as it is a C extension,
but writing Ruby C extensions is not something that requires "guru"
skills either. There's a nice document in the Ruby source tree[3] that
describes the process, and for someone who has written much Ruby code,
it is rather straightforward given some C experience.

The actual point is the other one you raised -- time. If you don't want
to spare your time on developing ruby-tk, then don't assume others
will. I've long hoped that an OSS game I liked became maintained again,
but it never happened. I then forked it and took over development
myself[4]. That's the only way that really works.

The point of this thread was **funding**, yes?

The thread lost connection to funding at some point I think. But by all
means, I'm all in support if anybody wants to volunteer and submit an
application for the programme described in the OP. If it at some point
looked as if I wouldn't be in favour it it, I apologise.

Marvin

[1]: Feature #8539: Unbundle ext/tk - Ruby master - Ruby Issue Tracking System
[2]: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/436401
[3]: https://github.com/ruby/ruby/blob/trunk/doc/extension.rdoc
[4]: GitHub - Secretchronicles/TSC: An open source two-dimensional platform game.

···

Am 06. August 2018 um 16:11 Uhr +0000 schrieb Andy Jones:
Am 06. August 2018 um 16:11 Uhr +0000 schrieb Andy Jones:

--
Blog: https://mg.guelker.eu
PGP/GPG ID: F1D8799FBCC8BC4F

24

Marvin, the links you posted are interesting, I will read with attention.

I saw NAGAI message (http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/436401\)
and its sad he perceived his work was not appreciated. Because, at least
for me, Tk is useful, very useful. He made a good job, I used Tk in much
desperate circustances (using pipes in CommonLisp to talk to Wish, a decade ago).
So, from my side, loud Bravo to NAGAI !

Let me clarify my position, what is and what is not in my reach.
I use ruby for scripting, I am not a guru, very far from it.
Simply, what I was writing in Perl and Python now i tend to write it
in Ruby, because I like it more, as simple as that.

If I was still in academia i could try work on this and put it in some
way under the umbrella of a reaserch project. But I am not an
academic now, time I have available for "community code" is really scarce
and fragmented.

But i want to contribute. This thing is important. So, if out of this
discussion spurge in some way the decision to put Tk back in its
place I am ready to take my share of the burded and contribute say, 100 euros,
personally.

My objective is this, i would like to write a Ruby scripts (with GUI, for end users)
copy them to any computer having Ruby installed and see them working,
no extra configurations. I always did that in Python, it is a great thing.

bye
Nicola

···

On 08/06/18 19:31, Marvin Gülker wrote:

Am 06. August 2018 um 16:11 Uhr +0000 schrieb Andy Jones:

Marvin >>>>>>>>
I see a lot of lamenting in this thread. If all of you who complain on this mailing list about ruby-tk not being maintained would form a group and dedicate your time to fixing ruby-tk [...]
<<<<<<<<

Nicola >>>>>>>>
I wish Tk would not be a gem, because, as experience proves, it is left behind => Ruby does not have a default GUI => this is a big problem.
<<<<<<<<

Clearly if you want Tk (or any other GUI) _as part of the Ruby
standard_, then you absolutely need a concerted, organised, official
effort, as opposed to a few blokes coming together to hack something.

I am in support of this point. There is no way to get it back into the
stdlib if there's not somebody who maintains it. It was specifically
removed from the stdlib because the existing maintainer didn't continue
maintaining it[1][2].

I didn't propose "lone wolf" uncoordinated hacking. I haven't said
that. What I said was:

dedicate your time to fixing ruby-tk instead of writing to this
mailing list about it

My interpretation as a non-native speaker of the verb "dedicate" is to
thoroughly work on something for a longer period of time. And that's
what I meant to suggest.

Am 06. August 2018 um 16:11 Uhr +0000 schrieb Andy Jones:

Also, please note Marvin: the reason many of us don’t just knock
something up to make Tk work again is, either we don't have the skills
(and presumably you don't think the only people on this list should be
Ruby gurus?) or, we have paid jobs and don’t have the time!

Contributing does not usually require to be a "Ruby guru". Libraries are
normal code after all. Ruby-tk may be specific as it is a C extension,
but writing Ruby C extensions is not something that requires "guru"
skills either. There's a nice document in the Ruby source tree[3] that
describes the process, and for someone who has written much Ruby code,
it is rather straightforward given some C experience.

The actual point is the other one you raised -- time. If you don't want
to spare your time on developing ruby-tk, then don't assume others
will. I've long hoped that an OSS game I liked became maintained again,
but it never happened. I then forked it and took over development
myself[4]. That's the only way that really works.

The point of this thread was **funding**, yes?

The thread lost connection to funding at some point I think. But by all
means, I'm all in support if anybody wants to volunteer and submit an
application for the programme described in the OP. If it at some point
looked as if I wouldn't be in favour it it, I apologise.

Marvin

[1]: Feature #8539: Unbundle ext/tk - Ruby master - Ruby Issue Tracking System
[2]: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/436401
[3]: https://github.com/ruby/ruby/blob/trunk/doc/extension.rdoc
[4]: GitHub - Secretchronicles/TSC: An open source two-dimensional platform game.

--
--------------------------
Dr. Nicola Mingotti
R&D - Borghi Srl
CTO - BondInsider
--------------------------

25

If Tk is now applied to Python, will that not mean a resurrection?

I heartily agree with the lack of GUI support, but that seems to be
scripting-language-wide, not just Ruby.

I mourn the loss of wX, but it seems truly dead. IMHO, that leaves FOX
Toolkit and Qt. In my C++ work, my opinion is that QT is a fat,
ostentatious payware wannabe, but FOX has real possibilities. It also
appears that FXruby is getting at least minimal updates as of earlier
this year.

I experimented with wX, and liked it, but, as you say, it now seems to
be completely dead.

I consider Ruby/Qt effectively dead too (which I think is too bad).
The Ruby binding to Qt is tied to Qt4, which is obsolete.

That leaves FOX. The fxruby gem is what I personally use for GUI
applications. It doesn't seem to be as active as much as it used to
be, but at least it's more usable than the alternatives.

What do people think? Has anyone besides me used these heavier-weight
GUIs? I thought FX was elegant even if it didn't have dials and
spinners. I've used wX and FOX in Ruby, and Qt with C++, and Tk with
Perl and Ruby.

I've used (formerly) wxruby, qtruby, and fxruby. (I tried to use
gtkruby but was discouraged by lack of adequate documentation.)

Despite its limitations, I agree with you that FX is elegant. I'd
like to see more support for it from the Ruby community.

···

On Sunday, 5 Aug 2018 11:22 PM -0400, Donald Wilde wrote:

I agree that Shoes, while fun, is not deep enough for real work.

On 8/5/18, Will Parsons <varro@nodomain.invalid> wrote:

On Friday, 3 Aug 2018 7:16 AM -0400, Andy Jones wrote:

Shoes doesn't really count -- it's a framework that uses Ruby, rather than
a library that you can use _in_ Ruby.

And I think the use cases for Tk and Gtk are quite different. Tk, like
shoes, lets you do something simple very quickly.

I disagree. One *could* use Tk for quite complex applications - if in
fact it were maintained, which apparently it is not. Shoes may be
good for getting simple applications up quickly, but doesn't seem to
be suited to serious use.

So I'd also welcome the return of Tk (although I don't much care if it's
in Stdlib).

I would too. Too bad the decision to take it out of core has resulted in
its being effectively abandoned.

--
Will

26

# gem install tk
Fetching: tk-0.2.0.gem (100%)
Building native extensions. This could take a while...
ERROR: Error installing tk:
        ERROR: Failed to build gem native extension.

*Not* done (because it relies on an obsolete version of Tk).

···

On Monday, 6 Aug 2018 12:30 PM -0400, Codebykevin wrote:

gem install tk

Done. =20

--
Will

27

Works just fine for me on macOS 10.13.6, building against Tk 8.6.8.

--Kevin

···

On 8/6/18 7:39 PM, Will Parsons wrote:

# gem install tk
Fetching: tk-0.2.0.gem (100%)
Building native extensions. This could take a while...
ERROR: Error installing tk:
         ERROR: Failed to build gem native extension.

*Not* done (because it relies on an obsolete version of Tk).

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

28

check further look at the log. possibly it just cannot find tk.
i have latest tk/tcl installed from activestate and use ldconfig to let
linux find the tk libs. (since i find ldconfig friendlier than setting some
env vars).
guess what, i use both NaHi(tk) and manveru's (ffi-tk) gems.

[1] pry(main)> require 'tk'
=> true
[2] pry(main)> require 'ffi-tk'
=> true

i luv both gems.
1) tk is authored by NaHi (one of the brilliant and humble tk hacker). the
gem is littered with lots of amazing examples fr simple to intermediate.
2) ffi-tk simply because i think w external libraries, using ffi for
wrapping is the way to go.

many thanks and many regards,
--botp

···

On Tue, Aug 7, 2018 at 7:39 AM, Will Parsons <varro@nodomain.invalid> wrote:

On Monday, 6 Aug 2018 12:30 PM -0400, Codebykevin wrote:
>
> gem install tk
>
> Done. =20

# gem install tk
Fetching: tk-0.2.0.gem (100%)
Building native extensions. This could take a while...
ERROR: Error installing tk:
        ERROR: Failed to build gem native extension.

*Not* done (because it relies on an obsolete version of Tk).

29

Contributing does not usually require to be a "Ruby guru".
Libraries are normal code after all. Ruby-tk may be specific as it is a C extension,
but writing Ruby C extensions is not something that requires "guru"
skills either [...], and for someone who has written much Ruby code,
it is rather straightforward given some C experience.

You and I have a very different idea of the mean skill level of a Ruby programmer. What you describe is beyond my skills at present, and I suspect I'm not the only one here.

I agree with you that contributing does not require "ruby guru" skill levels. You are presumably not suggesting that if I can't write a Ruby C extension library, I should just keep quiet?

The actual point is the other one you raised -- time. If you don't want
to spare your time on developing ruby-tk, then don't assume others
will

I didn't say that I didn't _want_ to "spare the time". I said I didn't have it to give. It's all used up either sleeping, looking after my family, or earning the money to do the same. The distinction between "don't want to" and "can't" is a very simple one. Please don't conflate them.

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.

30

I agree with you that contributing does not require "ruby guru" skill
levels. You are presumably not suggesting that if I can't write a
Ruby C extension library, I should just keep quiet?

No, that's not what I'm suggesting. What I'm recommending is that you
should be brave and don't treat things as being beyond your
skills. Skills can and should be improved; don't hesitate to try. That
however is something that requires time. I believe all humans to be
equal in what they can achieve -- consequently, I treat the argument "I
don't have the skill" as "I don't have the time to develop that
skill". That argument is absolutely fine, but should be made as such.

If however you neither want to participate in solving the problem, nor
have suggestions on how to approach it, then I ask you to be
quiet. Otherwise this is like the useless "me too" or "+1" comments
often seen in bugtrackers that are of no value and will not accelerate
implementation of the feature. This has nothing to do with skill (see
above).

It is okay to request a new feature. It is not okay to repeatedly
complain about it being missing if not wanting to help with it.

>>>>>>>>
The actual point is the other one you raised -- time. If you don't want
to spare your time on developing ruby-tk, then don't assume others
will
<<<<<<<<

I didn't say that I didn't _want_ to "spare the time". I said I
didn't have it to give. It's all used up either sleeping, looking
after my family, or earning the money to do the same. The distinction
between "don't want to" and "can't" is a very simple one. Please
don't conflate them.

I'm going to give you an extreme example to demonstrate that your
"can't" and my "don't want" are the same. Please don't take this as a
personal attack. It is not meant as such. Assume someone has a job that
takes up the entire time and thus prevents contributions as mentioned in
this thread. According to your definition it would be a "can't"
situation. According to my definition it is a "don't want" situation,
because, if that person wanted, he/she could quit the job. He/she
doesn't want to, and that's fine, because it is the only realistic
option. But it all comes down to human will.

In other words: when I say "can't", it is impossible by law of
nature. When you say "can't", it is impossible by means of a realistic
choice.

Peace?

Marvin

···

Am 07. August 2018 um 07:28 Uhr +0000 schrieb Andy Jones:

--
Blog: https://mg.guelker.eu
PGP/GPG ID: F1D8799FBCC8BC4F

31

No, that's not what I'm suggesting. What I'm recommending is that you
should be brave and don't treat things as being beyond your
skills. Skills can and should be improved; don't hesitate to try.

I said it was beyond my skills "at present". I'm sure you didn't mean to be patronising, but it certainly comes across that way at this end.

Again: should people refrain from ever suggesting that something would be a good idea, because they currently can't do it themselves?

It is okay to request a new feature. It is not okay to repeatedly
complain about it being missing if not wanting to help with it.

And you get to decide this, do you?

I'm going to give you an extreme example to demonstrate that your
"can't" and my "don't want" are the same. Please don't take this as a
personal attack.

But it certainly sounds like one. And while I'm sure you live in a magical land where jobs are there for the taking and folks can quit their current work with no risk or consequences -- I don't.

Is this MINISWAN for you? Are you being "nice"? I ask only for information. It's just that it seems to me that you might think you are being "nice".

This is the problem with "nice". Your perception as a dispenser of it doesn't have to match my perception as a receiver of it.

When people tell other people on an open forum what they should or should not do; suggest that in order to participate they should achieve some minimum standard of skill set by the other person? To me that doesn't feel "nice" at all.

I'm not going to comment again here for a while.

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

Please note that we have updated our privacy policy in line with new data protection regulations. Please refer to our website to view the ways in which we handle your data.

32

Again: should people refrain from ever suggesting that something would
be a good idea, because they currently can't do it themselves?

You're reading different things than I write. I can't help that. I'm
sorry. I do not suggest any such things. Request as many features as you
want, that's fine! However, there's just no point in complaining about
it over and over again once it *has* been suggested. It doesn't help
acceleration. This is my argument, and it has nothing to do with "who
you are to tell me what to say", I'm trying to convince you by argument
when it's better to just say nothing instead of something that doesn't
contribute to the technical discussion.

I'm not going to comment again here for a while.

You're deliberately trying to misunderstand me. I don't see a point in
continueing this discussion either. Let's leave it as it is.

Marvin

···

Am 07. August 2018 um 11:07 Uhr +0000 schrieb Andy Jones:

--
Blog: https://mg.guelker.eu
PGP/GPG ID: F1D8799FBCC8BC4F

33

--===============1859239258==
Content-Type: multipart/alternative; boundary="0000000000006acb1d0572d19890"

--0000000000006acb1d0572d19890
Content-Type: text/plain; charset="UTF-8"

>
> gem install tk
>
> Done. =20

# gem install tk
Fetching: tk-0.2.0.gem (100%)
Building native extensions. This could take a while...
ERROR: Error installing tk:
        ERROR: Failed to build gem native extension.

*Not* done (because it relies on an obsolete version of Tk).

check further look at the log. possibly it just cannot find tk.

Of course it cannot find Tk 5.x, because Tk 5.x is obsolete and not
installed! I do have Tk 8.6 installed, but that apparently is
incompatible with the current ruby tk gem.

Not included in my brief error output above:

   At present, Tcl/Tk8.6 is not supported. Although you can try to use
   Tcl/Tk8.6 with configure options, it will not work correctly. I
   recommend you to use Tcl/Tk8.5 or 8.4.

So, if want a version of Ruby/Tk that will actually *work*, I should
downgrade to an obsolete version of Tk. Not good.

i have latest tk/tcl installed from activestate and use ldconfig to let
linux find the tk libs. (since i find ldconfig friendlier than setting some
env vars).
guess what, i use both NaHi(tk) and manveru's (ffi-tk) gems.

OK. I don't use either Windows (no Activestate) or Linux. This *is*
a Ruby/Tk problem.

···

On Tuesday, 7 Aug 2018 1:22 AM -0400, botp wrote:

On Tue, Aug 7, 2018 at 7:39 AM, Will Parsons <varro@nodomain.invalid> wrote:

On Monday, 6 Aug 2018 12:30 PM -0400, Codebykevin wrote:

--
Will

34

Support for Tk 8.6 was added a year or two ago to Ruby, partly because of my bug report. It builds fine with 8.6. What version of Ruby are you using?

···

On 8/8/18 8:19 PM, Will Parsons wrote:

So, if want a version of Ruby/Tk that will actually*work*, I should
downgrade to an obsolete version of Tk. Not good.

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

35

Really? I'm using Ruby 2.4.4, which I think is current for my
platform (FreeBSD). OK - I think I'll have to look into this more
carefully.

···

On Wednesday, 8 Aug 2018 8:48 PM -0400, Kevin Walzer wrote:

On 8/8/18 8:19 PM, Will Parsons wrote:

So, if want a version of Ruby/Tk that will actually*work*, I should
downgrade to an obsolete version of Tk. Not good.

Support for Tk 8.6 was added a year or two ago to Ruby, partly because
of my bug report. It builds fine with 8.6. What version of Ruby are you
using?

--
Will

36

I'm using 2.3.1, and I bundle Tk 8.6.8 with my app on macOS.

···

On 8/8/18 9:18 PM, Will Parsons wrote:

Really? I'm using Ruby 2.4.4, which I think is current for my
platform (FreeBSD). OK - I think I'll have to look into this more
carefully.

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

37

Of course it cannot find Tk 5.x, because Tk 5.x is obsolete and not
installed!

you lost me there : )

I do have Tk 8.6 installed, but that apparently is
incompatible with the current ruby tk gem.

hmm. i may have to build a bsd machine here to prove that : )

Not included in my brief error output above:

   At present, Tcl/Tk8.6 is not supported. Although you can try to use
   Tcl/Tk8.6 with configure options, it will not work correctly. I
   recommend you to use Tcl/Tk8.5 or 8.4.

So, if want a version of Ruby/Tk that will actually *work*, I should
downgrade to an obsolete version of Tk. Not good.

search the archives. it's an old message / doc.
you can change it though. the source / doc is open : )

> i have latest tk/tcl installed from activestate and use ldconfig to let
> linux find the tk libs. (since i find ldconfig friendlier than setting
some
> env vars).
> guess what, i use both NaHi(tk) and manveru's (ffi-tk) gems.

OK. I don't use either Windows (no Activestate) or Linux. This *is*
a Ruby/Tk problem.

that is fine. i should have emphasized "ldconfig". ( i mentioned
activestate since years back then, it was the most difficult tk version to
incorporate in ruby. but now things have changed)

--
Will

many thanks and many regards
--botp

···

On Thu, Aug 9, 2018 at 8:19 AM, Will Parsons <varro@nodomain.invalid> wrote:

38

fwiw.

8] pry(main)> RUBY_VERSION
=> "2.4.4"
[9] pry(main)> system "lsb_release -a"
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.5 LTS
Release: 16.04
Codename: xenial
=> true
[10] pry(main)> require "tk"
=> true
[11] pry(main)> require "ffi-tk"
=> true

many thanks and many regards,
--botp

···

On Thu, Aug 9, 2018 at 9:18 AM, Will Parsons <varro@nodomain.invalid> wrote:

On Wednesday, 8 Aug 2018 8:48 PM -0400, Kevin Walzer wrote:
> On 8/8/18 8:19 PM, Will Parsons wrote:
>> So, if want a version of Ruby/Tk that will actually*work*, I should
>> downgrade to an obsolete version of Tk. Not good.
>
> Support for Tk 8.6 was added a year or two ago to Ruby, partly because
> of my bug report. It builds fine with 8.6. What version of Ruby are you
> using?

Really? I'm using Ruby 2.4.4, which I think is current for my
platform (FreeBSD). OK - I think I'll have to look into this more
carefully.

39

Hi,

About a week before opening the Tk issue here I thought
"Ok, if ActiveState packages Tk in their Ruby 90% of my (future) problems
with the end users are gone".

I never used ActiveState Ruby, I checked the gem list they include
and I have not found Tk. So, I sent them an email asking if it was
their intention to include it in the future. I never got a replay.
[ Here is the gem list: http://docs.activestate.com/activeruby/beta/pkg/ ]

I think, it would be a good thing if you also send them an email
about that. So, they will probably put attention to our case.
And we will have a Ruby with GUI (at least Tk) the end user will be able to install
in one shot. (at least in Windows).

bye
Nico

···

--
--------------------------
Dr. Nicola Mingotti
R&D - Borghi Srl
CTO - BondInsider
--------------------------