[paulb]

Hello, I'm Paul Beusterien and I was recently hired by the Symbian Foundation to lead the developer tools strategy and implementation. I was most recently at Wind River Systems where one of my roles was leading the development and first several releases of the Eclipse-based Workbench product for VxWorks and embedded Linux development.

I'm now chartered with creating a set of developer tools that will help accelerate the growth of the Symbian developer community.

As I've been coming up to speed, I see a huge list of possible items on which I could focus. I'd like your help in prioritizing that list.

Please reply in this thread with the top three items to improve the Symbian developer tools.

If you'd like to discuss tools in another (or additional) venue, let me know and I'd be happy to have a call, email, or skype conversation.

[antony]

Hi,

Hopefully you won't mind if I give you 4 instead of 3.

(1) Simple nothing -> Hello World experience. Having not actually written any Symbian C++ for a while I decided to try out Carbide 2.0 when it came out. It all installed fine, but then when I tried to load it it told me that I didn't have perl installed and quit. OK - so I installed perl. Then I started Carbide again and setup a new project. Ah - no SDK installed. OK - try again. Then I started Carbide again and setup a new project - could be simpler but I got there. Click on "build" (and go through the hideous CDT build config nonsense) and get told that I don't have a compiler installed. That took 15 mins to sort out; and if I didn't already know about CodeSourcery and Sourcery Lite then that could easily have been 90 mins. OK - so I'm finally running "Hello World" in the emulator, now let's try and do that on the device, and set a breakpoint, ... This process just needs to be super super simple. Carbide feels like it's optimised for experts and the repeat-case; it needs to optimise this case for me.

(2) General ease-of-use. I remember when I saw the "rainbow" view on Workbench 2.0. It was a nice touch. It was a simple idea that made multi-core debug much better. Symbian's tools need some of that. Carbide has all the basic features an IDE needs; certainly enough to be competitive with any other C++ IDE; it needs to be made nice to use.

(3) Signing. Once you've actually read the Symbian Signed manual and setup the environment signing actually isn't very difficult (unless you want device manufacturer caps). But setting up the basic environment is super difficult. Especially if you're just trying out your first app and so don't have a publisher ID and want to self-sign. I remember when I first tried to do this. It took me 3 hours and I that included 2 calls to the guy who ran Symbian Signed (a friend - well at least until I tried to do this).

(4) Web Programming. Although I'll always love C++ (well really C) I find myself more-and-more writing javascript, CSS, and XSLT (I've done a great pacman for S60). Being a loyal Symbian-supporter I wanted to setup an S60 web programming environment and went to symbian.org and Forum Nokia. No dice. After about 30 mins digging around I went over to Aptana and downloaded their IDE and then cobbled various bits and pieces together myself. It would have been nice if I could go to symbian.org and get a beautiful webdev package. That package should just be existing bits (e.g. Aptana) integrated nicely together; just something that helps me through that setup phase when I don't know what I don't know and have an 80% chance of giving up and going back to playing Warcraft.

Hope this helps,
Antony

[brian_____]

1. Upgrade to the latest stable GCC 4.x and include as much of its standard C++ library as possible besides I/O (especially unique_ptr and shared_ptr). For years GCC has supported ARM NEON SIMD instructions and many more important features than the old version of GCC that SDKs have been shipping with. It is possible for us to upgrade to GCC 4.x manually but we have to edit several Symbian header files to get things working.

2. Faster build/test/modify loop. If there is a compilation error, take me to that compilation error ASAP instead of making me wait for the build to finish, then waiting for me to click the Problems tab, then waiting for me to expand the "errors" subtree, then waiting for me to click the error message. Anything that can help me go from modifying code to seeing the results of that code executing (faster compilation, pre-compiled headers, background compilation, multi-threaded building, emulator startup time improvements, TRK launch time reduction, etc.) would be a huge win.

