Still no answer on this one: how can I flag a piece of text in FC to be a regular "text" or "label" component when brought into FB?
RichText is an FXG class for representing non-interactive text. You can change what text it displays programmatically (by setting it's text property) but the user cannot scroll, select, or edit it. It sounds like you just want to set the text being displayed dynamically so RichText should be sufficient, but if you want more interactive text, try using RichEditableText. As far as I know, there is no way to convert from RichText to RichEditableText or a Label component in FC, but it should be straighforward to do in Flash Builder.
I think the question was "How do I specify the type of component in Catalyst?" I would also like to know this answer, as instructing designers to use "RichEditableText" is a bit easier than me having to go through and change the MXML.
I agree. I would venture to say that, for Catalyst to be successful, the
person using catalyst will need to be able to specify everything about the
objects therein. What type of components/objects everything should be
Also, the ability to use the same style for multiple elements. If I have 10
text objects in FC that are 14 px blue Helvetica, I don't want them all
specified inline, 10 times. I'd want the ability, in Catalyst, to define a
style of some sort.
RichText can be changed dynamically (set the "content" property). Here's the docs: http://livedocs.adobe.com/flex/gumbo/langref/spark/primitives/RichText.html
Catalyst doesn't author Label or Text components. Instead, it creates RichText and RichEditableText (which are primitives with no chrome) and TextInput, which is basically a skinnable RichEditableText. These classes are part of the new text system, which are extremely powerful. Check out the specs here: http://opensource.adobe.com/wiki/display/flexsdk/Spark+Text+Primitives
I'm happy to use the new components. I'd still like a way in FC to define
styles that are re-used instead of all inline, though.
Yes, absolutely. Flash Builder supports styling through CSS, and this is definitely something we'll be considering for future versions of FC.
The hardest part about styles (IMHO) is the following usability nightmare: "I'm trying to change this thing but it just won't look like I want it to look (b/c of some random style selector somewhere)...WTF???". I'd love to hear your guys' insights into how to alleviate that problem.
The way styles work in Fireworks handles these cases pretty well. There's no barrier to overriding the properties of a style on an individual object, and it's easy to update the style with the new properties (or reset back to the style).
I'm not familiar with Fireworks styles...I'll check it out...thanks!