Talk:FUEL/Ideas
MOZILLA may be a bit long, especially if it is used extensively in extensions. Why not an alias like MOZ or MZ.
Another useful feature for this library would be some helper for boilerplate code in components (and other places). Maybe something similar to the jssh ComponentUtils (generateNSGetModule / generateFactory): http://lxr.mozilla.org/mozilla/source/extensions/jssh/nsJSShStarter.js (I know there's a bug open about it)
--SylvainPasche 00:16, 8 January 2007 (PST)
I'd love to see some functions to help simplify interaction with nsISupportsArrays of nsISupportsPrimitives. Doing this by hand in JS is extremely annoying.
--Dmose
Preference
If you want, you can take a look at an object i did for preferences manipulation : http://bbcomposer.elitwork.com/source/bbcomposer/chrome/bbcomposer/content/option_service.js Nicolas FROIDURE - 2007/04/27
Thunderbird
It would be nice if the relevant parts of the API worked in Thunderbird 3.0 as well. This would facilitate extensions that can utilize both products for integration as well as foster Thunderbird extension development on it's own. Most of the API seems like it would work very well on both with little/no changes. --Raccettura 05:44, 18 May 2007 (PDT)
Animation
I dunno if this falls in the FUEL category or not, but it would be nice to have an animation library built into Firefox. There are parts of the UI that are already implementing their own animation effects (the Prefs window, tab strip, and browsers for now I think). Seems silly for each one of them to write their own complete implementation. Before they get to deep into writing special code for every widget in the toolkit, seems best to look at some abstraction.
The animation class doesn't necessarily have to be a part of FUEL, but it seems like a nice place to put it. Extension writers would then have at least some documented and stable code to turn to when they wanted to fade an overlay, or resize a box.
Plus, having a consolidated animation class makes it easier to debug and to pref things off for users who don't want them. There are already some animation class examples out there to build on (some of which you could probably talk the creators into letting you use):
Animator
moo.fx
script.aculo.us
File I/O
This might be obvious (unless there's something I'm missing), but if someone develops a File I/O (which would be absolutely awesome and important), please make it Unicode-friendly...
Brettz9 16:40, 24 May 2007 (PDT)
API Naming
Can I ask what practices are being used to determine the naming for the API?
While I have little knowledge in this area, I'd like to offer the following: 1) Try to follow standard JavaScript naming practices 2) Where #1 is not defined, might it be considered to model after PHP function names? The library is large enough, the functionality useful, the naming simple (if sometimes argument order is inconsistent--which I hope FUEL can learn from--e.g., always put the string to be operated on as the first argument, etc.), the user base large, and the audience base perhaps similar to the audience base which would like to take advantage of FUEL (and would thus be familiar with its conventions).
Another ignorant question: As far as File I/O, didn't Server-Side Javascript already have such functionality? Are you going to deliberately name similar to or different from SSJS? Why doesn't Firefox itself use the SSJS File I/O, etc.?
I wonder also about whether the POW extension could fit in with all of this somehow too.
Brettz9 16:51, 24 May 2007 (PDT)