3. Throw away the emulator and build one that runs ARM binaries so I don't have to recompile when I switch between device & emulator builds, and so I don't get different results with the emulator vs. devices (in particular, installing apps in the emulator should install them in C:\ or E:\ and *not* Z:\). And/or, add just-in-time panic debugging to devices and allow us to interact with the device with the computer's screen & keyboard (similar to Remote Professional, Remote Device Access, and DeviceAnywhere).

[cowboycoder]

Hi Paul,
my first suggestion for you would be to download and install the various devkits that are around. Not just the ones from the Foundation, but the recent ones from Nokia, etc. And write a couple of small apps.
That should highlight some of the things you're going to see suggested.

[cowboycoder]

My own personal top 3 would be somewhat in agreement with Brian.

1) An IDE that helps, rather than hinders. Brian's example is a classic, but it's other things such as having to have clicked on the right bit of the IDE just to get to click the 'properties' item in the context menu. Like Brian said, it's all about the code-build-debug loop, get that as short as possible.

2) On target debugging. This is currently far from perfect. If I have a compatible device, then I should be choosing it for debugging without fear of being penalised by a slow and inconsistent experience. I shouldn't even want an emulator.

3) Don't even ship the WINSCW based 'emulator'. I keep hearing 'end of life' and 'better solution coming', but I've been hearing that for years now. It has so many subtle differences to an ARM build, that if you get caught by one you could be in for hours/days/weeks of banging your head against the wall trying to figure out why it works on the emulator, but not the device.

[petteri]

It is nice that you asked.

1. Templates. Oh please, this should be so simple thing. Templates should ease your work instead of being major pain in the ass. Current Carbide 2.0 templates are full of horrid and ugly "example code" that needs to be removed before you can even think of using those. It is also nice idea to have HTTP API template but make it so that all the S60 apps out there don't have same flaws, e.g. usage of synchronous version of RConnection::Start()... There needs to be more templates, they need to be more simple and more useful. Please remove also those copyright clauses, gives me the creeps to see (C) Copyright Nokia in my generated class.

2. Debugger and On-device debugger are still really buggy. Also lighter debug tools e.g. ECMT should be improved a lot, for example ECMT currently does not work properly with browser. Install ECMT and try to do POST with Browser and it will fail. Also it does not work if you are using COM port higher than 9 or something which is giving most of the users real headaches. There should be easy way to setup these things with clear instructions (yes this means they needs to be tested).

3. IDE is the key, it should be fast and easy to use. Carbide 1.x was huge/major disappointment, 2.0 was much better as it actually compiles things which I prefer. But please look for example CodeWarrior IDE and how it did things, it was so much better in compiling things. You actually saw what is happening there in real time, not just looking some ugly console output but there was an actual GUI. It is like magic when those warnings and errors pops up in real-time and you can modify the source code while compiling etc.

Major improvement areas in Carbide are IMO:

- Compiler UI and problems view. It needs to be real-time and basically it should work so that if you click an error, it should open the actual line where this error occurred, and there should not be any exceptions to this rule!
- Better resource editors. This includes MIF and MBM support with integrated svg2svgt conversions etc.
- Nobody is using UI designer as it generates more bloat than any useful stuff.
- For some reason I'm still using a lot of scripts for e.g. generating different SIS files and auto-versioning etc. Maybe there is something in Carbide, I don't know but if not it would make sense.

4. Symbian needs to embrace agile development practices e.g. TDD and CI officially. I've done successful projects with CruiseControl and with customized ANT scripts for Symbian command line tools so this is not hard. TDD needs probably a lot of work though, it would be nice to have test framework as a public release and with Carbide support.

Here is something to begin with I hope.

[detronizator]

1) Get rid of WINSCW and use a QEmu based real emulator. One binary: ARM!

2) SDK to work on Linux and Mac too. Symbian is missing a lot of good developers because it can be developed for only on M$ WinCrap.

3) Make the building system faster. SBSv1 is just too slow for the kind of machine we use today.

4) 1-plug-1-click On Hardware Debugging: something like Android devices.

5) In general, make the developer stay focused on their idea, not having to context switch to solve issues/problems/requirement of an SDK. Problmes that go behond the normal "installation wizard".

[pojala]

