CodeWarrior's Future

[MW Ron]

Here is part of the outline of the presentation I gave at AdHoc
(formerly MacHack) There still isn't much I can say until mid August

Ron

Why is Metrowerks Still Quiet?

On July 16th Freescale IPO occurred (stock symbol: FSL)

We still cannot disclose any long range plans (forward leading
information) until the Middle of August

We will have a more complete roadmap to present in mid August

Until then, we can only give out minimal information


Lets end some Anxietie Metrowerks isŠ

Planning to have patches for CodeWarrior Development Studio for Mac OS v9

Planning on a future release of CodeWarrior Development Studio for Mac
OS X

Developing a road map for the next release


What About Java?

We have various options to consider it isn't dead

The demand has not been large

It is needed for Academic sales

CodeWarrior Java compilers are too out of date

Native Javac plugins don¹t offer all the features we formerly provided

Let us know if you want Java

write to ***@metrowerks.com


What About 64-bit (G5) Compilers?

We are planning 64 bit compilers and G5 support

Please wait for the roadmap for this information


What About the Future on Mac?

As part of our alignment with Freescale Semiconductor all of Metrowerks
products, services and priorities were re-evaluated

Metrowerks must remain focused and not become stretched but Apple is one
of Freescale¹s customers

Apple developers are our richest asset for quality control ‹ No one
provides the coverage that you provide


What about PowerPlantX

PowerPlantX is, was, and always will be OPEN SOURCE, it is just not
public domain or GPL

There are many options for PowerPlantX

Please provide feedback to ***@metrowerks.com on your preferences


Regarding Competing with XCode

Metrowerks has always competed with so called ³free tools² and won the
marketshare

Competition is good

Our compilers and libraries are superior

Our support is superior

We recognize that our IDE is old


Sorry I can't say more I hope you draw some reassurance from this.

Ron

[Miro Jurisic]

Post by MW Ron
PowerPlantX is, was, and always will be OPEN SOURCE, it is just not
public domain or GPL

So you don't mind if I publish all of PPX on my web page? Or have you not read
the Open Source Definition at <http://www.opensource.org/docs/definition.php>?

meeroh

[MW Ron]

Post by Miro Jurisic

Post by MW Ron
PowerPlantX is, was, and always will be OPEN SOURCE, it is just not
public domain or GPL

So you don't mind if I publish all of PPX on my web page?

That would clearly be a violation of your license. Please it is silly
sophomoric talk like this that always leads to restrictions being placed
on licenses to the detriment of all. We used to have several books
included with CodeWarrior until some fools started saying they thought
they had the right to print them at kinkos... So don't joke on things
like this, it just makes things go sour...

Post by Miro Jurisic
Or have you not read
the Open Source Definition at <http://www.opensource.org/docs/definition.php>?

I'm saying you have the source for PowerPlant it is not a closed source
library. I am trying to reassure people that are currently using it
that they could continue to use it and improve it. I was not speaking
of "open sourced SOFTWARE" as defined in the site listed above.

However we are considering many options.

Ron

[Miro Jurisic]

Post by MW Ron

Post by Miro Jurisic

Post by MW Ron
PowerPlantX is, was, and always will be OPEN SOURCE, it is just not
public domain or GPL

So you don't mind if I publish all of PPX on my web page?

That would clearly be a violation of your license. Please it is silly
sophomoric talk like this that always leads to restrictions being placed on
licenses to the detriment of all. We used to have several books included
with CodeWarrior until some fools started saying they thought they had the
right to print them at kinkos... So don't joke on things like this, it just
makes things go sour...

I am not joking. You said PPX is open source. You are wrong, and I am calling
you on it, because I think it's a cheap marketing trick. You don't get to make
up what "open source" means, when there is a specific definition that has been
published by the OSI and adopted by the industry.

The OSI definition literally begins with "Open source doesn't just mean access
to the source code", and all that MW is giving us with PPX (and all we got with
PP) is access to source code. Yes, that is significant. No, I don't want you to
take it away. I do, however, want you to learn what "open source" means, and use
the term properly, because it does neither MW nor the MW customers any good if
you claim that PPX is open source when it's not.

meeroh

[patrox]

Post by Miro Jurisic
The OSI definition literally begins with "Open source doesn't just mean access
to the source code", and all that MW is giving us with PPX (and all we got with
PP) is access to source code. Yes, that is significant. No, I don't want you to
take it away. I do, however, want you to learn what "open source" means, and use
the term properly, because it does neither MW nor the MW customers any good if
you claim that PPX is open source when it's not.

Is that called "closed source" ?
Actually i'm facing a similar dilemma. I want to make my source available
but not open Source. ( i don't like the openSource idea nor licensing for
various reasons )
What are the licenses available for "closed source" products ?

For now i am just selling my source at a very high price ( people have the
choice of buying a .lib or the source ) , but that's kind of problematic for
people who want to upgrade or modidy the product to suit their needs. ( i
have no objection against that, i just don't want it to go wild , nor for
people to feel like it's free because it's not )

thank you
pat.

[z]

Post by patrox
Is that called "closed source" ?
Actually i'm facing a similar dilemma. I want to make my source available
but not open Source. ( i don't like the openSource idea nor licensing for
various reasons )
What are the licenses available for "closed source" products ?

MySQL is making big money with a dual license scheme, see
<http://www.mysql.com/products/licensing/index.html>. They have
acknowledged that there are really two parties outside (a) they get
applauded by those who have expert knowledge, mostly GPL/FSF
enthousiasts (b) they get applauded by those whose do have money for
support and commercial licenses.

Regards,

Adriaan van Os

[Glen Fisher]

MW Ron <***@metrowerks.com> wrote:
| PowerPlantX is, was, and always will be OPEN SOURCE, it is just not
| public domain or GPL

Miro Jurisic wrote:
| So you don't mind if I publish all of PPX on my web page?
| Or have you not read the Open Source Definition at
| <http://www.opensource.org/docs/definition.php>?

Do recall: OpenSource.org does *not* have the authority--or power--to
define unilaterally what the phrase "open source" means. Their "Open
Source Definition" states what *they* mean when they use it, not
necessarily what *other people* mean.

As the very same web page also says:
| The OSI Certified mark is OSI's way of certifying that the license
| under which the software is distributed conforms to the OSD; the
| generic term "Open Source" cannot provide that assurance

In other words, even OpenSource.org, the very source of the Open
Source Definition you cite, doesn't claim that something called "open
source" necessarily adheres to the Open Source Definition. Like it or
not, the phrase is a generic, not a trademark; any discussion of "open
source" has to recognize that. Unless someone says "open source as
defined by OpenSource.org", you have no assurance that the
OpenSource.org definition is the one intended.

Glen Fisher

[Brad Oliver]

Post by Glen Fisher
Unless someone says "open source as
defined by OpenSource.org", you have no assurance that the
OpenSource.org definition is the one intended.

I have no idea what Metrowerks' definition of "open source" means at
all. The logical conclusion one can draw, without such a clarification,
is the common use of the term, which means the OSD. if it's not "open
source" in the same way as stipulated in the OSD, I think it only fair
for Metrowerks to expound upon the differences so that people who work
with OSD code day in and day out know what they're getting into.

So to get back to the point - what good does it do me for PPX to be
labelled by Metrowkers as "open source"? How does this change anything?
What about MSL? It's "open source" in the same way as PPX.

[Peter Lui]

Post by MW Ron
As part of our alignment with Freescale Semiconductor all of Metrowerks
products, services and priorities were re-evaluated
Metrowerks must remain focused and not become stretched but Apple is
one of Freescale¹s customers

I'm not sure what you mean. Why is it a stretch to support one of
Freescale's customers?

Post by MW Ron
Apple developers are our richest asset for quality control ‹ No one
provides the coverage that you provide

The Metrowerks website says that "MW employs 550 people in more than 15
offices in 13 countries". I'm starting to wonder exactly how many of
these people are focused on Mac because it appears that despite being
the richest asset, MW doesn't seem to be focused on Mac.

[MW Ron]

Post by Peter Lui

Post by MW Ron
As part of our alignment with Freescale Semiconductor all of Metrowerks
products, services and priorities were re-evaluated
Metrowerks must remain focused and not become stretched but Apple is
one of Freescale¹s customers

I'm not sure what you mean. Why is it a stretch to support one of
Freescale's customers?

I'm saying this is a good thing for Mac developers

Post by Peter Lui

Post by MW Ron
Apple developers are our richest asset for quality control ‹ No one
provides the coverage that you provide

The Metrowerks website says that "MW employs 550 people in more than 15
offices in 13 countries". I'm starting to wonder exactly how many of
these people are focused on Mac because it appears that despite being
the richest asset, MW doesn't seem to be focused on Mac.

CodeWarrior Mac is an important product but it is a small product line.
I would like some constructive feedback and questions, not allegations.

Ron

[Brad Oliver]

Post by MW Ron
CodeWarrior Mac is an important product but it is a small product line.
I would like some constructive feedback and questions, not allegations.

Here you go.

- G5 support.

- A decent threaded compiler. Distributed compiles would be even better.

_ Tighter integration with Shark and MallocDebug. Go one step further
and try and integrate support for these tools in the IDE as part of the
debug process. Right now, building a Mach-O C++ app that uses MSL means
you can't use MallocDebug (the application not libMallocDebug.a) because
of duplicate symbol conflicts. Fix this.

- An IDE that works well in OSX and has a comparable feature set to
other first-class IDEs. Looking at code completion and other niceties,
Metrowerks' IDE no longer stands up as "best of breed". The current OSX
IDE looks not much different from when it first made it's appearance on
OSX, and that works to its detriment. There are many minor cosmetic
glitches throughout that make it seem slapped together hastily.

- Decent integration with various source control tools: a first-class
Perforce plugin, a first-class CVS plugin, a first-class Subversion
plug-in. None of the existing Mac IDE plugins are integrated well, and
only perform a subset of what is needed for day-to-day tasks. If I need
to drop out of the IDE to perform other SCM tasks anyway, IDE
integration doesn't help me all that much.

- Action, not promises. Saying that you're investigating these options
or have added them to a feature list or bug reporter does me no good,
and frankly doesn't give me any confidence that these statements are
anything more than marketing points designed to desperately keep your
customers from fleeing the platform.

- Stop playing catch-up with Xcode and meet or surpass it for
_everything_ it currently does better than CodeWarrior. Then stay ahead.
Right now, marketing-speak aside, Metrowerks is in the catch-up role for
many things.

In a nutshell, either commit to the Mac 100% or not at all. I don't want
to have to use Xcode for the areas where Metrowerks is deficient and
vice-versa. If I need to use Xcode for one thing, eventually I'll start
using it for more. When I do that, you've lost me as a customer.

[Chris Cox]

Post by Brad Oliver
_ Tighter integration with Shark and MallocDebug. Go one step further
and try and integrate support for these tools in the IDE as part of the
debug process. Right now, building a Mach-O C++ app that uses MSL means
you can't use MallocDebug (the application not libMallocDebug.a) because
of duplicate symbol conflicts. Fix this.

