[ANN] 2018 Call for Grant Proposals

[Shugo Maeda]

The Ruby Association is looking to give grants for development
projects related to Ruby implementations, libraries and frameworks, including
projects that improve existing software.

If you have a good idea, please submit a proposal. However, please
note that we do not intend to fund development projects of Ruby
applications for specific purposes because the aim of this grant is to
improve Ruby and its environment.

See the following site for details:

https://www.ruby.or.jp/en/news/20180801

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

[Nicola Mingotti]

I know i probably should not replay but, I guess i must rise
here a problem that has to be fixed. In the hope one or more
programmer, with time and skills, will accept the challenge
and hopefully enjoy the Ruby Association grant.

*** Ruby needs a simple _working_ GUI toolkit ***

It would be an very important to fix the gem "tk"
to work with latest stable realease of Tk, the only thing working
for me is compiling with Tk8.5 wich is the old stable.
[ https://www.tcl.tk/software/tcltk/choose.html ]

If it is necessary to break retro compatibility with previus rubytk
code, please do it,
call the gem e.g. "tk86"  and that's it. Who needs retro compatility
will have the burden to install old Tk libraries.

I don't use Rails, for me Ruby is a general purpose scripting language.
As such it needs a GUI.

bye
nicola

Post by Shugo Maeda
The Ruby Association is looking to give grants for development
projects related to Ruby implementations, libraries and frameworks, including
projects that improve existing software.
If you have a good idea, please submit a proposal. However, please
note that we do not intend to fund development projects of Ruby
applications for specific purposes because the aim of this grant is to
improve Ruby and its environment.
https://www.ruby.or.jp/en/news/20180801
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

[Marvin Gülker]

Post by Nicola Mingotti
*** Ruby needs a simple _working_ GUI toolkit ***

There's Shoes, in various variants, isn't it? Then, the Gtk+ bindings
for Ruby are well maintained and I've in the past had good success with
them (despite the project name ruby-gnome2 they provide up-to-date Gtk+3
bindings).

If you feel like fiddling, a friend of mine once started and then
abandoned bindings to wxWidgets, rwx
<https://github.com/Hanmac/rwx>. They might provide a starting point if
someone wants to create something new.

Post by Nicola Mingotti
It would be an very important to fix the gem "tk"
to work with latest stable realease of Tk, the only thing working
for me is compiling with Tk8.5 wich is the old stable.
[ https://www.tcl.tk/software/tcltk/choose.html ]

Specifically related to Tk, you're too late to the party. Tk once was
part of Ruby's stdlib, but the maintainer gave up on it because of
hostile messages he received about it. Search this mailinglist's archive
for more information. I very much regret that Tk was removed from the
stdlib, but maybe, just maybe, if a maintainer steps up re-adding it to
the stdlib could be re-considered.

Marvin

[Andy Jones]

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.

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


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.

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

[Carlo E. Prelz]

Subject: RE: [ANN] 2018 Call for Grant Proposals
Date: ven 03 ago 18 11:16:30 +0000

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

I'd like to encourage people to give a try at using Gtk in Ruby. It is
VASTLY easier to write a fully operative Gtk2/3 app in Ruby than in
C. It requires getting a bit used to it but then, a simple howto
process may be as small as this:

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

require('gtk3')

btn=Gtk::Button.new(:label=>"Ciao")
btn.signal_connect("clicked") do
puts("Ciao!") # any code that you want to execute when the button is pressed
end

w=Gtk::Window.new("Test")
w.signal_connect("destroy") do
Gtk::main_quit
end
w.border_width=40
w.set_size_request(200,100)
w.add(btn)
w.show_all

Gtk::main

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

I was also pleasantly surprised at witnessing how easily the whole
gtk3 was successfully brought in with a few gems (that is with a
recent Ruby and on Linux).

I had to write a couple of largish user-interface programs in the past
years in Ruby/Gtk. I must say that, once I entered into the paradigm,
the result was quite satisfactory.

My only pet peeve is that the port to mruby is old and outdated (and
pretends to use ffi...). The next time that I have a few dozens of
years free, I will do a new port ;-)

My heartfelt thanks to Kou and the team who maintains Gtk for Ruby.

Carlo

[Andy Jones]

I gather the equivalent in Ruby/TK is something like

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

require "tk"

root = TkRoot.new { title "Test" }

button = TkButton.new(buttonFrame) do
text "Ciao"
command proc {exit}
end

Tk.mainloop

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--



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.

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

[Nicola Mingotti]

It is one hour i am tring to write this message, i will cut it short.

MANTRA: *** Ruby Needs a Gui ****

-] There are many toolkits, If Tk is sobstituted by another for me it is
no prblem
but, Tk has the following pros:
1] Very easy
2] Well documented
2.1] Cross Platform
3] Stable in years, It is more than 20 years that, to write simple
interfaces, I write the same mambo-jumbo Tk adapted to language:
Python,Perl,Common-Lisp,Tcl.
4] Tk is packaged into Python, the dominant scripting language, so
more potential users could come and try Ruby with immediate satisfaction.
5] Tk resisted in Python for last 2 decaeds, it will mean something !
They changed "print" to "print()" but Tk is still there.

