Category: Javascript

Posted on

OpenKomodo is Open for Business

ActiveState is ready to start rocking the OpenKomodo project. They have everything ready to go:

All they need now is YOU! Head over and get involved. You can also start thinking about SnapDragon, the full-featured web development tool integrated with Firefox:

Komodo Snapdragon is an idea, a desire, a mission! Web development with Firefox benefits from excellent developer tools such as Firebug, but it needs more. We invite you to help define the future of Komodo Snapdragon. Join the Open Komodo community today and help shape the future!

Great mission! I look forward to SnapDragon planning and development.

Posted on

WebRunner Followup

Its been just over 2 weeks since we released WebRunner 0.7 and lots of people have tried it out (over 6500 downloads). We have been following blog posts, articles and comments to gather as much feedback as possible. Thanks for everyone who has taken the time to try WebRunner. Even more thanks to those who gave us feedback or made your own webapp bundles. Here’s a summary of what we learned:

Some FAQs

We received lots of feedback in comments and from blog posts. Here are some of the recurring issues:

  • Support for extensions – WebRunner does support extensions. DOM Inspector (found on the command menu) is an extension. WebRunner does not expose a UI for loading extensions yet. So you need to get the extension installed yourself at the moment. Also, many extensions just won’t work in WebRunner. Not only do you need to update the extension (install.rdf) to recognized WebRunner, but the overlay (merging) code will need to be tweaked too.
  • Google Gears support – Since Gears is an extension, it has the some of the problems listed above. Its not visual, so there shouldn’t be an overlay problem. It is possible to hack support for Gears into WebRunner. The best plan for Gears might be to suggest a patch to the Gears team to support WebRunner officially. Gears is open source and it might be possible. NOTE: Alex’s hack is not up to date anymore. The WebRunner ID changed to webrunner@developer.mozilla.org
  • Some way to set options/preferences – Access to a UI for setting things like file download location and proxy settings. Even so far as access to the about:config feature.
  • Multi-profile support – So you could run all Google webapps in a profile, but separate from your Zoho webapps (in their own profile) and separate from general purpose webapps.
  • Better support from Web Appllcations – Some web applications are not really designed to be run through WebRunner. Meebo is a good example. I couldn’t find a way to load just the buddy list in a window, which is what you’d want to do for WebRunner.
  • WebRunner uses Gecko 1.9 – WebRunner is using the newest (not yet released) version of the Gecko rendering engine. The same engine used in Firefox 3. This means we might have some problems, like: Rendering slightly different than Firefox 2 (might be a bug) and cursor/caret missing from GMail when using rich format editing (definitely a bug). Look for this to improve as Gecko 1.9 / Firefox 3 get closer to release.

Please keep the feedback coming. We are working to resolve as many of these issues as we can.

Making Webapp Bundles

Lot’s of people have taken a crack at making a webapp bundle. The WebRunner wiki page lists some of these.

What’s Coming

We have been trying to collect the bugs and feature requests out of the feedback and blog posts. Here are some things that have been added or fixed for the next release:

  • CSS themes – Bundles now support common (all platforms) and OS specific CSS theme overrides. You can make web applications take on different CSS styles
  • Spell check support – Red squiggles and suggestions on the context menu.
  • Better external link handling – Spreadsheets from Google Docs were opening in the default browser.
  • Tooltips support – We now display tooltips for elements with “title” attributes.
  • Copying hyperlinks – Context menu supports copying a link location, if you right click on a link.
  • More “Install Shortcut” options – Quick Launch Bar and Start Menu were added on Windows and Application folder was added on Mac.

Look for the next release sometime next week. Thanks again.

Posted on

Firefox 3 – Plays Well With Others

Mozilla endeavors to promote open standards, while at the same time, create a better Web, even if it means using the “other guys” specifications and DOM extensions. Here is a summary of features added to Firefox 3 (Gecko 1.9) that either implement a good open specification or someone else’s DOM extensions – for the betterment of the Web:

WHATWG Web Applications (link)

Internet Explorer DOM Extensions (link)

  • clientTop and clientLeft DOM extensions are now supported.
  • elementFromPoint DOM extension is now supported (bug 199692).
  • oncut, oncopy onpaste, onbeforecut, onbeforecopy and onbeforepaste DOM event extensions are now supported (bug 280959).
  • getClientRects and getBoundingClientRect DOM extensions are now supported (bug 174397).
  • The HttpOnly cookie extension attribute is now supported (bug 178993).

Yes, some of the Internet Explorer extensions are also WHATWG specs.

Not Invented Here? Not a problem 🙂

Posted on

Of RIA, Open Web and Plugins

Adobe’s Ryan Stewart has a post on the friction between Open Web advocates and “RIA vendors”. I think Ryan does a good job describing the work being done at Adobe (and Microsoft) to become active in a larger ecosystem, namely open source and cross-platform. There are a couple bits I want to respond (emphasis mine):