How can Metrowerks change Apple's code?

Post by Brad Oliver
- An IDE that works well in OSX and has a comparable feature set to
other first-class IDEs. Looking at code completion and other niceties,
Metrowerks' IDE no longer stands up as "best of breed". The current OSX
IDE looks not much different from when it first made it's appearance on
OSX, and that works to its detriment. There are many minor cosmetic
glitches throughout that make it seem slapped together hastily.
- Decent integration with various source control tools: a first-class
Perforce plugin

... already exists, from Perforce (although it needs to be updated now).


Chris

[Brad Oliver]

Post by Chris Cox

Post by Brad Oliver
_ Tighter integration with Shark and MallocDebug. Go one step further
and try and integrate support for these tools in the IDE as part of the
debug process. Right now, building a Mach-O C++ app that uses MSL means
you can't use MallocDebug (the application not libMallocDebug.a) because
of duplicate symbol conflicts. Fix this.

How can Metrowerks change Apple's code?

There are several ways Metrowerks can solve this problem:

1. Work with Apple so that the MallocDebug GUI app doesn't freak out
when it tries to link to System.framework and the target app has
duplicate symbols. Also work with Apple so that Shark can easily find
recognize the xSYM files from CodeWarrior 9. (If you're implying that
Metrowerks can't work with Apple to solve the problem at this level,
then I would argue that their relationship with Apple has deteriorated
to the point that Metrowerks can no longer serve Mac developers
properly. I don't believe this to currently be the case.)

2. Provide a means of building apps in CodeWarrior such that we can
build against the BSD standard libraries and use the BSD C++ runtime.

3. Provide their own GUI variant of MallocDebug in the Metrowerks
debugger. The BSD malloc library has a bunch of hooks in it right now to
support this level of detail - look in include/malloc/malloc.h.

4. Write their own Shark-like tool. Make it better than Apple's.

Post by Chris Cox

Post by Brad Oliver
- Decent integration with various source control tools: a first-class
Perforce plugin

... already exists, from Perforce (although it needs to be updated now).

By "first-class", I meant a plugin that recognizes long file names at a
minimum. It'd be nice if it also looked like it belonged on the Mac, but
hey, I'm a dreamer. ;-)

[Chris Cox]

Post by Brad Oliver

Post by Chris Cox

Post by Brad Oliver
_ Tighter integration with Shark and MallocDebug. Go one step further
and try and integrate support for these tools in the IDE as part of the
debug process. Right now, building a Mach-O C++ app that uses MSL means
you can't use MallocDebug (the application not libMallocDebug.a) because
of duplicate symbol conflicts. Fix this.

How can Metrowerks change Apple's code?

1. Work with Apple so that the MallocDebug GUI app doesn't freak out
when it tries to link to System.framework and the target app has
duplicate symbols. Also work with Apple so that Shark can easily find
recognize the xSYM files from CodeWarrior 9. (If you're implying that
Metrowerks can't work with Apple to solve the problem at this level,
then I would argue that their relationship with Apple has deteriorated
to the point that Metrowerks can no longer serve Mac developers
properly. I don't believe this to currently be the case.)

Metrowerks does work with Apple on this level.
And Shark does read quite a bit of xSYM (note the console messages when
using Shark on a CW compiled binary).

Post by Brad Oliver
2. Provide a means of building apps in CodeWarrior such that we can
build against the BSD standard libraries and use the BSD C++ runtime.
3. Provide their own GUI variant of MallocDebug in the Metrowerks
debugger. The BSD malloc library has a bunch of hooks in it right now to
support this level of detail - look in include/malloc/malloc.h.
4. Write their own Shark-like tool. Make it better than Apple's.

Why waste the effort?
Shark is already damn good and it's free.
(most other profiling tools are painful to use after working with Shark)

Post by Brad Oliver

Post by Chris Cox

Post by Brad Oliver
- Decent integration with various source control tools: a first-class
Perforce plugin

... already exists, from Perforce (although it needs to be updated now).

By "first-class", I meant a plugin that recognizes long file names at a
minimum. It'd be nice if it also looked like it belonged on the Mac, but
hey, I'm a dreamer. ;-)

Yes, Perforce needs to fix a few things in their plugin.
Have you loggged your requests with them?

Chris

[Brad Oliver]

Post by Chris Cox

Post by Brad Oliver

Post by Chris Cox
How can Metrowerks change Apple's code?

(If you're implying that
Metrowerks can't work with Apple to solve the problem at this level,
then I would argue that their relationship with Apple has deteriorated
to the point that Metrowerks can no longer serve Mac developers
properly. I don't believe this to currently be the case.)

Metrowerks does work with Apple on this level.

Then that is the answer to your question. ;-)

Post by Chris Cox
And Shark does read quite a bit of xSYM (note the console messages when
using Shark on a CW compiled binary).

I can supply an xSYM file for an app package created with CW 9 and Shark
will blissfully ignore it. Shark also seems to have issues finding and
loading xSYM files for shared libraries inside my app package that I
load at runtime. Perhaps there's some voodoo involved to get it to work
reliably. Maybe my apps are too funky. I don't know. My point is that it
should "just work", and currently does not.

Post by Chris Cox

Post by Brad Oliver
4. Write their own Shark-like tool. Make it better than Apple's.

Why waste the effort?
Shark is already damn good and it's free.
(most other profiling tools are painful to use after working with Shark)

If I can't get Shark to work reliably with CodeWarrior, and no one at
Apple or Metrowerks wants to expend the effort to resolve this, then
where does that leave me? Since Shark is, as you say, "damn good", it is
another force pushing me away from Metrowerks and towards Xcode.

Above all else, I need development tools that work with a minimum of
hassle. If the excuse given is that this is Apple's fault or that
somehow Metrowerks can't help it, I flatly reject that. It may not be
easy to solve, and it may involve doing some heavy lifting, but that is
not my concern as someone comparing CodeWarrior to Xcode.

Post by Chris Cox
Yes, Perforce needs to fix a few things in their plugin.
Have you loggged your requests with them?

Yes, and it's done no good as you can plainly see from the staggering
lack of updates to their CodeWarrior plugin.

Apple has taken the bull by the horns and written Perforce support for
Xcode, something I'd gladly *pay* Metrowerks to do for their product.
The P4 api is public and as such writing P4 plugins is not a task
limited exclusively to Perforce employees.

[Mikl?s Fazekas]

Post by Brad Oliver

Post by Chris Cox

Post by Brad Oliver
4. Write their own Shark-like tool. Make it better than Apple's.

Why waste the effort?
Shark is already damn good and it's free.
(most other profiling tools are painful to use after working with Shark)

If I can't get Shark to work reliably with CodeWarrior, and no one at
Apple or Metrowerks wants to expend the effort to resolve this, then
where does that leave me? Since Shark is, as you say, "damn good", it is
another force pushing me away from Metrowerks and towards Xcode.

For us Shark is working great with CW compiled binaries. (We mostly
use CFM altough).

If you have Shark & CW related issues, you should use the
chud-tools-***@group.apple.com or file bugs with radar.

Regards,
Miklos

[Steven Fisher]

Post by Brad Oliver
Apple has taken the bull by the horns and written Perforce support for
Xcode, something I'd gladly *pay* Metrowerks to do for their product.
The P4 api is public and as such writing P4 plugins is not a task
limited exclusively to Perforce employees.

What's wrong with the CW plugin that Perforce offers?

I have to admit I don't use it. My project that uses Perforce is locked
into CW Pro 4. So this is an honest question. :)

[Brad Oliver]

Post by Steven Fisher
What's wrong with the CW plugin that Perforce offers?

The largest issue is that it doesn't support long filenames. A minor
irritant is that if something gets wonky in your settings, the IDE will
repeatedly crash on launch and you have to perform some kind of voodoo
to make it stop (I could never determine the exact solution).

[Chris Cox]

Post by Brad Oliver

Post by Steven Fisher
What's wrong with the CW plugin that Perforce offers?

The largest issue is that it doesn't support long filenames.

Well, there are third party Perforce plugins, and Perforce is
constantly updating their code -- if you report this as a bug, they'll
fix it.

Post by Brad Oliver
A minor

Post by Steven Fisher
irritant is that if something gets wonky in your settings, the IDE will
repeatedly crash on launch and you have to perform some kind of voodoo
to make it stop (I could never determine the exact solution).

And I've never seen the IDE crash on launch (crash when closing several
windows quickly - yes.)

Chris

[Brad Oliver]

Post by Chris Cox

Post by Brad Oliver

Post by Steven Fisher
What's wrong with the CW plugin that Perforce offers?

The largest issue is that it doesn't support long filenames.

Well, there are third party Perforce plugins

Perforce plugins - plural? For the CodeWarrior IDE? Where can I find
them?

Post by Chris Cox
Perforce is
constantly updating their code -- if you report this as a bug, they'll
fix it.

Didn't we cover this ground a week ago? I e-mailed Perforce about it a
little over a year and a half with no fix in sight. The last update they
did to the CW IDE plugin was in 2002.

[Chris Cox]

Post by Brad Oliver

Post by Chris Cox

Post by Brad Oliver

Post by Chris Cox
How can Metrowerks change Apple's code?

(If you're implying that
Metrowerks can't work with Apple to solve the problem at this level,
then I would argue that their relationship with Apple has deteriorated
to the point that Metrowerks can no longer serve Mac developers
properly. I don't believe this to currently be the case.)

Metrowerks does work with Apple on this level.

Then that is the answer to your question. ;-)

Post by Chris Cox
And Shark does read quite a bit of xSYM (note the console messages when
using Shark on a CW compiled binary).

I can supply an xSYM file for an app package created with CW 9 and Shark
will blissfully ignore it.

But it seems to find the information for my applications (and plugins).
Have you logged this as a bug against Shark so they'll take a look at
it?

Post by Brad Oliver
Shark also seems to have issues finding and
loading xSYM files for shared libraries inside my app package that I
load at runtime. Perhaps there's some voodoo involved to get it to work
reliably. Maybe my apps are too funky. I don't know. My point is that it
should "just work", and currently does not.

True. And it would be likely to work better if someone in Apple
management didn't have something against PEF and Metrowerks.

But if you don't tell the Shark/CHUD guys about the bugs, they can't
fix them. (they're pretty responsive to bug reports and feature
suggestions, and I'm sure they'd like to receive reports from someone
other than myself once in a while ;-)

Post by Brad Oliver

Post by Chris Cox

Post by Brad Oliver
4. Write their own Shark-like tool. Make it better than Apple's.

Why waste the effort?
Shark is already damn good and it's free.
(most other profiling tools are painful to use after working with Shark)

If I can't get Shark to work reliably with CodeWarrior, and no one at
Apple or Metrowerks wants to expend the effort to resolve this, then
where does that leave me? Since Shark is, as you say, "damn good", it is
another force pushing me away from Metrowerks and towards Xcode.

Why?
You can get function names in Shark without a problem - the only thing
that doesn't always work perfectly with Metrowerks is source listing
and opening the source file in the IDE.

