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.

Filling up the Dance Card – EclipseCon 2016 Reston VA

I can tell EclipseCon is getting close by the level of my panic. Five weeks to go. And it’s getting pretty tight.

I have a whole bunch of things I want to demo and hopefully get the community excited about. The Preview of the Arduino C++ IDE, a showcase for the new build and launch systems I’ve been working on, is nearing it’s end on the Mars stream and it’s time to get it working on Neon. I have a talk on that on the Tuesday entitled “Build Arduino Apps like a Pro”. It is a really cool application of all the great work we’ve done on the CDT over the years and I have some cool places I want to take it.

I also have a very ambitious talk on Thursday called simply “Eclipse, the IDE for IoT”. In that talk I will demo and describe all the Eclipse IDE plug-ins you can use to build an IoT system, from an Arduino to the cloud services that analyze the data coming from that Arduino, to the Web and Android clients you use to view the results of that analysis. This is what has always driven my work and passion for the Eclipse IDE. It’s a truly Integrated development environment with a capital ‘I’ that can do everything I need to build systems. And I’m proud to show that off to anyone who wants to see it.

Aside from my talks it’s going to be a very busy week. On Monday, we have the CDT Summit where anyone who has interest can join as we talk about CDT issues of the day and work on plans for the future. We’re such a diverse group and have built up a family of contributors, not only working on the CDT project itself, but on our siblings in Linux Tools and Parallel Tools and the occasion discussion about Target Management. I have a good start on my ideas for a new CDT build system that I’ll talk about and how it’s used for Qt, CMake and Arduino. And we have a Hackathon schedule Tuesday night where we should be able to get deep and dirty into the code.

For me, I have interest in the Internet of Things Summit on Tuesday and Wednesday. I work for an RTOS company so, of course, we have interest in IoT since our customers do. Actually we have customers who have done IoT for years and we now have a label for what they’ve been doing. But I’m interested to hear what kind of things people are building that fit the IoT label and what kind of open platforms they are using to build those things that are on the Internet. There’s been a lot of hype over IoT and we need to filter that and see what people are really doing with it.

Thursday is Eclipse Council day. I am a member of both the Architecture Council and the Planning Council. It’s a tricky job these councils are. You have a grand title, but you don’t really have much power over what projects do. We’re really here to help projects and much of the discussion we’ll have will be on how to help them better and to really help them make Eclipse better. Our reputation is based on the technology they produce and we really need to find ways to make sure the quality of that technology is world class.

But the highlight of every EclipseCon isn’t just the sessions and summits. It’s the people. It’s the chance to talk about things you care about with other people who also care about those things. It’s a chance to put faces on the the e-mail addresses you see on the mailing lists and bugzillas. It’s a chance to feel part of the bigger team that is the Eclipse community. We are a friendly bunch, often found at the bar in the evenings, well, OK, always found at the bar in the evenings. If you get a chance, please come down and please stop me or anyone else you know in the group and say Hi and join in and be a part of our great community.

Eclipse CDT Launching and Toolchains

I’m working on adding debugging for CDT’s upgraded Qt projects support. Looking at the legacy CDT launch delegates, I’m having a hard time figuring out how to reuse the parts that I need. I’m not sure the old delegates have the structure we need to support the automated workflows we’re trying to do going forward.

Of course, this is driven by the work we’ve done with the Launch Bar. UI look and feel aside, people love the workflows it enables. You select the thing you want to launch, where you want to launch it and a mode for the launch and you hit play and it goes off and builds the thing and launches it without any additional interaction. Of course you can customize things but you don’t really have to if you just want to keep things simple.

I guess the problem we have next is implementing that. We’re essentially using launch configuration delegates for all this. I’ve added a sub-interface that adds the launch target, i.e. where you want to launch, to the methods of the delegates. And really, the buildForLaunch and launch methods are the only ones you really should be extending. The pre and final launch checks don’t have the ILaunch so I’m not sure how they’re supposed to check anything other than the configuration is valid.

The issue I run into next is that for a launch mode like Debug, I need to know what debugger makes sense for the given launch. Unfortunately in CDT, we’ve pretty much hard coded gdb everywhere so it’s hard to tell it to use a different debugger. But for Qt, I want to eventually support the Windows debugger cdb as well as lldb where available. What’s the best mechanism to do that without creating delegates for them which, trust me, if you have multiple delegates per config type and mode, you’re in for a world of UX hurt.

