Klaus, why do you want to keep this totally separate? Just because? There's no technical reason why this functionality can't be included... after all, Autopano used to have the exact functionality i'm requesting.
You're analogy is week... In fact, i can use it... I use a camera to take photos of stuff around us, but if i want to take photos of really small stuff, i can use a macro lens to do a descent job... But if i want to get really good photos of really, really really small stuff, then i change to a microscope, which is the right tool for that job.
This is a feature request sub-forum... Please don't just come in here to shoot down ideas because you don't like them. We all have different needs/uses for APG/PTP.
There are different approaches to software development. I know, because I have been involved with them in some way.
I do know where this "software separation" idea comes from ... the Unix world. It originated in having programs doing simple things, but combined by a command line shell that could pipe them together. I have one command that lists files one per line. I have another command that counts number of lines. I can run both commands and pipe them together to get a count of files. I don't have to write a separate program to count files.
The philosophy is do one thing, or a related group of things, and do that or them well.
Software to do stitching needs different things done than software to do flash authoring. They should be separate programs because that makes it easier to write, easier to test, and easier to debug.
But ... that said ... separate programs does not necessarily mean the user experience has to deal with the boundaries of functionality. These boundaries should be transparent to what the end user does.
If I want my end result image to be in JPEG format, or PNG format, or TIFF format, that should be a simple project choice, right? Is a "basic Flash file" any harder? JPEG, PNG, and TIFF already have options where I might choose things like quality. Flash certainly does, too.
What I am saying here is, if a known program exists on the computer APP or APG is running on, to convert to certain other formats (or import in other ways, or do filtering of the result, etc), why not have the UI for APP/APG understand this and include that in the options of formats or whatever else could be done.
This is not saying that APP/APG should include the ability to make Flash. What I am saying is that the user interface part that controls APP/APG should help the workflow by knowing how to schedule and execute the creation of Flash output product when the means do to that exists. I assume PTP or other programs that make Flash can make simple basic pan/scroll Flash files for an image. So if PTP is also present, let APP/APG's UI fire up PTP to have that done as part of the batch job?
This is actually a modular software facility idea, and is not at all new. The user interface would learn what functions it can do from description files each of the work components that are installed specify. The end user can have installed those components for what they want to do. APP/APG can be a component (package). PTP can be a component. Other future ideas can be components. The UI component can be included with each one so they can run "stand alone". But it would be the same UI that runs based on the joint set of what components are installed. Workspace icons or execute menus can name the components (APG, PTP, etc) and execution tells the UI executable which component panel(s) to start by default. Or the option can be "Kolor Suite" (does that sound nice?) and it runs in a way that brings up the master panel to start. Any choice can still get any components to work. Then what this thing can do depends on what components are installed.
You could also have dummy components to fall back on when the real component is not present that suggest the component to buy and offers to visit the kolor.com web site to "buy it now".
If I were interested in making Flash output, I'd definitely want to be able to simply specify to do that as part of the whole rendering run. Think of stitching has just one part of an overall rendering run. You still have to format the result product into JPEG or PNG or TIFF or whatever else is available. The rendering ... to a final product ... is more than just doing stitching. It is encoding, too. Basic Flash really isn't much more than that. And given that Flash is a very common presentation format, I'd expect a lot of people to want to do that.
So it is, therefore, my suggestion to explore seamless user experience integration across the entire Kolor product line of software products that have anything related to each other. And this does not break the philosophy of doing separate things and doing them well. This is really just a better user interface that can let the user work more smoothly between the separate software.
If we didn't have this kind of philosophy in other programs, then to do things like printing a document you create, you'd have to first save it, then start the program to print a document (because the first one is focusing on creating it), load the file, and click print. Well, we don't have that for most GUI apps ... there's a print button or menu selection or hot key ... in office tools, web browsers, mail clients, etc.