Post by Brad Oliver
Above all else, I need development tools that work with a minimum of
hassle. If the excuse given is that this is Apple's fault or that
somehow Metrowerks can't help it, I flatly reject that.

I'm sorry you reject reality. But I've heard that there are many
medications available today to help with that. =;->

Chris

[Brad Oliver]

Post by Chris Cox

Post by Brad Oliver
I can supply an xSYM file for an app package created with CW 9 and Shark
will blissfully ignore it.

But it seems to find the information for my applications (and plugins).

I keep the xSYM file next to the executable in the package (where
CodeWarrior leaves it), likewise for shared libraries that wind up in
the package. I'm also building Mach-O apps. Do you do anything different?

Post by Chris Cox
Why?
You can get function names in Shark without a problem - the only thing
that doesn't always work perfectly with Metrowerks is source listing
and opening the source file in the IDE.

The xSYM files are generally only needed for the source listing (the
function names are usually embedded in the app), so are you saying that
it doesn't work for you? That is the heart of my complaint - that xSYM
files supplied by CW 9 aren't being used by Shark. I did a quick check
just now, and I see no indication in the OSX Console that Shark is using
the xSYM files at all.

Post by Chris Cox

Post by Brad Oliver
Above all else, I need development tools that work with a minimum of
hassle. If the excuse given is that this is Apple's fault or that
somehow Metrowerks can't help it, I flatly reject that.

I'm sorry you reject reality.

I don't reject reality, just laziness and excuses without merit. I'm
willing to stand corrected if you can provide me an example where
Metrowerks is unable to solve these problems with just a little hard
work.

[Thomas Engelmeier]

Post by Brad Oliver
I keep the xSYM file next to the executable in the package (where
CodeWarrior leaves it), likewise for shared libraries that wind up in
the package. I'm also building Mach-O apps. Do you do anything different?

That brings me to an forgotten feature request for CW DS 10:

For bundles, create an optional default xSym location _outside_ of the
bundle so for delivering test releases it is not necessary all the time
to strip the xSym file in order to obtain something mailable... [I donŒt
care for many internal test releases if they are unoptimized debug
builds, but I do have to care it its 400k compressed or 2.5MB..]

Regards,
Tom_E

[Chris Cox]

Post by Brad Oliver

Post by Chris Cox

Post by Brad Oliver
I can supply an xSYM file for an app package created with CW 9 and Shark
will blissfully ignore it.

But it seems to find the information for my applications (and plugins).

I keep the xSYM file next to the executable in the package (where
CodeWarrior leaves it), likewise for shared libraries that wind up in
the package. I'm also building Mach-O apps. Do you do anything different?

No, I leave it all where it was built.

Post by Brad Oliver

Post by Chris Cox
Why?
You can get function names in Shark without a problem - the only thing
that doesn't always work perfectly with Metrowerks is source listing
and opening the source file in the IDE.

The xSYM files are generally only needed for the source listing (the
function names are usually embedded in the app), so are you saying that
it doesn't work for you?

All of it works for me - but doesn't appear to work for you and some
others.

Post by Brad Oliver
That is the heart of my complaint - that xSYM
files supplied by CW 9 aren't being used by Shark. I did a quick check
just now, and I see no indication in the OSX Console that Shark is using
the xSYM files at all.

Ok - submit that as a bug against shark.

Post by Brad Oliver

Post by Chris Cox

Post by Brad Oliver
Above all else, I need development tools that work with a minimum of
hassle. If the excuse given is that this is Apple's fault or that
somehow Metrowerks can't help it, I flatly reject that.

I'm sorry you reject reality.

I don't reject reality, just laziness and excuses without merit. I'm
willing to stand corrected if you can provide me an example where
Metrowerks is unable to solve these problems with just a little hard
work.

How can Metrowerks solve problems that are almost certainly in Apple's
code?

Chris

[Brad Oliver]

Post by Chris Cox
How can Metrowerks solve problems that are almost certainly in Apple's
code?

I covered this in detail much earlier in this thread (and now closing in
on 3 weeks ago), listing solutions and workarounds that Metrowerks could
apply in the event they couldn't directly fix Apple's code for all of
the cases I went into specifics about.

You replied directly to that message, so I don't see much benefit to
repeating myself unless you need a clarification about one of solutions
I proferred in response to your identical question back then.

[Adriaan van Os]

Post by Chris Cox

Post by Brad Oliver
I can supply an xSYM file for an app package created with CW 9 and Shark
will blissfully ignore it.

<snip>

Post by Chris Cox
All of it works for me - but doesn't appear to work for you and some
others.

CW 9 writes xSYM files in a newer format (versions 3.3.3R0). Could this
be the cause - Shark not reading the newer xSYM format ? Have you tried
with CW 8 ?

Regards,

Adriaan van Os

[Brad Oliver]

Post by Adriaan van Os

Post by Chris Cox
All of it works for me - but doesn't appear to work for you and some
others.

CW 9 writes xSYM files in a newer format (versions 3.3.3R0). Could this
be the cause - Shark not reading the newer xSYM format ? Have you tried
with CW 8 ?

My more recent apps don't have CW Pro 8 project files, so I can't easily
test that, but a spot sampling shows that some of my older apps do work
fine with Pro 8. Still, I'm not sure what's going on here, as the other
poster reports that it works for him with CW 9. I see that CHUD 4.0b6
was just released a week ago, so I'll give that a shot and see if it
helps.

[Scott Ribe]

Post by Brad Oliver
My more recent apps don't have CW Pro 8 project files, so I can't easily
test that, but a spot sampling shows that some of my older apps do work
fine with Pro 8. Still, I'm not sure what's going on here, as the other
poster reports that it works for him with CW 9. I see that CHUD 4.0b6
was just released a week ago, so I'll give that a shot and see if it
helps.

I did recently discover that Shark won't parse the xSYM file unless there's
at least line #s output in STABS info. I had turned off all STABS generation
for my release build, and had to put that minimum back in before Shark would
show me source code. I should probably file a bug against Apple's
documentation--in the meantime perhaps MW should put up a brief note on this
so that at least googling "CodeWarrior Shark" will provide an answer.

[MW Ron]

Post by Scott Ribe

Post by Brad Oliver
My more recent apps don't have CW Pro 8 project files, so I can't easily
test that, but a spot sampling shows that some of my older apps do work
fine with Pro 8. Still, I'm not sure what's going on here, as the other
poster reports that it works for him with CW 9. I see that CHUD 4.0b6
was just released a week ago, so I'll give that a shot and see if it
helps.

I did recently discover that Shark won't parse the xSYM file unless there's
at least line #s output in STABS info. I had turned off all STABS generation
for my release build, and had to put that minimum back in before Shark would
show me source code. I should probably file a bug against Apple's
documentation--in the meantime perhaps MW should put up a brief note on this
so that at least googling "CodeWarrior Shark" will provide an answer.

I'll add this as a suggestion.

Ron

[Peter Lui]

Post by MW Ron
CodeWarrior Mac is an important product but it is a small product line.
I would like some constructive feedback and questions, not allegations.

MW has the list of features that developers want to see. They have been
talked about for the last 2 years in this newsgroup and written out on
endless marketing surveys at trade shows.

MW needs to stop dragging it's feet and get on the Mac OS X train which
left the station a long time ago.

Any forthcoming release short of a spectacular turn around will be a
sore disappointment. I look forward to August and your pending
announcement.

Post by MW Ron
Our compilers and libraries are superior

Yes, they are fast but hardware gets faster and with every gcc release
the gap keeps closing. They are not SO great that they are keeping
developers from switching to XCode.

Post by MW Ron
Our support is superior

Please elaborate.

Post by MW Ron
We recognize that our IDE is old

No, all of the tools in the box that made CW so great have stagnated.

[Jonathan Hoyle]

Post by MW Ron
I would like some constructive feedback and questions, not allegations.

1. Many of the new features that Apple has added to ProjectBuilder to
create "XCode" are features that are not specific to their compiler
itself, so you could add these to CodeWarrior. Some of these features
are less than what their true reality, such as "Zero-Link", which is
more annoying than anything else to me, since it merely hides link
errors. Still, some people seem to like it, and there are many other
very useful features they do have, such as distributed building which
anyone would like. I know it's playing catchup, but it's a good
start.

2. Better integration of PowerPlant X (or its successor) with
Interface Builder .nib files. It ought to be a killer framework,
making Cocoa developers stand up and say, "Boy that's cool...I thought
my Objective C coding was the fastest way to program, but PowerPlant
wraps everything in C++ objects so transparently, I'm going to
switch!"

3. Java: Get in or Get out. Hey, I've always liked the fact you guys
supported Java, and what little Java programming I did do a few years
ago was done in CodeWarrior. But don't leave people hanging not
knowing which way you're going. I greatly respected Metrowerks at
WWDC 2000 when they announced well in advance that they were going to
end development of Pascal and 68K. They were honest and upfront, and
prepared developers for what was coming. (Contrast this with
Symantec's pocket-vetoing Think Pascal and later Symantec C++, all the
time lying about how they were going to continue to support it.)
Metrowerks went above and beyond the call of duty with one final
Carbonized Pascal compiler before dropping it. It was with style and
class, and even the most pissed-off pascal programmer at least
appreciated the heads up. Java deserves no less.

4. I know that you had said in a previous thread that no
cross-platform framework is in the works, but this is an appeal to
reconsider. It is one of the more difficult aspects about being a Mac
developer that managers can't see spending the same amount of
development money they do on the Windows platform just to get 1/10th
of an increase. If we had a single framework, similar perhaps to Qt
by Trolltech (preferably something easier), then we can tell our
bosses that with one development cost, we can support both platforms.
It would be killer to do.

5. Speaking of Qt, work with Trolltech to get the compiler issues
settled. Right now, if I want to use Qt, we have to switch to Xcode
because Trolltech says that CodeWarrior's compiler is incompatible.
Of course Metrowerks thinks that the Qt source is faulty. Look, I
don't know who's fault it is, their's or your's, but this ought to be
worked out. If we make the switch to Qt, we'll be forced to drop
CodeWarrior and go to a dual compiler solution of XCode/Visual C++.
Yuch.

Hope that helps.

Jonathan Hoyle
Gene Codes Corporation

[Paul]

...............
4. I know that you had said in a previous thread that no
cross-platform framework is in the works, but this is an appeal to
reconsider. It is one of the more difficult aspects about being a Mac
developer that managers can't see spending the same amount of
development money they do on the Windows platform just to get 1/10th
of an increase. If we had a single framework, similar perhaps to Qt
by Trolltech (preferably something easier), then we can tell our
bosses that with one development cost, we can support both platforms.
It would be killer to do.
...............

A crossplatform framework is the single biggest thing I'd like to see, and
the only thing I can think of that would really put MW on the general map.
There's lots of stuff (help integration, code completion) that could be
better but I can live without it (I'm stuck w/ VS.NET at work which does
both much better than CW but sucks moose on performance, stability, and
usability.) Right now there just isn't anything I'm comfortable with on a
commercial project. Most of the good ones support Mac as an afterthought
(e.g., wxWindows, Qt.)