One thing I keep coming to as I look at renewing how we build and launch in CDT is that these two things are intrinsically tied. For whatever reason, we’ve tried to separate them but workflows are so much better if they know about each other. Builds produce the symbol files that the debugger needs at launch time. And usually the format of those symbol files tell you what debugger you can use. And for most SDKs out there, you get a debugger along with your compilers and linkers anyway.

I really thing the debugger needs to be a part of CDT’s concept of toolchain. The new CDT build system asks the build configuration, which knows what toolchain is being used, to do the build. We should just ask it to do launches too. Now that’s just a crazy idea.

Of course, I’m doing a brain dump here as I think about it. I may change my mind especially as I try and implement this. I’d sure like to hear other peoples thoughts and what other CDT extenders do. Most vendors who do extend CDT don’t usually use CDT’s launch configurations. I can see why since they’re both too flexible and inflexible at the same time. I just wonder if others have thought about this.

Happy New Year! Looking forward to 2016

It’s New Years Eve, a great time to reflect on the year that was 2015. I’ve been full steam ahead on a number of projects both with Eclipse and with my real job at QNX and quite often both. I’ve been blessed to have a management team that lets me me do the things I love and hopefully I am repaying them by making great products that our customers will love and that the open source community of Eclipse will love too.

2016 will be more of the same. I’ll have two cloud-y type projects for QNX on the go. I’ve grown to really love that area of software development, especially using the tools we’ve built on Eclipse and the great run-time technologies you get for so little cost from cloud platform providers. And it’s just great to have something new to learn to feed my insatiable curiosity.

For Eclipse, a few things are going to come together for the Neon release in June. I’ve been working hard with my intern Matthew, who’s “unfortunately” gone back to school for a few months, in building great Qt development environment for the CDT, including a QML editor with content assist and search. It will be a great alternative for Qt developers.

The Qt support is built on a new light-weight build and launch system I’ve put together. We’ve started work on CMake support based on that as well. Of course the new system is based on the Launch Bar which you will continue to hear more about. I think it’s an important addition that brings our Eclipse users, especially those that target multiple platforms, a great user experience.

I’m doing a lot of work on my Arduino C++ IDE. I’ve had such great feedback and help from the community. My plan is to take it beyond the Arduino platform to other microcontroller systems, especially the ESP8266 and upcoming ESP32 based on FreeRTOS. They are are great platforms for IoT projects. I had thoughts of doing Raspberry Pi too, but I have other plans for that (hint: programming real-time GPIO with Linux hurts my soul).

I’m really looking forward to EclipseCon NA 2015 in Reston. I have two talks, one on the work with Arduino C++. The other one is especially important to me. I’ll be showing Eclipse being used where it really shines, as the “IDE for everything”, or at least in this case, IoT. Eclipse is great because it’s frameworks let you build an IDE for anything and it really shows when you use it for a bunch of different things, Arduino, Qt, Android, vert.x Java, web front end, AWS lambda’s, everything you need in a single workspace to manage a distributed system, uh I mean IoT system (new lingo for an old idea).

So, that’s all for now. I’ll continue to write and make demo and instructional videos about the Eclipse projects I’m working on throughout the upcoming year. I can’t wait to get 2016 started. Happy New Year to you all!

API Changes for LaunchBar for Neon

The LaunchBar project that a number of us are working on is in a weird home at Eclipse for the moment, i.e. as a component of the CDT project. That makes it hard to reach everyone who’s extending it for their projects and products. Of course that’s assuming there are any, but if there are, I hope they’re following Planet Eclipse or my blog.

I have a big API change that I will be pushing tonight on the master branch. It reintroduces a concept I had a while ago but gave up when I foolishly drove IRemoteConnection as the way to model launch targets. Launch targets are the place where you want to launch. It will now have an ILaunchTarget which is a very general object, simply a name and a type identifier. And there are a few things around that to be able to match ILaunchTargets to your target management system of choice. In theory, I should be able to now push the whole launch bar to platform debug without adding weird dependencies.

The change is on the master branch which will be used for Neon. Maintenance for Mars will continue on the ‘mars’ branch. As always, let me know if you have any feedback, see any bugs, or have thoughts of where you think you could help.

Of course I need to document all of this and as I get satisfied we finally have the right APIs in place I’ll do that and help anyone who wants to use the launch bar with their launch configuration types, launch modes, and launch target types. More soon.