My top three peeves have already been mentioned, but I'll cast my 0.02 € anyway...

1) The WINSCW simulator is incredibly slow and misleading in too many non-obvious ways. Replacing it with a genuine device emulator would improve the Symbian development experience enormously. (QEMU would probably be a natural choice of foundation for an ARM emulator solution?)

2) Ship GCC 4.x as the standard compiler. This ought to be a no-brainer.

3) Eliminate those lingering bizarre Windows-only dependencies in the toolchain. (When the SDK requires an outdated version of ActivePerl and .BAT files abound, it honestly gives the impression that the last update must have been in 1999...)

To gain any mindshare among developers, you simply need to support the dominant Unixes at some point (Linux and Mac OS X). But when designing the cross-platform toolchain, please consider adopting something more modern than bad old GNU Make -- there are some excellent open-source build tools that are faster, more powerful and easier to configure.

[simonm]

1) Get rid of the winscw emulator and replace it with an ARM simulator (e.g. QEmu based). I know there is already something like this around but it needs offical support! The emulator is also the biggest barrier to developing on linux.

2) Spend more effort updating the tools & toolchain. There are far too many 'rough edges' when developing for Symbian OS, some of which have already been mentioned. But as a quick list: debugging support on h/w and in Carbide is too hard and requires too much setup; too many scripts/tools rely on old or obsolete versions of tools - e.g. some Perl scripts still need 5.6.1, plus the TOOLS platform relies on obsolete MS VisualC++ 6.0 toolchain (there are still a few of these hanging around in the SF codeline even now); Old versions of compilers are still used - GCC but also RVCT; SBSv2 *still* can't reliably build the whole OS, it needs constant patches and updates, etc.

The only way this is going to get fixed is by a well-coordinated official push. Hoping the 'open source community' will fix these things is a sure path to failure.

3) Fixing the signing issues. Even if most developers can get past 1) and 2), then when they want to try their app on h/w, here is another step with a load of big gotchas ready to put them off.

[b2]

"I'm now chartered with creating a set of developer tools that will help accelerate the growth of the Symbian developer community."

I have no illusions of this idea being realistic or coming to fruition but I'd thought I'd toss it out. Also it's not a suggestion in any way, shape or form to change the main developer tool set.

How about something for Python? Ideally an IDE something like REALbasic where you could quickly code, debug, test and submit to Horizon in a single application. Testing process should allow for single device application signing and it should be Wine compliant (or a HTML5 browser based webapp) to allow for cross platform use. Also (while you're at it) build a new Python interpreter based on Unladen Swallow easily installable from Horizon. And a pony. =)

There are thousands of good python programmers out there that would love a shot at making a few extra dollars like some have through Apple's App Store. Hopefully more programmers mean more applications which (again, hopefully) means the greater chance of publicity for Symbian which is good for all concerned. Give them a first class IDE, a simple development model and a distribution/payment system like Horizon and IMO they'll flock to it. Since all apps would have to come through signed from Horizon you should be able to minimize malware.

Again, totally unrealistic but I just had to throw it out. Good luck Paul.

[orbital]

1) enable development on more than one OS
1a) port carbide IDE to linux (90% of it is already cross platform, but there are windows only bits there like DE.EXE)
1b) port tools to linux (most are already built for windows using mingw so this should be simple for those)
1c) open source the linux tools so enthusiasts can port them to other unix e.g. macos

2) break dependencies on outdated tools
(perl, python, gcc, java etc)
For the MCL, not building with the latest stable release of tools should be considered a defect (and either fixed on the MCL, or fixed in the tool)
SDK can be tested with fixed version of tools, which shouldn't be more than 6 months out of date at release of the SDK
SDK patches should be released in case new tools cause compatibility breaks.
RCL (whose purpose is stability) should have fixed version tools, but again the current version which was available at time of branching should be chosen by default.

3) "plug and play" on target debug
All manufacturer's USB drivers should be included in the SDK
IDE should detect automatically which phones are attached by USB and create a debug connection.
debug via bluetooth should be no more complicated than choosing which phone (and pairing the first time)
debug agent (e.g. TRK) included in SDK should be symbian signed, and have an option to start automatically on bluetooth/USB connection