With Greg Dow gone and PowerPlant X not really mature enough to be practical
yet, MW ought to consider buying out CPLAT (Mac, Windows, Linux;
www.ksoft.net), which was always PowerPlant-like and is now in the process
of being rewritten a la PowerPlant X. It's one of the very few that treats
Mac's as first class citizens.

CPLAT is a one man show since '98, which testifies to its basic quality and
the ability of its designer. THE problem with it is that one man apparently
can't do everything: its UI designer (more advanced than Constructor) is
still unusably buggy, for example. With more support, particularly in the
area of QA, it could take off.

Second brilliant idea: "adopt" GNUStep. This would mean enabling
Objective-C++ for non-Mac's (how hard could that be? They already have a
runtime) and helping develop and support the framework on Windows. I
actually like Cocoa, but it's a total non-starter around here for obvious
reasons. I could make a case for it if I wasn't stuck w/ Mac only code and
had a quality __Objective-C++__ compiler available (pure Objective-C isn't
much fun; combined w/ C++ features where they make sense, it's killer.)


Paul

[Thomas Engelmeier]

Post by Paul
reasons. I could make a case for it if I wasn't stuck w/ Mac only code and
had a quality __Objective-C++__ compiler available (pure Objective-C isn't
much fun; combined w/ C++ features where they make sense, it's killer.)

As long as Objective-C TRY - CATCH blocks and C++ exceptions do not mix
correctly, probably an quality killer.

Regards,
Tom_E

[Thomas Engelmeier]

Post by Jonathan Hoyle
Some of these features
are less than what their true reality, such as "Zero-Link",

Well, that is the implementation, not the concept..

FTR: changing a line of code during execution of an application would be
a huge timesaver if the setup for debugging is pretty complex...

[X-Platform framework]

Post by Jonathan Hoyle
It would be killer to do.

I do not think so, as it would be a least-common-denominator framework
like e.g. old MFC versions, Swing, SWT etc..

regards,
Tom_E

[Wade Williams]

Post by MW Ron
I would like some constructive feedback and questions, not allegations.

Some for starters.

1) 100% complete integration with all of Apple's tools even when using
MSL. Last time I checked, Shark worked, but MallocDebug did not.

Apple's tools are *far* too useful for me to give up their
functionality. If I have to choose between MSL and Apple's tools, then
I'll move to XCode in a heartbeat, despite its warts.

(Yes, I realize that MallocDebug will also work if you build a BSD
project, but if I'm going to do that, I might as well use XCode)

I also realize this will take cooperation from Apple - but I believe it
can be done if MW is committed enough to it.

2) More debugger functionality - specifically, I'd to be able to set
forward breakpoints and access the gdb console.

3) An IDE which does not create duplicate files in the project when
cloning a project.

4) A text-based project file format

5) Completion that works.

6) A documentation display system that isn't horrific.

7) Complete control over building IDE projects from the command-line
without Applescript. You're almost there with cmdide - it just needs a
little more functionality. (Yes, I've submitted a bug)

Wade

[MW Ron]

Post by Wade Williams

Post by MW Ron
I would like some constructive feedback and questions, not allegations.

Some for starters.
1) 100% complete integration with all of Apple's tools even when using
MSL. Last time I checked, Shark worked, but MallocDebug did not.

I don't know why, it should but I have heard it doesn't. We use the
same basic malloc as Apple.

Post by Wade Williams
2) More debugger functionality - specifically, I'd to be able to set
forward breakpoints and access the gdb console.

Good idea, I'll add this.

Post by Wade Williams
3) An IDE which does not create duplicate files in the project when
cloning a project.

Can you expand on this a bit.

Post by Wade Williams
4) A text-based project file format

On the drawing boards

Post by Wade Williams
5) Completion that works.

Please submit bug reports. we need to know when it doesn't work.

Post by Wade Williams
6) A documentation display system that isn't horrific.

I tend to agree with you on this, the problem is trying to have one
cross compatible that may never be possible.

Post by Wade Williams
7) Complete control over building IDE projects from the command-line
without Applescript. You're almost there with cmdide - it just needs a
little more functionality. (Yes, I've submitted a bug)

yes, that is planned.

Ron

[Brad Oliver]

Post by MW Ron

Post by Wade Williams
1) 100% complete integration with all of Apple's tools even when using
MSL. Last time I checked, Shark worked, but MallocDebug did not.

I don't know why, it should but I have heard it doesn't. We use the
same basic malloc as Apple.

MSL causes the MallocDebug GUI app grief because of symbol conflicts
between MSL and libSystem. It looks like when it tries to link it's own
libSystem into the app, the symbol clashes at runtime cause dyld to
fail, since the symbols are in a different "fragment" (if that's the
correct Mach-O term).

That's my speculation at least. Someone correct me if I'm wrong.

[Adriaan van Os]

Post by MW Ron
I would like some constructive feedback and questions, not allegations.

My wishes:

1. A "go forward" and "go backward" in the editor. I mean, it should
remember where you were in a source file. This is in Netscape, Safari,
Acrobat Reader, etcetera.

2. A feature that would take CW's engineers five minutes to implement: a
shift-left and shift-right with the shift-key pressed to move one
space rather than one tab to the left or right. This is in the MPW
editor (and I have missed it ever since).

Regards,

Adriaan van Os

[Miro Jurisic]

Post by Adriaan van Os
1. A "go forward" and "go backward" in the editor. I mean, it should
remember where you were in a source file. This is in Netscape, Safari,
Acrobat Reader, etcetera.

You mean like "Forward" and "Backward" in the Find menu?

meeroh

[Stephen Chu]

Post by Miro Jurisic

Post by Adriaan van Os
1. A "go forward" and "go backward" in the editor. I mean, it should
remember where you were in a source file. This is in Netscape, Safari,
Acrobat Reader, etcetera.

You mean like "Forward" and "Backward" in the Find menu?

Which never take me to where I want it to. Never understand how exactly
it works.

[Adriaan van Os]

Post by Stephen Chu

Post by Miro Jurisic

Post by Adriaan van Os
1. A "go forward" and "go backward" in the editor. I mean, it should
remember where you were in a source file. This is in Netscape, Safari,
Acrobat Reader, etcetera.

You mean like "Forward" and "Backward" in the Find menu?

Which never take me to where I want it to. Never understand how exactly
it works.

As far as I know, in CW the "forward" and "backward" are class browser
commands (so, they are not the feature that I suggested).

Regards,

Adriaan van Os

[Thomas Engelmeier]

Post by Miro Jurisic

Post by Adriaan van Os
1. A "go forward" and "go backward" in the editor. I mean, it should
remember where you were in a source file. This is in Netscape, Safari,
Acrobat Reader, etcetera.

You mean like "Forward" and "Backward" in the Find menu?

Probably no.

you edit foo::bar, compile, an header is missing, you insert it ,
compile it, fix an glitch in foo::buggy, compile, run, and now want to
continue work on foo::bar. Currently you need either set an marker or go
back manual to foo:bar...

Regards,
Tom_E

[Brad Oliver]

Post by MW Ron
I would like some constructive feedback and questions, not allegations.

I have a few more wishes.

1. Fix the debugger's log window. Right now we have two choices - a
SIOUX output window that is inexplicably slow as molasses if text starts
streaming out to it in any significant volume, or a terminal window
which is flaky and unreliable.

I prefer to route output to the terminal window just because it's orders
of magnitude faster than the SIOUX window, but sometimes text goes out
to the terminal window, sometimes it's randomly routed back to the junky
SIOUX window. All the time, I have terminal windows spawning, and I have
to keep closing the previous one each time I run my app in the debugger.

2. Fix symbol lookups for system libraries. For example, just today my
app crashed with the top of the backtrace pointing to
com.apple.GeForce3GLDriver, according to Crash Reporter. Crash Reporter
is capable of giving me a stack backtrace with full symbol names, while
if I crash in CodeWarrior, all fragments after my app are mysteriously
unknown.

[MW Ron]

Post by Brad Oliver

Post by MW Ron
I would like some constructive feedback and questions, not allegations.

I have a few more wishes.
1. Fix the debugger's log window. Right now we have two choices - a
SIOUX output window that is inexplicably slow as molasses if text starts
streaming out to it in any significant volume, or a terminal window
which is flaky and unreliable.
I prefer to route output to the terminal window just because it's orders
of magnitude faster than the SIOUX window, but sometimes text goes out
to the terminal window, sometimes it's randomly routed back to the junky
SIOUX window. All the time, I have terminal windows spawning, and I have
to keep closing the previous one each time I run my app in the debugger.

If you only have output you should have the console window too.. I
assume you also want standard input. Instead of a suggestion, I would
recommend you file this as a bug report instead.

Post by Brad Oliver
2. Fix symbol lookups for system libraries. For example, just today my
app crashed with the top of the backtrace pointing to
com.apple.GeForce3GLDriver, according to Crash Reporter. Crash Reporter
is capable of giving me a stack backtrace with full symbol names, while
if I crash in CodeWarrior, all fragments after my app are mysteriously
unknown.

Again, this should not be a suggestion but filed as a bug report.

We can't fix them if we don't know about them... Don't assume it is
common or others report them because the more reports there are, the
higher the priority will be.

Ron

[Brad Oliver]

Post by MW Ron
Again, this should not be a suggestion but filed as a bug report.

OK, here's a suggestion - make your bug reports a *lot* easier to file.
I'd love to be able to file a bug from within CodeWarrior.

You can snag most of the info you need about my setup from within
CodeWarrior programmatically, then send that info along with my bug
report text directly to Metrowerks.

Right now, the MW documentation has a file with an e-mail bug form in
it, but it also says I can fill out an online form at a given URL. If I
go to that URL and click on "Report a bug", I'm sent back to my e-mail
app. The process seems, well, buggy. ;-)

[Miro Jurisic]

Post by Brad Oliver
OK, here's a suggestion - make your bug reports a *lot* easier to file.
I'd love to be able to file a bug from within CodeWarrior.

They have a bug reporter app. It works. I forget where it lives :-)

meeroh

[Brad Oliver]

Post by Miro Jurisic

Post by Brad Oliver
OK, here's a suggestion - make your bug reports a *lot* easier to file.
I'd love to be able to file a bug from within CodeWarrior.

They have a bug reporter app. It works. I forget where it lives :-)

This is an unspoken part of my complaint. I had to dig around just to
find the text file with the bug report template in it, because it's in a
non-obivous place (inside the "Release Notes" folder), to me at least.

I can't find the bug reporter app to save my life. Is it part of a
default CW 9 install? I don't know that I've ever seen it.

[MW Ron]

Post by Brad Oliver

Post by Miro Jurisic

Post by Brad Oliver
OK, here's a suggestion - make your bug reports a *lot* easier to file.
I'd love to be able to file a bug from within CodeWarrior.

They have a bug reporter app. It works. I forget where it lives :-)

This is an unspoken part of my complaint. I had to dig around just to
find the text file with the bug report template in it, because it's in a
non-obivous place (inside the "Release Notes" folder), to me at least.