-] It is not more than 1.5 years I stared to use Ruby so I was not here when
it was decided to expunge Tk from Ruby and make it a gem.
In my opionion that was a *mistake*.
1]  programs written for non-programmers require a GUI
2] if you are using a scripting language it means you want to save
coding time and possibly
avoid libraries and compilation issues.
=> Putting Tk into a Gem was not a good idea because it requires extra
libraries
which Average Joe is not able to set up. Installing the gem requires
extra parameters,
with are not immediate to discover.
==> You, the programmer, must fix the stuff in their computer which is
extremely annoying.

-] I read around that there were issues in adapting Tk8.6 to Ruby becasue
of the new features introduced.
==> Ok, this is a good reason to give a grant to a motivated programmer
how can fix the thing.
If Python can do it, Ruby also can.

[leam hall]

Post by Nicola Mingotti
MANTRA: *** Ruby Needs a Gui ****

Agreed!

Post by Nicola Mingotti
=> Putting Tk into a Gem was not a good idea because it requires extra libraries which Average Joe is not able to set up. Installing the gem requires extra parameters, with are not immediate to discover.

ciao Nicola!

If I understand the background on Ruby, there is movement to turn more
of the Standard Library into gems. The idea is that the gem can
progress at a different pace than the Ruby version. I do not know if
that is good or bad, but people whose opinions I respect seem to like
the idea.

Leam

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

[Fabian Zitter]

It is a good idea, at least if the Ruby community keeps growing / does not fall under a certain threshold.
Right now, some features are held back by the democratic process. Some people like the idea, others don’t... Instead of making an absolute decision, Ruby chooses to give the power to developers. That way the standard library can focus on core features, while more specialized libraries can be opinionated (rails), based on C extensions (nokogiri), or use pure Ruby with all the pros and cons...

Sent from my iPhone

Post by leam hall

Post by Nicola Mingotti
MANTRA: *** Ruby Needs a Gui ****

Agreed!

Post by Nicola Mingotti
=> Putting Tk into a Gem was not a good idea because it requires extra libraries which Average Joe is not able to set up. Installing the gem requires extra parameters, with are not immediate to discover.

ciao Nicola!
If I understand the background on Ruby, there is movement to turn more
of the Standard Library into gems. The idea is that the gem can
progress at a different pace than the Ruby version. I do not know if
that is good or bad, but people whose opinions I respect seem to like
the idea.
Leam
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options

[Nicola Mingotti]

ciao Lem !

In general I support the idea of moving non fundamental stuff out "base
Ruby"
and into gems.

On the other side, to use the Python lingo, the kind and amount of batteries
you include into the base system defines what the tool is intended to do.
Or at least, what the tool makes easy to achieve.

In my personal opinion the GUI is so fundamental for a scripting language
that it is necessary to include it in the base system. As a gem, there
is the
risk it will be left behind, like it is actually. This must not happen.

Every single pice of code that is directed to non-programmers must have
a GUI.
I guess 80% of Mac Users do not even know how to start the terminal, and 85%
of Windows users as well.

If we do not make trivial to run a GUI in Ruby it is like saying that,
ok, Ruby is
not intended for end user applications. Only for web stuff, for servers,
or for doployment by programmers and computer enhusiasts of all kind.

bye
Nicola

Post by leam hall
ciao Nicola!
If I understand the background on Ruby, there is movement to turn more
of the Standard Library into gems. The idea is that the gem can
progress at a different pace than the Ruby version. I do not know if
that is good or bad, but people whose opinions I respect seem to like
the idea.

[Will Parsons]

