SIDEBAR
»
S
I
D
E
B
A
R
«
Source editor worth $70
Nov 14th, 2013 by Eugene Ostroukhov

I’ve been a devoted Eclipse user for more then a decade (with most of that time spent developing applications based on Eclipse) but I’ve noticed that I am becoming less and less inclined to spend my time trying to convince Eclipse to actually edit my files. I ended up using  Eclipse only for Java – Xcode is great C++/C (libclang-powered editor with C++11 support) with VIM was standard for all other files. For the last couple months I’ve been slowly migrating to Sublime – now I reached the point when I even consider using it for Java files.

This is just a “disgruntled veteran Eclipse user” view on why it is worth it to pay for your coding editor these days.

It can open files! And folders…

Cmd+S, Cmd+N and Cmd+O are the first shortcuts everybody learns. Eclipse is unique in that it breaks this convention. “Open File” is an afterthought (doesn’t even have a key shortcut), with many plugins unable to work with those files – even if your editor manages not to show an error dialog (or dump an exception in log) – some features still are not available.

Sublime not just behaves as expected – it goes one step further. I can “open” any folder – showing that folder in the Sublime “Project Explorer”-like pane. What is truly surprising is that Sublime manages to deliver many Eclipse  killer features – including “Open Resource…” and “Goto Symbol in Project” (think JDT/CDT “Find Type” and “Find Function”). No metadata files is created in those folders, no indexer is ran. Right now my “workspace” has a mix of Bootstrap-based HTML application with a Python server-side – and without any plugins I can immediately focus on a CSS rule or on a Python function. I’ve also shown to my colleagues that I can open mid-sized C projects and be able to open random function within seconds. No setup, no long-running background jobs.

It opens shell scripts, .ini files without spinning up Xcode or any other heavy “external editor”.

Editor is the same

Cmd+Shift+R will go to symbol in any file in any language (that I tried) – in Eclipse, CDT and JDT installed in the same workbench have confusing separate realms with Cmd+Shift+T been bound to different dialogs depending on active editor. Cmd+Shift+R and Cmd+Shift+A are yet other parallel realms, adding to the confusion.

Sublime can expand selection to enclosing scope in Dita XML, Python or in JavaScript. Sublime actually even unifies Eclipse-like “Goto line” and “Quick outline” popups into “Goto Everything” – I’ve been wondering for years why Eclipse uses separate pop-ups for that.

One prominent Sublime feature is multiple cursors. Curiously, this feature is really familiar to JDT and CDT users – you can see multiple cursors when you rename variables. In Sublime multiple cursors can be used to select search results (quite similar to Eclipse rename refactoring) or to apply edits to several separate locations at once.

No mouse

I spend most my time in Eclipse having source editor maximized (I also used to hide toolbar – until I started using Eclipse Kepler where Cmd+3 makes toolbar visible no matter what).

In Sublime I can split the window (not the editor ;) ) using just the keyboard. I can move editors between stacks or focus on stacks without reaching the mouse. Switching between editor predictably opens a tab to left/right – instead of randomly popping from the recent editors stack.

Niceties

There is no preferences UI as such in Sublime – keybindings and settings are stored in JSON files that are editable in the text editor.

Plenty of plugins, easy discovery. “Cmd+Shift+P”, “Install<Return>”, type filter string. Plugin is found and installed even before “Marketplace client” would open.

Files can be opened from the command-line. Reliably. Even on Mac.

Missing parts?

Sublime does not integrate SCM support. Well, there are some plugins – but I haven’t figured them out yet, mostly because I am command-line Git and Perforce user (as not all my files are in the workspace) – the only thing I miss is Perforce checkout from the editor.

No debugger UI. Surprisingly, no biggie – JavaScript users are using browser anyways, C* users get to keep their GDB/LLDB primed.

No way to run shell command from within the editor. As in VIM.

Next generation

IntelliJ and Eclipse were revolutionary tools – they eschewed RAD features and visual designers that were a cornerstone of the IDE experience and focused on the core programming experience instead – providing ultimate source editor, making refactoring mainstream. Sublime seems to do the same trick – only this time it is Eclipse that is slow and outdated. Sublime does not force me to manage workspaces (in couple weeks I will have to start working in a different branch (in Perforce it is a different folder) – ain’t it fun, with my 20+ projects?), flip perspectives (the first thing I show to QA or new team members – “If you don’t understand what’s going on on the screen, do “Window > Reset perspective”) or wait till my cancel button click is honored. Again, as 10 years ago, I’m enjoying my editor instead of wrestling with it…