It has been in the same place for well over 6 years, probably more than
that.

Post by Brad Oliver
I can't find the bug reporter app to save my life. Is it part of a
default CW 9 install? I don't know that I've ever seen it.

Form Maker in the same folder

Ron

[Brad Oliver]

Post by MW Ron

Post by Brad Oliver
This is an unspoken part of my complaint. I had to dig around just to
find the text file with the bug report template in it, because it's in a
non-obivous place (inside the "Release Notes" folder), to me at least.

It has been in the same place for well over 6 years, probably more than
that.

How often do you suppose I have to file a bug report? Honestly, it's not
very often. So each time I must do so, I try in vain to remember where
the bug report form is. Sometimes I find it, sometimes I give up. Each
time I do find it, I think, "Wow, this is a very non-intuitive place."

Post by MW Ron

Post by Brad Oliver
I can't find the bug reporter app to save my life. Is it part of a
default CW 9 install? I don't know that I've ever seen it.

Form Maker in the same folder

Could you guys make this a little more intuitive? FormMaker to me
doesn't say "automated bug reporter." Integrate it into the IDE and
you've got everything I could want. You'll save yourself a lot of
support hassle, and probably get a lot more valuable feedback as a
result.

[Chris Cox]

Post by Brad Oliver

Post by MW Ron

Post by Brad Oliver
This is an unspoken part of my complaint. I had to dig around just to
find the text file with the bug report template in it, because it's in a
non-obivous place (inside the "Release Notes" folder), to me at least.

It has been in the same place for well over 6 years, probably more than
that.

How often do you suppose I have to file a bug report? Honestly, it's not
very often. So each time I must do so, I try in vain to remember where
the bug report form is. Sometimes I find it, sometimes I give up. Each
time I do find it, I think, "Wow, this is a very non-intuitive place."

Post by MW Ron

Post by Brad Oliver
I can't find the bug reporter app to save my life. Is it part of a
default CW 9 install? I don't know that I've ever seen it.

Form Maker in the same folder

Could you guys make this a little more intuitive? FormMaker to me
doesn't say "automated bug reporter." Integrate it into the IDE and
you've got everything I could want. You'll save yourself a lot of
support hassle, and probably get a lot more valuable feedback as a
result.

How about just having a menu item in the IDE "report bugs" that
launches FormMaker? The only time that would fail is if you're
reporting that the IDE won't launch or menus won't work ;-)

Chris

[MW Ron]

Post by Chris Cox
How about just having a menu item in the IDE "report bugs" that
launches FormMaker? The only time that would fail is if you're
reporting that the IDE won't launch or menus won't work ;-)

I'll suggest it, this should be simple to do

Ron

[Isaac Wankerl]

Post by Brad Oliver

Post by Miro Jurisic

Post by Brad Oliver
OK, here's a suggestion - make your bug reports a *lot* easier to file.
I'd love to be able to file a bug from within CodeWarrior.

They have a bug reporter app. It works. I forget where it lives :-)

This is an unspoken part of my complaint. I had to dig around just to
find the text file with the bug report template in it, because it's in a
non-obivous place (inside the "Release Notes" folder), to me at least.
I can't find the bug reporter app to save my life. Is it part of a
default CW 9 install? I don't know that I've ever seen it.

It's named FormMaker and it's located inside the Release
Notes/Contacting Metrowerks/FormMaker folder.

[Bruce Horn]

I'm mostly very pleased with CodeWarrior. Have been since 1.0 :-)

One thing I'd like: up/down buttons next to the popup menu of threads in
the debug window for the app. I have 11 threads and it's very tiring to
select each thread in turn with the popup to see what it is doing.

Bruce

[MW Ron]

In article

Post by Bruce Horn
I'm mostly very pleased with CodeWarrior. Have been since 1.0 :-)
One thing I'd like: up/down buttons next to the popup menu of threads in
the debug window for the app. I have 11 threads and it's very tiring to
select each thread in turn with the popup to see what it is doing.

I'll add this as a suggestion.

Ron

[MW Ron]

Post by Brad Oliver

Post by MW Ron
Again, this should not be a suggestion but filed as a bug report.

OK, here's a suggestion - make your bug reports a *lot* easier to file.
I'd love to be able to file a bug from within CodeWarrior.

I know and the form is set up for every possible product and much of its
not relevant. I just filed one, cut out all the needless stuff and
then keep it for a template for future use. I did that 5 years ago and
just update it with new versions.

Post by Brad Oliver
You can snag most of the info you need about my setup from within
CodeWarrior programmatically, then send that info along with my bug
report text directly to Metrowerks.

Did you look at Form Maker... that is what you want, it is in the
Release Notes / Contacting Metrowerks folder

Post by Brad Oliver
Right now, the MW documentation has a file with an e-mail bug form in
it, but it also says I can fill out an online form at a given URL. If I
go to that URL and click on "Report a bug", I'm sent back to my e-mail
app. The process seems, well, buggy. ;-)

It shouldn't

http://www.metrowerks.com/MW/Support/Contact+Support/bug.htm

I just tried it and it worked.

Ron

[Brad Oliver]

Post by MW Ron

Post by Brad Oliver
Right now, the MW documentation has a file with an e-mail bug form in
it, but it also says I can fill out an online form at a given URL. If I
go to that URL and click on "Report a bug", I'm sent back to my e-mail
app. The process seems, well, buggy. ;-)

It shouldn't
http://www.metrowerks.com/MW/Support/Contact+Support/bug.htm
I just tried it and it worked.

Here is what the file "email_Bug_Report_Form.txt" says, right at the top:

"To submit a bug report, please complete the web-based form found at:

<http://www.metrowerks.com/contact/>
"

If you click on that URL, you are given a page with a link that says
"Report a Bug". If you click on that link, you'll find it's just a
mailto: that goes to ***@metrowerks.com

Is this my punishment for reading the readme? ;-)

[Steven Fisher]

Post by Adriaan van Os
2. A feature that would take CW's engineers five minutes to implement: a
shift-left and shift-right with the shift-key pressed to move one
space rather than one tab to the left or right. This is in the MPW
editor (and I have missed it ever since).

While we're talking about block movement, one thing I've seen that I
really like (I think maybe it was in Word?) is tab and shift-tab to
indent/outdent when text is selected.

AND A DELETE LINE KEY. I've been asking for this since Codewarrior 8.
No, not Pro 8... the original Gold 8. :)

(Unless, of course, these are already in Pro 9. I don't have Pro 9 yet.)

[Miro Jurisic]

Post by Steven Fisher
While we're talking about block movement, one thing I've seen that I
really like (I think maybe it was in Word?) is tab and shift-tab to
indent/outdent when text is selected.

That's an option in CW9 IDE, off by default IIRC.

meeroh

[Wade Williams]

Post by MW Ron

Post by Wade Williams
3) An IDE which does not create duplicate files in the project when
cloning a project.

Can you expand on this a bit.

Yes. Frequently when cloning a target, every file in the target will
end up with two entries in the project and the project will refuse to
build. The "easiest" fix is to delete all the files in the target and
then add them back.

Wade

[Glenn Andreas]

Post by Wade Williams

Post by MW Ron

Post by Wade Williams
3) An IDE which does not create duplicate files in the project when
cloning a project.

Can you expand on this a bit.

Yes. Frequently when cloning a target, every file in the target will
end up with two entries in the project and the project will refuse to
build. The "easiest" fix is to delete all the files in the target and
then add them back.
Wade

I've seen that. Normally that means that the search paths of some
target aren't the same as the other search paths (so it sees the file
"foo" that it know that is in the searched path "{bar}" in target "Good"
but target "Bad" doesn't have the search path "{bar}" so it can't find
"foo" so it might be a different "foo" for that target). Since it can't
find it (and made the second entry) it won't build. Deleting the files
and adding them back in explicitly adds the search paths for where those
files are.

The easier solution is to make sure that the new target's search paths
are the same (I believe you can take the old ones, export them as XML,
and import them in the new project).

[MW Ron]

Post by Wade Williams

Post by MW Ron

Post by Wade Williams
3) An IDE which does not create duplicate files in the project when
cloning a project.

Can you expand on this a bit.

Yes. Frequently when cloning a target, every file in the target will
end up with two entries in the project and the project will refuse to
build. The "easiest" fix is to delete all the files in the target and
then add them back.

This is a safety feature of the IDE why this happens is that there are
two caches one for the files and one for internal and if they don't
match we let the user know.

Ron

[Wade Williams]

Post by MW Ron
This is a safety feature of the IDE why this happens is that there are
two caches one for the files and one for internal and if they don't
match we let the user know.

Huh?

Fine, but why screw up my project? Why not put up a dialog that says,
"The projects caches do not match. Press this button to do X which
will solve the problem, or press cancel."

Wade

[Dave Thorup]

Post by Wade Williams

Post by MW Ron
This is a safety feature of the IDE why this happens is that there are
two caches one for the files and one for internal and if they don't
match we let the user know.

Huh?
Fine, but why screw up my project? Why not put up a dialog that says,
"The projects caches do not match. Press this button to do X which
will solve the problem, or press cancel."

This doesn't sound like any sane safety feature to me. I'm in the
final stages of updating a huge project (almost 600 files) and I'm
stuck because I can't update the last target to the new directory
structure without causing duplicate entries for most of the files in
the project.

Is there any way to do this?