This is a multi-part message in MIME format.
--===============0632053842==
Content-Type: multipart/alternative;
boundary="------------44F55FCF0CD8C94D9CC5933F"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------44F55FCF0CD8C94D9CC5933F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
ciao Lem !
In general I support the idea of moving non fundamental stuff out "base
Ruby"
and into gems.
On the other side, to use the Python lingo, the kind and amount of batteries
you include into the base system defines what the tool is intended to do.
Or at least, what the tool makes easy to achieve.
In my personal opinion the GUI is so fundamental for a scripting language
that it is necessary to include it in the base system. As a gem, there
is the
risk it will be left behind, like it is actually. This must not happen.

That is (IMO) *exactly* what has happend to Tk.

Every single pice of code that is directed to non-programmers must have
a GUI.
I guess 80% of Mac Users do not even know how to start the terminal, and 85%
of Windows users as well.
If we do not make trivial to run a GUI in Ruby it is like saying that,
ok, Ruby is
not intended for end user applications. Only for web stuff, for servers,
or for doployment by programmers and computer enhusiasts of all kind.

I couldn't agree more.

[Will Parsons]

This is a multi-part message in MIME format.
--===============1005528524==
Content-Type: multipart/alternative;
boundary="------------32FDFC27CB24A601BEEE02CF"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------32FDFC27CB24A601BEEE02CF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
It is one hour i am tring to write this message, i will cut it short.
MANTRA: *** Ruby Needs a Gui ****
-] There are many toolkits, If Tk is sobstituted by another for me it is
no prblem
1] Very easy
2] Well documented
2.1] Cross Platform
3] Stable in years, It is more than 20 years that, to write simple
Python,Perl,Common-Lisp,Tcl.
4] Tk is packaged into Python, the dominant scripting language, so
more potential users could come and try Ruby with immediate satisfaction.
5] Tk resisted in Python for last 2 decaeds, it will mean something !
They changed "print" to "print()" but Tk is still there.
-] It is not more than 1.5 years I stared to use Ruby so I was not here when
it was decided to expunge Tk from Ruby and make it a gem.
In my opionion that was a *mistake*.

Tk *used* to be standard with Ruby, but the decision to remove it from
the core package and make it a gem has in fact been disastrous!
Please correct me if I'm wrong, but Tk simply doesn't build with
non-obsolete versions of Tk (meaning, Tk8.6).

So, what used to be the *standard* GUI for Ruby apparently has been
completely abandoned!

1]  programs written for non-programmers require a GUI
2] if you are using a scripting language it means you want to save
coding time and possibly
avoid libraries and compilation issues.
=> Putting Tk into a Gem was not a good idea because it requires extra
libraries
which Average Joe is not able to set up. Installing the gem requires
extra parameters,
with are not immediate to discover.
==> You, the programmer, must fix the stuff in their computer which is
extremely annoying.
-] I read around that there were issues in adapting Tk8.6 to Ruby becasue
of the new features introduced.
==> Ok, this is a good reason to give a grant to a motivated programmer
how can fix the thing.
If Python can do it, Ruby also can.

Presumably. But it hasn't been done so far.

[Marvin Gülker]

Post by Will Parsons
So, what used to be the *standard* GUI for Ruby apparently has been
completely abandoned!

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 instead of writing to this
mailing list about it, I'm sure that ruby-tk would be quickly back at
live again.

Stop complaining and start acting. That's the best way to change things.
Otherwise, deal with the existing, maintained options (i.e. Gtk+ or
Fox).

Marvin

[Donald Wilde]

Good point. The problem is not the GTK documentation, it's the
Ruby/GTK docs. I agree that if you're not hip to C the jump may seem
difficult.

Tk is old and moth-eaten. Time to move on. GTK is a Gnome project and
not likely to go away. The only downside is that it doesn't help with
Windows. That was what was so awesome about wXWidgets.

I'm up to my gills now but it seems that the thing to do is to start a
little Facebook group and assemble a team to learn Ruby/GTK and
document the heck out of it.

There is no question in my mind that C++ "smells" a lot worse than
Ruby but that's why Ruby/GTK documented would be so useful. I haven't
used it myself for anything but toys, but putting together an e-book
like FXruby would be a huge step forward for our favorite language.!

Post by Marvin Gülker

Post by Will Parsons
So, what used to be the *standard* GUI for Ruby apparently has been
completely abandoned!

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 instead of writing to this
mailing list about it, I'm sure that ruby-tk would be quickly back at
live again.

