What is Two? Much more than yet another Eclipse IDE

It’s been a wild few weeks on the journey I now simply call “Two”. (Until it becomes an Eclipse project, I can’t call it one. And rightly so). The feedback I’ve received, especially as it hit the presses, was fantastic. It’s driven a lot of traffic to my github repo. I’ve even received a few pull requests from people cleaning up my mess as I plow through it. At the very least, people are intrigued by idea of an IDE built with Web UI technologies running locally under Electron.

As I work through the vision, I don’t think it’s fair to simply call it yet another Eclipse IDE. It’s much grander than that. For me, Two is about that vision. It’s more than a code editor. It’s more than just taking the existing Eclipse IDE and implement it in HTML5 running locally. It’s about a whole new way for developers to work with their tools and access the resources available to them on the web.

Developers today have access to many powerful web services. Github is a huge one. At Eclipse we use Bugzilla for bug tracking. A lot of companies use JIRA. People may be using Gitlab as their private Github. You may be using Gerrit for code reviews. I notice LLVM is using Phabricator for code reviews. And there’s the venerable Review Board still active today. Jenkins for continuous integration. And don’t tell me you don’t cut and paste error messages into Google searches to find others who’ve seen the same problem and worked out a solution. The Web is a critical tool in the developers belt.

I was intrigued by an article written by the creators of a tool called Ship. It’s a Mac native, i.e. Cocoa, app that integrates with the Github issue tracker. This quote hit me:

“A point of pride for us is that many people we have shown Ship 2.0 haven’t been able to tell where the web-based content ends and the native Cocoa stuff begins.”

That’s exactly it. If we can say the same for Two, where you can’t tell where the web ends and integration with local tools begin, then we’ve hit a home run.

Integrated Development Environments provide the most value when they have integrations between tools, which the developer has had to do manually for years. The IDE’s role is to automate workflows that transgress all the tools the developer has to use, where the workflow becomes the key, not the individual tools themselves. This focus makes it much easier for them to accomplish their objectives, so they don’t have to learn all the intricacies of underlying environments, but provide a unified language.

And that’s what Two needs to be, a tools integrator that includes not only the tools the user has installed locally, but also integrates with these super powerful web resources in seamless workflows.

The other important factor with IDEs that so many forget, is that experienced developers will always have a bit of mistrust in their IDE no matter how good it is. They need to be able to get close to the iron and run the underlying tools manually at a place where their trust is higher. An IDE that hides that, or makes those tools hard to get to, will struggle being universal. That’s why I’m not a fan of Cloud or Docker hosted tools. In making deployment easy for the provider, they make it hard for the user to touch the bits they’re creating.

The main reason I don’t want to call this Eclipse Two is that this isn’t just about a next generation Eclipse IDE. That IDE was my One, the first IDE that I’ve had a hand in creating. I want to rethink the whole developer experience and create an IDE that works well in the modern world, now almost 20 years after One. This is Two.

Looking Forward to 2017

I know a lot of people didn’t like how 2016 turned out, especially Americans, but for me it was a year of reflection and renewal.

As the state of the art for user interface frameworks gel around hardware accelerated graphics, I have been worrying for the future of Eclipse. It’s age is really starting to show and it’s getting harder to find tools developers that want to work with it. And with the murky future of JavaFX and Java as a desktop application technology, It’s time to start looking for the next thing in desktop IDE frameworks.

I also spent a lot of the year learning more about what embedded software engineers do. I’ve been building tools for them for many years but haven’t had a chance to use them myself. As Arduino and Raspberry Pi become cheap yet powerful and accessible devices, I bought a few of them and am starting to see how fun it is to program these devices to interact with the real world.

There are a few areas where I will be focusing my time in 2017. Here are some quick highlights. One New Years resolution I definitely have is to write more so I’ll be adding details as the year progresses.

Eclipse Two

Those who follow me on Twitter will notice me working on a new project that has grown from my fascination with Electron. Electron is the combination of Chromium and node.js in a desktop application framework. It’s what Visual Studio Code is written with along with many new and upcoming desktop applications, like Slack. It’s given me a fun opportunity to really learn HTML, CSS, and JavaScript and think of how I’d build an IDE with it. I have a couple of things running and you can follow along here on my github account.