Indeed, times, they are a-changing…

CSS Validator sources were published
Nov 2nd, 2010 by Eugene Ostroukhov

CSS Validator sources were published as a new project at EclipseLabs.

This project adds a W3C CSS Validator as a WTP build-time validator (i.e. the validation markers will be shown only after the CSS file is saved in the editor). It should be compatible with any WTP-based IDE though I only tested it with vanilla “Eclipse for JS developers”.

Browsers in SWT
Oct 7th, 2010 by Eugene Ostroukhov

Browsers are arguably the single most important application in the modern computing. There are many reasons why all major modern UI toolkits provide an integration with one (or several). There are many reasons to use browser in Eclipse RCP or IDE application:

  1. Use it to display static information with rich formatting (i.e. API doc, query result)
  2. Use it to integrate rich web application – either by creating a site-specific browser that connects to a remote server or by serving the application from your Eclipse instance.
  3. To provide better tools for web developers – integrating browser will let you better understand application runtime state and will allow you better explain to user the result of modifications.

SWT has a browser integration for a long time. Actually it has several integrations:

  1. Default System Browser. That’s what you get when you use the org.eclipse.swt.browser.Browser class (without specifying the “MOZILLA” style). This is by far the most stable integration that would cause you the least integration problems. It will wrap OS default browser (IE on Windows, Firefox on Linux and Webkit (Safari) on Mac OS X) – not that it will wrap the OS-default browser, not the browser that the user chose as a default. The biggest issue is that on Windows it turns into pumpkin IE – and you have no control over actual IE version it would become. So you will likely need to avoid some advanced features (including HTML5) and really invest a lot to ensure cross-platform compatibility of your web app code. Another issue is that there is little control over some more advanced browser features – i.e. as an IDE developer you may need to change the security configuration and that is not possible in a unified cross-platform way. Oh, and “default browser” might not be available on some Linux setups (at least that was a case a few years ago).
  2. XULRunner (Mozilla Firefox). This support is baked into SWT (see this snippet) and is triggered by specifying SWT.MOZILLA as a browser style. This browser provides a uniform cross-platform rich web experience but it still has a few shortcomings. First of all, it requires the browser to be installed separately. It will try to use the Firefox from the user OS and that means that you would have little control over the Firefox version – and this is exaggerated by the fact that some newer Firefox versions may break compatibility with older SWT versions and thus force the users to update their SWT-based applications. There are also some pretty irritating issues around integration edges (i.e. FF may grab input focus when you try to refresh it). There is a way to bundle XULRunner with your application if you create your custom bundle or use the one Zend created for ATF project.
  3. WebKit integration. This one gets more and traction as the WebKit is probably the most designed-for-embedding browser engine. SWT uses WebKit on Mac by default and support on GTK was introduced in SWT 3.6. Support for Webkit on Windows is planned for SWT 3.7. I have not tried it yet but it looks like there still will be a problem with the distribution as WebKit has some core components licensed under LGPL, which makes it impossible to be published on Eclipse.org.
  4. WebKit4SWT from Genuitec. This integration is Windows-only. As far as I understand, it is based on Chromium Embedding Framework so there is a chance that it will be available on other platforms when the upstream project adds those platforms (Valve used same framework for their Steam client and had published Mac source code – but it is not yet integrated into the upstream project). This project is used for Genuitec MobiOne project.
Qt WebKit integration sources published
Sep 30th, 2010 by Eugene Ostroukhov

I created a project on Google Code for the Qt WebKit integration in SWT. At this moment it will only run on Windows and Mac and only if you have Qt SDK installed. I am trying to find a way to either statically link Qt to the DLL or to bundle it in Eclipse Plug-in (it is doable on Windows but doesn’t work for me on Mac).

Current code has a basic browser view that can open pages in WebKit browser, marshal some events and has next/previous/stop/refresh actions. I was focused on more technical challenges (like making sure event queues don’t lock and events are properly propagated). From this point I will be extending API so if there is anybody interested in the component – feel free to participate in the discussion groups and bugtracker to communicate your requirements.

Qt is not only styling…
Sep 22nd, 2010 by Eugene Ostroukhov

…but is also a set of cross-platform widgets.

This is my shot at embedding WebKit into Eclipse SWT:

QWebView embedded in SWT/Win32

QWebView embedded in SWT/Win32

QWebView embedded in SWT/Cocoa32

QWebView embedded in SWT/Cocoa32