--
Don Wilde

"Social programming generates beliefs, beliefs create attitudes,
attitudes cause feelings, feelings cause us to act, and actions
produce results -- good or bad." -- adapted from "What to Say When You
Talk to Yourself," by Shad Helmstetter, Ph. D.

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://li

[Nicola Mingotti]

With all respect Marvin, I fully disagree.

What I am supporting here is exactly the opposite of what
you propose: "A lone wolf(s) hack to fix the tk gem".

-] 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.

-] I wish a grant would be established to fund sombedoby,
to put Tk back into base Ruby. In such a way you would be *sure*
the GUI is *always* there, as "puts", ready for you to use.

-] 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: https://www.tcl.tk/software/tcltk/license.html
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).

*] A sad consideration. I am closing a nice script i wrote in the last
day to
speed-up office phone calls. After a phase of test i must perform, I
guess the soft could be useful also to
at least other 4-5 people in our office. But the problem is, I am
developing the
stuff in FreeBSD, the other employees use Windows and Mac.
Paradoxically, absurdely i would say,
it seems to me that the path of least offort to make the program run on
all office platforms
is to rewrite it in Python !

goodbye
Nicola

Post by Marvin Gülker
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 instead of writing to this
mailing list about it, I'm sure that ruby-tk would be quickly back at
live again.
Stop complaining and start acting. That's the best way to change things.
Otherwise, deal with the existing, maintained options (i.e. Gtk+ or
Fox).
Marvin

[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.

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.

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-tal

[Marvin Gülker]

Post by 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

Post by Andy Jones
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.

Post by 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.

Post by Andy Jones
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]: https://bugs.ruby-lang.org/issues/8539
[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]: https://github.com/Secretchronicles/TSC

[Nicola Mingotti]

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

Post by Marvin Gülker

Post by 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

Post by Andy Jones
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.

Post by 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.

Post by Andy Jones
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]: https://bugs.ruby-lang.org/issues/8539
[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]: https://github.com/Secretchronicles/TSC

[Andy Jones]

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>

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.

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

[Marvin Gülker]

Post by Andy Jones
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.

Post by Andy Jones
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

[Andy Jones]

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>

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.

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

[Marvin Gülker]

Post by Andy Jones
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.

Post by Andy Jones
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

[Codebykevin]

-] 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: https://www.tcl.tk/software/tcltk/license.html
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)

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 https://www.codebykevin.com/stringscan.html for a Ruby Tk GUI that runs on Mac and Windows. Written by me.

[Will Parsons]

Post by Codebykevin
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).

[Kevin Walzer]

Post by Will Parsons
# gem install tk
Fetching: tk-0.2.0.gem (100%)
Building native extensions. This could take a while...
ERROR: Failed to build gem native extension.
*Not* done (because it relies on an obsolete version of Tk).

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

--Kevin

[botp]

Post by Will Parsons

Post by Codebykevin
gem install tk
Done. =20

# gem install tk
Fetching: tk-0.2.0.gem (100%)
Building native extensions. This could take a while...
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.
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

[Will Parsons]

--===============1859239258==
Content-Type: multipart/alternative; boundary="0000000000006acb1d0572d19890"
--0000000000006acb1d0572d19890
Content-Type: text/plain; charset="UTF-8"

Post by Will Parsons

Post by Codebykevin
gem install tk
Done. =20

# gem install tk
Fetching: tk-0.2.0.gem (100%)
Building native extensions. This could take a while...
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.

[Kevin Walzer]

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 Parsons]

Post by Kevin Walzer

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.

[Kevin Walzer]

Post by Will Parsons
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.

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

[botp]

Post by Will Parsons

Post by Kevin Walzer

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.

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

[Nicola Mingotti]

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

[botp]

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

you lost me there : )

Post by Will Parsons
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 : )

Post by Will Parsons
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 : )

Post by Will Parsons

Post by botp
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

Post by botp
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)

Post by Will Parsons
--
Will

many thanks and many regards
--botp

[Will Parsons]

Post by Carlo E. Prelz
Subject: RE: [ANN] 2018 Call for Grant Proposals
Date: ven 03 ago 18 11:16:30 +0000

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