4) easy developer certificates
Developer certificates for user+system capabilities need to be easy and free/cheap to obtain
Don't make developers interact with symbian signed and publisher ID until they have something ready to publish (or need restricted capabilities)
Don't make developers wait for an email/web form response every time they recompile

[teknolog]

Many of the points above are spot on.

These things I believe:

* One single SDK, right now my \Symbian folder has about 10 different SDKs installed.
* Drop the EPOC emulator, switch to an ARM emulator.
* Trim the compile-launch cycle. Launching on the emulator should not have to take more than 10 seconds on a modern PC.
* Make Python development a first class citizen in Carbide. Same for WRT.
* Possibly drop Carbide as a product, make the "ADK" something you install on top of Eclipse like Android does it.
* By the way, stop using the term ADK, people are familiar with the term SDK.
* Improve on device debugging. It works fine when I get it running, but it is a royal PITA.
* Fix C++ autocomplete in Carbide. It still does not work.
* Add more examples, structure the examples, spice them up. Add the Big Yellow Heart and the Friendly Spaceman to make them look cool. The SDK must be fun!
* Linux and Mac SDKs are a must.
* Clean up a lot of the old madness. File name cases are screwed up everywhere, for instance. The S60 API has hundreds of C++ warnings!
* Contain the SDK. Don't force the user to install Perl, Python or an external compiler. Include everything in the package. Another 100 MB is nothing today!

And finally:

* Get cracking! We're already behind, we need to catch up and overtake our competitors. (yes, I am coming on board over in London from September 1st).

Semper fi!

Teknolog

[paulb]

Thanks to all who shared their thoughts tools improvement opportunities. Sorry about the delay in response, but now I'd like to summarize the comments, share some of my thoughts, and explain a bit about where the Symbian tools team is and where we're heading.

1. Usability(7) - Ease of Use, Faster Build/Test/Modify Cycle, IDE helps rather than hinders, help keep developer focused, no rough edges

Improving usability is one of the biggest challenges since usability permeates the vast collection of Symbian tools we have. In some ways we need to rebalance the culture more towards quality and less towards quantity. We can make progress by identifying and improving some key use cases (like edit/compile/build/debug). Also, should increase the emphasis on integration and system testing.

2. Replace the emulator (5)

We are aggressively exploring ways to incorporate QEMU as a Symbian simulation solution If you're interested in taking ownership of the QEMU package or contributing let me know.

3. On-target debugging (4)

We're working on a proposal for plug & play debugging along with a validation process that uses a large cross-debugging test suite from the open source community

4. Linux/Mac (3)

We have a proposal in place that provides core tools (compile, debug, simulation, and build) by the end of the year, followed up by IDE support in subsequent months.

5. Fix Signing (3)

Rod Burns is leading the signing improvement initiative. I'll coordinate with him on the tooling requirements.

6. gcc 4.x (2)

From a tools perspective, gcc 4.x is ready. There is an active initiative to update the runtime to compile cleanly with it.

7. Hello World Experience

Thanks to the Symbian Technical Communications team, there has been some recent good progress on improving the developer.symbian.org QuickStarts. See http://developer.symbian.org/wiki/in..._Symbian_World There is definitely much more we can do around installation and setup, and we'll work on those as we progress on taking installation ownership inside the foundation. We will explore the feasibility of starting with a light Eclipse installation and using its P2 updater to get the remaining right set of tools and SDKs.

8. Web programming

The initial focus will be to provide a pure-Eclipse plugin for Web development that doesn't depend upon proprietary software. Also, we'll put some energy on easing Web app deployment. Most Web developers can already develop their apps. They especially need help with deploying it.

9. Templates Improvements

Bug 231 has been filed.

10. Agile Development Facilitation Tools

This would be a good thing, but won't be a high priority initially because of all of the core tools challenges. However, that does not mean that we won't support integrations with tools like Mylyn from Tasktop if the community drives it.

