How do I: create a folder picker element for users to set folder preference with?

[pd]

Hi

I've tried using a panel and thought I'd write a standard HTML file
input tag. However this will display a file picker rather than a
folder picker. AFAIK there is no input type in HTML that will invoke a
folder-picker; only a file picker.

If Jetpack panels and widgets are mainly UI designed to load HTML
content, how can I implement something like a folder picker if HTML
doesn't support it?

I guess this points to a bigger topic. Whilst Jetpack supports UI
through panels and widgets but panels and widgets only load standard
HTML, how can Jetpack developers code features that are not supported
by HTML?

[KWierso]

If you include 'require("chrome")', you can probably use
https://developer.mozilla.org/en/nsIFilePicker

You'd have to do some message passing to get it to work. (User clicks
a box in a panel, panel sends a message back to the addon, addon shows
the folder picker, user chooses a folder, addon sends path back to
panel as a message, panel adds the path to the box)

[pd]

Thanks KWierso. require("chrome") seems to be undocumented (surprise,
surprise) except maybe this pos:

http://groups.google.com/group/mozilla-labs-jetpack/browse_thread/thread/d288b79903b5b434

Unfortunately that post does not give a syntax example for using any
component classes or component interfaces from Jetpack. It refers to a
lot of aliases and so forth but does not include ven one example of
how to call a chrome-level interface such as nsIFilePicker. The
standed pre-Jetpack method was something like this:


var filePicker = Components.classes["@mozilla.org/filepicker;1"]
.createInstance(Components.interfaces.nsIFilePicker);

The above post suggests Jetpack users start with this:

var {Cc, Ci} = require("chrome");

My best guess for how to instantiate a folder picker would then be:

var folderPicker = Cc["@mozilla.org/filepicker;
1"].createInstance(Ci.nsIFilePicker);

Am I on the right track?

I wonder where

On Feb 18, 4:42 am, KWierso <kwie...@gmail.com> wrote:
> If you include 'require("chrome")', you can probably usehttps://developer.mozilla.org/en/nsIFilePicker

[pd]

I don't believe it, this worked:

[Atul Varma]

On 2/18/11 8:41 AM, pd wrote:
> Thanks KWierso. require("chrome") seems to be undocumented (surprise,
> surprise) except maybe this pos:
>
> http://groups.google.com/group/mozilla-labs-jetpack/browse_thread/thread/d288b79903b5b434

Actually, it is documented here:

https://jetpack.mozillalabs.com/sdk/1.0b2/docs/#guide/chrome

By the way, I'd appreciate it if you could curb your sarcasm a bit; a
big part of any Mozilla project is its community, and lots of folks on
this list are working hard to make this product the best it can be--some
of them are volunteering their free time to do so. Constructive
criticism is always appreciated, but please don't denigrate the efforts
of everyone on the project.

Thanks!

- Atul

[pd]

Geez people are sensitive! :) Thanks for the doco link. I was looking
through the 1.03rc1 doco but came across the js/style path bug.

Unfortunately it looks like whilst require("chrome") has helped me
access a file picker through nsIFilePicker, I cannot configure
nsIFilePicker to pick just folders due to the init method wanting a
window reference. Seems like tricky stuff.

I'm trying to look up what magic I need to conjure to get the
nsIFilePicker to remember what window it is attached to in order to
initialize it to look for folders only (modeFolder). The recommended
code is:

.init(window, "Dialog title", nsIFilePicker.modeFolder);

however I get the following error:

ReferenceError: window is not defined

I'm trying to determine how to get a window reference through the
recommeded nsIWindowMediator using the getMostRecentWindow() method
however it is not clear what this is a method of. The only example is
this:

nsIDOMWindowInternal getMostRecentWindow(
in wstring aWindowType
);

but that syntax (note the space b/w nsIDOMWindowInternal and
getMostRecentWindow) is foreign to me.

Anybody have some suggestions? I'll promise to keep my sarcasm to
myself!

pd

On Feb 19, 2:12 am, Atul Varma <ava...@mozilla.com> wrote:
> On 2/18/11 8:41 AM, pd wrote:> Thanks KWierso. require("chrome") seems to be undocumented (surprise,
> > surprise) except maybe this pos:
>

> >http://groups.google.com/group/mozilla-labs-jetpack/browse_thread/thr...

[pd]

SOLUTION!

var window = require("window-utils").activeWindow;

const {Cc, Ci} = require("chrome");

const nsIFP = Ci.nsIFilePicker;

var dirPicker = Cc["@mozilla.org/filepicker;1"]
.createInstance(nsIFP);