Of course people have asked why not just extend one of the many text editor frameworks, like VIsual Studio Code, for what I need. There is a big difference between text editors and IDEs. Text editors seem to focus maniacally on being just text editors. IDEs add different types of visualizations and graphical editors that abstract away some of the more complex aspects of systems development. Web developers may not appreciate it much (yet), but embedded software developers really need the help that these abstractions provide.

My hope is that this work with an Electron-based IDE bears fruit and attracts IDE developers who are excited about the same idea. I’ve called it Eclipse Two (and it’s not e2, BTW, it’s Two), since it’s my full intention that if the Eclipse community is interested, we’ll bring it there. As it was in the days Eclipse One was introduced in 2001 and CDT in 2002, we can’t build this by ourselves. It only succeeds with a strong community and with strong architectural leadership that Eclipse is famous for.

CDT and the Language Services Protocol

The Language Services Protocol (LSP) is quickly becoming the accepted architecture that enables IDE’s to acquire language knowledge users expect as well as allows us to experiment with new IDE front ends, like Eclipse Two. Since it’ll be a few years before a new desktop IDE enters prime time, we’ll need to keep Eclipse and the CDT alive and thriving.

One thing we’re starting to see, thanks to Dr. Peter Sommerlad and friends on the C++ Language committee, is the C++ language continuing to evolve and modernize with new language constructs introduced every three years. It’s going to be very difficult for the small CDT team to keep up.

We need to look for alternative language providers and work with other IDEs, possibly leveraging the LLVM project’s libclang or some other parser that we could hook up to the LSP. That will likely be a lot of work since we rely on the CDT’s parsers for many features that the LSP doesn’t currently support but I think it’s a long term direction we need to investigate and a number of us CDT committers feel the same way.

Arduino and the Electronic Hobbyist

I am still fully committed to the Arduino plug-ins I’ve built for CDT and will continue to enhance them as the Arduino community and the mainstream Arduino IDE evolves. I am still hoping that members of the community will help with code along with their fantastic bug reports. The feedback has been nice to see and I’m glad the plug-ins have been useful.

The more I look at the work that embedded software engineers do and the incredible complexity of the systems they are working with, the more I am reassured that these developers do indeed need the help a good IDE can give them. Of course, it has to be a good IDE and I continue to work to understand what that means and help make it happen.

BTW, I had started on some plug-ins I was using to program the ESP8266 I used in my demos in 2016. Since then I’ve been in conversation with the ESP32 community and it’s been great to see that they are already adopting Eclipse and the CDT. Instructions are here if you’re interested. The good news for me is that it’ll give me a chance to stop working on my own plug-ins and to give me more time to focus on the other things in this list :).

Use an RTOS for your Real Time system

Programming the ESP8266 gave me some experience with FreeRTOS. In the demo, I have an ultrasonic sensor that I use to trigger different colors in the NeoPixels I also have attached to the chip. All of this is very real time sensitive. I need to measure the time between two interrupts to calculate distance from the sensor, and the NeoPixel communications depend on sending a serial stream of data at a very sensitive clock rate. Real time matters.

As part of the demo, I was showing CMake and the Launch Bar and how easy it was to switch from building and launching for one system to another. I took the real-time code for the ESP8266 and pretty much ran it as is on my BeagleBone running the QNX Neutrino RTOS, including the interrupt handlers and the NeoPixel code. I can’t imagine doing that on Linux. I know I work for the company, but it really helped me appreciate the Neutrino microkernel architecture and how easy it is to build an embedded system with the tools and APIs we provide.

The problem is, not enough people know about Neutrino and what a good RTOS can offer. Too many people are using Linux in real-time systems because it’s easier to get started, because it’s what they know, not because it’s the right architecture. One thing I hope to do is to help with the cause and spread the word and make it easier for the community to try it out. What that means, we’ll have to see in the upcoming months.

Beyond the IDE

I’ve made my career as a tools developer to do what I can to help other software developers build systems. But tools alone isn’t enough. Tools need to be combined with education through demos and tutorials and other types of instruction. Now imagine combining the two, a tutorial you access on the web that drives your desktop IDE as you learn.

And with that we come full circle as that’s one of the use cases I hope we can achieve with Eclipse Two! An IDE that not only helps you write and test code and build systems, but teaches you how best to do that as well.

Happy New Year and all the best in 2017!

It’s going to be a great year for the Eclipse community and technology and I look forward to helping where I can.

