Gecko:Wish List
Miscanellous wishes go here.
- Whaooo.... 1st post ????
Any chances of having a Moz-Platform Gecko:SDK targeted at XUL or XUL+XPCOM+JScript application only?
Mozilla is a great platform for portable cross Unix-Windows development... The only Pb is it seems to need the full of Mozilla. Actually, looking more carefully, a Moz application only needs some standard global and classic chrome resources and maybe some XPCOM componenent for any custom stuff not available as yet. Pb is that maybe the final customer doesn't to have mozilla, or firefox, or maybe he want to be sure the XUL application will not corrupt any existing mozilla installation....
Basically, we need a simple way of starting a mozilla XUL application, without having the whole of mozilla installed:
- A simple and small bootstrap
- A small chrome (just what is needed to have all the XUL widget in classic look'n feel
- A way to configure the bootstart to take a chrome url as the starting poing, and maybe a folder identifier for profile and prefs.
- A mean to start a new instance of the XUL MozApp even if the application is already running (and feel sorry for the profiles, but who cares)....
We need all that, plus on Windows (and other platforms?) it should register itself as an ActiveX plugin for application/xml+xul (and possibly xml+xhtml) so IE users can run XUL too! See http://www.saintpatrickdc.org/bsmedberg/index.php?p=15
This stuff is being discussed on Mozilla2.0 mailing lists under the name 'libxul'. I think darin is driving this one.
Is this the place to ask for Python scripting support in addition to javascript? Not easy I know, can of worms, yes. Greatly desired though. (yes I know about Gecko:Py XPCOM) that's not really what I want.
(Gecko:Axel Hecht) yes, this would be the place to ask. But if Gecko:Py XPCOM is not the thing you want, what do you really want? Keep in mind that enabling python scripting without extensions would require shipping python in some way. That is rather unlikely, IMHO. So a use case would probably help in evaluating if it's feasable or not.
What I (at least) would like is the ability to use python in all the places that js is currently used, in particular, for interacting with the loaded XUL and HTML documents. As far as I know, Gecko:Py XPCOM only allows the implementation of XPCOM components in python and doesn't allow python-in-XUL or python-in-XBL. Some people really like python :)
(amix) I see no need to distribute Python with Mozilla. The whish here is addressing the fact to be able to use Python instead of Javascript in XUL. So, only if the user installs an XUL Application, that uses Python as in-document-scripting language, this user would have to install Python. This would be a dependancy to run certain such applications. Filling this dependancy would be the apps developers or the apps users task. The current Python implementation works on a lower level and allows working with XPCOM itself from Python.
Copied over from xuldev, Load external DTD. This is really important for XUL remote application. For the time being the only way to load a DTD is using chrome. We need the ability to load DTD with a relative path. Otherwise remote xul developer can't localize their remote applications. Localizing remote XUL applications is a real improvement comparing to traditional web application. Actually, I don't know if this is a bug or a security restriction: http://bugzilla.mozilla.org/show_bug.cgi?id=22942
This is really a twofold issue. One is loading DTDs in general, which we should do, based on xml catalogs for the most part. But then, having localisation for remote xul applications would be nice, though I have no idea how relative links are supposed to resolve the issue. And I'm not sure how we should handle this part of the chrome protocol handler for remote content. One thing I came up with would be a PI like
<?moz-localize base="some-base-url" leaf="some-relative.url"?>
which would insert navigator.language between some-base-url/lo-CA/some-relative.url
(guest) Sorry if I'm missing the point. Currently in remote XUL we can load stylesheet <?xml-stylesheet href="../path/my.css" type="text/css"?> we can load overlay <?xul-overlay href="../path/overlay.xul"?> we can load javascript <script src="../path/my.js" type="application/x-javascript"/> Why we can't load our DTD with the entities in the same way? Eg: <!DOCTYPE window [
<!ENTITY % localeDTD SYSTEM "href:../path/myent.dtd" > >
Now, we are forced to embedding ENTITY elements into an inline DOCTYPE declaration in the same file and this prevent any serious localization. It's a pitty. http://www.ypoker.com/
(Gecko:Axel Hecht) Yes, it is a pity. From a technical point of view, at least the CSS part should not be blocking the parser, I wonder what the script is doing. I somewhere heard that overlays would be loaded synchronous, too. So yes, webapps already take a hit. But that wouldn't get any better by adding yet another blocking load.
But the real reason is, one is handled in the xul content sink, the other is handled in our xml parser. We will look into what it takes to support this, AFAICT.
Gecko:Web DAV support
"Compile" xul+javascript aplication , as java, as python + pyrex does, like a virtual machine.
---
We really need a way, via scriptable XPCOM to allow a XUL window to minimise to the system tray (not sure what it's called under other OSs [actually, it's not called that on Windows either, it's the "Taskbar Notification Area" -- JGR/Silver]). That way we could tiny little (konfabulator style) apps, in xul and javascript that stay resident.
Also, a scriptable way to easily make popups for notifications - much like the new mail notification from thunderbird! Just give us access to that function from all apps.
It would be great if we could also edit the context menu when we click on a icon in the system tray/taskbar.
i heard there were a project about it.. isn't it the right time to spice up the web with python applets? java is being used for many puposes (server-side, mobile phones), but java applets are definitely dead, and flash / shockwave is a very different approach.
(amix) I'd love to have the full XUL DTD available so I could load it into an XML editor or emacs-XUL mode. Right now the DTD is internal to Mozilla. There have been tries by the one or other company, but they limited this DTD onto their own needs and none is being updated anymore.