I'd like to encourage people to give a try at using Gtk in Ruby. It is
VASTLY easier to write a fully operative Gtk2/3 app in Ruby than in
C. It requires getting a bit used to it but then, a simple howto
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
require('gtk3')
btn=Gtk::Button.new(:label=>"Ciao")
btn.signal_connect("clicked") do
puts("Ciao!") # any code that you want to execute when the button is pressed
end
w=Gtk::Window.new("Test")
w.signal_connect("destroy") do
Gtk::main_quit
end
w.border_width=40
w.set_size_request(200,100)
w.add(btn)
w.show_all
Gtk::main
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
I was also pleasantly surprised at witnessing how easily the whole
gtk3 was successfully brought in with a few gems (that is with a
recent Ruby and on Linux).
I had to write a couple of largish user-interface programs in the past
years in Ruby/Gtk. I must say that, once I entered into the paradigm,
the result was quite satisfactory.
My only pet peeve is that the port to mruby is old and outdated (and
pretends to use ffi...). The next time that I have a few dozens of
years free, I will do a new port ;-)
My heartfelt thanks to Kou and the team who maintains Gtk for Ruby.

Simple how-to's are fine, but try to build *any* kind sophisticated
GUI application using Ruby/Gtk, and one is sure to come accross one
*serious* obstacle - Ruby/Gtk documentation is so poor as to be
completely useless! Good luck in making anything more than a trivial
application.

[Carlo E. Prelz]

Subject: Re: [ANN] 2018 Call for Grant Proposals
Date: dom 05 ago 18 10:52:54 -0400

Post by Will Parsons
Simple how-to's are fine, but try to build *any* kind sophisticated
GUI application using Ruby/Gtk, and one is sure to come accross one
*serious* obstacle - Ruby/Gtk documentation is so poor as to be
completely useless! Good luck in making anything more than a trivial
application.

I have done that. As I already mentioned, it's been hard. But
obstacles can be solved. At least they have been, in the case of my
few applications (one quite large, the others smaller but requiring
live, non-sluggish interactive bitmap manipulations).

The documentation may be poor, but it is certainly not useless. Then,
I must say that I did my work before the 'introspection' stuff came
to be, so my best documentation was the source. Now, I may have more
problems. But still, everything has to be learned.

Anyway, Gtk was the only working option. I never liked the looks of Tk
(although people were able to do wonders with it - I think of
PureData). Same goes with Qt, that reeks of c++ from miles away. I
don't know if you ever had the joy of compiling Qt.

If I were the Ruby god, I'd start from scratch, doing a nice, tight
rendering engine in C that does not pretend to be directly usable from
applications, and an elegant, clean Ruby interface that exploits the
power of object orientation. And, of course, without the dependance
from hundreds of gems. But, having seen the complexity of Gtk, having
negotiated the use of every aspect I needed with much sweat, I know
that it would be years of effort before you'd obtain the complete
palette of necessary widgets.

If I did not have a job, and if someone offered to pay me for my
needs, that's one think I'd like to dedicate my time to for a few
years...

Carlo

[Will Parsons]

Post by Andy Jones
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.

Post by Andy Jones
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.

[Donald Wilde]

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.

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 agree that Shoes, while fun, is not deep enough for real work.

Post by Will Parsons

Post by Andy Jones
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.

Post by Andy Jones
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
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

--
Don Wilde

"Social programming generates beliefs, beliefs create attitudes,
attitudes cause feelings, feelings cause us to act, and actions
produce results -- good or bad." -- adapted from "What to Say When You
Talk to Yourself," by Shad Helmstetter, Ph. D.

Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

[Will Parsons]

Post by Donald Wilde
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.

Post by Donald Wilde
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.

Post by Donald Wilde
I agree that Shoes, while fun, is not deep enough for real work.

Post by Will Parsons

Post by Andy Jones
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.

Post by Andy Jones
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.

[Leam Hall]

Post by Marvin Gülker
Specifically related to Tk, you're too late to the party. Tk once was
part of Ruby's stdlib, but the maintainer gave up on it because of
hostile messages he received about it.
Marvin

I've felt some of the same hostility. Sometimes it seems like "Matz is
nice so we can be jerks." Maybe I'm overly sensitive, but some attitudes
in the community have pushed me away from Ruby more than once. I dread
asking questions on IRC; either nothings happens or someone tells me I
should upgrade. The other day it was just "cut and paste the code to the
new class".

On the other hand there are folks like Andy here and baweaver on IRC
that are very knowledgeable and helpful. One of my personal goals is to
remain encouraging as I learn enough to be helpful.

Leam


Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org?subject=unsubscribe>
<http://lists.r