Using Eclipse CDT with MSYS2

MSYS2 is a relatively new distribution to support the MinGW compiler on Windows. It’s actually grown beyond that and has a pretty rich set of packages that include CMake, clang and gcc, and a huge set of libraries including Qt and SDL. It’s kept reasonably up-to-date and I’m sure if we can grow the community even more, we could get things even faster (e.g. Qt is one minor release behind).

On Windows, the CDT loves MinGW and MSYS. As Eclipse is a native application, it really expects things like path names and such to be native Windows things. Cygwin, being a Linux emulation layer, and the recent Bash for Windows are actually hard for CDT to integrate with because they hide away the native.

For Eclipse Neon, CDT has added support for automatically detecting the MinGW compilers in an MSYS2 installation. This article will give a quick guide on how to set up MSYS2 with the proper set of packages to start building C++ projects on Windows.

First a quick rant about their choice of package manager, pacman. I’m sure people who use Arch Linux love pacman. It’s pretty powerful. But I worry that it’s a tough fit for Windows users. The problem gets worse as there are actually three sets of packages, msys (common), mingw32 (for 32-bit tools), and mingw64 (for 64-bit tools) and some packages are in multiple of those. pacman makes you pick each time you install a package. And it gets worse installing the toolchain since mingw32 and mingw64 each have toolchains that target 32-bit and 64-bit. Now you’re up to five combinations.

But it’s what we got so we’ll have to make due. Hopefully we can simplify this a bit.

First, most people are on 64-bit Windows these days and for that, just select the mingw64 packages and the x86_64 toolchains. If you are on 32-bit Windows, go mingw32 and i686 toolchain. If you are targeting both 32 and 64 bit, simply add the other toolchain. But also make sure you add all the libraries for that architecture too.

MSYS2 starts with a pretty decent installer. It’s available from https://msys2.github.io/. The instructions on that page are a good description on how to do the initial setup. After finishing that, you still have no toolchains or libraries. To set up your development environment, run the following command. This gives you gcc and make, enough to build a hello world project.

pacman -S make mingw64/mingw-w64-x86_64-gcc

A couple of quick notes on that. The toolchain comes from the mingw-w64 project which produces both 32-bit and 64-bit compilers. Confusing? Yes. Also, pick the make from the default package set since it’s a more full featured make than the mingw32-make that comes with the mingw64 package set.

That should be enough to get started. Feel free to poke around and add library packages you’d like to use. Qt projects should just work with CDT’s new (and still very young) Qt plug-ins.

More later as we figure out the right configuration for CMake and for other libraries.

EclipseCon Europe 2016 So Glad to be Back

I spent a good chunk of the week trying to figure out the last time I was at EclipseCon Europe. The last thing I remember was spending a night in the Nestor bar until 5 a.m. with a handful of attendees, including Torkild, with the honored presence of Dave Thomas, the spiritual founder of Eclipse. That was 2008! It’s been eight years! I’ve missed so much. But I’m so glad that things in my life have cleared up to enable me to attend and I don’t expect I’ll miss another one for a while.

My biggest take away from the conference is simply the diversity of the people interested in Eclipse and the diversity of things happening at Eclipse. There’s still a large chunk of it related to the RCP platform and the IDE we build on top of it. But there’s really cool things happening with the Science and IoT groups as well. And the OSGi lego train display was mesmerizing but really showed off OSGi’s roots in the industrial space.

The week started with the CDT Summit on Monday. We had a good representation from different companies who build tools based on the CDT. We had a mini demo camp where they had the opportunity to show off what they’re doing. There’s some really cool stuff happening. It’s great to see them trying to make the complex world of embedded development simpler to understand through some great visualizations. We also noticed a couple of areas where the different vendors are building the same functionality. Those are great opportunities to collaborate in the open and the CDT project is very welcoming to new things. Finally it was very interesting to see how all the vendors really rely on our managed build GUI to simplify compiler and other build settings for users. That’s something we’ll need to carry forward into the new Core Build system (which I still need to blog about, stay tuned for that).