11. Build System

The Raptor build system is soon to go EPL and has many improvements over abld. Also, we might look at a pure make solution for application developers.

12. Python

We don't plan to do anything change existing python support, but it will be a lower priority than C++ and web development.


The Symbian tools team will drive the initiatives described above, but since we're currently three people and not likely to grow much more, we'll need lots of contributions and support. Initially our strategy is to develop an understanding of the full toolset by finding the sources of the 31 Tools Packages and learning how to build them. You can follow our progress at http://developer.symbian.org/wiki/in...Package_Status

Also, as alluded to above, we're working to ensure an open, cross-platform set of development tools. In collaboration with CodeSourcery, we've developed a proposal that would provide core tools(gcc, gdb, qemu, and build) for application developers in 2009, followed up by IDE support in subsequent months. We're working to get funding/contribution to make this happen and also explore extending for platform developers. If you're interested in collaborating, let me know.

Thanks for reading this long post and please don't hesitate to contact me if you'd like to discuss any of these points in more detail.

--
Paul Beusterien
Symbian Foundation Development Tools Manager

[brian_____]

Paul, that all sounds great.

As one of the "replace the emulator" people, I want to clarify that my was to *replace* the current emulator with a QEMU(-ish) ARM emulator, not to augment the WINSCW emulator with a secondary ARM emulator. I understand that there will likely be some time where both emulators are supported but maintaining both in the long term seems counterproductive. Having the emulator match actual devices as closely as possible is the primary motivation for many people wanting an ARM emulator. If manufacturer-customized ROM images will be available for the ARM emulator, then what would be the point of supporting WINSCW any longer? Conversely, if manufacturers aren't going to support the ARM emulator by providing ROM images containing their UI customizations and other modifications, then the existance of the ARM emulator isn't going to help most app developers; in that case I think turning over the entire ARM emulator project to outside contributors would make the most sense.

I think a Mac port of the toolchain is a great idea because then I can use one OS for Symbian, Android, and iPhone development. But, does Symbian itself really need to spend resources on a Linux port of the toolchain? Lack of a Linux toolchain isn't hurting the iPhone, and I doubt it is hurting Symbian either. I think it would be a very smart use of resources to create a really good Mac port and let outside contributors maintain a Linux port.

[paulb]

Brian, there is no doubt about replacing the WINSCW emulator. It has a limited lifespan since it will not likely support future technologies like SMP, future graphics and Qt. The only question is what it gets replaced with. I'd like the replacement to be open source technology like QEMU.

Regarding Linux support, there is community interest in it, although I tend to agree that it is probably less important than Mac. However, the incremental cost to get viable toolsets with the second is fairly small. Note that Symbian is not likely to have the funding to create "very good" ports on its own. We'll drive to get the tools over the initial hump of viability, but it will take community support and contribution to make them "very good".

[brian_____]

OK, the emulator stuff sounds great.

What would developers be giving up by getting a Linux and/or Mac OS X port? I think it would be very interesting to do a survey that listed the ideas that Symbian is willing to implement and see how Linux and/or Mac support ranks relative to other improvements.

[paulb]

Windows developers would lose a month or two of investment. Mac and Linux developers would gain the opportunity to develop for Symbian.

And the Symbian community would have the potential to gain tremendously from the influx of developers who would be able to begin contributing.

[teknolog]

All very good news!

When it comes to usability, I believe wrapping existing tools in another layer could be a good start. A few user-friendly Python scripts that in addition can be run behind the scenes through a button press in Carbide would go a long way.

Regarding Linux support I think this is a bit of a credibility issue. I've worked at several large corporations where Linux is taking place as the development platform of choice, while Windows is kept mostly for running Outlook. Running on multiple platforms would likely help us get rid of some Windows idiosyncracies we are suffering from today (usage of drive letters, disregard for file name casing, fear of environment variables, short filename usage etc...)

Also, the contribution factor is likely far greater on Linux than on Windows.

I am slightly disappointed that picking up Python as an officially supported API is not a priority at the moment. A program written in Python for S60 would probably be far easier to switch to Qt when those APIs are available. I understand that there are limited resources.

