librelist archives

« back to archive

Shoes in pure Ruby

Shoes in pure Ruby

From:
ashbb
Date:
2010-08-21 @ 09:05
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

Re: [shoes] Shoes in pure Ruby

From:
Vojtěch Šalbaba
Date:
2010-08-21 @ 21:31
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
>

Re: [shoes] Shoes in pure Ruby

From:
Devyn Cairns
Date:
2010-08-21 @ 22:32
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Cecil Coupe
Date:
2010-08-22 @ 04:06
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 
> 
> 


Re: [shoes] Shoes in pure Ruby [Long]

From:
Devyn Cairns
Date:
2010-08-22 @ 06:35
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
ashbb
Date:
2010-08-22 @ 06:58
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Devyn Cairns
Date:
2010-08-22 @ 07:03
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Cecil Coupe
Date:
2010-08-22 @ 22:27
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.
> 


Re: [shoes] Shoes in pure Ruby [Long]

From:
Devyn Cairns
Date:
2010-08-23 @ 03:14
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Cecil Coupe
Date:
2010-08-23 @ 05:03
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
ashbb
Date:
2010-08-23 @ 13:41
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Devyn Cairns
Date:
2010-08-25 @ 02:47
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Devyn Cairns
Date:
2010-08-25 @ 03:14
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Cecil Coupe
Date:
2010-08-25 @ 05:48
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.

Re: [shoes] Shoes in pure Ruby [Long]

From:
Devyn Cairns
Date:
2010-08-26 @ 01:23
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Steve Klabnik
Date:
2010-08-26 @ 02:39
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.

Re: [shoes] Shoes in pure Ruby [Long]

From:
Devyn Cairns
Date:
2010-08-26 @ 04:13
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Cecil Coupe
Date:
2010-08-26 @ 05:05
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Steve Klabnik
Date:
2010-08-26 @ 13:38
> 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.

Re: [shoes] Shoes in pure Ruby [Long]

From:
Cecil Coupe
Date:
2010-08-27 @ 01:12
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. 

Re: [shoes] Shoes in pure Ruby [Long]

From:
Martin DeMello
Date:
2010-08-23 @ 14:26
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Scott Werner
Date:
2010-08-22 @ 12:05
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 
>> 
>> 
> 
> 
> 

Re: [shoes] Shoes in pure Ruby [Long]

From:
Fela Winkelmolen
Date:
2010-08-23 @ 20:09
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Cecil Coupe
Date:
2010-08-24 @ 01:38
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?





Re: [shoes] Shoes in pure Ruby [Long]

From:
Steve Klabnik
Date:
2010-08-24 @ 02:45
QT is GPL'd, and 100% cross platform.

Re: [shoes] Shoes in pure Ruby [Long]

From:
Cecil Coupe
Date:
2010-08-24 @ 05:24
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++. 

Re: [shoes] Shoes in pure Ruby [Long]

From:
Martin DeMello
Date:
2010-08-24 @ 05:27
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Cecil Coupe
Date:
2010-08-24 @ 06:20
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. 

Re: [shoes] Shoes in pure Ruby [Long]

From:
Fela Winkelmolen
Date:
2010-08-24 @ 06:48
>> 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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Vojtěch Šalbaba
Date:
2010-08-24 @ 11:05
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
>

Re: [shoes] Shoes in pure Ruby [Long]

From:
Steve Klabnik
Date:
2010-08-24 @ 12:23
> 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.

Re: [shoes] Shoes in pure Ruby [Long]

From:
ashbb
Date:
2010-08-24 @ 14:27
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Fela Winkelmolen
Date:
2010-08-24 @ 06:11
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 =)

Re: [shoes] Shoes in pure Ruby [Long]

From:
Steve Klabnik
Date:
2010-08-23 @ 20:46
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?

Re: [shoes] Shoes in pure Ruby [Long]

From:
Martin DeMello
Date:
2010-08-23 @ 20:56
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Steve Klabnik
Date:
2010-08-23 @ 21:05
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
>

Re: [shoes] Shoes in pure Ruby [Long]

From:
Martin DeMello
Date:
2010-08-23 @ 21:14
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
>>
>

Re: [shoes] Shoes in pure Ruby [Long]

From:
Steve Klabnik
Date:
2010-08-23 @ 21:17
> 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.

Re: [shoes] Shoes in pure Ruby [Long]

From:
Martin DeMello
Date:
2010-08-23 @ 21:36
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

Re: [shoes] Shoes in pure Ruby [Long]

From:
Steve Klabnik
Date:
2010-08-23 @ 21:38
> 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.

Re: [shoes] Shoes in pure Ruby [Long]

From:
Cecil Coupe
Date:
2010-08-24 @ 03:23
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.