dirPicker.init(

window,
"Pick a folder",
nsIFP.modeGetFolder

);

var dir = dirPicker.show();

if (dir == nsIFP.returnOK) {

console.log('dir is ' + dirPicker.file.path);

}



Thanks to those who helped: Atul, alexp_, Kwierso.

It felt very good to get over this problem!

[Atul Varma]

Awesome, nice work!

It'd be great to have that made into a handy little module so others can
use it without having to know what 'chrome' and all that XPCOM gloop
is... Would you be interested in turning it into a redistributable
package? No worries if not. :)

- Atul

[pd]

I think you might over-rate my coding abilities Atul. I'd like to yeah
for sure. I did think about it. However I wouldn't know the first
place to start and wouldn't want to write something crap then suggest
others depend on it.

[Matej Cepl]

Dne 19.2.2011 17:58, pd napsal(a):

> I think you might over-rate my coding abilities Atul. I'd like to yeah
> for sure. I did think about it. However I wouldn't know the first
> place to start and wouldn't want to write something crap then suggest
> others depend on it.

Just write a regular Jetpack library, post it somewhere and file a bug
to bugzilla for its inclusion. By that you can get code review for free.

Also, you can ask for the inclusion into
https://wiki.mozilla.org/Labs/Jetpack/Modules

Matěj

[Atul Varma]

On 2/20/11 5:14 AM, Matej Cepl wrote:
> Dne 19.2.2011 17:58, pd napsal(a):
>> I think you might over-rate my coding abilities Atul. I'd like to yeah
>> for sure. I did think about it. However I wouldn't know the first
>> place to start and wouldn't want to write something crap then suggest
>> others depend on it.
> Just write a regular Jetpack library, post it somewhere and file a bug
> to bugzilla for its inclusion. By that you can get code review for free.

Actually, I would recommend just making a Github repository for the
package/module and posting a link to it here. Then folks who are
interested in helping out can just post comments directly to the code in
Github, and if they have bugfixes, they can easily fork your repository
and issue pull requests. As an added benefit, in the future, anyone who
wanted to see a Jetpack package go from clever hack to stable library
could browse through the evolution of your repo on Github's website.

One of the really nice things about the CommonJS module/packaging system
is that it allows developers to share functionality without the need for
a "gatekeeper" like the core Jetpack team to include it in the official
distribution. The third-party package ecosystem can then serve as a
proving ground for packages that would eventually like to make their way
into the official distribution--at least, that's the way that
programming communities like Python work, and it was my original intent
in implementing Jetpack's packaging system.

- Atul

[pd]

I could do all that Atul and maybe I yet will but I'm wondering if
adding any hidden properties and methods to the Jetpack documentation
might not be a higher priority. To get my folder picker code working I
had to hang out in the Jetpack IRC channel when (seemingly) people
living in east-coast US were likely to be around. That means the crack
of dawn here in Australia and I just cannot get up that early or stay
up all night to be told there is a property available to me that is
undocumented. I am referring to:

var window = require("window-utils").activeWindow;

I had no idea that properties (and maybe methods?) like that were
available and / or could be called so easily.

How many other such properties and/or methods are undocumented?

[Christian Sonne]

It's true I don't see activeWindow documented there (feel free to file a bug for that), but window-utils does have documentation: https://jetpack.mozillalabs.com/sdk/1.0b2/docs/#module/api-utils/window-utils

-- cers / Christian Sonne

--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.
To post to this group, send email to mozilla-la...@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs-jet...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

[pd]

On Feb 21, 10:47 am, Christian Sonne <freakc...@gmail.com> wrote:
> It's true I don't see activeWindow documented there (feel free to file a bug
> for that)

I can't, they banned me.

> , but window-utils does have documentation:https://jetpack.mozillalabs.com/sdk/1.0b2/docs/#module/api-utils/wind...

I'm aware of that and did not mean to imply otherwise. Rather I think
I'm getting the hang of the way Jetpack modules are mostly calls to
old ns Interfaces with a nicer, shorter syntax. Is this correct? For
example, is windows-utils just a shortcut reference to:

https://developer.mozilla.org/en/nsIWindowWatcher

and therefore can all those methods be used even though they are not
documented in the SDK docs?

I might be confused but it appears that *perhaps* the Jetpack
documentation deliberately hides some of this information in perhaps
an attempt to make Jetpack seem less overwhelming to web-oriented
developers? I'm just guessing, please don't bite my head off.