I think it’s indicative of wider problems between the “open web” and RIA vendors. The basic issue is that everyone’s too combative. I wish more open web people would look at what both Microsoft and Adobe are doing and see that all in all, the RIA solutions are becoming more open, not less. In fact, I’d argue that RIAs have moved the entire web in a more open direction.

I think Ryan’s use of the term “RIA” to indicate a “proprietary vendor plugin” will cause confusion. Rich Internet Applications can be created without the need for proprietary vendor plugins. Also, what Adobe has done around open sourcing parts of their plugin system has been welcomed by everyone. However, there are still large chunks of closed source and encumbered file formats that work against the Open Web.

I’m not sure if RIAs will ever be as fully open as the open web advocates want, but think how far applications in the browser have come (as far as openness) since the days of ActiveX enhancements in IE.

As I have stated, RIAs can be fully open and, as a card carrying Open Web advocate, those make me happy. However, how far have Adobe and Microsoft come from the days of ActiveX vendor plugins? Last time I checked, ActiveX was still the technology of choice for Flash and Silverlight on IE. Honestly, even if Flash and Silverlight were completely open source, the fact they are plugins and not native Web standards will be a stumbling block for many Open Web folks.

They’ve [Flash and Silverlight] pushed the web forward in a way that it seemed the open web groups couldn’t (video, vector graphics, easy cross platform/browser development).

Yes, they have pushed the Web forward, I’ll admit that. The resurgence of SVG and the new & elements are evidence of that. But then Linux is a platform too, and I suppose that Mozilla could market Firefox as the one, true cross platform Web platform – but we don’t. We encourage choice and competition. We want developers to have choice too and not be locked into a single stack. Let me know when Flash can run a Silverlight application.

Mike Shaver responds in a comment to the post.

Posted on

Hello JS-CTYPES, Goodbye Binary Components

I have been working on a small project that ports Python’s ctypes functionality to Mozilla’s XPCOM system. For those unfamiliar with ctypes, its a Python module that allows developers to declare and call exported methods from binary/shared libraries. Developers can then wrap these binary calls in pure Python.

The JavaScript port, called js-ctypes, will give developers this same kind of functionality in Mozilla’s privileged JavaScript. The idea for the library came after helping many extension developers through the process of building binary (C++) XPCOM components. The story usually went something like this:

  1. Developer wants functionality not built into the Mozilla platform, but easily supported by the native OS.
  2. Developer wants to use a 3rd party library in an extension or xul app.
  3. Developer has methods in native code for performance reasons.

The usual answer to these problems is creating a binary (C++) component to act as a wrapper so the native features can be exposed to JavaScript via XPCOM. However, the process of building binary XPCOM components is significantly harder than JavaScript components. The macros and memory management rules of binary components are harder than JavaScript, but its really the compiler and linker flags, IDL, makefiles and SDK versions that make the process painful. The build process must be repeated for each platform too. For many cases, its just too much work.

The goal of js-ctypes is to allow developers to declare methods in binary libraries and then expose those methods as callable JavaScript functions. Developers can then create pure JavaScript library wrappers around binary libraries – without making binary XPCOM wrappers.

Here is a really simple example of using Window’s native MessageBox call from JavaScript:


const nsINativeType = Components.interfaces.nsINativeType;
 
function msgbox() {
  var library = Components.classes["@mozilla.org/js-ctypes;1"]
                          .createInstance(Components.interfaces.nsINativeLibrary);
  library.open("user32.dll"); // Load the shared Windows DLL

  var messageBox = library.declare(
      "MessageBoxW",          // name of the exported method
      nsINativeType.INT32,    // return type
      nsINativeType.INT32,    // parent hwnd (its a Window's thing)
      nsINativeType.WSTRING,  // Unicode message string
      nsINativeType.WSTRING,  // Unicode title string
      nsINativeType.INT32     // bitflag for buttons to show
  );

  var ret = messageBox(0, "This is the message", "Msg Title 1", 3);
  alert(ret);

  // You can reuse the method
  var ret = messageBox(0, "This is another message", "Msg Title 2", 3);
  alert(ret);
}

The js-ctypes code uses the same libffi library as the Python ctypes module. It is currently known to work on Windows and compiles on Linux, but I haven’t got around to testing it. We need to start the Mac implementation. We also need to add support for struct and more primitive types.

The code is in SVN here and we have a Bugzilla component too (see bugs, file bug).

Note: This functionality cannot be accessed from JavaScript used in web content. Only JavaScript that runs with chrome privileges (extensions and Firefox UI for example) can use js-ctypes.

Posted on

Joel Spolsky and Weak Metaphors

Joel’s latest strategy letter is a long-winded diatribe on the current state of browser-based application development. There is some good stuff in there, but some of the metaphors are really stretched and the comparisons between desktop and web-based applications is a bit broken. Joel seems to think that web-based applications should support the same kind of features as desktop applications. This line of thought can only go so far.

For example, cut and paste between applications. I assume Joel wants to copy more than text from edit boxes and selected HTML from the page. No reason this couldn’t be done today (Live Clipboard anyone?) but doing so requires cooperation between the applications in question. The Web platform already supports it. And hey, the same kind of limits occur on desktop applications. Try pasting an Outlook contact into Quicken. On the Web right now, microformats and mashups provide functionality not easily possible in desktop applications.

