Mozilla2:Improving Development Environment: Difference between revisions

→‎Overview: and sometimes you cannot spell "forest" b/c of the trees...
(→‎Overview: and sometimes you cannot spell "forest" b/c of the trees...)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Overview ==
== Overview ==
Sometimes when you work on a project for too long, you cannot see the forest for the trees. It seems like the good people, who have been working on Mozilla for so long, cannot see how esoteric the requirements for building anything are. This could lead to a situation where Mozilla is losing potential developers based on bad first impressions. Because when you first experience XUL development, you must first experience the requirements to set up an app before you can even do "Hello World".


The purpose of this page is to bring together the claims from developpers.
The purpose of this page is to bring together related claims from new XUL developers who have a fresh perspective. The final aim is to ease the work complexity of new XUL developers, and to make mozilla/firefox a great development environment, '''out of the box'''.
The final aim is to ease the work of developpers, and to make mozilla/firefox a great development environment, out of the box.


In this area, you may either point other developpers to a solution  
In this area, you may either point other developers to a solution  
you found, or ask for an improvement. You can link to a specific page /  
you found, or ask for an improvement. You can link to a specific page /  
newgroup thread to start a constructive discussion.
newgroup thread to start a constructive discussion.


== Matrix of claims ==
== List of claims ==


Feel free to add items to the table below :
Feel free to add items to the list below :


<table border="1" cellspacing="0" cellpadding="4" >
=== Few error messages ===  
<tr style="background-color : gray">
 
    <th>Problem</th>
====Description====
      <th>Description</th>
When creating a package, firefox will fail silently if their's a<br>
      <th>Impacts (firefox, XulRunner, Packaging)</th>
syntax error in one of the package description files.
      <th>Current solutions</th>
 
      <th>Proposal</th>
====Impact====
      <th>Ressources (Bug ID, Link)</th>
Firefox, Packaging
</tr>
 
<tr>
====Solutions, workarounds====
    <td>Few error messages</td>
Is there an option to make firefox more verbose ?
    <td>When creating a package, firefox will fail silently if their's a syntax error in one of the package description files
 
    </td>
====Improvements====
    <td>Firefox, Packaging</td>
Make the extension module more defensive.
    <td>Is there an option to make firefox more verbose ?</td>
Add meaningfull messages.
    <td>Make the extension module more defensive, add clear messages
 
    </td>
=== No simple option ===
    <td>
 
    </td>
====Description====
</tr>
Currently, the requirements for setting up the project are very elaborate.  
<tr>
There are too many boiler-plate items on the check list that have to be successfully completed.  
    <td>No simple option</td>
All of which can be assumed (see Ruby on Rails philosophy) but are potential blockers for new developers who silently pass up XUL because it looked like a lot of unnecessary pain.
    <td>Currently the requirements for setting up the project are very elaborate. There are too many boiler-plate items on the check list that have to be successfully completed. All of which can be assumed (see Ruby on Rails philosophy) but are potential blockers for new developers who silently pass up XUL because it looked like a lot of unnecessary pain.</td>
 
    <td>XUL Runner apps. Mozilla/Firefox extensions.</td>
====Impact====
    <td>none</td>
XUL Runner apps. Mozilla/Firefox extensions.
    <td>Why can't it be as simple as passing a jar file to xulrunner/firefox bin on the command-line - the same way you pass a jar file to java bin?</td>
 
    <td></td>
====Solutions, workarounds====
</tr>
None
</table>
 
====Improvements====
Why can't it be as simple as passing a jar file to xulrunner/firefox bin  
on the command-line - the same way you pass a jar file to java bin.
 
=== Privileges / Security barrier ===
 
====Description====
When one's developping a XUL app, he will soon face privilege issues.
actually, many access to deep Mozilla functionnalities (as interacting with XPCOM)
are restricted by privilege.
 
We understand that it is mandatory, but some privilege requirements
have impact on functionnalities that do not obviously require security
(like drag & drop for example).
 
Moreover, locally installed applications (extensions) have a special status,
will full privileges that no remote application could ever get.
Mozilla already embeds a signing facilities [http://www.mozilla.org/projects/security/components/signed-scripts.html signing facilities]
Signed scripts or signed applications should be able to execute with full privileges,
without prior installation.
 
This barrier may prevent the develoment of great online applications,
as we already have for XUL extenstions.
 
====Impact====
Remote applications.
Thx...
 
====Links====
This point is already being discussed [[XUL:Remove_Privilege| here]]
 
== dev extension proposal and DEV MODE ==
Once mature, a KISS (keep it simple stupid) ''dev starter kit'' could be bundled with FF to tempt potential developers into "giving it a go". It could be accessed from the tools menu under "create my own extension".
* Easily set important DEV MODE flags. ie, no xul cache
* auto generate a skeleton extension based on a choice of templates
* click a "publish" button to produce an XPI along with a basic HTML page including a link to it.
99

edits