Regardless, if someone is needed to add undocumented methods and
properties from the full ns Interfaces documentation into the Jetpack
SDK documentation, I'd be happy to try and help. This might help me
get a better perspective on the codebase as a whole.

> -- cers / Christian Sonne
>

[Drew Willcoxon]

> I'm aware of that and did not mean to imply otherwise. Rather I think
> I'm getting the hang of the way Jetpack modules are mostly calls to
> old ns Interfaces with a nicer, shorter syntax. Is this correct? For
> example, is windows-utils just a shortcut reference to:
>
> https://developer.mozilla.org/en/nsIWindowWatcher
>
> and therefore can all those methods be used even though they are not
> documented in the SDK docs?

It's true that Jetpack APIs are often implemented using Gecko's nsIFoo
components, but they are not simple wrappers, so you can't assume that
jetpack-foo will have the same methods as nsIFoo just because they seem
like they might be related. Jetpack APIs are something entirely new, so
it's best to approach them without any assumptions you might have from
working with other Mozilla code.

Also, window-utils and all other APIs in the api-utils package are
"low-level" APIs. You're free to use them, but unlike the "high-level"
APIs in addon-kit we don't make a special effort to keep them stable,
and they may have more inconsistencies and rough edges. Documenting
them is also not as high a priority as documenting addon-kit APIs. We
haven't done a good job of explaining the distinction between api-utils
and addon-kit until recently: the welcome page at
https://jetpack.mozillalabs.com/sdk/1.0b2/docs/ talks about it, among
other pages.

> I can't, they banned me.

You can make a pull request on GitHub: http://github.com/mozilla/addon-sdk

Or if you'd like to submit a patch via this group, that would be fine too!

Drew

[pd]

So the 'low-level' (should that just be "low-priority"?) APIs are not
guaranteed to remain supported? My little extension relies on the file
low-level module. Should I stop now before I begin and waste my time?

There are a lot more "low-level" modules/APIs than there are the
opposite. I think it is reasonable to see modules/APIs in the
documentation and expect them to be supported. Maybe I'm alone here
though. You do hide them underneath a "more" link by default.

I really think that those behind Jetpack should make it much clearer
what the scope of the project is.

1) Is it intended to fully duplicate XUL extension abilities?
2) How many "high levels" modules/APIs will Jetpack most likely end up
with?
3) Can using the api-utils be relied upon at all if they are
considered lessor or 'low-level' modules/APIs?

You know I feel like I'm shadow boxing trying to write extensions/add-
on code for Firefox. What all this discussion boils down to is simple:
core Mozillians have your hands on the reigns and everybody else is
trying to get a perspective however which way they can however the
horse has bolted and non-Mozillians are falling on and off, barely
holding on to the reigns, climbing back up in the saddle and then
being kicked off again.

Whilst I appreciate you guys may well be hammering away at code to get
Jetpack 1.0 done ASAP, it is, at least I think, fairly difficult to
get a full picture of what is happening.

Are you guys coding in a manner supported by automated documentation-
generation tools? Maybe this would help narrow the gap between the
code you are creating and the need to have it documented ASAP whilst
Jetpack is in a rapid development phase yet developers want to adopt
it immediately.

On Feb 21, 2:02 pm, Drew Willcoxon <a...@mozilla.com> wrote:
>  > I'm aware of that and did not mean to imply otherwise. Rather I think
>  > I'm getting the hang of the way Jetpack modules are mostly calls to
>  > old ns Interfaces with a nicer, shorter syntax. Is this correct? For
>  > example, is windows-utils just a shortcut reference to:
>  >
>  >https://developer.mozilla.org/en/nsIWindowWatcher
>  >
>  > and therefore can all those methods be used even though they are not
>  > documented in the SDK docs?
>
> It's true that Jetpack APIs are often implemented using Gecko's nsIFoo
> components, but they are not simple wrappers, so you can't assume that
> jetpack-foo will have the same methods as nsIFoo just because they seem
> like they might be related.  Jetpack APIs are something entirely new, so
> it's best to approach them without any assumptions you might have from
> working with other Mozilla code.
>
> Also, window-utils and all other APIs in the api-utils package are
> "low-level" APIs.  You're free to use them, but unlike the "high-level"
> APIs in addon-kit we don't make a special effort to keep them stable,
> and they may have more inconsistencies and rough edges.  Documenting
> them is also not as high a priority as documenting addon-kit APIs.  We
> haven't done a good job of explaining the distinction between api-utils

> and addon-kit until recently: the welcome page athttps://jetpack.mozillalabs.com/sdk/1.0b2/docs/talks about it, among