<< Break SeaMonkey at a pad near you! | The roads I take... | Integration eines Magento-2-Webshops mit FreeFinance und selbstgebautem Warenmanagement >>

My XULRunner Wishlist

As AllPeers, Mark Finkle and Songbird have all posted their wishlists for XULRunner's future, I think it's a good idea to throw mine in, in the light of possible Mozpad acitivities on such items.
Not that this is my personal view as a SeaMonkey and L10n contributor and no common view of the SeaMonkey project or the Mozilla L10n Project (MLP), though I'd guess that some of those items would be on the wishlists of multiple community members in those projects.

Killing app-specific differences in toolkit:
Toolkit and other core code still contains app-specific ifdefs in many cases, which block moving the applications to XULRunner. There should be no need for MOZ_PHOENIX, MOZ_THUNDERBIRD, MOZ_SUITE and friends in that code. We came across such problems in printUtils recently, and I'm sure there are still enough others. Efforts like generalizing openURL() are good steps, but actually long overdue.
More robustness in mozStorage:
When the topic of moving any code to mozStorage from RDF or Mork backends in SeaMonkey or MailNews comes up, people keep telling me there are so many warnings around how easily things can go wrong with mozStorage/SQLite when it comes to other apps wanting to access our data or even multiple threads accessing the database (see How to corrupt your database). If we want to make mozStorage the general backend for databases in XULRunner, we need to find way so that that developers don't back out because of such fears before even trying to use it.
Template Query Processor for mozStorage (bug 321172):
SeaMonkey has a lot of UI that is based on RDF templates. If we should be moving to mozStorage as a backend for much of our data, it would be very helpful to be able to be able to build UI as easily as for RDF, which needs templates to work with mozStorage.
Pipe-based IPC (bug 68702):
Invoking external processes and controlling them via stdin/stdout or even named pipes is something that many more XULRunner apps will want in the future. I mostly care for having a good way to integrate EnigMail/OpenPGP into SeaMonkey by default, which needs to call gpg through such a mechanism, but I'm sure there are many other needs for this.
OpenSync support (bug 303963):
While the linked bug report is about MailNews and most of the work for this is probably app-specific, it might be a good idea to provide hooks on the platform side to hook into this open, cross-platform data synchronization framework, so it's easy for Mozilla/XULRunner-based apps to use it and provide synchronization with a wide variety of devices and applications.
Profile management improvements:
Profile roaming seems to be something that gets requested again and again, but does not work well. The mostly working framework we have for that in SeaMonkey 1.x is broken with toolkit profiles on trunk (bug 378647) and there's no code for doing this with toolkit profiles. I also would love to have profile language selection back if multiple languages are installed for the application (also an xpfe feature not supported by toolkit). Accessing one profile from multiple instances/processes (bug 135137) would probably be nice but is hard to get right.
L20n (wiki page):
The localization framework used for Mozilla applications up till now has its merits but also its share of problems. Based on what we know about current localization frameworks, which all have their own big problems, Axel Hecht, the L10n lead of MoCo, has figured out a next-generation L10n framework which he calls "L20n". We really need such an improved framework with one single file format for everything and enough flexibility for complicated languages (those are out there and currently not supported well in any software).
Language switching in EM (bug 377881):
Being able to easily install a language pack and switch to using it is good for L10n testers but sometimes also for normal users, esp. in multi-language families and countries. We should not clutter the interface for those users who don't need this, though. To achieve that, we can leave the current way of language handling in Extension Manager, just with small tweaks so that language switching is handled the same way as theme switching.
Tray icon support (bug 325353):
The main reason why the so-called "Quicklaunch" feature on Windows has remained popular with our users in the SeaMonkey 1.x product line is that they have a tray icon with a context menu that provides fast access to open browser and mail windows. Additionally, it kept mail libraries loaded and provided information about new mail arriving - and it allowed to close all SeaMonkey windows and still have fast access to the browser, mail and get this mail notification. It would really be nice if we could still provide that functionality with toolkit-based versions of SeaMonkey, but we'd need tray icon support in toolkit for that.
Splash screen support (bug 329742):
This might sound like a small thing, but having a splash screen gets branding across, which is why I believe many corporate users of XULRunner will want this, and on laptop machines with slow harddisks, even Firefox takes long to launch, with currently no visual feedback at all to the user that anything is happening.
KDE integration (bug 140751):
As a KDE user, like probably half or more of the Linux population, I'd really wish we could integrate more with KDE. We currently are able to fetch file type icons (moz-icon) from GNOME, and system settings also from there, but it doesn't help much when GNOME isn't configured much because I never use it. We've grown to use themes from KDE quite well in default themes, as KDE makes GTK inherit its settings and we inherit them from there, which works interestingly well. It might be worth to investigate how we can pick up other things through such channels, like e.g. default apps for certain MIME types.

I think I have touched my main wishes here, others might still come up to my mind later, but I hope they're only smaller wishes

Beitrag geschrieben von KaiRo und gepostet am 14. Juli 2007 16:16 | Tags: L10n, Mozilla, Mozpad, platform, SeaMonkey, XULRunner | 1 Kommentar | TrackBack

Kommentare

Autor	Beitrag
kde.user@from.brasil	I'm glad that at least you want a better KDE integration. As a user I simply don't understand why the most used WM in Linux (every poll I read says it have between 55 to 75% of the users) appears to be ignored by most of the Mozilla developers. For me a QT version or native widgets are not even necessary, all I want is this: - A installer (even a GTK one) that ask user to install in it's home folder or as root to all users; a installer that creates icons in desktop and in K-Menu. Some one man made linux applications have this, why Mozilla ones can't? - The applications need to be aware of KDE, they need to register themselves as the defaults (if the user wants), detect and use the other related softwares (like Kmail or Akregator) automatically. - The KDE filepicker should be used when running KDE. - Tray icon support, at least for mail applications. Thank you very much and sorry for my bad english. 14.07.2007 18:35

Autor

Beitrag

kde.user@from.brasil

I'm glad that at least you want a better KDE integration.

As a user I simply don't understand why the most used WM in Linux (every poll I read says it have between 55 to 75% of the users) appears to be ignored by most of the Mozilla developers.

For me a QT version or native widgets are not even necessary, all I want is this:

- A installer (even a GTK one) that ask user to install in it's home folder or as root to all users; a installer that creates icons in desktop and in K-Menu. Some one man made linux applications have this, why Mozilla ones can't?

- The applications need to be aware of KDE, they need to register themselves as the defaults (if the user wants), detect and use the other related softwares (like Kmail or Akregator) automatically.

- The KDE filepicker should be used when running KDE.

- Tray icon support, at least for mail applications.

Thank you very much and sorry for my bad english.

14.07.2007 18:35

Kommentar hinzufügen