From what it looks like after having read the archives, the only way
to do this is to export the file to XML, then open the XML file and
manually change the target's access paths, then import the project
back into CodeWarrior. I have yet to try this, but before I do I ask,
is there any other way!? =(

Thanks!

[MW Ron]

In article <***@posting.google.com>, Dave Thorup
says...

Post by Dave Thorup

Post by Wade Williams

Post by MW Ron
This is a safety feature of the IDE why this happens is that there are
two caches one for the files and one for internal and if they don't
match we let the user know.

Huh?
Fine, but why screw up my project? Why not put up a dialog that says,
"The projects caches do not match. Press this button to do X which
will solve the problem, or press cancel."

It is telling you that it was actually corrupted already it is telling you that.

Post by Dave Thorup
This doesn't sound like any sane safety feature to me. I'm in the
final stages of updating a huge project (almost 600 files) and I'm
stuck because I can't update the last target to the new directory
structure without causing duplicate entries for most of the files in
the project.
Is there any way to do this?

I understand your reasoning and we did a lot of things in CW 9 to make sure this
doesn't happpen It primarily was happening with CW 8 and a version control but
I think we fixed this. If you have CW 9 and ir recurs want to know.

Ron

[Dave Thorup]

Post by MW Ron
says...

Post by Dave Thorup
This doesn't sound like any sane safety feature to me. I'm in the
final stages of updating a huge project (almost 600 files) and I'm
stuck because I can't update the last target to the new directory
structure without causing duplicate entries for most of the files in
the project.
Is there any way to do this?

I understand your reasoning and we did a lot of things in CW 9 to make sure this
doesn't happpen It primarily was happening with CW 8 and a version control but
I think we fixed this. If you have CW 9 and ir recurs want to know.

Is there anything I can do now to fix my corrupted project? Do you
have any kind of tool that can fix it?

The project in question used to be a CW 8 project that has been
recently updated to CW 9. The access paths changed back when it was a
CW 8 project and I've updated all but one of the targets. I don't
even need to save the one target that hasn't been updated since I can
easily recreate it from the other existing targets. All I want to do
is be able to delete the old target without getting duplicate copies
of files in the other targets.

Is there anything I can do?

One of these days I will probably just give in and recreate the whole
d@#$ project, but I dread the day that I have to do that. For now
I'll just keep my bad target around.

Dave

[MW Ron]

Post by Dave Thorup
Is there anything I can do now to fix my corrupted project? Do you
have any kind of tool that can fix it?
The project in question used to be a CW 8 project that has been
recently updated to CW 9. The access paths changed back when it was a
CW 8 project and I've updated all but one of the targets. I don't
even need to save the one target that hasn't been updated since I can
easily recreate it from the other existing targets. All I want to do
is be able to delete the old target without getting duplicate copies
of files in the other targets.

You should be able to just delete it, I think CW 9 will remove files if there
are no targets using them (I'd test it but I'm on the road again)

Post by Dave Thorup
Is there anything I can do?
One of these days I will probably just give in and recreate the whole
I'll just keep my bad target around.

export this to XML before you do anything. You might be able to modify the XML
file to remove the target too.

hope some of this helps, Let me know if it doesn't.

Ron

[Dave Thorup]

Post by MW Ron

Post by Dave Thorup
Is there anything I can do now to fix my corrupted project? Do you
have any kind of tool that can fix it?

You should be able to just delete it, I think CW 9 will remove files if there
are no targets using them (I'd test it but I'm on the road again)

I've tried this, many times. I use version control so I have no
problem trying something and then reverting when it doesn't work and
I've tried everything I can think of.

Yes, CW does remove the files that are exclusive to the deleted
target, but files that are used by all the targets (the duplicated
files) remain in their duplicated form. Here's what happens:

Say my project has the following targets: foo, bar and baz. The
underlying directory structure for the common source of all the
projects changed some time ago. Targets foo and bar have been updated
to the new source tree but baz has not been updated. Upon updating
the access paths for the first target, foo, my project acquired
duplicate file entries for every file in the project, this:

_File_ | _Included in Target_
|
File.h | x
File.cpp | x

turned into this:

_File_ | _Included in Target_
|
File.h | x
File.cpp | x
File.h |
File.cpp |

I then updated bar to the new source tree, but whenever I tried to
update or delete baz my project turned into this:

_File_ | _Included in Target_
|
File.h | x
File.cpp | x
File.h | x
File.cpp | x

Rather than deleting the duplicate file entries, now each file is not
only duplicated, but both (the file and its duplicate) are included in
the target.

I just noticed that my current project now looks like the final one
above for all my targets (Doh!). This must have happened recently,
possibly when I switched to CW 9 (just a few days ago). So it won't
matter now if I delete my old target. All of the access path updates
that I've done were in CW 8.3 and I had just given up on correcting
the duplicate file problem back then.

There's also the problem that deleting the duplicate file deletes both
of the files from the project.

I've been slowly removing code groups that contain duplicates and
replacing them, so I've probably corrected about 25% of the project so
far.

Post by MW Ron

Post by Dave Thorup
Is there anything I can do?

export this to XML before you do anything. You might be able to modify the XML
file to remove the target too.

I've already tried exporting to XML and I took a look at it. While it
looks like I can delete the duplicate file listings in the XML file I
have no desire to manually do that for all of the hundreds of files
that need to be corrected in the project.

I'll probably just continue to correct the project, little by little
until I've fixed everything.

Dave

[MW Ron]

Post by Dave Thorup

Post by Wade Williams

Post by MW Ron
This is a safety feature of the IDE why this happens is that there are
two caches one for the files and one for internal and if they don't
match we let the user know.

Huh?
Fine, but why screw up my project? Why not put up a dialog that says,
"The projects caches do not match. Press this button to do X which
will solve the problem, or press cancel."

This doesn't sound like any sane safety feature to me. I'm in the
final stages of updating a huge project (almost 600 files) and I'm
stuck because I can't update the last target to the new directory
structure without causing duplicate entries for most of the files in
the project.
Is there any way to do this?

use Relative File Paths in the target settings.

Post by Dave Thorup
From what it looks like after having read the archives, the only way
to do this is to export the file to XML, then open the XML file and
manually change the target's access paths, then import the project
back into CodeWarrior. I have yet to try this, but before I do I ask,
is there any other way!? =(

I think sub projects is a better way than relative files, I always hate
to see one project have more than one file with the same name.

Ron

[Larry]

Post by MW Ron
CodeWarrior Mac is an important product but it is a small product line.
I would like some constructive feedback and questions,

- I would desperately love for CW to not be brought to its knees by
whatever it's doing when I see Parsing, Caching, and Searching at the
bottom of the project window. I've never figured out exactly what's
going on, but sometimes making a change to one file and saving it can
tie CW up for minutes while it "parses" hundreds of files, sometimes
more than 2000 of them. For example, I just turned on a couple of
warning options for a target, and after searching what appeared to be
all of the framework files, it launched into parsing 2004 files. Ugh.
Sometimes using the Find and Open File window triggers several seconds
of caching. I can't begin to imagine why CW needs to repeatedly cache
anything in the system frameworks which hasn't changed in weeks or
months.

- I'd also like CW to use better threading so editing stays responsive
while compiling.

- Like others, I want to be able to use diagnostic tools which work
with Xcode-built applications.

- I'd like to see the various windows be updated to comply with the
Aqua guidelines.

- In general I want CW to return to being the premier IDE for the Mac.
It seems to me that for some time now MW has failed to do anything
more significant than keeping CW compatible with the latest versions
of Mac OS X. I understand that's probably a lot of work, but as a
long-time user of CW (since before there was even a Pro version), I
can recall the days when I didn't give up anything to use CW. That's
not true anymore. It seems instead that speed and some interface
issues are the big advantages of CW, and even the interface looks
pretty dated these days. Xcode/gcc does a better job of enforcing C++
standards compliance, for example. and it generates applications that
work with MallocDebug without going through contortions.

- I want MW to think of us as Mac users as well as Mac developers. One
thing which usually frustrates me with developer tools is that they
often feel like they were developed for someone who doesn't care about
the interface, how easy the product is to use, or any of the other
issues we think about when creating end-user software. I am a Mac
*user* who happens to write Mac software for a living. There is no
truth to any notion that I don't care about the normal usability
issues just because I'm a developer. I want Aqua guideline compliance.
I want help tags. I want all the stuff that makes using CW a Mac-like
experience. Given that over the years I've spent more on CW than all
other software combined, I don't think this is an unreasonable
expectation.

- I want the next release to be a clear improvement, not two steps
forward and a step-and-a-half back like Pro 9 seemed to be.

- I want to see something more tangible than "It's planned," "We're
considering something like that," blah blah blah. Plans don't make my
life with CW or my product any better. Apple seems to be slowing the
pace at which it releases major versions of Mac OS X, so this might be
a good time for MW to get CW up to speed in other areas besides OS
compatibility.

Post by MW Ron
not allegations.

MW is almost universally regarded as having fallen behind in CW
development. There's little real information, lots of vague promises
from you, and little (no?) tangible evidence that things will get
significantly better anytime soon. I hope that all this will change,
and soon. But the reality is that for at least three years now we've
been waiting to be able to stop making excuses for our development
environment. I understand if you don't like some of what we say, but
the solution is simple: Show us something different. Trust me, I would
love to be able to sing the praises of CW.

[Thorrsten Froehlich]

Post by Larry

Post by MW Ron
CodeWarrior Mac is an important product but it is a small product line.
I would like some constructive feedback and questions,

- I would desperately love for CW to not be brought to its knees by
whatever it's doing when I see Parsing, Caching, and Searching at the
bottom of the project window. I've never figured out exactly what's
going on

This must have been discussed here a million times already. It is the
stupid language parser. To turn it off set Target Settings: Target:
Build Extras: Generate Browser Data From: Compiler.

Thorsten

[Milton Aupperle]

Post by Thorrsten Froehlich

Post by Larry

Post by MW Ron
CodeWarrior Mac is an important product but it is a small product line.
I would like some constructive feedback and questions,

- I would desperately love for CW to not be brought to its knees by
whatever it's doing when I see Parsing, Caching, and Searching at the
bottom of the project window. I've never figured out exactly what's
going on

This must have been discussed here a million times already. It is the
Build Extras: Generate Browser Data From: Compiler.
Thorsten

I completely agree with this and it really needs to be addressed in a
future update. Every time I open a CW 8.3 project in CW 9.x this is
"on" by default and it's a PITA. The default should be set to
"Compiler" as a default. I've advised clients about this - but I really
should not need to.

Another issue I have is that CW 8.x and 9.x will open a file (i.e. a
.c or .h or .cp) in project when I double click on it and then
immediately collapse the file window to the dock, just as if I had used
the minimize widget. Then every time I double click on that file again,
it collapses to the dock. The only workaround is to change the order of
the file in the project (ie drag it up one or down one) and then the
problem goes away - but another file may later on develop this. This
has happened in many project files and once it happens it's 100%
repeatable. It seems to be mainly with the first file listed in a
group folder of a project. Opening the file by double clicking from the
finder does not cause it to happen, so it must be some bug in the
project file code.

Milton Aupperle
www.outcastsoft.com

[Jim Correia]

In article

Post by Milton Aupperle
Another issue I have is that CW 8.x and 9.x will open a file (i.e. a
.c or .h or .cp) in project when I double click on it and then
immediately collapse the file window to the dock, just as if I had used
the minimize widget. Then every time I double click on that file again,
it collapses to the dock. The only workaround is to change the order of
the file in the project (ie drag it up one or down one) and then the
problem goes away - but another file may later on develop this. This
has happened in many project files and once it happens it's 100%
repeatable. It seems to be mainly with the first file listed in a
group folder of a project. Opening the file by double clicking from the
finder does not cause it to happen, so it must be some bug in the
project file code.

It is a bug in the OS. The bug is if a window opens in a location where
the title bar is under the mouse the mouseup from your double click goes
to that window and minimizes it. Turning off double-click to minimize is
the only workaround at present.

Jim

[Milton Aupperle]

Post by MW Ron
In article

Post by Milton Aupperle
Another issue I have is that CW 8.x and 9.x will open a file (i.e. a
.c or .h or .cp) in project when I double click on it and then
immediately collapse the file window to the dock, just as if I had used
the minimize widget. Then every time I double click on that file again,
it collapses to the dock. The only workaround is to change the order of
the file in the project (ie drag it up one or down one) and then the
problem goes away - but another file may later on develop this. This
has happened in many project files and once it happens it's 100%
repeatable. It seems to be mainly with the first file listed in a
group folder of a project. Opening the file by double clicking from the
finder does not cause it to happen, so it must be some bug in the
project file code.

It is a bug in the OS. The bug is if a window opens in a location where
the title bar is under the mouse the mouseup from your double click goes
to that window and minimizes it. Turning off double-click to minimize is
the only workaround at present.
Jim

Hi Jim;

Thanks for the suggestion, but that isn't the case.

When I double click on the file name in the Project window the cursor
no where near where the window title bar appears at. And why would
changing the order of the files names in the Project window stop it
from happening.

TTYL..

Milton Aupperle

[Jim Correia]

In article

Post by Milton Aupperle
Hi Jim;
Thanks for the suggestion, but that isn't the case.
When I double click on the file name in the Project window the cursor
no where near where the window title bar appears at. And why would
changing the order of the files names in the Project window stop it
from happening.

It would stop it from triggering the bug I am talking about because then
the file won't open up under the mouse. (I know you said that isn't the
case.)

You can attach to CodeWarrior, break on CollapseWindow, trigger the bug
and look at the backtrace to see who is minimizing the window.

Jim

[James W. Walker]

In article

Post by Milton Aupperle
When I double click on the file name in the Project window the cursor
no where near where the window title bar appears at.

Then I guess it's not the same bug that I and others have seen.

Post by Milton Aupperle
And why would
changing the order of the files names in the Project window stop it
from happening.

Because you're changing the place where you will be double-clicking,
but not changing where the window will appear when it opens.

[Eric Albert]

Post by MW Ron
In article

Post by Milton Aupperle
Another issue I have is that CW 8.x and 9.x will open a file (i.e. a
.c or .h or .cp) in project when I double click on it and then
immediately collapse the file window to the dock, just as if I had used
the minimize widget. Then every time I double click on that file again,
it collapses to the dock. The only workaround is to change the order of
the file in the project (ie drag it up one or down one) and then the
problem goes away - but another file may later on develop this. This
has happened in many project files and once it happens it's 100%
repeatable. It seems to be mainly with the first file listed in a
group folder of a project. Opening the file by double clicking from the
finder does not cause it to happen, so it must be some bug in the
project file code.

It is a bug in the OS. The bug is if a window opens in a location where
the title bar is under the mouse the mouseup from your double click goes
to that window and minimizes it. Turning off double-click to minimize is
the only workaround at present.

Someone (or multiple people) should file a bug report on this.... :)