This effort is quite different from SWT/Qt as it does not intend to provide whole SWT on top of Qt – my goal is to compliment “native” SWTs with Qt widgets. I believe Qt is a great complement for SWT as:

  1. It has uniform cross-platform API – meaning developers can provide consistent functionality on all major desktop platforms.
  2. It has native look-and-feel – Qt relies on native APIs. My tests had shown that embedding Qt into SWT is more stable then embedding Swing into SWT.
  3. Qt provide a lot of well-tested ready to embed components – QWebView integration is my primary focus right now. It was fairly straightforward to embed full-fledged WebKit browser into Eclipse workbench. I researched other WebKit “bindings” like the Cocoa’s WebKit and it looks like Qt provides most comprehensive APIs of them all.

This project will become an open-source project on one of the OSS hosting sites. I see following issues with the project:

  1. It will be LGPL project. Qt is LGPL and my code statically compiles to some other LGPLed Qt code. There isn’t really a lot of options. LGPL means that no Eclipse Foundation project will ever be able to leverage it. Note: WebCore and JavaScriptCore (they are primary WebKit components) are both released under LGPL meaning that any WebKit binary will always have LGPL code.
  2. Huge size and distribution problems. I have little C++ and Qt experience so I was unable to statically link JNI DLL to Qt libraries. Qt dynamic libraries introduce both distribution and size concerns.

Current state and future directions:

  1. The code will be published after I expose more QWebView APIs to SWT clients and will improve the build configuration.
  2. I plan to focus on QWebKit functionality like QWebInspector and QWebPage
  3. Research other Qt components that are attractive to SWT crowd (native combo with images)?

Help wanted:

  1. Build configuration to produce binaries as small as possible.
  2. SWT/GTK port – I am completely unfamiliar with GTK development so I haven’t even started looking in this direction. It shouldn’t be hard – both Win32-specific and Cocoa-specific parts are a few dozen lines long.
What can a Mobile Web Application do?
Sep 16th, 2010 by Eugene Ostroukhov

Paul’s Eclipse Day presentation made it obvious that there are some misconseptions about the whole “mobile web application” concept.

The core issue is that most “web applications” are essentially two different applications that are created using different technologies and interact between themselves using HTTP protocol. There is a remote application (e.g. an Apache server serving static pages or Tomcat with JSP pages or any other server running PHP, ASP and other scripts) and a local application written in HTML, JS and CSS. For years all “web application” developers’ attention was drawn to a server but with the advent of AJAX more and more code is moving to a browser.

“Mobile web applications” consist of only the client-side part so they are more “mobile applications” then “web applications”. The goal is to take the best of the both worlds – to combine flexibility and maturity of the client-side web technologies with pervasiveness and high availability of the mobile application. From the user point of view “mobile web application” is just a regular application that can be installed from application store (i.e. OVI store or Apple iTunes store) and ran from the regular application launcher UI. Unlike regular “web applications” these “mobile applications” can be used even when there is no network connection available.

Another trait that “mobile web application” share with other mobile applications is the ability to access native services like accelerometer, camera or address book. There is an ongoing effort to unify these APIs across all the platforms but at this moment each platform has its own API that is not compatible with others. This results in another common “mobile” problem of forcing the developers to rely on emulators to be able to test and debug application before deploying it on actual hardware.

Here are some answers to common questions on Mobile Web Runtimes and Tools for Mobile Web:

Can I deploy my PHP(or JSP or ASP.NET) application to mobile phone?

No. This is a server-side application and needs to be ran on web server. You can only deploy client-side code.

Can I publish to app store, like Ovi, Android Marketplace and others?

You can publish it on the Ovi Store and other stores.

Do I need to sign an application before distributing them?

This is really platform-dependent. You don’t need to sign the application for Symbian WRT but you may need to do it for other platforms.

Why TMW is proposed under Seqoyah and not the WebTools?

TMW does not intent to reimplement WebTools (including JSDT). Think of how Tools for Mobile Java rely on JDT for the core Java support – same goes for the relationship between TMW and WTP/JSDT. TMW is really focused on “mobile” parts.

Can I create an application for different platforms?

Yes, in most cases. It really depends on how much the application relies on mobile-specific APIs. There are some frameworks (i.e. PhoneGap) that allow consistent API across several mobile platforms.

What about standards support in mobile web browsers and mobile web runtimes?

Even though most mobile web browsers are based on a same WebKit engine they differ vastly in their capabilities. But still, all the platforms move in the same direction by implementing common standards like HTML5, CSS3 and other W3C specification. You can find a great comparison here.

Using expressions in your extension points
Sep 7th, 2010 by Eugene Ostroukhov