While on the subject of alternative runtimes, I experimented with WRT and found it very likable. However, having to copy the wgz file to the drive and have it manually install on the emulator seems like a crude way to do it. WRT developers likely have an even lower pain threshold than C++ developers. Here a simple Python script with associated button in Carbide could help a lot.

Keep up the good work!

[brian_____]

Paul and Sebastian,

To be clear, I wasn't saying that a Linux support shouldn't exist. I was saying that if you aren't going to create very good (production-quality) ports, then it is better to shift as much of the porting to contributors as possible. The contributors will need one really good version to base their port on anyway, especially regarding UI. Plus, don't you think Nokia will eventually contribute Linux support if Symbian itself doesn't work on it? I would think they want to have as much commonality between their Maemo and Symbian toolchains as possible, and I imagine they're eager to support Linux for Maemo. It looks like a choice between Symbian subsidizing the Maemo toolchain or Maemo subsidizing the Symbian toolchain.

The point I was really trying to make is that it would be great if Symbian ensured that there's a *very good* version of the toolchain on at least one platform. If the Linux and Mac OS X ports are not going to be very good then the implication is that the Windows port has to be the usable one. My post is just a request to not slow down development of the production-quality port to develop non-production-quality ports.

I do agree with you guys that there will be more 3rd-party Symbian software created if Linux is supported. But, I think that software will tend to be Android-quality software (with low consumer appeal) and not iPhone-quality software (which seems to have a lot of consumer appeal). I think there's pretty convincing evidence of a strong correlation between the design & quality of the tools (including the OS) a developer uses and the appeal of his apps in the market.

[teknolog]

Originally Posted by brian_____

The point I was really trying to make is that it would be great if Symbian ensured that there's a *very good* version of the toolchain on at least one platform. If the Linux and Mac OS X ports are not going to be very good then the implication is that the Windows port has to be the usable one. My post is just a request to not slow down development of the production-quality port to develop non-production-quality ports.

I agree with you in theory, but I have the feeling that ensuring cross platform support would by itself raise the quality of the SDK. It would require throwing many of the old tools away and replacing them with state-of-the-art tools. Like I said before, the SDK suffers from too many years on Windows and avoidance of open source tools.

Of course, resources are limited and maybe I am expecting too much from the tools team and the move to open source.

And there is no doubt that raising the quality of the SDK for Windows is the primary concern.

[paulb]

Originally Posted by teknolog

While on the subject of alternative runtimes, I experimented with WRT and found it very likable. However, having to copy the wgz file to the drive and have it manually install on the emulator seems like a crude way to do it. WRT developers likely have an even lower pain threshold than C++ developers. Here a simple Python script with associated button in Carbide could help a lot.

I agree that the manual management of wgz files is a terrible experience for web developers. In fact, I'd like to prioritize web app deployment higher than web app development. Web developers typically know how to develop their apps - they don't know how to deploy them to a phone.

In the short term, the Symbian technical publications team has agreed to improve the WRT getting started to better describe how to deploy wgz files. In the medium term, we'll improve the tools functionality to make deployment more transparent.

[paulb]

Originally Posted by brian_____

I do agree with you guys that there will be more 3rd-party Symbian software created if Linux is supported. But, I think that software will tend to be Android-quality software (with low consumer appeal) and not iPhone-quality software (which seems to have a lot of consumer appeal). I think there's pretty convincing evidence of a strong correlation between the design & quality of the tools (including the OS) a developer uses and the appeal of his apps in the market.

I'm not sure I agree about Android quality being higher than iPhone. However, I do agree that higher tools quality correlates with higher app quality for at least two reasons :

• High quality tools hide development platform complexities so developers can focus on creating innovate applications
• Good tools lead to fun development which leads to more development which increases the chances for market successful apps

[william_roberts]

The toolchain support for GCC 4.x is not yet available from the Symbian Foundation, and there will need to be further source code changes.

See the Wiki page "Beyond RVCT 2.2" for more details.