On Tuesday, I had my talk where I showed off Eclipse for embedded. It’s really a showcase of all the hard work we’ve done to simplify CDT for embedded development and to support open frameworks that users are using today, including Arduino, Qt, CMake, ESP8266, etc. It also shows why Eclipse is so important to us in the embedded world. IoT is a marketing buzzword, but it’s also an architecture that many of us have used in the past and which is growing thanks to accessible cloud platforms. These days, you need to program both your Arduino and your cloud service and Eclipse lets you do those things with a single IDE.

The rest of the week was spent chatting with my open source collegues, building relationships, getting a feel for the current state of the Eclipse IDE and where we need to go in the future. The Visual Studio Code keynote from Dirk Baeumer we very eye opening. I’ve been studying VS.Code for a few months trying to get a sense of what it’s appeal is and whether a desktop IDE based on a Web frontend is the new modern way of building IDEs. Now VS.Code isn’t an IDE, or at least it’s not as much an IDE as the Eclipse IDE is. We have a lot of tools that render different sorts of data visually in Eclipse and those high value things need to carry forward in any new world. But it’s food for thought and I’m going to invest some time to see what can be done there.

As Mike loves to say in his keynotes, Eclipse is many things. I think first and foremost, it’s a community. Technologies come and go, and individual people come and go, but there always seems to be a great energy when we come together. The task for us is to carry that energy forward into our day-to-day work and keep momentum going on all the great things we talked about. It’s not easy, but it’s why we need to be there.

Pushing the Eclipse IDE Forward

It’s been a crazy week if you follow the ide-dev mailing list at Eclipse. We’ve had many posts over the years discussing our competitive relationship with IntelliJ and the depression that sets in when we try to figure out how to make Eclipse make better so people don’t hate on it so much and then how nothing changes.

This time, though,  sparked by what seemed to be an innocent post by Mickael Istria about yet another claim that IntelliJ has better content assist (which from what I’ve seen, it actually does). This time it sparked a huge conversation with many Eclipse contributors chiming in with their thoughts about where we are with the Eclipse IDE and what needs to be done to make things better. A great summary of the last few days has been captured in a German-language Jaxenter article.

The difference this time is that it’s actually sparked action. Mickael, Pascal Rapicault, and others have switched some of their focus on the low hanging user experience issues and are providing fixes for them. The community has been activated and I love seeing it.

Someone asked why the Architecture Council at Eclipse doesn’t step in and help guide some of this effort and after discussing it at our monthly call, we’ve decided to do just that. Dani Megert and I will revive the UI Guidelines effort and update the current set and extend it to more general user experience guidance. We’ll use the UI Best Practices group mailing list to hold public discussions to help with that. Everyone is welcome to participate. And I’m sure the ide-dev list will continue to be busy as contributors discuss implementation details.

Eclipse became the number one Java IDE with little marketing. Back in the 2000’s developers were hungry for a good Java IDE and since Eclipse was free and easy to set up (yes, unzipping the IDE wasn’t that bad an experience) and worked well, had great static analysis and refactoring, they fell in love with it.

Other IDEs have caught up and in certain areas passed Eclipse and, yes, IntelliJ has become more popular. It’s not because of marketing. Developers decide what they like to use by downloading it and trying it out. As long as we keep our web presence in shape that developers can find the IDE, especially the Java one, and then keep working to make it functionally the best IDE we can, we’ll be able to continue to serve the needs of developers for a long time.

Our best marketing comes from our users. That’s the same with all technology these days. I’d rather hear from someone who’s tried Docker Swarm than believe what the Docker people are telling me (for example). That’s how we got Eclipse to number one, and where we need to focus to keep the ball rolling. And as a contributor community, we’re working hard to get them something good to talk about.

See you in Ludwigsburg at EclipseCon Europe!

It’s been many years since I’ve been to EclipseCon Europe. It hasn’t been from a lack of desire. There’s just been a few personal and business reasons that made it difficult. But this year, the road is clear and my talk, “Arduino, Qt, and Iot with the Eclipse C++ IDE” has been accepted as one of the early bird selections. I was really proud of that and can’t wait to get there.

This last year or so has been a very active one for me and the team here at QNX with our contributions to Eclipse. The Launch Bar, which proved popular with BlackBerry 10 developers, has been made more general and is now hosted at Eclipse for all projects to use. It greatly simplifies the launch and build experience, especially when dealing with remote machines.

We are actively working on support in CDT for Qt, which has proven popular with QNX customers and other embedded systems developers. The highlight is the addition of a QML editor which we will continue to add content assist and other features expected of good Eclipse editors. While these things are good for QNX users, we think these things will be good for all users of Eclipse and also support Qt on Windows, Mac, and Linux.