Joel also brings up lack of UI consistency in web applications. Not so sure about this one. I believe a little bit of consistency goes a long way and many web applications share common UI elements and concepts. Let’s not forget just how consistent desktop applications can be. Microsoft Office seems somewhat consistent with its applications, except for the ribbon is missing from some. Sure, it may not be appropriate in all applications. I’m fine with that – just not overly consistent. And take a look at the UI’s of “web-style” desktop applications and media players and tools like Microsoft Expression (best if viewed with Silverlight). Again, just saying a little consistency goes a long way.

Finally, we get to the “NewSDK” concept. The super-do-it-all framework that all web applications use and Joel compares this to Microsoft Windows and the Windows SDK. Personally, I would be comparing the Web to Windows, not some framework that runs on the Web. Compare that “NewSDK” framework to MFC or WPF. In a followup post, Joel responds to readers who forwarded their version of the “NewSDK” by saying:

Indeed countless people have already emailed me to say that “NewSDK is here, it’s (choose one) Flex Builder, Google Web Toolkit, Java Web Start, Silverlight, JavaFX, Flash, ActionScript, MORFIK, OpenLaszlo, … (many omitted)” Ahem. These are not HERE until your TAXI DRIVER has heard of them, because I assure you he’s heard of Microsoft Windows.

Again, he’s comparing apples to oranges. Ask your TAXI DRVIER if he’s heard of the Internet. And again, I’d use MFC, WinForms, VCL as desktop examples of the “NewSDK” examples listed in the quote. Ask him if he’s heard of WPF.

Here’s another quote that rubbed me the wrong way:

If you’re a web app developer, and you don’t want to support the SDK everybody else is supporting, you’ll increasingly find that people won’t use your web app, because it doesn’t, you know, cut and paste and support address book synchronization and whatever weird new interop features we’ll want in 2010.

The ideas in this quote are exactly NOT what the Web is about. This is anti-Web. Forcing interop by mandating a framework is ridiculous in a place where open standards and formats are embraced. Web development can and is improving, but let’s not try to turn the Web into Windows. Of course, some people already are.

Posted on

ActiveState’s Open Komodo Project

Today ActiveState announced the Open Komodo Project, an initiative to create an open source platform for building developer environments. The project overview has lots of information on the details. Here is a good summary:

Open Komodo is not a product, but rather a code base upon which Integrated Development Environment (IDE) software packages can be developed. ActiveState’s Komodo Edit (free but not open source multi-platform, multi-language editor) and Komodo IDE (multi-platform, multi-language IDE for dynamic languages and Ajax technologies IDE) are existing, mature products that will use the Open Komodo platform.

In addition to the code base, the project will also start building a web development tool called SnapDragon:

The Open Komodo Project aims to create a full-featured web development tool for client-side web development integrated with Firefox©, Mozilla’s free, open source web browser, and based on the award-winning Komodo IDE. This new tool, codenamed Komodo Snapdragon, will be developed in collaboration with the open source community.

The project timeline gives information on how the project is expected to unfold. There seem to be many ways developers can participate in the project, including just lurking on the mailing list.

This project will provide some great open source code to the Mozilla platform for development tools. This is an area that many Mozilla developers feel is lacking and has been a much talked about issue for the new MozPad group as well. I look forward to a strong community forming around the project and using the code base to create many great developer tools.

Thanks ActiveState!

Posted on

What’s New on MDC

Here is some recent content additions or changes appearing on the Mozilla Developer Center (MDC).

  • XUL Popup Guide: Great information on using popups (panels, menus and tooltips) in extensions and XUL applications. The popup infrastructure was heavily rewritten in Gecko 1.9 (Firefox 3). Thanks Neil.
  • E4X Tutorial: Joey Minta put together a really good tutorial covering many aspects of using E4X – the ability to use raw XML in JavaScript.
  • Code Snippets for XUL : Some examples of getting the from mouse click and the selected from right-click were added.
Posted on

Firefox 3 – ContentEditable

Firefox 3 is expanding its rich WYSIWYG editing capabilities by adding support for the contentEditable attribute. Setting contentEditable to “true” allows you to make parts of a document editable. Firefox already supports using designMode to make an entire document editable. Here is a previous post about using designMode.

Here is an example of using contentEditable to make a simple rich editor in HTML: contenteditable.htm
(NOTE: requires Firefox3.a6+ or a browser that supports contentEditable)

The new contentEditable features support the same API as designMode for interacting with the editable element:

  • document.execCommand – Executes the given command.
  • document.queryCommandEnabled – Determines whether the given command can be executed on the document in its current state.
  • document.queryCommandIndeterm – Determines whether the current selection is in an indetermined state.
  • document.queryCommandState – Determines whether the given command has been executed on the current selection.
  • document.queryCommandValue – Determines the current value of the document, range, or current selection for the given command.