22
edits
Talk:FUEL/Ideas: Difference between revisions
m
→API Naming: forgot sig again
Raccettura (talk | contribs) No edit summary |
m (→API Naming: forgot sig again) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 18: | Line 18: | ||
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. | 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. | ||
--[[User:Raccettura|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, [https://bugzilla.mozilla.org/show_bug.cgi?id=347363 tab strip], and [https://bugzilla.mozilla.org/show_bug.cgi?id=380960 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): | |||
[http://berniecode.com/writing/animator.html Animator]<br> | |||
[http://moofx.mad4milk.net/#introduction moo.fx]<br> | |||
[http://script.aculo.us/ script.aculo.us]<br> | |||
== 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... | |||
[[User:Brettz9|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 [http://davidkellogg.com/wiki/Main_Page?origin=moz_pow POW extension] could fit in with all of this somehow too. | |||
[[User:Brettz9|Brettz9]] 16:51, 24 May 2007 (PDT) | |||