20/03/14 13:50, intrigeri wrote:
> Hi,
>
> bertagaz@??? wrote (29 Dec 2013 17:44:57 GMT) :
>> On Fri, Dec 27, 2013 at 07:36:15PM +0100, intrigeri wrote:
>>> The parent ticket (#5731) is still blocked by #6400, as nobody
>>> commited to either upstream our stuff into the ruby-sikuli Gem, or to
>>> maintain our own adapter on the long term. I'm unsure what conclusion
>>> we should draw of it. Admitedly, the new setup is way less scary than
>>> the previous one, and our adapter is 85 lines long, but still, I'm
>>> concerned we might happily be replacing it with another kind of
>>> technical debt.
>
> AFAICT, nothing has happened on this front since then.
>
>> I've had a quick look at a way to implement that upstream. Using the
>> RUBY_ENGINE variable, it seems easy to have the gem selecting the right
>> handler depending on which interpreter is used.
>
>> Still there are some subtilities in our code that I'm not sure to
>> understand, this is quite low level, and I'm not sure to be able to handle
>> this upstreaming myself alone.
>
> In the meantime, the sikuli_ruby Gem [1] has been abandonned, and our
> current best option for upstreaming seems to be Rukuli [2], that seems
> quite alive (10 contributors, a few commits every month).
>
> [1] https://github.com/chaslemley/sikuli_ruby
> [2] https://github.com/andreanastacio/Rukuli
>
> anonym, bertagaz: want to have a(nother) look, and decide if you
> prefer to do the upstreaming work now, or to commit to maintain our
> own sikuli/rjb adapter on the long run?
I have looked several times at what would be necessary for upstreaming
this, and changed my mind about what to do equally many times.
It definitely would be some work. We'd need to add a wrapper that either
uses RJB or JRuby constructs depending on what's available. While that
wouldn't be too hard in principle, it seems RJB handles exceptions in a
way that will be complicated to get to a similar state as in JRuby,
which is what sikuli-ruby/Rukuli expects. Add to this that I'm neither a
Ruby nor (J)Ruby Guru, and all this stuff is pretty low-level and
intricate. I think that even RJB may need to adapted a bit, for the
exception issue.
Furthermore the sikuli-ruby API (inherited to Rukuli) isn't a
particularly good fit for us, and has some design issues:
* It doesn't expose some functionality we need. When we used it (and
JRuby) we had to monkeypatch it from the get go -- it still feels
like it's very incomplete, a beta or whatever.
* It has completely screwed up by mixing Key:s with KeyModifier:s,
which effectively makes it impossible to use the KeyModifiers in
combination with a Key, e.g. "Ctrl+C" or whatever.
* Other stuff I cannot remember.
Add to this that we do not know for how long Rukuli will stay maintained.
Lastly I'm personally quite happy with using the proxied Java objects
exposed by RJB directly as it allows me to consult Sikuli rather
extensive docs, and use any tricks I find used in the (Java-oriented)
Sikuli community.
Because of all this I've finally concluded that I would prefer to keep
on maintaining our "sikuli/rjb adapter" for the time being, and possibly
return to this upstreaming process if Rukuli shows promise to at least
stay maintained for the foreseeable future.
Cheers!