I have switched my personal focus on embedded real-time systems and working on making Eclipse and the CDT much easier for developers making software for those systems. My Arduino C++ IDE bridges the gap between professional embedded developers and the hobbyist working with Arduino boards. It’s a great exercise in providing a user experience that can satisfy both and I think we’re making strides there.

My talk will attempt to cover all of that. It’s a tall order, but I have a simple, yet somewhat contrived example that shows an Arduino board with sensors and lights talking to a BeagleBone board running QNX with a touchscreen showing status from the board. The BeagleBone then communicates with a MQTT server which is watched by a vertx.x Web server to show the same information on web page. All of that is built with Eclipse and the massive ecosystem we’ve built over the years. It’s a great showcase.

It should be a great time. It’ll be good to see a lot of my European friends I haven’t seen for years or have only met on mailing lists or who I’ve never met but have an interest in the CDT and other Eclipse IDE projects. We have a CDT summit planned for the Monday and I hope to see everyone there and share what we’re planning and to see what you’re interested in.

It will be a great week. And now I really can’t wait!

Now Available: The Eclipse C++ IDE for Arduino

Back in October, I released the preview edition of the Arduino C++ IDE and the response has been fantastic. I had something like 50 bug reports and lots of questions on every forum imaginable. That great feedback gave me a lot of incentive to fix those bugs and get a release out based on the work we’ve done in CDT for the Eclipse Neon release. And that is now done and available on the Eclipse Marketplace.

What’s new in this release? Well, a name change for one. I wanted to highlight that this is an Eclipse CDT project effort, not necessarily an Arduino one, so I’ve renamed it to the “Eclipse C++ IDE for Arduino.” This fits in with our strategy moving forward of providing more vertical stack support for different platforms. Expect another marketplace entry for the Eclipse C++ IDE for Qt in the next release or two, for example.

But what matters to users is usability, of course. The main new feature in this release is the Arduino Download Manager available in the Help menu. It provides a dialog that guides you through download and install of Arduino Platforms and Libraries. The metadata provided by the Arduino community has been hugely beneficial in letting me build Arduino support into CDT in such a way that new boards and libraries can easily be added. And this new dialog is your gateway into that community.

Screen Shot 2016-07-18 at 12.14.21 PM

I’ve also done a video as an introduction. It’s only 11 minutes but walks you through installation to having an Arduino sketch running on your board outputting to the Serial Console.

As always, I love to hear from users either through forums or bug reports, especially bug reports. I have things set up to quickly get fixes to users through it’s own p2 update site. Always try Help -> Check for Updates to get the latest.

Blogging QNX

I’ve been working on the Eclipse CDT project for a really long time now. It started in 2001 when I fell into an opportunity to pursue my dream to work on a C/C++ IDE and, in particular, coming from the modeling world with ObjecTime Developer and Rational Rose RT, create a C++ parser that can build up a model of user’s code. I have been extremely lucky do that and to represent my various employers over the years on the project and am very proud of what we in the community have built and continue to build in the CDT.

Over the last couple of years, I started to get curious about what our users were doing with CDT. One of the ironies of working on a C/C++ IDE written in Java, you actually don’t get to use C++ very much other than the odd hello world tests. So I started to get deeper into the world of embedded systems. It started with Arduino and the world of microcontrollers. These are amazing little devices that let you build systems that interact with the real world with inexpensive hardware that brings me back to my youth and the 8-bit processors of the day. And, of course, being the CDT guy, I started working on a plug-in for CDT that helped you program these little things while showing off CDT’s latest features, the Arduino C++ IDE.

I recently bought a Raspberry Pi 3 to take things up a notch. It’s a little powerhouse that’s really not much more expensive than an Arduino and I’m thinking it would make a great platform for robotics. I can imagine putting some ultrasonic sensors on the sides and a camera on top and doing some image processing so the robot can drive some motors and find it’s way around a room of obstacles. But the thought of doing such real-time processing using Linux made me gag. I work for a real-time operating system company and I guess I’m really believing in what we do and really should be using QNX for that.

