librelist archives

Re: [shoes] Passing command line args to shows, application focus, PDF viewing

From:

Cecil Coupe

Date:

2010-04-08 @ 03:29

> 1) Is there a way to pass commandline arguments to Shoes?  Whenever I
> tried it (as in
> 
http://github.com/AndrewO/assert_acceptable/blob/master/lib/assert_acceptable/acceptor.rb#L24),
> I would get a warning that my message text was not a directory.  The
> code would work later, but I'm guessing that was because I was ARGV
> still works as expected/

I took a quick look at the shoes/shoes.rb file where some of the option
parsing occurs (like passing the args on -g|--gem). Adding --args and
--script seems like a good idea. 

> 
> 2) Is there a cross-platform way for a Shoes app to make itself the
> focused app?  When I run a unit test using this (on OS X), it always
> appears behind my terminal.  Something tells me that's handled by the
> OS, but I'd love it if I were wrong.

On my system (Ubuntu) when I run a shoes script from the command line
the windows are on top and active. I vaguely remember that problem when
I had OSX and I think there was Terminal preference or maybe a system
preference to control it. 
> 
> 3) Originally I was trying to base the acceptance or failure of the
> assertion off of the process exit status.  However the Shoes
> Kernel.exit seems to not take a status param.  Writing to STDOUT works
> fine, but I'd be interested if it's possible (or advisable) to change
> the exit status.

Seems like oversight to me for Shoes.exit not to return a status code
assuming it makes sense to the 
> 
> Finally, I realize that most Shoes apps are written as standalones.
> Is this a sort of philosophical abuse of Shoes that would be better
> done in another (even possibly non-Ruby) GUI?

It's an interesting idea, putting a shoes app in a command line pipe or
in one of those Apple workflow thingies. I'd want to verify that Shoes
never redirects stdout or stderr. I think it does in some situations but
I can't prove it so don't rely on my claim.

If your process/workflow allows it, Make Shoes the controller of the
process and design a wizard like GUI to move through the scripts and
images within between Shoes pages/views program. I've always thought
that was nice niche for Shoes.

That said, it should behave as part of pipe. 

> 
> Thanks, and I appreciate the work you all have done to keep Shoes going.
> 
> –Andrew

I did a tiny bit of research on exit status codes.

On Wed, 2010-04-07 at 21:29 -0600, Cecil Coupe wrote:
> > 3) Originally I was trying to base the acceptance or failure of the
> > assertion off of the process exit status.  However the Shoes
> > Kernel.exit seems to not take a status param.  Writing to STDOUT
> works
> > fine, but I'd be interested if it's possible (or advisable) to
> change
> > the exit status.
> 
> Seems like oversight to me for Shoes.exit not to return a status code
> assuming it makes sense.

I'm sure you will be shocked to learn I was wrong and it makes sense. As
written, the shoes exit/quit command accepts no status code. That could
be added. Eventually the call will reach code in shoes/native/gtk.c,
windows.c and cocoa.m

>From what I see, gtk_quit() accepts no exit code argument -- Game over.
cocoa.m and windows.c hard code their response so Shoes could perhaps
translate to platform specific exit code in their exits but it wouldn't
necessarily be unix command line exit codes suitable for a command line
pipe. Perhaps there is a gtk call to set the exit code, before the quit?
Who knows? I'm not GTK savvy. 

In some ways it doesn't make sense for a qui app to return a status -
Theres only one menu item - Quit, mirrored in button_press-> quit()

Writing/hooking a dbus talking plus and/or applescript extension or gem
into shoes would be a fine project to look into once shoes policeman is
stable enough. 

Shoes sends the 'quit' command and the 'exit' command to the same piece
of native code shoes_native_quit(), They don't have to be the same
function. Perhaps exit could have an optional argument (default to
current behavior) that indicates the status code to return. I'm only
thinking out loud and soliciting feedback. 

GTK does have a deprecated gtk_exit(int code) -- I need to learn more
about that before I go too far. But,

What if we add a new shoes command -- 'fail' or 'quit-because' or...
Maybe 'terminate'. A shoes scripter that needs exit codes could write

  button "Accept" do
	terminate
	# without arguments, it would send the "success" code for the 
	# platform (like exit and quit do now)
  end
  button "Reject" do 
	terminate :reason => "I don't like it", :return = 12
  end

The terminate arguments is not clear to me. Maybe :return -> 12 is the
unix status code or it could be a call back to some applescript or dbus
thing or whatever windows uses for external scripting.  Or

  terminate(reason-string, code-int [,&block]

or something like that. 

Your thoughts? 

P.S. This is a lot more fun than chasing 1.9.1 threading issues. I grow
weary of them.

>
>
> P.S. This is a lot more fun than chasing 1.9.1 threading issues. I grow
> weary of them.
>
>
I don't know a whole ton about this, but I hear that 1.9.2 doesn't have the
same threading issues as 1.9.1...

Hi Andrew et al,

Thank you for sharing your interesting idea, assert_acceptable.
It's very cool! So, I was inspired. :)

Look at a tiny note. I modified your code to use XML-RPC.


http://github.com/ashbb/shoes_tutorial_html/blob/master/mdowns/00546_XMLRPC4R.mdown

I don't think this is a good solution to use Shoes in your library. But hope
this helps in some time or other. ;-)