<http://bugreport.apple.com/>

-Eric

[James W. Walker]

Post by Eric Albert
Someone (or multiple people) should file a bug report on this.... :)
<http://bugreport.apple.com/>

I did so months ago, and it was closed as a duplicate.

[Jim Correia]

Post by James W. Walker

Post by Eric Albert
Someone (or multiple people) should file a bug report on this.... :)
<http://bugreport.apple.com/>

I did so months ago, and it was closed as a duplicate.

As did I with the same result :-)

[Milton Aupperle]

Post by Jim Correia

Post by James W. Walker

Post by Eric Albert
Someone (or multiple people) should file a bug report on this.... :)
<http://bugreport.apple.com/>

I did so months ago, and it was closed as a duplicate.

As did I with the same result :-)

Which means it's in Limbo and probably will never be fixed.

I have several bugs that have been flagged as "Duplicate" - 36 months
ago.

[Eric Albert]

In article

Post by Milton Aupperle

Post by Jim Correia

Post by James W. Walker

Post by Eric Albert
Someone (or multiple people) should file a bug report on this.... :)
<http://bugreport.apple.com/>

I did so months ago, and it was closed as a duplicate.

As did I with the same result :-)

Which means it's in Limbo and probably will never be fixed.

Not at all. That merely means it's a duplicate of an existing bug.
Filing duplicate versions of a bug makes it more likely that the bug'll
get fixed sooner, not less.

Post by Milton Aupperle
I have several bugs that have been flagged as "Duplicate" - 36 months
ago.

If you have bugs that are three years old that haven't been fixed,
they're unlikely to get fixed now because the OS has changed so much
since then (10.0) that the people who have the bugs don't have any
reason to think the problems still exist or affect anyone. I'd suggest
re-filing the bugs against 10.3.4, with good test cases. (Hint: A
reproducible test case, or better yet, a code snippet, always makes a
bug far more likely to get fixed.)

-Eric

[Milton Aupperle]

In article <ejalbert-***@localhost>, Eric Albert
<***@cs.stanford.edu> wrote:

------------SNIPPEd for Brevity -----------------

Post by Eric Albert
If you have bugs that are three years old that haven't been fixed,
they're unlikely to get fixed now because the OS has changed so much
since then (10.0) that the people who have the bugs don't have any
reason to think the problems still exist or affect anyone. I'd suggest
re-filing the bugs against 10.3.4, with good test cases. (Hint: A
reproducible test case, or better yet, a code snippet, always makes a
bug far more likely to get fixed.)

Been there, done that - still Apple has done nothing. Unless it's a bug
that affects Apple's products it's unlikely they will ever fix them.
And that's not just me - lots of Developers I deal are runnign into the
same song and dance from Apple.

I have a list of some of the more Severe Ones (for this one product) of
them with Radar bug numbers at the bottom of the following URL:

http://www.outcastsoft.com/ASCDFG1394.html


The bug(s) in question were introduced in QuickTime 6.02 and still not
fixed including QT 6.5.x. I have filed complete working code,
complete working examples, complete descriptions and have asked Apple
Bugs multiple times about them it. As a Select Mac developer, I have
even tried opening a DTS events to try and get them looked into, but
because they are bonified bugs, DTS can do nothing. I was alos on the
QucikTime beta list for QT 6.1, 6.2,6.3 and 6.4 and each time I asked
and begged Apple to look into them - but they didn't.

So it's pretty obvious what Apple does with Bug Reports - nothing.

Milton Aupperle

[James W. Walker]

In article

Post by Milton Aupperle
Been there, done that - still Apple has done nothing. Unless it's a bug
that affects Apple's products it's unlikely they will ever fix them.
And that's not just me - lots of Developers I deal are runnign into the
same song and dance from Apple.

It probably depends on which group in Apple has the
responsibility/power to fix it. I recently reported a cosmetic bug in
HIToolbox which affected my application, and as far as I know did not
affect any Apple product, and they are fixing it in 10.3.5.

[Eric Albert]

Post by MW Ron
In article

Post by Milton Aupperle
Been there, done that - still Apple has done nothing. Unless it's a bug
that affects Apple's products it's unlikely they will ever fix them.
And that's not just me - lots of Developers I deal are runnign into the
same song and dance from Apple.

It probably depends on which group in Apple has the
responsibility/power to fix it. I recently reported a cosmetic bug in
HIToolbox which affected my application, and as far as I know did not
affect any Apple product, and they are fixing it in 10.3.5.

That's true; each group has its own way of handling bugs.

-Eric

[Eric Albert]

In article

Post by Milton Aupperle
I have a list of some of the more Severe Ones (for this one product) of
http://www.outcastsoft.com/ASCDFG1394.html
So it's pretty obvious what Apple does with Bug Reports - nothing.

About half of the bugs for which you have Radar numbers on that page
(many are missing numbers) have been fixed. That's not a terrific
ratio, but it's hardly nothing.

-Eric

[Milton Aupperle]

Post by MW Ron
In article

Post by Milton Aupperle
I have a list of some of the more Severe Ones (for this one product) of
http://www.outcastsoft.com/ASCDFG1394.html
So it's pretty obvious what Apple does with Bug Reports - nothing.

About half of the bugs for which you have Radar numbers on that page
(many are missing numbers) have been fixed. That's not a terrific
ratio, but it's hardly nothing.

That's not true.

Of those bugs only 2 of the 9 have actually been fixed - I hardly call
that "half".

And getting a bug fixed should not entail the user spending $00's of
dollars to purchase Panther, as Apple did not fix some bugs for Jaguar.

Of the 9 major bugs (bugs that are hard to duplicate or hardware
dependent aren't worth trying to get Apple to look at - but they are
worth mentioning for users / developers) I listed, 6 of them have Radar
bug ID's, so your "many are missing #'s" statement is wrong. Some are
so old that (like the "resource path for pop" bug) that I can't find
the bug report anymore - I believe I posted it back in OS 8.x days.

And the "3467318" bug has resurfaced again in QuickTime 6.5.1, just as
it did in 6.4 and 6.1. Getting them to re-open it again is simply a
waste of time and we've worked around it ourselves.

Milton Aupperle

[Eric Albert]

In article

Post by Milton Aupperle
And getting a bug fixed should not entail the user spending $00's of
dollars to purchase Panther, as Apple did not fix some bugs for Jaguar.

The process of selecting bugs for a software update is very complicated
and involves many considerations. Unfortunately, it's simply not
possible to include every bug fix in an update -- some are tied to new
features, others are too risky, others aren't critical, and so on.
Nobody ever wants to tell someone that they have to buy the next version
to get a bug fix that's important to them, but sometimes there's just no
other way.

Post by Milton Aupperle
Some are
so old that (like the "resource path for pop" bug) that I can't find
the bug report anymore - I believe I posted it back in OS 8.x days.

If it was reported against Mac OS 8, you definitely need to report it
again on a modern version of the OS to have any reasonable chance of
getting it fixed. Almost the entire OS has changed in the interim.

Post by Milton Aupperle
And the "3467318" bug has resurfaced again in QuickTime 6.5.1, just as
it did in 6.4 and 6.1. Getting them to re-open it again is simply a
waste of time and we've worked around it ourselves.

Don't bother asking them to re-open it if you don't want to. Just file
it again. The cause may be different under QuickTime 6.5.1, even if the
symptom is the same.

-Eric

[Brad Oliver]

In article

Post by Milton Aupperle
Been there, done that - still Apple has done nothing. Unless it's a bug
that affects Apple's products it's unlikely they will ever fix them.

That's demonstratably not true. I have a lot of experience filing bugs
with Apple ;-) and almost all of them have been fixed. Even crusty,
deprecated old DrawSprocket bugs which are no longer in any product
Apple cares about.

[Gregory Weston]

In article

Post by Milton Aupperle
So it's pretty obvious what Apple does with Bug Reports - nothing.

Not my experience at all. Every bug report I've filed since the Public
Beta has been at least acknowledged and all but two fixed.

[Larry]

Post by Milton Aupperle
Been there, done that - still Apple has done nothing. Unless it's a bug
that affects Apple's products it's unlikely they will ever fix them.

Lots of people at Apple use Interface Builder, and its bugs still
don't get fixed. LOL

Post by Milton Aupperle
And that's not just me - lots of Developers I deal are runnign into the
same song and dance from Apple.

I haven't found this to be the case. It's certainly not the case that
all of my bugs have been fixed, but many have. You can't tell what's
happening with your bug because you can't read the internal
discussion. Someone at Apple once sent me the internal discussion
pertaining to a pretty simple cosmetic bug I filed, and it was amazing
how much discussion had taken place and how many people had
contributed. That bug may never get fixed, but only because fixing it
would be more involved than you'd think and they still have bigger
fish to fry, but even so it was clear my bug report was taken
seriously.