Well that has me now deep into the world of creating a Board Support Package, BSP, that will let me run QNX on the Raspberry Pi 2 and 3. It’s been a blast and I’ve learned so much about the operating system I’ve been writing an IDE for all these years. And it’s about time. It’s a very different world and have even had to learn ARM assembly language.

Being the blogger that I am, I’ve decided to spend more time writing about that experience and to share it with developers working with QNX, or interested in what we do, or simply learning about real-time software development and maybe a little IoT. I’ll still blog about the Eclipse IDE pieces I’m working on and will share those with the Eclipse Planet. But if you want to follow along the QNX side too, I invite you to subscribe to my blog using the form on the main page.

It’s a new chapter for me. But it fits well with everything I’ve done over the years, doing what I can to help developers make better software with great tools but now also expanding that embedded systems and their run-times. I have some really cool projects, like my robot, that will help me focus on a specific group of developers who are also working on some really cool projects and I can’t wait to get started.

Eclipse Andmore needs love too

I posted a tweet the other day after seeing yet another election for a new committer to the Eclipse Platform UI project.

They are doing a great job down there and they rightly took the tweet as a compliment. But my point was more that a great Eclipse IDE also depends on having great support for the platforms our users are building their software for. And the one that has me particularly concerned lately is Android.

When Google threw their support towards IntelliJ and the new Android Studio, the Eclipse contributor community went into shock. Aside from J2EE, the Google Android Development Tools was a source of pride and a showcase for the great things Eclipse can do. To be slapped in the face like that woke us up to the real problems we had of which there were many ranging from a user experience that dated from the long gone era of Windows MFC apps, to community issues as plug-ins developers had to deal with new requirements that the Eclipse SDK team never had to face. And it’s great to see teams like the Platform UI team growing and helping to address those.

For our part, a small band of us made an attempt to “rescue” the ADT plug-ins. We forked them and brought them to Eclipse as the Andmore project. It was really the heroic effort of Dave Carver who managed to get the plug-ins in shape and get them through the Eclipse IP process and get the project started that we have Andmore today.

But we’ve had a really hard time getting any momentum on it. There are a few contributors that have dropped by and it’s greatly appreciated. But Dave has moved on to a new job and hasn’t had much time to spend on it. And without active leadership, I fear Andmore will fall into dormancy and we’ll lose the opportunity to bring Android developers back into the Eclipse family where they can enjoy all the great work the Platform UI team has been doing.

I always hoped I would have the opportunity to help Andmore and it’s still on my long term plans to jump in more. But as things stand now, it’s only a side project for me. And I have much more pressing side projects I need to get done. I’ve been getting back to my roots in the embedded space and am working hard to put together an Eclipse package that can be used by electronics students and hobbyists who want to program their Arduinos and other microcontroller boards with CDT and to get them hooked on the wonderful world of Eclipse.

So I’ll leave this here. There are a few things that I see Andmore needs to be competitive with Android Studio. It doesn’t need to beat it, but it needs to be a credible alternative, especially for developers working on projects where Android is only a part of a bigger system that is being developed using Eclipse.

Gradle Support

The Android SDK comes with first class build support with Gradle. If you want to build a modern Android project, you have to use Gradle. It’s not even up for debate. For my Eclipse IDE for IoT talk I managed to get a simple implementation of Gradle support for Android working. It was pretty easy. But it will be a challenge to get it integrated into the existing Andmore plug-ins.

Keeping up with the SDK

What Google probably thought was a good idea, they’ve been able to reuse a number of jars from their SDK in the Eclipse plug-ins. The problem is that those jars are external dependencies and every time they up-version them, we need to bring them back through the Eclipse IP process and re-import them into the Andmore builds. It’s a serious amount of work. I just wonder if we can reduce that dependency and leverage more out-of-process communication to make the architecture easier this way.

The Real Tragedy of the Commons

I’ve seen the term “Tragedy of the Commons” used incorrectly in relation to my tweet by a few people. You can find the real definition on Wikipedia. Eclipse’s version is that many plug-in developers have built their plug-ins with the assumption that theirs is the only one installed and the users only care about them. They add menus and toolbars wherever they want, and especially in highly visible places where users can find them. Better yet, they pop up dialogs to warn users of configuration issues on startup to urge the user to resolve them before using the IDE.