Have fun with Shoes,
ashbb

You may want to check out http://github.com/Bluebie/legs as an alternative
to XML-RPC. It's more suited to really simple Ruby RPC.

On Fri, Apr 16, 2010 at 11:30 PM, Satoshi Asakawa <ashbbb@gmail.com> wrote:

> Hi Andrew et al,
>
> Thank you for sharing your interesting idea, assert_acceptable.
> It's very cool! So, I was inspired. :)
>
> Look at a tiny note. I modified your code to use XML-RPC.
>
>
> 
http://github.com/ashbb/shoes_tutorial_html/blob/master/mdowns/00546_XMLRPC4R.mdown
>
> I don't think this is a good solution to use Shoes in your library. But
> hope this helps in some time or other. ;-)
>
> Have fun with Shoes,
> ashbb
>



-- 
   ~devyn

Wow, Legs! Thank you for the information. Looks cool!

ashbb

On Wed, Apr 7, 2010 at 8:29 PM, Cecil Coupe <ccoupe@cableone.net> wrote:

>
> > 1) Is there a way to pass commandline arguments to Shoes?  Whenever I
> > tried it (as in
> >
> 
http://github.com/AndrewO/assert_acceptable/blob/master/lib/assert_acceptable/acceptor.rb#L24
> ),
> > I would get a warning that my message text was not a directory.  The
> > code would work later, but I'm guessing that was because I was ARGV
> > still works as expected/
>
> I took a quick look at the shoes/shoes.rb file where some of the option
> parsing occurs (like passing the args on -g|--gem). Adding --args and
> --script seems like a good idea.
>

If I remember correctly, try `shoes <file> <options> -- <args>` (make sure
to inspect ARGV though, with this, I'm not sure what it'll give you)


>
> >
> > 2) Is there a cross-platform way for a Shoes app to make itself the
> > focused app?  When I run a unit test using this (on OS X), it always
> > appears behind my terminal.  Something tells me that's handled by the
> > OS, but I'd love it if I were wrong.
>
> On my system (Ubuntu) when I run a shoes script from the command line
> the windows are on top and active. I vaguely remember that problem when
> I had OSX and I think there was Terminal preference or maybe a system
> preference to control it.
>

Well, if I spawn Shoes from my Visor, the Visor rolls up and focuses on the
Shoes app... but that might just be Visor (I'd recommend it, actually, it's
very useful)


> >
> > 3) Originally I was trying to base the acceptance or failure of the
> > assertion off of the process exit status.  However the Shoes
> > Kernel.exit seems to not take a status param.  Writing to STDOUT works
> > fine, but I'd be interested if it's possible (or advisable) to change
> > the exit status.
>
> Seems like oversight to me for Shoes.exit not to return a status code
> assuming it makes sense to the
>

I agree


> >
> > Finally, I realize that most Shoes apps are written as standalones.
> > Is this a sort of philosophical abuse of Shoes that would be better
> > done in another (even possibly non-Ruby) GUI?
>
> It's an interesting idea, putting a shoes app in a command line pipe or
> in one of those Apple workflow thingies. I'd want to verify that Shoes
> never redirects stdout or stderr. I think it does in some situations but
> I can't prove it so don't rely on my claim.
>

It doesn't redirect it from my experience. You can have issues though if you
don't set $stdout.sync = true


>
> If your process/workflow allows it, Make Shoes the controller of the
> process and design a wizard like GUI to move through the scripts and
> images within between Shoes pages/views program. I've always thought
> that was nice niche for Shoes.
>
> That said, it should behave as part of pipe.
>
> >
> > Thanks, and I appreciate the work you all have done to keep Shoes going.
> >
> > –Andrew
>
>
>


-- 
   ~devyn

> 
> If I remember correctly, try `shoes <file> <options> -- <args>` (make
> sure to inspect ARGV though, with this, I'm not sure what it'll give
> you)

I do believe that is the current way. If your shoes program requires
your own --/-switches (optparse) it won't work so you have to create and
parse your own command line syntax from the args you do get (like gem or
git does for example)
>  
>         
>         >
>         > 2) Is there a cross-platform way for a Shoes app to make
>         itself the
>         > focused app?  When I run a unit test using this (on OS X),
>         it always
>         > appears behind my terminal.  Something tells me that's
>         handled by the
>         > OS, but I'd love it if I were wrong.
>         
>         
>         On my system (Ubuntu) when I run a shoes script from the
>         command line
>         the windows are on top and active. I vaguely remember that
>         problem when
>         I had OSX and I think there was Terminal preference or maybe a
>         system
>         preference to control it.
> 
> 
> Well, if I spawn Shoes from my Visor, the Visor rolls up and focuses
> on the Shoes app... but that might just be Visor (I'd recommend it,
> actually, it's very useful)

  Nearly OT, my window not on top and in front memory with OSX was with
Java GUI apps run from the commandline and much older versions of OSX
and Java. Try running an OSX GUI app from the commandline (don't use the
open command). Or see what happens if you 'open xxxx/Shoes.app
yzzxx/my-script my-arg-1 and-2'

 or whatever seems right from 'man open'