screengrab triggered by command line args

[miles zarathustra]

Hi all,

I want to give the browser a URL and a file name, and have it save the image
of the rendered web page (named in the URL) into the named file (png, .gif,
whatever. I'll use ImageMagick on it next, so I'm flexible.)

The best idea I've come up with so far is to trying to trigger the "screen
grab" extension from command line arguments.

On the mozilla developer site, I have found a "hello world," weighing in at
173 lines, that accomplishes the amazing task of discerning the command-
line arguments! (Woohoo! Thank God for these advanced developer tools
that make life so much easier! I'll never go back to perl's @ARGV again!)

http://developer.mozilla.org/en/docs/Chrome:_Command_Line

Anyhoo, I am wondering if this gem, miraculously written in XPCOM /
Javascript will even run? But I don't find any coherent instructions on
how to connect it to the browser, and have no idea if, when I do, I will be
able to call the necessary javascript to do the screen grab.

Does anyone have any clues that might help? Should I abandon all hope here
and now? I am just wondering.

It seems like it ought to be so simple....

Thanks,

-= miles =-

[Nickolay Ponomarev]

On 10/24/06, miles zarathustra <use...@ignorearanyaka.orgignore> wrote:
> On the mozilla developer site, I have found a "hello world," weighing in at
> 173 lines, that accomplishes the amazing task of discerning the command-
> line arguments! (Woohoo! Thank God for these advanced developer tools
> that make life so much easier! I'll never go back to perl's @ARGV again!)
>

There are about 30 lines of non-boilerplate code. Verbosity of XPCOM
code is a known problem, no need to be sarcastic when asking for help.

> http://developer.mozilla.org/en/docs/Chrome:_Command_Line
>
> Anyhoo, I am wondering if this gem, miraculously written in XPCOM /
> Javascript will even run? But I don't find any coherent instructions on
> how to connect it to the browser, and have no idea if, when I do, I will be
> able to call the necessary javascript to do the screen grab.
>

This is a standard XPCOM component. You install/use it by putting in
your extension's/application's 'components' folder:
http://developer.mozilla.org/en/docs/Bundles

Whether you'll be able to "call the necessary javascript" depends on
what exactly you're going to call. Do you have the actual screen
grabbing code? I'd start with that rather than the cmd line handler.

Nickolay

[Nickolay Ponomarev]

On 10/24/06, Nickolay Ponomarev <asqu...@gmail.com> wrote:
> This is a standard XPCOM component. You install/use it by putting in
> your extension's/application's 'components' folder:
> http://developer.mozilla.org/en/docs/Bundles
>

BTW, it would be appreciated by your followers if you edited the page
(http://developer.mozilla.org/en/docs/Chrome:_Command_Line) to mention
that.

Nickolay

[miles zarathustra]

Nickolay Ponomarev wrote:

>
>> http://developer.mozilla.org/en/docs/Chrome:_Command_Line
>>
....

>>
> This is a standard XPCOM component. You install/use it by putting in
> your extension's/application's 'components' folder:
> http://developer.mozilla.org/en/docs/Bundles

This looks useful. I notice that it doesn't seem to mention either of the
two configuration files that I saw described on another XPCom howto page
which I currently can't find (I think compreg.dat was one ... it's all on
another machine in another city)

I'm finding more helpful pages on XPCom as I get to know it better, but
still no really comprehensive "how to."

I just found:
http://basic.mozillanews.org/mozilla_book/ch08.html#77065

Which may give me what I need, once I spend the hours studying it.

>
> Whether you'll be able to "call the necessary javascript" depends on
> what exactly you're going to call. Do you have the actual screen
> grabbing code? I'd start with that rather than the cmd line handler.

I'm starting with the screen grab code (an existing extension)

https://addons.mozilla.org/firefox/1146/
also: http://andy.5263.org/

So the function I'm trying to call is in the extension javascript. I'm
planning to hack screen grab to use the filename specified on the cmd line
rather than popping a file picker.

So my question would be whether the extension shares a namespace with an
XPCom add-on (or whatever it's called) or how to bridge the two.

> ... Verbosity of XPCOM

> code is a known problem, no need to be sarcastic when asking for help.
>

now you're taking all my fun away!

You know, I used to be an APL programmer, and we were doing with a few
characters what would take 57 lines of Basic or C. Now I do a lot of Java,
and have learned to work with the modern bloat ... and acknowledge that
there is a purpose to it sometimes. I actually really enjoy programming in
Java.

But still... I see stuff like this and marvel at what we call "progress!"

-= miles =-

[miles zarathustra]

Nickolay Ponomarev wrote:

OK, I'll look into it. (they let ME edit the page? it hadn't occurred to
me.)

