Hi all, I remember this post: http://librelist.com/browser//shoes/2009/11/2/direction-of-shoes/ If possible, I'd like to challenge rewriting Shoes in pure Ruby. But for now, I've no idea and no ability and don't know where is the start point. :( Please give me your comments and suggestions. ashbb
I cant see rewriting shoes as one man job. And it will be pain in the arse - in my experience, Ruby is slow. And it will be enormous amount of work. And it would be awesome if it would ever work. Do you mean pure ruby, or jruby, as mental was suggesting? regards Vojtěch Šalbaba 2010/8/21 ashbb <ashbbb@gmail.com> > Hi all, > > I remember this post: > http://librelist.com/browser//shoes/2009/11/2/direction-of-shoes/ > > If possible, I'd like to challenge rewriting Shoes in pure Ruby. > > But for now, I've no idea and no ability and don't know where is the start > point. :( > > Please give me your comments and suggestions. > > ashbb >
There are pro's and con's worth discussing. Java + jRuby is not going to start up nearly as quickly. Even pure java GUI apps have to set up splash/progress screens to let the user know something is happening. Some things can't be done. Like easy user installation (they have download and install java and jruby first) On the other hand, we wouldn't need pack.rb and binject so that's a plus for developers. As far as I know, Java has no video/audio widgets that work as users think they should. (+) We wouldn't have to figure out VLC or port Bloopsaphone. There is no reason or way to distribute SqLite (the user will be happy to install it, or mySql or Oracle or DB2 and get the java bridge working). We Shoes developers wouldn't have to distribute/manage the entire ext tree. Any gem issues can't be fixed by us so that's another load off our developer shoulders. That sounds like a lot of user fun and uniqueness taken out of Shoes. On the other hand, with all the uniqueness removed, it would be easier to maintain. You only have write the awt/swt mapping once which wouldn't be easy but not certainly not impossible for a motivated person with a lot of time on their hands. It wouldn't be the Shoes we know, but it could be done. User experience would suck. I seriously doubt one can write the Shoes to Java GUI mapping layer in Ruby . Duby might work, but you're still fight getting all the widget event listeners, widgets and graphics context set correct like Shoes wants and what awt/swt (your choice) allows. That is the hard work and the language used to do it is a minor problem. As someone asked a few days ago, why can't Shoes be a gem? The reasons _why didn't use heavy weight Java or wxRuby or wxTk are deep in our source code. Contemplate how you would move Shoes (as we know it) to Android. On Sat, 2010-08-21 at 23:31 +0200, Vojtěch Šalbaba wrote: > I cant see rewriting shoes as one man job. And it will be pain in the > arse - in my experience, Ruby is slow. > And it will be enormous amount of work. > And it would be awesome if it would ever work. > Do you mean pure ruby, or jruby, as mental was suggesting? > regards > Vojtěch Šalbaba > > > > 2010/8/21 ashbb <ashbbb@gmail.com> > Hi all, > > I remember this post: > http://librelist.com/browser//shoes/2009/11/2/direction-of-shoes/ > > If possible, I'd like to challenge rewriting Shoes in pure > Ruby. > > But for now, I've no idea and no ability and don't know where > is the start point. :( > > Please give me your comments and suggestions. > > ashbb > >
I was playing around a bit with the idea of a Shoes implementation in Qt-ruby. You can find a _very_ basic proof of concempt with a working Shoes::app() (with a stack layout) and button() here: http://gist.github.com/546187 The advantages compared to other approaches might be: - pure ruby implementation (can be a disadvantage also) - a lot of missing features would be available automatically, little things like: scrollbars working with mouse wheel and page up/down buttons, text selection working in paras, non us keyword layout (having deadkeys) working - cross-platform handled by Qt - you can use the methods and classes of Qt if Shoes doesn't offer what is needed (but i'm not sure how much of Qt we would want to expose to the user...) Disadvantages: - shoes would need to be rewritten (who will do it? maybe I will try to see how hard it is, when I finish the Hackety summer of code, if I get around to it and if I get anything noteworthy out of it I will report back) - packaging is surely harder than with the jRuby idea - I don't know how much experience people involved with Shoes have with Qt I don't know about the performance, it might be slow in some places as the idea would be to use ruby, but the graphics would be done by the Qt code (QGraphicsView with QGraphicsWidgets seem promizing) Okay, just sharing my thoughts... :) Ciao, - fela
On Mon, 2010-08-23 at 22:09 +0200, Fela Winkelmolen wrote: > I was playing around a bit with the idea of a Shoes implementation in > Qt-ruby. You can find a _very_ basic proof of concempt with a working > Shoes::app() (with a stack layout) and button() here: > http://gist.github.com/546187 I'm pleased you shared that, Fela. Thank you. It demonstrates how Shoes works in a few lines of Ruby. I'm not current on QT license status? Is it cross platform & open source?
QT is GPL'd, and 100% cross platform.
On Tue, Aug 24, 2010 at 4:45 AM, Steve Klabnik <steve@steveklabnik.com> wrote:
> QT is GPL'd, and 100% cross platform.
Actually Nokia has licensed it also under the LGPL which makes the
free version available for proprietary applications too =)
On Mon, 2010-08-23 at 22:45 -0400, Steve Klabnik wrote:
> QT is GPL'd, and 100% cross platform.
Qt looks promising as a C/C++ level replacement at the widget level of
Shoes and google search hints suggest that Cairo might know about it.
[Must verify that] That would be a big win for "Shoes as we know it
now". Conversion ease with a the opportunity to expose additional
widgets and functions to a savvy developer. There are hints they can do
Devyn's OpenGL magic pixie frame rate dust too.
Definitely worth exploring. It's not the Ruby level reimplementation
everyone wants but that's the gap that Shoe fills. Beginners don't want
to learn about signals, events and menu management (ctrl-click drop
downs or menus at top of the frame or menu bar). Those things should be
available though (A Shoes Advanced March Manual would be required)
If I remember correctly, back when _why created Shoes, The
Qt/Trolltech/Nokia was a fricking mess of OSS uncertainty. It might be
different now.
When the facts change, I change my mind. I'm still sure I dislike C++.
On Tue, Aug 24, 2010 at 10:54 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Mon, 2010-08-23 at 22:45 -0400, Steve Klabnik wrote: >> QT is GPL'd, and 100% cross platform. > > Qt looks promising as a C/C++ level replacement at the widget level of > Shoes and google search hints suggest that Cairo might know about it. We need to be sure that Qt works with 1.9 first. martin
On Tue, 2010-08-24 at 10:57 +0530, Martin DeMello wrote: > On Tue, Aug 24, 2010 at 10:54 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > > On Mon, 2010-08-23 at 22:45 -0400, Steve Klabnik wrote: > >> QT is GPL'd, and 100% cross platform. > > > > Qt looks promising as a C/C++ level replacement at the widget level of > > Shoes and google search hints suggest that Cairo might know about it. > > We need to be sure that Qt works with 1.9 first. > > martin Agreed. We are talking about out a Shoes release way out in time when 1.9.2, is so 'last year' that people complain how out of step we are. Thread handling (integration of two native thread models is a concern) and the website is shy Some simple hello world QT scripts using the latest ruby wrappers in 1.9.1/2 with would help if that was direction to take. Fela provided z script, tens of emails ago. We should try it. Turns out my Ubutnu has Qt installed without the KDE baggage, I haven't tried Fela's script because that would as you noted, require facts.
>> We need to be sure that Qt works with 1.9 first. >> >> martin > > Agreed. We are talking about out a Shoes release way out in time when > 1.9.2, is so 'last year' that people complain how out of step we are. > Thread handling (integration of two native thread models is a concern) > and the website is shy > > Some simple hello world QT scripts using the latest ruby wrappers in > 1.9.1/2 with would help if that was direction to take. Fela provided z > script, tens of emails ago. We should try it. Turns out my Ubutnu has Qt > installed without the KDE baggage, I haven't tried Fela's script > because that would as you noted, require facts. I didn't manage to built qt ruby myself as I got a compilation error, so I used the version provided by the ubuntu repositories, which uses 1.8. But it is supposed to work also with 1.9
Qtruby be sure to check thread support. One year back, qtruby did not support threads, certainly with 1.8 ruby. Check with 1.9. regards Vojtěch Šalbaba 2010/8/24 Fela Winkelmolen <fela.kde@gmail.com> > >> We need to be sure that Qt works with 1.9 first. > >> > >> martin > > > > Agreed. We are talking about out a Shoes release way out in time when > > 1.9.2, is so 'last year' that people complain how out of step we are. > > Thread handling (integration of two native thread models is a concern) > > and the website is shy > > > > Some simple hello world QT scripts using the latest ruby wrappers in > > 1.9.1/2 with would help if that was direction to take. Fela provided z > > script, tens of emails ago. We should try it. Turns out my Ubutnu has Qt > > installed without the KDE baggage, I haven't tried Fela's script > > because that would as you noted, require facts. > > I didn't manage to built qt ruby myself as I got a compilation error, > so I used the version provided by the ubuntu repositories, which uses > 1.8. But it is supposed to work also with 1.9 >
> It's not the Ruby level reimplementation > everyone wants but that's the gap that Shoe fills That's what qtbindings is for ;) http://rubygems.org/gems/qtbindings > Beginners don't want > to learn about signals, events and menu management (ctrl-click drop > downs or menus at top of the frame or menu bar). Those things should be > available though (A Shoes Advanced March Manual would be required) Of course not! This is about implementing Shoes on top of Qt, the existing Shoes API wouldn't be any different than it is now. > I'm still sure I dislike C++. Me too. And you're right, the license situation wasn't great a while back. > Some simple hello world QT scripts using the latest ruby wrappers in > 1.9.1/2 with would help if that was direction to take. Well.... I've started a branch to work on this here: http://github.com/steveklabnik/shoes/tree/qtruby So far, just stubbing things out, I have ask and alert working, that's it. Just setting up a skeleton. > We need to be sure that Qt works with 1.9 first. I'm building this branch with 1.9.2. > Qtruby be sure to check thread support. I haven't looked into this yet. Anyway, this is pretty easy so far. I'm going to spike this out for the next week or so and see how far I get. If anyone wants to lend a hand, that's cool, or you can just wait and see. But I think this has promise.
Hi Steve, Fela et al,
Awesome!
Look at this: http://www.rin-shun.com/tmp/Qt_Shoes_snapshot.png
I just did the following.
- gem install qtbindings
- git clone git://github.com/steveklabnik/shoes.git
- git checkout qtruby
- ruby test1.rb
- then got the above snapshot!
# test1.rb
require './lib/shoes'
Shoes.app :height => 250, :width => 200 do
button 'push me' do
alert 'Qt met Shoes!'
end
end
Your QtShoes worked with ruby 1.9.1 mingw32 on my Windows 7 32bit laptop!
ashbb
I've been staying out of this discussion while I let my thoughts cook a while, and checked out what everyone else thinks. Here's my two cents: All of this discussion comes back to a few small things, and that's the mission statement of Shoes. Here's what _why had to say about Shoes: > Shoes is a cross-platform toolkit for writing graphical apps easily and artfully using Ruby. > Unlike most other GUI toolkits, Shoes is designed to be easy and straightforward without losing power. Really, it’s easy! Important things: 1) cross platform. 2) 'easily and artfully' 3) easy and straightforward And I agree. What I love about Shoes is that it's actually Ruby. You're not doing silly things like wxruby. Not to denigrate that project, but they say this themselves: > The API doesn't seem very Ruby-like > The current API is basically a straight port of the wxWidgets C++ interface. Well, actually it has several of the same adjustments > that wxPython also had to adopt due to language constraints. This interface is a bit clumsy in spots, thanks to its long history. (from http://wxruby.rubyforge.org/wiki/wiki.pl?WxRubyFAQs ) Anyway, this is what we're trying to do. We have this code, and it works. Sort of. There are lots of issues. Compilation is absolutely insane. Lots of the process is stuff that only _why knew about. These shoes have deep, dark corners. We've been doing a good job of this so far, but we're only a few intrepid codesmiths. Let's face it, while Shoes has gotten a bit more active lately, we're still less than a dozen members in sum total. With that much said, a re-write would introduce significant amounts of technical risk. It would be pretty advantageous. All of the code would be known by us. We could choose better dependancies, and fix the cross-platform issues. But it's also dangerous. Like I said, we only have a few people. How much time can really be put into this? And a re-write would basically stop development of Shoes proper, for the same 'lack of manpower' reasons. At the same time, I think that a re-write would be good, overall. I think we should go for it. WalkAbout, totally new. I think for Shoes to move forward, it's the best possible thing. Mostly to get rid of the damn dependancies. And for a clean, fresh start. So. With that said. What would I do, for a re-write? Well, there's a couple of considerations: 1. Cross platform. This is absolutely necessary. It should be write once, run everywhere, ideally. 2. Packaging : this is a biggie, too. People use this a lot, and it's a major pain point, currently. I need this for Hackety Hack, too. 3. Compilation: it should be reasonably easy to get shoes up and running 4. API support: I agree with Devyn's comment about the API being a bit more nice in some small ways. I don't have a list off of the top of my head, but this would be a great opportunity to do some things that might break backwards compatibility. 5. Testability: Shoes has no tests, and there's no way to test Shoes apps. Ideally, a solution would let us do this. Right now, this is horrible about Shoes. > That sounds like a lot of user fun and uniqueness taken out of Shoes. I disagree with this, a lot. As long as the Shoes API is the same/close, how would it be different? Nobody knows Shoes internals anyway (sorry, bad pun), why would they care if it's using Cairo or wxwidgets or anything else? Ultimately, though, here's the kicker: If this happens, someone's going to have to do it. We can talk all we want about what might be better or what might not be better, in the end, whoever picks it up and does something will probably win. If I had unlimited time, I'd start tomorrow. Getting OSX to work (sort of, HEAD is still a bit wonky) put me in such a furious rage that I'd rather just rewrite all of shoes myself than play around with it. Here's the other big thing: if we do 'decide' to do this... how does that decision come about? Do we have a vote of some kind, here on the ML, or somewhere else? Who all can vote? Does it matter?
On Mon, 2010-08-23 at 16:46 -0400, Steve Klabnik wrote: > I've been staying out of this discussion while I let my thoughts cook > a while, and checked out what everyone else thinks. > > Here's my two cents: > > All of this discussion comes back to a few small things, and that's > the mission statement of Shoes. Here's what _why had to say about > Shoes: > > > Shoes is a cross-platform toolkit for writing graphical apps easily and artfully using Ruby. > > Unlike most other GUI toolkits, Shoes is designed to be easy and straightforward without losing power. Really, it’s easy! > > Important things: > > 1) cross platform. > 2) 'easily and artfully' > 3) easy and straightforward > > And I agree. What I love about Shoes is that it's actually Ruby. > You're not doing silly things like wxruby. Not to denigrate that > project, but they say this themselves: > > > The API doesn't seem very Ruby-like > > The current API is basically a straight port of the wxWidgets C++ interface. Well, actually it has several of the same adjustments > that wxPython also had to adopt due to language constraints. This interface is a bit clumsy in spots, thanks to its long history. > > (from http://wxruby.rubyforge.org/wiki/wiki.pl?WxRubyFAQs ) Yup, you have to connect the event dispatch to a ruby block. You probably have to match new()/malloc() to destroy()/free() to avoid memory leaks. You have to convert Shoe arguments to the tool kits arguments. That's what the C code in Shoes does (3 times for mac,msw,gtk), plus the cairo drawing. It has to be done no matter what graphical kit you pick. Even in Java it's easy to leak memory in a GUI. It only has to be done once for a new cross plaftorm toolkit and everything you need to know is right there in the C source code. It really is just (mostly) syntax conversion. Boring, tedious Except for the shoes/layout manager (flow/stacks). That might be tricky. Or not. > > Anyway, this is what we're trying to do. We have this code, and it > works. Sort of. There are lots of issues. Compilation is absolutely > insane. Lots of the process is stuff that only _why knew about. These > shoes have deep, dark corners. We've been doing a good job of this so > far, but we're only a few intrepid codesmiths. Let's face it, while > Shoes has gotten a bit more active lately, we're still less than a > dozen members in sum total. > > With that much said, a re-write would introduce significant amounts of > technical risk. It would be pretty advantageous. All of the code would > be known by us. We could choose better dependancies, and fix the > cross-platform issues. But it's also dangerous. Like I said, we only > have a few people. How much time can really be put into this? And a > re-write would basically stop development of Shoes proper, for the > same 'lack of manpower' reasons. > > At the same time, I think that a re-write would be good, overall. I > think we should go for it. WalkAbout, totally new. I think for Shoes > to move forward, it's the best possible thing. Mostly to get rid of > the damn dependancies. And for a clean, fresh start. > > > > So. With that said. What would I do, for a re-write? Well, there's a > couple of considerations: > > 1. Cross platform. This is absolutely necessary. It should be write > once, run everywhere, ideally. > 2. Packaging : this is a biggie, too. People use this a lot, and it's > a major pain point, currently. I need this for Hackety Hack, too. > 3. Compilation: it should be reasonably easy to get shoes up and running > 4. API support: I agree with Devyn's comment about the API being a bit > more nice in some small ways. I don't have a list off of the top of my > head, but this would be a great opportunity to do some things that > might break backwards compatibility. > 5. Testability: Shoes has no tests, and there's no way to test Shoes > apps. Ideally, a solution would let us do this. Right now, this is > horrible about Shoes. > > > That sounds like a lot of user fun and uniqueness taken out of Shoes. > > I disagree with this, a lot. As long as the Shoes API is the > same/close, how would it be different? Nobody knows Shoes internals > anyway (sorry, bad pun), why would they care if it's using Cairo or > wxwidgets or anything else? The context of my comment was that after removing the packaging and builtins (ext/ dir) to fit in the Java/JRuby mold, it wouldn't be the same beginner friendly approachable shoes. There is Shoes (the language) and Shoes (the user experience). > > Ultimately, though, here's the kicker: If this happens, someone's > going to have to do it. We can talk all we want about what might be > better or what might not be better, in the end, whoever picks it up > and does something will probably win. Yeah, that's what will happen. Someone with the time will step up and do the early work, and either succeed or fail to attract the needed support to finish it. > > If I had unlimited time, I'd start tomorrow. Getting OSX to work (sort > of, HEAD is still a bit wonky) put me in such a furious rage that I'd > rather just rewrite all of shoes myself than play around with it. I know the feeling. I'm tempted to rip most of the binary packager out of shoes (you can't get to it w/o a commandline switch anyway) and make a gem out of if to be used in a separate Shoes Packager app with a lot more flexibility for selecting what you want to do and pointing to where the damn net install binaries actually live and what their name is. > > > Here's the other big thing: if we do 'decide' to do this... how does > that decision come about? Do we have a vote of some kind, here on the > ML, or somewhere else? Who all can vote? Does it matter? Practically, the process doesn't matter without a shared goal or a accepted leader. We're still talking about a goal. That's fine and fun and useful because we learn something.
On Tue, Aug 24, 2010 at 2:16 AM, Steve Klabnik <steve@steveklabnik.com> wrote: > > Here's the other big thing: if we do 'decide' to do this... how does > that decision come about? Do we have a vote of some kind, here on the > ML, or somewhere else? Who all can vote? Does it matter? I'd say start a project and have people hack on it in parallel with hacking on the shoes 3 c codebase. We'd get cross-pollination of ideas that way. The new project might even attract coders who don't want to get into the current code but might be excited about a ground-up rewrite. martin
Quite true. I just don't want to have a bunch of people work on something like this, and then have it not even be accepted back into trunk. That's all. It'd absolutely be in a different branch. On Mon, Aug 23, 2010 at 4:56 PM, Martin DeMello <martindemello.libre@gmail.com> wrote: > On Tue, Aug 24, 2010 at 2:16 AM, Steve Klabnik <steve@steveklabnik.com> wrote: >> >> Here's the other big thing: if we do 'decide' to do this... how does >> that decision come about? Do we have a vote of some kind, here on the >> ML, or somewhere else? Who all can vote? Does it matter? > > I'd say start a project and have people hack on it in parallel with > hacking on the shoes 3 c codebase. We'd get cross-pollination of ideas > that way. The new project might even attract coders who don't want to > get into the current code but might be excited about a ground-up > rewrite. > > martin >
It wouldn't be a question of being accepted into trunk, because the new codebase would clearly be incompatible with shoes 3. So if people for some reason don't like the new branch, it'd at most come down to arguing over what gets to be called "shoes". I'd be fine with the new code being called something slightly different, like JShoes, if it came to that. As to where I stand on the rewrite, I'm all for it, for two main reasons - 1. shoes needs a serious speed boost and 2. some of the scoping rules are rather ugly, and detract from a widget-oriented approach. If we found a really good high-level canvas engine with enough flexibility in its layout mechanism to let shoes be built on top of it with the stacks-and-flows layout intact, and built ruby bindings to it, we might even manage to make it a ruby library rather than an fork of the interpreter. martin On Tue, Aug 24, 2010 at 2:35 AM, Steve Klabnik <steve@steveklabnik.com> wrote: > Quite true. I just don't want to have a bunch of people work on > something like this, and then have it not even be accepted back into > trunk. That's all. It'd absolutely be in a different branch. > > On Mon, Aug 23, 2010 at 4:56 PM, Martin DeMello > <martindemello.libre@gmail.com> wrote: >> On Tue, Aug 24, 2010 at 2:16 AM, Steve Klabnik <steve@steveklabnik.com> wrote: >>> >>> Here's the other big thing: if we do 'decide' to do this... how does >>> that decision come about? Do we have a vote of some kind, here on the >>> ML, or somewhere else? Who all can vote? Does it matter? >> >> I'd say start a project and have people hack on it in parallel with >> hacking on the shoes 3 c codebase. We'd get cross-pollination of ideas >> that way. The new project might even attract coders who don't want to >> get into the current code but might be excited about a ground-up >> rewrite. >> >> martin >> >
> It wouldn't be a question of being accepted into trunk, because the > new codebase would clearly be incompatible with shoes 3. What I'm talking about is that Shoes 4 _is_ the re-write. > I'd be fine with the new > code being called something slightly different, like JShoes, if it > came to that. While I'm fine with that in concept, a fork would destroy our already small community.
On Tue, Aug 24, 2010 at 2:47 AM, Steve Klabnik <steve@steveklabnik.com> wrote: >>> It wouldn't be a question of being accepted into trunk, because the >>> new codebase would clearly be incompatible with shoes 3. >> >> What I'm talking about is that Shoes 4 _is_ the re-write. >> >>> I'd be fine with the new >>> code being called something slightly different, like JShoes, if it >>> came to that. >> >> While I'm fine with that in concept, a fork would destroy our already >> small community. My fear is that embarking on an ambitious ground-up rewrite while shoes 3 languishes could do that too. martin
> My fear is that embarking on an ambitious ground-up rewrite while > shoes 3 languishes could do that too. Absolutely. This isn't a lightly-made decision.
If I'm not mistaken, using rawr+monkeybars with jruby, you're able to package your application with the jruby jar and the only requirement for users would be having java installed, which a majority of people do. At least thats my understanding of how those tools all work together... On 22 Aug 2010, at 12:06 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > There are pro's and con's worth discussing. > > Java + jRuby is not going to start up nearly as quickly. Even pure java > GUI apps have to set up splash/progress screens to let the user know > something is happening. > > Some things can't be done. Like easy user installation (they have > download and install java and jruby first) On the other hand, we > wouldn't need pack.rb and binject so that's a plus for developers. > > As far as I know, Java has no video/audio widgets that work as users > think they should. (+) We wouldn't have to figure out VLC or port > Bloopsaphone. There is no reason or way to distribute SqLite (the user > will be happy to install it, or mySql or Oracle or DB2 and get the java > bridge working). We Shoes developers wouldn't have to distribute/manage > the entire ext tree. Any gem issues can't be fixed by us so that's > another load off our developer shoulders. > > That sounds like a lot of user fun and uniqueness taken out of Shoes. > On the other hand, with all the uniqueness removed, it would be easier > to maintain. You only have write the awt/swt mapping once which wouldn't > be easy but not certainly not impossible for a motivated person with a > lot of time on their hands. > > It wouldn't be the Shoes we know, but it could be done. User experience > would suck. > > I seriously doubt one can write the Shoes to Java GUI mapping layer in > Ruby . Duby might work, but you're still fight getting all the widget > event listeners, widgets and graphics context set correct like Shoes > wants and what awt/swt (your choice) allows. That is the hard work and > the language used to do it is a minor problem. > > As someone asked a few days ago, why can't Shoes be a gem? The reasons > _why didn't use heavy weight Java or wxRuby or wxTk are deep in our > source code. > > Contemplate how you would move Shoes (as we know it) to Android. > > > > On Sat, 2010-08-21 at 23:31 +0200, Vojtěch Šalbaba wrote: >> I cant see rewriting shoes as one man job. And it will be pain in the >> arse - in my experience, Ruby is slow. >> And it will be enormous amount of work. >> And it would be awesome if it would ever work. >> Do you mean pure ruby, or jruby, as mental was suggesting? >> regards >> Vojtěch Šalbaba >> >> >> >> 2010/8/21 ashbb <ashbbb@gmail.com> >> Hi all, >> >> I remember this post: >> http://librelist.com/browser//shoes/2009/11/2/direction-of-shoes/ >> >> If possible, I'd like to challenge rewriting Shoes in pure >> Ruby. >> >> But for now, I've no idea and no ability and don't know where >> is the start point. :( >> >> Please give me your comments and suggestions. >> >> ashbb >> >> > > >
On Sat, Aug 21, 2010 at 9:06 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > There are pro's and con's worth discussing. > > Java + jRuby is not going to start up nearly as quickly. Even pure java > GUI apps have to set up splash/progress screens to let the user know > something is happening. > JVM has gotten a lot faster over the years. I disagree; I think it's entirely possible. > > Some things can't be done. Like easy user installation (they have > download and install java and jruby first) On the other hand, we > wouldn't need pack.rb and binject so that's a plus for developers. > Java, yes, although many operating systems already include it in some form and would just need to be updated. But JRuby could be bundled with it, current Shoes already includes an entire Ruby distribution (stdlib and all) and JRuby is even smaller. > > As far as I know, Java has no video/audio widgets that work as users > think they should. (+) Sure there are, not in the standard library, but they're around :) > We wouldn't have to figure out VLC or port > Bloopsaphone. There is no reason or way to distribute SqLite (the user > will be happy to install it, or mySql or Oracle or DB2 and get the java > bridge working). We Shoes developers wouldn't have to distribute/manage > the entire ext tree. Any gem issues can't be fixed by us so that's > another load off our developer shoulders. > > That sounds like a lot of user fun and uniqueness taken out of Shoes. > I disagree. Shoes would be faster and even more flexible. Shoes with Cairo is slow. > On the other hand, with all the uniqueness removed, it would be easier > to maintain. You only have write the awt/swt mapping once which wouldn't > be easy but not certainly not impossible for a motivated person with a > lot of time on their hands. > Who says we have to use AWT or SWT? Personally, I feel that native-looking UIs should not be the goal of Shoes; that Shoes is more about the unique, artsy interfaces inspired by the freedom of the web (but a lot easier and more flexible). > > It wouldn't be the Shoes we know, but it could be done. User experience > would suck. > Framerate would be better, though. I once built a game in Shoes (on old-ish hardware, mind you) with a fair bit of drawing (about 16 layers) involved, and I could squeeze out a max of 20fps out of it (and that was at 400x300). Ported it to LÖVE, and it ran at 80fps 1024x768. I'm not really sure how there could be such a difference, but… > > I seriously doubt one can write the Shoes to Java GUI mapping layer in > Ruby . Again, no one says we have to use Java's standard library. There's LWJGL, for example (and higher level 2D libraries on top of it like Slick). > Duby might work, but you're still fight getting all the widget > event listeners, widgets and graphics context set correct like Shoes > wants and what awt/swt (your choice) allows. That is the hard work and > the language used to do it is a minor problem. > I don't think we have to be 100% backward compatible. I think Shoes' API could be quite a bit more intuitive. Sure, this may break some more complex existing apps, but I think it'll make Shoes a lot more fun (one of the goals). > > As someone asked a few days ago, why can't Shoes be a gem? The reasons > _why didn't use heavy weight Java or wxRuby or wxTk are deep in our > source code. > Java's pretty big, I'll admit, but many people already have it installed (from own experience). OS X includes it! > > Contemplate how you would move Shoes (as we know it) to Android. > I don't think that's a goal, at least, for now. Android may use Java the language, but there are a lot of differences that may/may not be worth the effort. That said, it could make an interesting hobbyist project, to make something Shoes-like for Android. > > > > On Sat, 2010-08-21 at 23:31 +0200, Vojtěch Šalbaba wrote: > > I cant see rewriting shoes as one man job. And it will be pain in the > > arse - in my experience, Ruby is slow. > > And it will be enormous amount of work. > > And it would be awesome if it would ever work. > > Do you mean pure ruby, or jruby, as mental was suggesting? > > regards > > Vojtěch Šalbaba > > > > > > > > 2010/8/21 ashbb <ashbbb@gmail.com> > > Hi all, > > > > I remember this post: > > > http://librelist.com/browser//shoes/2009/11/2/direction-of-shoes/ > > > > If possible, I'd like to challenge rewriting Shoes in pure > > Ruby. > > > > But for now, I've no idea and no ability and don't know where > > is the start point. :( > > > > Please give me your comments and suggestions. > > > > ashbb > > > > > > > > -- ~devyn
On Sun, Aug 22, 2010 at 12:05 PM, Devyn Cairns <devyn.cairns@gmail.com> wrote: > > JVM has gotten a lot faster over the years. I disagree; I think it's > entirely possible. The startup speed is still horrible, though. Don't underestimate the impact of this; I'm developing a GUI app in swing/clojure and this is the worst aspect of it. martin
On Sat, 2010-08-21 at 23:35 -0700, Devyn Cairns wrote: > > Who says we have to use AWT or SWT? Personally, I feel that > native-looking UIs should not be the goal of Shoes; that Shoes is more > about the unique, artsy interfaces inspired by the freedom of the web > (but a lot easier and more flexible). LWJGL still needs native code to be build and installed in the users java.path. ick. You propose to write edit_line, edit_box, and scrolls from a mouse click and a keyboard interface? With internalization? You're braver than I. Remember how long Swing took to write? > > > It wouldn't be the Shoes we know, but it could be done. User > experience > would suck. > > > Framerate would be better, though. I once built a game in Shoes (on > old-ish hardware, mind you) with a fair bit of drawing (about 16 > layers) involved, and I could squeeze out a max of 20fps out of it > (and that was at 400x300). Ported it to LÖVE, and it ran at 80fps > 1024x768. I'm not really sure how there could be such a difference, > but… > > > I seriously doubt one can write the Shoes to Java GUI mapping > layer in > Ruby . > > > Again, no one says we have to use Java's standard library. There's > LWJGL, for example (and higher level 2D libraries on top of it like > Slick). > > Duby might work, but you're still fight getting all the widget > event listeners, widgets and graphics context set correct like > Shoes > wants and what awt/swt (your choice) allows. That is the hard > work and > the language used to do it is a minor problem. > > > I don't think we have to be 100% backward compatible. I think Shoes' > API could be quite a bit more intuitive. Sure, this may break some > more complex existing apps, but I think it'll make Shoes a lot more > fun (one of the goals). It is difficult to write big applications in Shoes because you run into speed issues or design limitations. Big applications are better left to wxruby (which has some Shoes like sugar) or other more complete toolkits. > > > As someone asked a few days ago, why can't Shoes be a gem? The > reasons > _why didn't use heavy weight Java or wxRuby or wxTk are deep > in our > source code. >
On Sun, Aug 22, 2010 at 3:27 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Sat, 2010-08-21 at 23:35 -0700, Devyn Cairns wrote: > > > > > Who says we have to use AWT or SWT? Personally, I feel that > > native-looking UIs should not be the goal of Shoes; that Shoes is more > > about the unique, artsy interfaces inspired by the freedom of the web > > (but a lot easier and more flexible). > > LWJGL still needs native code to be build and installed in the users > java.path. ick. > > You propose to write edit_line, edit_box, and scrolls from a mouse click > and a keyboard interface? With internalization? You're braver than I. > Remember how long Swing took to write? > There's always a way… and always an easier way… > > > > > > It wouldn't be the Shoes we know, but it could be done. User > > experience > > would suck. > > > > > > Framerate would be better, though. I once built a game in Shoes (on > > old-ish hardware, mind you) with a fair bit of drawing (about 16 > > layers) involved, and I could squeeze out a max of 20fps out of it > > (and that was at 400x300). Ported it to LÖVE, and it ran at 80fps > > 1024x768. I'm not really sure how there could be such a difference, > > but… > > > > > > I seriously doubt one can write the Shoes to Java GUI mapping > > layer in > > Ruby . > > > > > > Again, no one says we have to use Java's standard library. There's > > LWJGL, for example (and higher level 2D libraries on top of it like > > Slick). > > > > Duby might work, but you're still fight getting all the widget > > event listeners, widgets and graphics context set correct like > > Shoes > > wants and what awt/swt (your choice) allows. That is the hard > > work and > > the language used to do it is a minor problem. > > > > > > I don't think we have to be 100% backward compatible. I think Shoes' > > API could be quite a bit more intuitive. Sure, this may break some > > more complex existing apps, but I think it'll make Shoes a lot more > > fun (one of the goals). > > It is difficult to write big applications in Shoes because you run into > speed issues or design limitations. Big applications are better left to > wxruby (which has some Shoes like sugar) or other more complete > toolkits. > This isn't the goal of Shoes, though. Shoes is meant for making small GUI wrappers or just generally artsy (code-wise) things. I don't think _why ever intended for it to be used like that. Ever. > > > > > > As someone asked a few days ago, why can't Shoes be a gem? The > > reasons > > _why didn't use heavy weight Java or wxRuby or wxTk are deep > > in our > > source code. > > > > > > -- ~devyn
On Sun, 2010-08-22 at 20:14 -0700, Devyn Cairns wrote: > > > On Sun, Aug 22, 2010 at 3:27 PM, Cecil Coupe <ccoupe@cableone.net> > wrote: > On Sat, 2010-08-21 at 23:35 -0700, Devyn Cairns wrote: > > > > > Who says we have to use AWT or SWT? Personally, I feel that > > native-looking UIs should not be the goal of Shoes; that > Shoes is more > > about the unique, artsy interfaces inspired by the freedom > of the web > > (but a lot easier and more flexible). > > > LWJGL still needs native code to be build and installed in the > users > java.path. ick. > > You propose to write edit_line, edit_box, and scrolls from a > mouse click > and a keyboard interface? With internalization? You're braver > than I. > Remember how long Swing took to write? > > > There's always a way… and always an easier way… Indeed. Don't reinvent the wheel is the easier way or wait for someone else to do it. Bless the swt forks to doing just that. Too bad the LWJGL folks don't describe how to integrate swt or awt. Just links to articles to be written. If you know how, tell us (and them) > It is difficult to write big applications in Shoes because you > run into > speed issues or design limitations. Big applications are > better left to > wxruby (which has some Shoes like sugar) or other more > complete > toolkits. > > > This isn't the goal of Shoes, though. Shoes is meant for making small > GUI wrappers or just generally artsy (code-wise) things. > > > I don't think _why ever intended for it to be used like that. Ever. Was it meant for maximum frame rate games? Or people like me that stuff a few thousand para into a slot to discover that is beyond Shoes ability? Having looked at the C code in shoes/ for a few hours it's hopelessly tied to Cairo and the native widgets. I'm not sure the user written Shoes widget is a viable idea either after having poked around. It depends on what you think Shoes is and what it should be. Is it a simple to install way to learn GUI programming? That you can simply package to share your creation with your buds. Almost as easy as sending a link to your garage band mp3 with "Dude, listen to this" On the other hand, if you think of Shoes as a promising GUI DSL that just needs more widgets and options and better frame rates, then you can port the spirit of Shoes 'the GUI language' to another platform of your choice that doesn't have the easy to share capabilities. Whether that platform is jRuby(+swt|awt|swing) or something like wxRuby won't matter in the effort involved. Strip out all the builtin ext/ libraries and private gem libraries and make Shoes a supra layout manager. Just a gem to include at the top of the script. It's only 30 or 40 classes to be rewritten and tested. Go for it. We are waiting. --Cecil
Hi all, I found rcairo was updated a few days ago on github: http://github.com/rcairo/rcairo So, I came up with an idea, - replace platform native/dependent code (edit_line, edit_box, button, list_box) with rcairo Do you think it is worth trying? ashbb
On Mon, Aug 23, 2010 at 6:41 AM, ashbb <ashbbb@gmail.com> wrote: > Hi all, > > I found rcairo was updated a few days ago on github: > http://github.com/rcairo/rcairo > > So, I came up with an idea, > > - replace platform native/dependent code (edit_line, edit_box, button, > list_box) with rcairo > > Do you think it is worth trying? > Unless I misunderstand, I don't think this will really help us at all. > > ashbb > -- ~devyn
Sorry about that last email, it kind of got… lost ;] About the whole situation: I think Qt could work for us. Maybe. Only if Cairo works well with it. Cairo can output through OpenGL (via glitz), which would be ideal if we can get Qt working with OpenGL in this way. It would give us great hardware acceleration, which we desperately need (if you don't believe me, just try an animation test at a large resolution with Shoes. LLLLLLAAAAAAGGGGGG ALERT!!! o_O) On a related note, I'm still anti-native-widgets. I really think they stick out like a sore thumb in Shoes' artfully crafted, web-inspired interfaces. We should just provide a detailed custom widget API, and provide some default widgets (which use this API themselves) for use. As I see it, blending in is quite the opposite of the goal of Shoes. I think _why said it best: I don't like the bulkiness and the layers and layers of wxWindows, FOX, QT, > GNOME. They are big, big libraries and all the apps look identical, devoid of > spirit. Our goal should be to produce a platform that facilitates easy creation of unique applications. -- ~devyn
On Tue, 2010-08-24 at 20:14 -0700, Devyn Cairns wrote: > Sorry about that last email, it kind of got… lost ;] > > About the whole situation: I think Qt could work for us. Maybe. Only > if Cairo works well with it. Cairo can output through OpenGL (via > glitz), which would be ideal if we can get Qt working with OpenGL in > this way. It would give us great hardware acceleration, which we > desperately need (if you don't believe me, just try an animation test > at a large resolution with Shoes. LLLLLLAAAAAAGGGGGG ALERT!!! o_O) Cairo is an attempt to match OSX's pdf rendering model. PDF. Documents. Forms, small images in forms. It was seriously cool idea when OSX did that. It was happening. We all squealed in delight. A paradigm shift of epic proportions. Apple made it work w/o requiring graphics cards that cost more than the machine to put them in. Still, Apple couldn't deliver on gaming performance demands. Why do you expect Cairo and Shoes should deliver what Apple couldn't provide for Quartz? If Cairo is to slow and you know the solution, I'm sure they'd love to hear about it. > On a related note, I'm still anti-native-widgets. I really think they > stick out like a sore thumb in Shoes' artfully crafted, web-inspired > interfaces. We should just provide a detailed custom widget API, and > provide some default widgets (which use this API themselves) for use. We'd love to hear (in detail) about your alternative vision of push buttons, checkboxes, radio buttons, menus, drop down menus, edit_lines, edit_boxes and progress bars. You could change GUI design forever! No, I'm really not being snarky because all proposals have something to consider. > As I see it, blending in is quite the opposite of the goal of Shoes. I > think _why said it best: > > I don't like the bulkiness and the layers and layers of > wxWindows, FOX, QT, GNOME. > They are big, big libraries and all the apps look identical, > devoid of spirit. > > > Our goal should be to produce a platform that facilitates easy > creation of unique applications. _why was brilliant and eccentric, in code and art and prose. He vanished like the Jesus did in those missing years. We've got your widget free vision, and not enough details to implement something that doesn't look like a crap DVD front page with annoying swirling background, endless annoying music and incomprehensible navigation and it's different for every DVD. Or is that what you propose for Shoes? Art first, usefulness is #2? > > -- > ~devyn I mentioned [long] in the subject header. Forgive me. Or tolerate me.
On Tue, Aug 24, 2010 at 10:48 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Tue, 2010-08-24 at 20:14 -0700, Devyn Cairns wrote: > > Sorry about that last email, it kind of got… lost ;] > > > > About the whole situation: I think Qt could work for us. Maybe. Only > > if Cairo works well with it. Cairo can output through OpenGL (via > > glitz), which would be ideal if we can get Qt working with OpenGL in > > this way. It would give us great hardware acceleration, which we > > desperately need (if you don't believe me, just try an animation test > > at a large resolution with Shoes. LLLLLLAAAAAAGGGGGG ALERT!!! o_O) > > Cairo is an attempt to match OSX's pdf rendering model. PDF. Documents. > Forms, small images in forms. It was seriously cool idea when OSX did > that. It was happening. We all squealed in delight. A paradigm shift of > epic proportions. Apple made it work w/o requiring graphics cards that > cost more than the machine to put them in. Still, Apple couldn't deliver > on gaming performance demands. Why do you expect Cairo and Shoes should > deliver what Apple couldn't provide for Quartz? If Cairo is to slow and > you know the solution, I'm sure they'd love to hear about it. > Cairo itself isn't too slow; for Shoes' drawing purposes that kind of vector-graphics based API is perfect! I have this crazy idea, though, that using glitz as a backend with it will speed it up a ton. After all, that's why Cairo supports many different backends, isn't it? So you can choose the one you need. Even if there's no hardware OpenGL support (which by now I think is quite unlikely), there's software OpenGL drawing. > > On a related note, I'm still anti-native-widgets. I really think they > > stick out like a sore thumb in Shoes' artfully crafted, web-inspired > > interfaces. We should just provide a detailed custom widget API, and > > provide some default widgets (which use this API themselves) for use. > > We'd love to hear (in detail) about your alternative vision of push > buttons, checkboxes, radio buttons, menus, drop down menus, edit_lines, > edit_boxes and progress bars. You could change GUI design forever! No, > I'm really not being snarky because all proposals have something to > consider. > > > As I see it, blending in is quite the opposite of the goal of Shoes. I > > think _why said it best: > > > > I don't like the bulkiness and the layers and layers of > > wxWindows, FOX, QT, GNOME. > > They are big, big libraries and all the apps look identical, > > devoid of spirit. > > > > > > Our goal should be to produce a platform that facilitates easy > > creation of unique applications. > > _why was brilliant and eccentric, in code and art and prose. Yes, indeed! And I think it would be wise to follow in his steps. > He vanished like the Jesus did in those missing years. > Still not completely sure what you mean by that. > > We've got your widget free vision, and not enough details to implement > something that doesn't look like a crap DVD front page with annoying > swirling background, endless annoying music and incomprehensible > navigation and it's different for every DVD. Your point here is valid. But again, look at the web for inspiration. There's so many great-looking sites out there! How many of them (the good looking ones) use native widgets, though? And Shoes beats HTML+CSS in ease of layout; stacks + flows are brilliant! I think this is the direction we should head in. We need to be a better, easier, simpler HTML. That doesn't necessarily mean following the browser paradigm; I think that's wrong for Shoes. But ease of delivery should certainly be a goal. > Or is that what you propose > for Shoes? Art first, usefulness is #2? > I didn't say widget free, I said native-widget free. Shoes, in its basic form, *is* a GUI toolkit—but that's not its purpose. Shoes is not a competitor to Wx, Qt, etc. Yeah, they have a lot in common, it's true. However, as I see it: *Similarities* - We strive for cross-platform compatibility. - We're platforms for GUI applications. *Differences* - Shoes is more about code that, really, anyone could understand given a little bit of an explanation of the syntax. - Shoes is about unique content and presentation, more like the web as it is today, whereas other toolkits are about uniform interfaces and guidelines like Apple's HIG. If you still don't agree, try making a nice, animated, colorful background. Then put a native button in the middle of it. See? Ugly. I think if we ditch native controls, we could save a lot of code and make Shoes go way further. > > > > > -- > > ~devyn > I mentioned [long] in the subject header. Forgive me. Or tolerate me. > It's fine; I think our discussions help the community more than they hurt it. They help give us a clear direction of where to go (it works best when the two people have quite opposite views). -- ~devyn
On Wed, 2010-08-25 at 18:23 -0700, Devyn Cairns wrote: > > > I think if we ditch native controls, we could save a lot of code and > make Shoes go way further. Time to wind this sub-sub-thread down. I'm not opposed to someone creating a non-native edit_list with scroll bars using cairo drawing primitives and the primitive mouse, keyboard interfaces. In C or rcairo. Easy peasy, eh?. Less code? Ask the Swing developers about less code or how long it takes to invent the not-native widgets. The Shoes developers group is small. We couldn't even get the packager, stubs and website in sync for the fricken policeman release. > > > It's fine; I think our discussions help the community more than they > hurt it. They help give us a clear direction of where to go (it works > best when the two people have quite opposite views). Grand visions are fun to explore and occasionally powerful. Experiments are good and I expect the community will learn something from Shoes/qt and Shoes/rcairo. That's all good. In the 'between' time we have bugs to fix. Shoes alert() (probably console, ask and friends) appears to not be thread safe with 1.9.1/GLib and the website can't deliver what the linux and dmg stubs want. > > -- > ~devyn
> In the 'between' time we have bugs to fix. Shoes alert() (probably > console, ask and friends) appears to not be thread safe with 1.9.1/GLib > and the website can't deliver what the linux and dmg stubs want. Where did I miss this? Or has it just been something you've noticed and haven't reported to the group yet? The thread safety, not the site.
On Thu, 2010-08-26 at 09:38 -0400, Steve Klabnik wrote: > > In the 'between' time we have bugs to fix. Shoes alert() (probably > > console, ask and friends) appears to not be thread safe with 1.9.1/GLib > > and the website can't deliver what the linux and dmg stubs want. > > Where did I miss this? Or has it just been something you've noticed > and haven't reported to the group yet? > > > The thread safety, not the site. I reported it during the ruby/qt/ messages, so it was easy to miss. Gtk is complaining that alert is trying to start a new gui main thread. It usually hangs everything, or quits or sometimes sort of works as it should. you can try to recreate it by starting the Shoes packager (shoes -p) select either osx or linux (unselect the others) and attempt to package any script into a binary. Bring up the console window if you like. When you click the go button, pack.rb starts a ruby thread and calls the selected os packager which attempts to download from the website, which fails for linux or osx calls Shoes alert and GTK tosses up an error message on the terminal and the hang/quit/succeed occurs. For me. on system. I'm quite willing to believe that an alert in thread is a bad idea or that alert was never written to consider that possibility and it would hang raisins in 1.8.7 too when the website fails to deliver. I kind of remember that it did back then.
Also, just as a note... many of these toolkits have the capacity for custom widgets, so if having shoes look unique is really that important to the project, that doesn't preclude the use of them.
Custom widgets drawn with Cairo? On Wed, Aug 25, 2010 at 7:39 PM, Steve Klabnik <steve@steveklabnik.com>wrote: > Also, just as a note... many of these toolkits have the capacity for > custom widgets, so if having shoes look unique is really that > important to the project, that doesn't preclude the use of them. > -- ~devyn
Hi Vojtěch, Devyn, Cecil et al, Thank you for the discussions. :) Vojtěch wrote: > Do you mean pure ruby, or jruby, as mental was suggesting? I used the word `pure ruby`, but I don't have a clear definition. :-P I just want to avoid platform dependent maintenance as far as possible. Cecil and Devyn wrote: > It wouldn't be the Shoes we know... > Shoes is more about the unique, artsy interfaces.... Good point. I love Shoes. I don't want to lose any fun of Shoes. ;-) Thanks again. I'll keep consideration a little more. ashbb
On Sat, Aug 21, 2010 at 11:58 PM, ashbb <ashbbb@gmail.com> wrote: > Hi Vojtěch, Devyn, Cecil et al, > > Thank you for the discussions. :) > > > Vojtěch wrote: > > Do you mean pure ruby, or jruby, as mental was suggesting? > I used the word `pure ruby`, but I don't have a clear definition. :-P > I just want to avoid platform dependent maintenance as far as possible. > > Cecil and Devyn wrote: > > It wouldn't be the Shoes we know... > > Shoes is more about the unique, artsy interfaces.... > Good point. I love Shoes. I don't want to lose any fun of Shoes. ;-) > Perhaps you misunderstood my argument—I think that Shoes could be much more unique and artsy were it developed with a faster and more readable library such as Slick using an abstraction written in JRuby. > > Thanks again. I'll keep consideration a little more. > > ashbb > > -- ~devyn
2010/8/21 Vojtěch Šalbaba <vojtech.salbaba@gmail.com> > I cant see rewriting shoes as one man job. And it will be pain in the arse > - in my experience, Ruby is slow. It's been getting a lot faster; 1.8.7 to 1.9.1 was a huge leap in speed (by my tests, ~10x for many applications—but don't trust them, they're probably flawed. the point: it's faster) > And it will be enormous amount of work. > And it would be awesome if it would ever work. > Totally. > Do you mean pure ruby, or jruby, as mental was suggesting? > Personally I would go with JRuby, in my experience Java-based apps are a lot easier to distribute. It's a bit low-level, but we could use LWJGL in some form to do this. It'd make Shoes a *lot* faster. > regards > Vojtěch Šalbaba > > > > 2010/8/21 ashbb <ashbbb@gmail.com> > > Hi all, >> >> I remember this post: >> http://librelist.com/browser//shoes/2009/11/2/direction-of-shoes/ >> >> If possible, I'd like to challenge rewriting Shoes in pure Ruby. >> >> But for now, I've no idea and no ability and don't know where is the start >> point. :( >> >> Please give me your comments and suggestions. >> >> ashbb >> > > -- ~devyn