[paulb]

There are over a hundred Symbian tools coming from thirty packages. It can be quite confusing for users to find the tools they need. Even experienced tools developers often do not know much about the tools outside of their immediate area.

The ADT is now almost as big as the PDT. Do we need a separate ADT? There are some tools, like Carbide.ui and layout tools that are used by designers as opposed to developers. How should these be packaged.

If you have comments about the requirements I've described or would like to add others, add them to this thread.

Let me know if you'd like to join a Working Group to sort out tools structure, including the packaging and documentation strategy.

[cdavies]

Yes, I wrote an idea the other day that Carbide UI ought to be separated from the rest of the developer tools. Or better yet, the installer ought to allow custom choices for what gets installed. Of course, I realised after I'd written the idea that I'd written it in Google Chrome rather than Firefox, and so I couldn't actually publish it (sigh.)

I think one tools installer would be best, but you could have some different "profiles" within the installer. Application developers might just get the minimum set of IDE and build tools, then various layers on top including the CBR tools and such like for device creators, right up to the totally useless, cluttering your disk up with a quarter of a gigabyte of junk, Carbide UI.

[william_roberts]

I think we should be looking at an "installation manager" rather than an installer. By that, I mean that you should download & install a smallish application which then offers you the choices and does all of the requested downloads and installations on your behalf. The classic "installer" would have all of the available stuff in the one package, so you have to download it all before you get a chance to say that you only want a few small bits.

The manager approach has some other benefits - it would allow the "check for updates?" functionality, and as it's code running on your development host it would give us the chance to improve the downloads by referring to things that you already have installed. You'd still pay the full cost for the first download, but subsequent ones could use techniques like "rsync" or more content-directed information like the old CBR tools.

Finally, it gets rid of the "which kit should I download?" complexity, and lets users with unusual combinations of requirements to get what they want directly. If you have a digital thermometer peripheral for which you want to write a device driver and then a theme which makes uses of temperature information, which kit(s) do you need?

[paulb]

Thanks to Larry Knibb, Ravi Kurupati and Dan Podwall for joining me on the Tools Structure Focus Group. (Note that we're a "focus group" and not a "working group" because of the special SF working group definition)

If you'd still like to join us, contact Larry, Ravi or Dan about the first assignment. (I'll be on vacation for the next week.)

Otherwise, you can expect a status update from us in two or three weeks.

[mikek]

Another merit of William's proposal for an installation manager is that it could be made very cross-platform for Windows/Linux.

[iain]

Originally Posted by mikek

Another merit of William's proposal for an installation manager is that it could be made very cross-platform for Windows/Linux.

There would still be a lot of platform-specific code, as you'd be dealing with the installation systems of the appropriate targets.

Maybe someone should write the front end in Qt though...