-= miles =-

[Nickolay Ponomarev]

On 10/25/06, miles zarathustra <use...@ignorearanyaka.orgignore> wrote:
> > This is a standard XPCOM component. You install/use it by putting in
> > your extension's/application's 'components' folder:
> > http://developer.mozilla.org/en/docs/Bundles
>
> This looks useful. I notice that it doesn't seem to mention either of the
> two configuration files that I saw described on another XPCom howto page
> which I currently can't find (I think compreg.dat was one ... it's all on
> another machine in another city)
>
> I'm finding more helpful pages on XPCom as I get to know it better, but
> still no really comprehensive "how to."
>

Yeah, the documentation has room for improvement. You're welcome to
help with it as you learn XPCOM yourself :)

compreg.dat / xpti.dat contain information about registered components
and interfaces. These files are written out by Firefox after the XPCOM
registration process.

During the registration process, Firefox looks in a few predefined
places (like app's and each extension's components folder) for files
that may contain components or interfaces.

For each file that might provide components (e.g. js or binary so or
dll), it tries to run its registration function, which calls back into
component manager to register the components it provides (and adds
them to XPCOM "categories" if needed). Each typelib (xpt) file is
scanned for interfaces.

So all you need to do is to put a specially-crafted component file in
one of folders Firefox searches for components and trigger the
registration process (a common way to do it when developing is to
delete compreg.dat). Or just create an XPI with your component in its
components/ folder and install it; autoregistration happens after
installing XPIs too.

> > Whether you'll be able to "call the necessary javascript" depends on
> > what exactly you're going to call. Do you have the actual screen
> > grabbing code? I'd start with that rather than the cmd line handler.
>
> I'm starting with the screen grab code (an existing extension)
>
> https://addons.mozilla.org/firefox/1146/
> also: http://andy.5263.org/
>

ok. There's also canvas, which has the drawWindow method. Not sure how
well it works yet (I heard there are problems with large pages and
plugins).

> So the function I'm trying to call is in the extension javascript. I'm
> planning to hack screen grab to use the filename specified on the cmd line
> rather than popping a file picker.
>
> So my question would be whether the extension shares a namespace with an
> XPCom add-on (or whatever it's called) or how to bridge the two.
>

There's a separate "scope" (different global object) for each "window"
(which is not just windows in the window manager sense - see
http://developer.mozilla.org/en/docs/Working_with_windows_in_chrome_code#Content_windows
) and for each XPCOM component.

That extension's code most likely lives in a browser.xul overlay,
meaning it's is in a different scope than your cmd line handler's
code. On the other hand, the handler's code is invoked early when you
can't make screen shots of the page yet. So you'll probably have to
find a way to defer the handling until the browser window opens.

>
> > ... Verbosity of XPCOM
> > code is a known problem, no need to be sarcastic when asking for help.
> >
>
> now you're taking all my fun away!
>
>
> You know, I used to be an APL programmer, and we were doing with a few
> characters what would take 57 lines of Basic or C. Now I do a lot of Java,
> and have learned to work with the modern bloat ... and acknowledge that
> there is a purpose to it sometimes. I actually really enjoy programming in
> Java.
>
> But still... I see stuff like this and marvel at what we call "progress!"
>

I don't like verbose programming languages/frameworks myself (and I
don't enjoy programming in Java ;p ), but ranting about this while at
the same asking a question doesn't help neither answer your question,
nor fix the verbosity.

Nickolay

[miles zarathustra]

Wow, this is quite informative. Thank you.

Yes, I thought of the timing/construction-order issue. It sounds tricky.
What I need is some sort of trigger when the page is done loading, to begin
the screen grab.

I've been studying the documentation and am still working on absorbing the
information. What you have added looks really helpful. I think I'm ready
to try to get the example working, from which I will hopefully be able to
tell a lot by how well it works and how flexible it can be.

I suppose sarcasm can often be difficult to appreciate, but it's right
around the corner from irony, which, in my observation, is the ruling
principle of the universe.

Thanks again,

-= miles =-