Originally I meant to create a reference of the Eclipse expressions and properties available in SDK but there is already such article in Eclipse Wiki. I would strongly recommend bookmarking that article – it is an excellent reference. I would like to describe how you could leverage the expressions in your extension points (when you declare extension points as opposed to providing extensions to platform extension points). There are several reasons to use expressions as a part of your extension point:

  1. Lazy initialization – expression can be tested without activating the plugin that contributed the extension.
  2. External declaration – expressions are declared in the plugin.xml and that sometimes makes it easier to maintain them.
  3. Flexible and pluggable language. Users can leverage org.eclipse.core.expressions.definitions extension point to declare reusable expressions. Users can also leverage org.eclipse.core.expressions.propertyTesters to declare property testers that contain complex logic.

To use expression in your extension point you will need to update your extension point schema file (exsd file) to declare expression language elements. The easiest way is by referencing expression language schema:

<include schemaLocation="schema://org.eclipse.core.expressions/schema/expressionLanguage.exsd"/>

This will import all the elements so you can use them in the extension elements editor:

Expression elmeents in the extension element editorNote that you can specify any expression element as the expression root. I would recommend to using the “enablement” element as this would let you get all changes to expression languages as they appear in the subsequent Eclipse releases. Plug-in developers will see the expressions in the PDE editor after extension point definition is updated.

To test the expression you will need to parse the expression:

IConfigurationElement[] children = configurationElement.getChildren("enablement");
if (children.length == 1) {
    expression = ExpressionConverter.getDefault().perform(children[0]);
}

Then you will have to create “evaluation context” and evaluate the expression. Evaluation context provides all the variables that are available to the expression – like “activeWorkbenchWindow” and others in the commands framework. You may spacify one object as a “default” (it is “project” variable in my snippet):

final EvaluationResult result = expression.evaluate(new EvaluationContext(null, project));

“result” will be one of FALSE, TRUE and NOTLOADED. NOTLOADED is mostly when the user references the propery tester from inactive plug-in and tells the framework to avoid plug-in activation to instantiate just the property tester.

After this point the user will be able to use the expressions with your extension point just the same way they are used in extension points declared by core Eclipse.

Tools for Mobile Web
Jul 27th, 2010 by Eugene Ostroukhov

We (the Symbian Foundation) proposed a new project – Tools for Mobile Web. We offer our code as a basis for this new Eclipse project and now that we released version 1.0 of our product we would like to focus on this contribution. I would like to better explain what we would like to see out of this project. We did several presentations already so there are some common questions we had to answer.

What is “mobile web”?

In the scope of this project “mobile web” means “mobile web runtimes” that are present on most modern popular smartphones. Developers can use web technologies (HTML, CSS and JavaScript) to create mobile applications. These applications are quite different from the regular web pages in that they are not served from a web site but are installed on the device not unlike regular “native” mobile applications. They can be distributed through the OVI store or other platform-dependent application stores. These application have a broader access to device capabilities – they can access GPS and accelerometer sensor readings, use device-specific UI (i.e. software buttons on Symbian phones), read address book or be notified when SMS or MMS message was received.

Simulator can run web runtime applications and provides basic controls to trigger events

Device simulator

But there is Web Tools Project already!

TWM does not mean to reimplement WTP functionality. We build on top of the WTP reusing all the powerful tools in provides (like JSDT). We focus on adding functionality that is specific to mobile development – like deployment to phone or mobile API simulation.

Will you add support for JQuery UI (or <your other favorite JS library>)?

Our focus is on adding mobile development-specific functionality. We do not plan to implement functionality that users consider “missing” from the WTP. On the other hand we hope to cooperate with WTP and possibly contribute to such areas. Once the WTP gets support for the library then TMW will “inherit” it.

We are watching closely JavaScript frameworks that are more specific to mobile application development. We already added support for PhoneGap framework and we may add support for other frameworks as they mature and gain popularity.

Is there any timeframe on when the tools will be available?

You can already download Tools that support Symbian WRT development. They are feature complete and EPL licensed so we encourage you to try them whether you are a JavaScript developer looking to expand to mobile platforms or an Eclipse enthusiast interested in IDEs for mobile. Currently we are focused on refactoring our code to add support for any number of the runtimes and to prepare it for migration to eclipse.org. From that point we will continue development of both Symbian-specific and runtime-agnostic parts.

What about support for other platforms?

We have implemented support for PhoneGap APIs but we only package applications for Symbian platform. Aplix already stepped up to contribute support for BONDI runtime. We expect other interested parties to contribute support for other platforms.

What can the IDE do?