Post by Milton Aupperle
I have a list of some of the more Severe Ones (for this one product) of
http://www.outcastsoft.com/ASCDFG1394.html
The bug(s) in question were introduced in QuickTime 6.02 and still not
fixed including QT 6.5.x. I have filed complete working code,
complete working examples, complete descriptions and have asked Apple
Bugs multiple times about them it. As a Select Mac developer, I have
even tried opening a DTS events to try and get them looked into, but
because they are bonified bugs, DTS can do nothing. I was alos on the
QucikTime beta list for QT 6.1, 6.2,6.3 and 6.4 and each time I asked
and begged Apple to look into them - but they didn't.

As I understand it, QuickTime is a sprawling technology with thousands
of APIs, lots of engineers working on it, and a slightly larger dose
of egos than most technologies in the Mac OS. The upshot is that yes,
it may be harder to get a QT fixed.

Post by Milton Aupperle
So it's pretty obvious what Apple does with Bug Reports - nothing.

This is simply not true. Based on my experience every bug report is
read and assigned to an engineer. I've had bugs fixed. I've been asked
for addition information. I've even gotten a phone call from someone
in devbugs wanting to verify that a bug I'd reported in Nav Services
had been fixed (it had)! And as developers go, they don't get much
smaller than I am. Yes, they called me. Really.

[Eric Albert]

Post by Jim Correia

Post by James W. Walker

Post by Eric Albert
Someone (or multiple people) should file a bug report on this.... :)
<http://bugreport.apple.com/>

I did so months ago, and it was closed as a duplicate.

As did I with the same result :-)

Any chance y'all could either post or mail me your bug numbers? I'd
like to check to make sure they're connected to the dup I filed of the
same bug, which I could've sworn only had one dup.

-Eric

[Larry]

Post by Jim Correia

Post by Milton Aupperle
Another issue I have is that CW 8.x and 9.x will open a file (i.e. a
.c or .h or .cp) in project when I double click on it and then
immediately collapse the file window to the dock, just as if I had used
the minimize widget. Then every time I double click on that file again,
it collapses to the dock. The only workaround is to change the order of
the file in the project (ie drag it up one or down one) and then the
problem goes away - but another file may later on develop this. This
has happened in many project files and once it happens it's 100%
repeatable. It seems to be mainly with the first file listed in a
group folder of a project. Opening the file by double clicking from the
finder does not cause it to happen, so it must be some bug in the
project file code.

It is a bug in the OS. The bug is if a window opens in a location where
the title bar is under the mouse the mouseup from your double click goes
to that window and minimizes it. Turning off double-click to minimize is
the only workaround at present.

It gets even worse. If I Option-double-click something to go to its
definition and the window opens with its title bar under the mouse,
ALL of my CW windows get minimized. I was a sad puppy the day I saw 28
windows shoot into the Dock and realized there's no way to get them
all out at once. ;-)

Yes, I filed a bug in Radar, but unfortunately it looks like it won't
get fixed before Tiger.

[Miro Jurisic]

I was a sad puppy the day I saw 28 windows shoot into the Dock and realized
there's no way to get them all out at once. ;-)

Two ways: one, turn on the default workspace in the IDE and relaunch it. It will
reload all windows to where you had them. Then turn it off if you don't like it.
Two, kill the dock. It respawns, but all windows are unminimized when it does so.

meeroh

[Mr. Magoo]

Post by Miro Jurisic

I was a sad puppy the day I saw 28 windows shoot into the Dock and realized
there's no way to get them all out at once. ;-)

Two ways: one, turn on the default workspace in the IDE and relaunch
it. It will reload all windows to where you had them. Then turn it
off if you don't like it. Two, kill the dock. It respawns, but all
windows are unminimized when it does so.

Three - file a bug with Apple. As of 10.3 option-clicking a minimized
window from a Cocoa app maximizes all. This doesn't work in Carbon.

(OTOH windows with the right CE handler in carbon apps get a close menu
item, and Cocoa windows don't.)

M

[James W. Walker]

In article

Post by Milton Aupperle
Another issue I have is that CW 8.x and 9.x will open a file (i.e. a
.c or .h or .cp) in project when I double click on it and then
immediately collapse the file window to the dock, just as if I had used
the minimize widget. Then every time I double click on that file again,
it collapses to the dock. The only workaround is to change the order of
the file in the project (ie drag it up one or down one) and then the
problem goes away - but another file may later on develop this. This
has happened in many project files and once it happens it's 100%
repeatable. It seems to be mainly with the first file listed in a
group folder of a project. Opening the file by double clicking from the
finder does not cause it to happen, so it must be some bug in the
project file code.

It seems to be an OS bug. What you don't seem to have noticed is that
it happens when the place where you double-click happens to be within
the region where the title bar appears.

A workaround is to go to the Appearance preference panel and uncheck
"Minimize when double-clicking a window title bar".

[Scott Ribe]

Post by James W. Walker
It seems to be an OS bug. What you don't seem to have noticed is that
it happens when the place where you double-click happens to be within
the region where the title bar appears.
A workaround is to go to the Appearance preference panel and uncheck
"Minimize when double-clicking a window title bar".

AHA! I had this problem the other day in a totally different app (never seen
it in CodeWarrior) and I believe the window's title bar was about where I
was double-clicking...

[MW Ron]

In article

Post by Milton Aupperle
Another issue I have is that CW 8.x and 9.x will open a file (i.e. a
.c or .h or .cp) in project when I double click on it and then
immediately collapse the file window to the dock, just as if I had used
the minimize widget. Then every time I double click on that file again,
it collapses to the dock. The only workaround is to change the order of
the file in the project (ie drag it up one or down one) and then the
problem goes away - but another file may later on develop this. This
has happened in many project files and once it happens it's 100%
repeatable. It seems to be mainly with the first file listed in a
group folder of a project. Opening the file by double clicking from the
finder does not cause it to happen, so it must be some bug in the
project file code.

I either don't understand the problem, or can't reproduce it. Did you
file this as a bug report?

Ron

[Larry]

Post by Thorrsten Froehlich

Post by Larry

Post by MW Ron
CodeWarrior Mac is an important product but it is a small product line.
I would like some constructive feedback and questions,

- I would desperately love for CW to not be brought to its knees by
whatever it's doing when I see Parsing, Caching, and Searching at the
bottom of the project window. I've never figured out exactly what's
going on

This must have been discussed here a million times already. It is the
Build Extras: Generate Browser Data From: Compiler.

I tried that, but IIRC I lost my syntax coloring which was even worse.
It's been a while, but I do remember turning it off and thinking that
some consequence of the cure was worse than the disease. ;-)

It's ridiculous, IMO, to have a feature that even after two major
releases is widely regarded as unusable. Gee, I wish *I* could add
unusable features, update compatibility with the latest OS and charge
people $200 for the upgrade. LOL If they really, absolutely have to do
all that stuff (and I'm not convinced they do), then at least it
should be done in a low-priorty thread or in an idle event timer so it
doesn't impact performance and responsiveness significantly, and it
should be paused while compiling. Furthermore, there must be a bug in
it somewhere because I've seen times when every time I save a change
to a file CW becomes unresponsive for several seconds, which is a real
pain since I save a lot. I've found that if I quit CW when I see that
and relaunch, the problem goes away.

[MW Ron]

Post by Larry

Post by MW Ron
CodeWarrior Mac is an important product but it is a small product line.
I would like some constructive feedback and questions,

- I would desperately love for CW to not be brought to its knees by
whatever it's doing when I see Parsing, Caching, and Searching at the
bottom of the project window. I've never figured out exactly what's
going on, but sometimes making a change to one file and saving it can
tie CW up for minutes while it "parses" hundreds of files, sometimes
more than 2000 of them. For example, I just turned on a couple of
warning options for a target, and after searching what appeared to be
all of the framework files, it launched into parsing 2004 files. Ugh.
Sometimes using the Find and Open File window triggers several seconds
of caching. I can't begin to imagine why CW needs to repeatedly cache
anything in the system frameworks which hasn't changed in weeks or
months.

Turn off Language Parsing, Turn on Compiler parser

This should only happen seriously the first time and you can do other
things while it is happening if you have CW 9.2 However I think the
nature of Frameworks and Cocoa do make this much harder to parse on the
fly.

Post by Larry
- I'd also like CW to use better threading so editing stays responsive
while compiling.

On the to do list.

Post by Larry
- Like others, I want to be able to use diagnostic tools which work
with Xcode-built applications.

They should work with CodeWarrior, I'm not sure why they don't.

Post by Larry
- I'd like to see the various windows be updated to comply with the
Aqua guidelines.

going to native IDE is a plan for future since we won't use PowerPlantXp
for the IDE but have a different approach.

Post by Larry
- In general I want CW to return to being the premier IDE for the Mac.

This is our intent, We won't have any CW this year, we are promising
the finest product or we just won't release it.

Post by Larry
Xcode/gcc does a better job of enforcing C++
standards compliance, for example. and it generates applications that
work with MallocDebug without going through contortions.

I don't believe that XCode/gcc is as compliant as CodeWarrior it
certainly isn't in the Boost tests where CW scores a 99+% rating.

I don't know why MallocDebug does not work out of the box, we use the
same underlying Malloc. It is something we can look into.

Post by Larry
- I want the next release to be a clear improvement, not two steps
forward and a step-and-a-half back like Pro 9 seemed to be.

I think CW 9 was a clear step up, but CW 10 will hopefully be a quantum
step up.

Post by Larry
- I want to see something more tangible than "It's planned," "We're
considering something like that," blah blah blah. Plans don't make my
life with CW or my product any better. Apple seems to be slowing the
pace at which it releases major versions of Mac OS X, so this might be
a good time for MW to get CW up to speed in other areas besides OS
compatibility.

This is an excellent point but talk is all you will see for a while.

Ron

[Adriaan van Os]

Post by MW Ron
What About 64-bit (G5) Compilers?
We are planning 64 bit compilers and G5 support

This would imply a 64-bit debugger (but OK, I will wait till mid August
for more info).

Regards,

Adriaan van Os

[jlarsson]

Post by Jonathan Hoyle
*
5. Speaking of Qt, work with Trolltech to get the compiler issues
settled. Right now, if I want to use Qt, we have to switch to Xcode
because Trolltech says that CodeWarrior's compiler is incompatible.
Of course Metrowerks thinks that the Qt source is faulty. Look, I
don't know who's fault it is, their's or your's, but this ought to
be
worked out. If we make the switch to Qt, we'll be forced to drop
CodeWarrior and go to a dual compiler solution of XCode/Visual C++.
*

I am in total agreement here. Please work with Trolltech and make sure
Codewarrior is a supported environment. Or even better so that Qt
Designer works well within the CodeWarrior IDE.

The two products would complement each other very nicely and I would
switch back to CodeWarrior on both Windows and Mac (since I'm curently
using Qt exclusively I've completely dropped out of the CodeWarrior
upgrade loop).

/Jan L.



--
jlarsson
------------------------------------------------------------------------
Posted via http://www.codecomments.com
------------------------------------------------------------------------