What would that look like if every plug-in did that and users installed them all at the same time? (And I know Eike Stepper has tried this and produced a monster!) That’s the Tragedy of the Commons for Eclipse. Plug-in developers have to think of the common good, of all the other plug-ins out there in the Eclipse ecosystem and to make sure their plug-ins play well with those.

Well, Andmore has a few issues in that regard, especially with dialogs on startup. Yes, I know my Android SDK isn’t installed, yet. I’m busy with something else. For me, it’s one of those design issues where instead of a “don’t show again” checkbox on the dialog, I want a “don’t have ever showed this dialog” one.

I truly hope that a segment of the Eclipse community will feel that supporting Android development with Eclipse is important. Hell, I think supporting iOS is important too. We can’t be the IDE for everything without having support for the big things. I’m glad we’re addressing the common UI pieces in the Eclipse Platform, but as I tweeted, the whole Eclipse IDE stack needs that love too.


LaunchBar and User Experience

Screen Shot 2016-02-09 at 10.03.27 PM

In an effort to make the LaunchBar more “Eclipse standard”, I am trying to make the icons for the build, launch, and stop buttons 24 pixels square. They were 32, which I do admit made the entire tool bar a little too fat. 24 pixel high makes it much more streamlined and you barely notice that it’s still a couple of pixels higher than without the launch bar. I think users can live with that. And I’ll find out soon enough as I always do.

Now, the icons I have there now are ugly. My claim to fame is writing parsers and build systems, not graphic design. I just whipped these together to show what they could look like and get a feel on how the new size helps with the overall visual. We’ll get someone (and Tony McCrary has volunteered) to make them more professional looking.

But I still get the argument from a few people that the UX is bad because the Launch Bar doesn’t look like the rest of the toolbar. Well, no, it doesn’t. And it wasn’t meant to. I think I need to tell the story of how the Launch Bar came about to help explain why.

It started when we were working on BlackBerry Momentics, the IDE for BB10. Our manager hooked us up with a manager who worked in our Sweden office. These were designers who worked at the former TAT (The Astonishing Tribe) who were responsible for the beautiful user experience that became the Cascades framework for BB10. They sent over a handful of “developer experience” designers to a workshop in Ottawa and we brainstormed about how we could make Eclipse beautiful, and more important, a great experience especially for developers who were new to BB10 development.

It was an eye opening experience. They were very cautious about our feelings over the Eclipse UX but were very candid about what they thought. And we didn’t really argue. They took special aim at the tool bar and the “ridiculous” 16-bit icons that were  supposed to somehow be meaningful to a new user. It leads to an overwhelming feeling that only intimidates these poor people and we really want to make sure they become successful using our tools. The first recommendation they gave us was to turn off all of the tool bar buttons.

Then we took aim at the launch experience. I have to admit we took some inspiration from popular IDEs that we all had experience with. But in the end, isn’t the most important thing you do with an IDE other than type your code in, is launch the thing you’re coding? We felt it deserved a place front and center. So the Ottawa gang put forward the general layout of the Launch Bar and the Swedes provided the icons and the spacing around the whole widget. They made it big on purpose and made the buttons soft so that the user interface wasn’t so intimidating and was easy to understand.

The feedback we got was tremendous. I’ve told this story before, but when our product manager presented the new look at a developers conference, one of the attendees went up to him after and gave him a hug for making his life so much better. That kind of feedback for a tools developer is hard to beat and something we should all strive for.

As we move forward, and we focus on the general QNX developer and bring them more and more of what’s available in the Eclipse ecosystem, we felt it important that we push the Launch Bar upstream and work to enable it for more and more use cases. Of course, when you try to address a larger audience, not all of them are going to appreciate the look and feel of it. It is different than most things on the tool bar. But by design, it was supposed to dominate the tool bar. Remember, there wasn’t supposed to be anything else there. It’s actually the old tool bar icons that don’t fit. When I set up my environment now, I turn off everything I can and it does result in a very clean look.

I appreciate that not everyone is going to like the Launch Bar or find it useful. We are striving to make it an optional feature. But as we work to support different types of targets you can launch on, we’re finding hard to do without the Launch Bar. So we will get lots of haters and, if you work at all in open source or tools in general, it’s just part of the game and something you get used to. You can’t make everyone happy. But on the other hand, you also need to make sure you don’t make everyone sad. And those UX guys we worked with were very sad about the Eclipse UX and I’m just trying to keep their effort to fix things up alive.