meta bug to track prism changes for maemo.
Created attachment 333678 [details] [diff] [review]
maemo changes (diff as is)
these are the main changes inside /prism dir for prism-maemo. thoughts , mfinkle ?
some points to be improved:
* it is not yet integrated to fennec's xulrunner neither to fennec itself as we want for the future.
* instead, it integrates w/ microb as following: there is a external .py file to handle open_mime for prism, and there is another external .sh script to call microb whenever an external link is opening. See:
* I have done my own /debian directory.
* it includes my softkb patch in bug 406837, so works fine in n800.
after installing prism-maemo (I know, this is extremely ugly, but at port inital stage I had to show it in a international conference).
I'm not sure I'm superthrilled about having a bunch of Maemo-specific #ifdefs spread through the code. If we end up supporting a few different platforms like this the code is going to get very messy. Can't we define some abstract interfaces or configuration files in the appropriate areas instead?
For example, there should be a separate file to define which shortcut destinations are available on each platform. I'm not sure I understand Maemo behavior if there is no shortcut destination (you have an #ifdef around the check).
What are the XUL changes in install-shortcut.xul needed for?
Maybe an optional .css file available for each platform?
The createShortcut code is a mess anyway. We should clean this up and move each platform into its own file (or even directory).
How come the external protocol service is not used on Maemo?
Couldn't the fullscreen/zoom stuff be generalized to work on all platforms?
* Fullscreen should be added for all platforms, not just Maemo
* Let's try to make platform changes (even #ifdefs) in CSS to hide XUL or change widths, instead of using conditionals in the XUL
* Let's try to use less conditionals in the createShortcut stuff. For example, we could add a Directory Provider for Maemo to use (instead of "Desk")
* Overall, I am not against using NS_OSSO conditionals, but we could try to be smarter about how we use them and try to minimize them.
Great work, Antonio