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.
A simple use case would be making a XUL Application made with python. What else would be really evolution would be making python a replacement for js so you can make a site with python code, but that I think, would be really hard.
I would also like another language for scripting, not especially python but maybe also ruby, because i dislike JS. As i found several different ways to create classes/objects in JS I'm confused and can't really handle JS. ( In my opinion JS is not a good language)
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.
(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.
User:Biesi - a way to redirect certain content types to other URLs. For example, redirect application/x-foo to chrome://fooviewer/content/fooviewer.xul. this'd allow adding new content viewers to mozilla, using XUL.
We need Gecko2:NewTextAPI.
Gecko_OpenDocument_support - this idea comes from the OOo camp and basically focus on adding the hability of gecko to render the opendocument XML schema and display it as a OpenDocument reader or XHTML page natively.
CSS3 hyperlink presentation module would be nice. w3c hyperlink specs This could provide a non-javascript method of replacing the depricated target="_blank" method of opening things in new windows/tabs.
I wish the Plugin API for Windows is changed so that any plugin can register its MIME types at run time as in the Unix API. The current API requires MIME type information stored in the plugin DLL's resource data, which is not good for runtime modification.
User:yathosho with many firefox users using other gecko-based products (thunderbird, songbird), i thought i makes not much sense to run the gecko engine in multiple instances. could gecko run from some kind of system level (i.e. windows service) and gecko-based applications access it from there? i'm not an experienced enough programmer, i thought this would certainly speed up the performance of each application. i have no idea if this could be done without risking vulnerability on the other hand
Before we target for new and exotic enhancements, shouldn't we ask for a complete implementation of the defined standards? One thing that is constantly ignored in every roadmap is "dynamic fonts". This is not some weird gimmick for a small group of freaks, this is already defined both in the CSS2 (1998) and SVG specifications. It makes no sense to claim to have the "most complete implementation of web standards", without the @font-face implementation.
Copyright issues are no excuse. This does work in all IE versions and it did work in the old Netscape 4.x. Nobody had copyright issues with them. "custom" file formats is no excuse either, as you can always use an "Open Type" font.
The Gecko Programmers do magic all day, I can't believe that it's beyond their capabilities.
Implement CSS3 Force Wrapping: the 'word-wrap' property... word-wrap in CSS3 https://bugzilla.mozilla.org/show_bug.cgi?id=99457 Waiting for 6 years, this property will add in CSS3...