It is a fully integrated IDE that supports application development cycle from creating a new application project to deployment on the device or packaging for distribution.

IDE main screen

Main screen

Our editing experience is based on WTP were we extended JSDT with the support for mobile libraries and added CSS validator and application manifest validator.

Another important part is the simulator and debugger that are built into our IDE. It can be used as a live preview of your application or as a runtime for debugging. Our primary goal was to reduce overhead of the mobile application development so we chose to use desktop browser (Chrome) to ensure maximum debugger performance. We understand that this approach is not completely accurate but it had proven to be “good enough” for debugging of the vast majority of the tasks. We plan on adding on-device debugging in one of the next releases.

How do I start using this IDE?

Follow this link for up-to-date information on using our IDE. Do not hesitate to contact us on our forums or submit bugs to bugtracker.

How is this IDE related to other solutions for WRT development (i.e. Nokia plug-in for Aptana, Dreamweaver)?

Our code owes to a large degree to Nokia code contribution. Our initial goal was to achieve feature-parity with Aptana-based solution. We added several important features including PhoneGap support and acceleration events simulation that were not available in the original code.

Why open-source?
Jun 4th, 2010 by Eugene Ostroukhov

The first questions developers ask about out new Mobile Web IDE is “why do we need another solution?” This question is really justified provided there are already several established alternatives in all shapes and sizes.

Our answer is that we wanted to have a completely open-sourced tools – and that leads to another question. “Why should we (as users) care?” Now that open-source is not that much of a buzz-word it used to be most users don’t really care if they can see the source code – they are more concerned with usability and ROI. This is what we hope to achieve with our project:

  1. Single all-in-one download for every platform. All you need to install our IDE is to download ZIP file for your platform and to unzip it anywhere on your filesystem.
  2. Use latest-and-greatest upstream projects available from the community. We use JSDT for JavaScript editing, Chrome Java SDK for debugging, W3C CSS validator for validation.
  3. Use our codebase for an effort to provide a reference IDE for mobile web development. We want to contribute our project to serve as a basis for Eclipse project that will foster development of similar IDEs for different runtimes. Currently all major mobile platforms provide a way to create and deploy applications using web technologies. Until this point there was a separate IDE for each platform and we hope our project will encourage cooperation and ultimately result in better tools and consistent user experience.

We have a lot of plans that should justify having “yet another” Mobile Web IDE even more:

  1. Support other mobile APIs. Currently we are working on out-of-box PhoneGap support but we will also consider other APIs and runtimes.
  2. Improve preview and simulation. We are working on support for more sensors and mobile APIs.
  3. Streamline UI.

So we encourage you to give the IDE a try. You can post your comments and suggestions to our forum. We would be grateful for any bug reports posted to our bugtracker.

Using Jetty as an OSGi HTTP Service
May 19th, 2010 by Eugene Ostroukhov

I was unable to find any documentation on how to use Jetty as an OSGi HTTP service. We needed it as a part of our WRT tools effort to host a code that would serve as a runtime environment (sort of “emulator”) for the user code. I guess there are many other scenarios that could make use of the embedded server.

Basically, everything you need to know can be found in org.eclipse.wst.ws.internal.explorer.WebappManager class that is part of the WebTools project. The code is very simple:

Dictionary d = new Hashtable();
d.put("http.port", new Integer(getPortParameter())); //$NON-NLS-1$
// set the base URL
d.put("context.path", "/wse"); //$NON-NLS-1$ //$NON-NLS-2$
d.put("other.info", "org.eclipse.wst.ws.explorer"); //$NON-NLS-1$ //$NON-NLS-2$</p>

<p>// suppress Jetty INFO/DEBUG messages to stderr
Logger.getLogger("org.mortbay").setLevel(Level.WARNING); //$NON-NLS-1$</p>

<p>JettyConfigurator.startServer(webappName, d);
checkBundle();

In our code we do not specify the context path (so we have root as a context path) and specify a different ID so both our code and Web Services tools could coexist.

What is really important is that the server will run in Eclipse process and deployed servlets can have access to Eclipse APIs so you can interact with the workbench as you need – i.e. you can have all the settings stored in the preference store and configurable from the preference page, access the workspace and interact with your IDE (i.e. in our case it is possible to do AJAX call to disconnect JavaScript debugger).

There are two ways to register servlets:

  1. Programmatic (using OSGi APIs)
  2. Declarative (using org.eclipse.equinox.http.registry.servlets extension point)

In our application we use programmatic way so we don’t have to rely on singletons to integrate them with our IDE.

»  Substance:WordPress   »  Style:Ahren Ahimsa