Hrm… very interesting. I assume this would include the ability to declare arbitrary “classes” for widget types, or would it be assumed that all widgets would inherit a monolithic style? The former could work for my intentions… but I still see this as ending up with the same “problem”. In the absence of the style definitions, you’d be back to defaults.
I don’t know. Sounds like a lot of work to end up with what sounds like the same basic functionality to me. 
That’s a good approach.Regarding the stylesheet option, something like:
<cabbagestyle>
image: colour("red")
button: colour("pink"), text("Button")
hslider: colour(green"), range(0, 1, 1, 1, 1)
checkbox: value(1), text("Mute"), colour:0("red)
</cabbagestyle>
Which can be imported when creating your main form:
<Cabbage>
form size(400, 300), import("darkTheme.xml")
hslider ...
All widgets would adhere to this monolithic theme when created. But it doesn’t give as much scope as macros does it? The problem is when you import two plants that have the same macro names. In some cases this is ideal, in others it will create problems and confusion.
Btw, Csound 7 will support namespaces which should make this easy to modify later. At present I think it’s planned to use them for UDOs. So one could give all UDOs a namespace, so a UDO called phasor in your personal collection might be called like:
aSignal myUDOs::phasor 10
That would mean we don’t have to prepend a unique ID to each UDO name which is a little ugly.
I think that functionally, this stylesheet idea would be no different to me than having the unexpanded macros there. All widgets end up the same with a base style. Definitely cool and useful in certain situations, but doesn’t entirely fill my specific needs. I could probably set a baseline of some sort (particularly plants and maybe fonts), but I would still need macros or have to keep track of widget instances and set them manually via a UDO/method to end up with different classes of certain widgets. For example, having different colored knobs based on function (pan,drywet,effect,filter,gain)
That’s an implicit issue with using macros in just about any situation or language, isn’t it? Ideally macros wouldn’t be defined in the included abstraction files anyway… but really, as usual, it should be up to the user to not do something silly with their macros and definitions. You can’t protect entirely from the user doing something dumb or counterproductive… I’m proof of that 
Tho if you want to go overboard… I could always request ifdef ifndef and undef for the cabbage section… those could definitely help that situation 
I saw some of the discussion about that, it looks very interesting and useful.
I just updated the OSX installer for Cabbage 2, see beta releases page. This version supports the new import() system. It also includes a few simple example files in the Instructional folder (customPlantImport and GridSeqneucerImport) that show how to import plants from xml files. It’s still quite raw so please don’t expect everything to just magically work out of the box, it’s relatively untested! For now you can only import one plant. I will remove this restriction shortly. I just don’t want to give you guys too much rope!
You can however import as many macro files as you wish, i.e., import("macro1.inc", "macro2.inc", etc)
Oh and macros should also work across imported plants.
Sounds awesome! Looking forward to trying it out. Any chance of a lite installer (particularly OSX) getting added to the mix?
Just curious, do you mean only import one type for multiple instances, or only one instance of any type at a time?
You can only import one plant xml file at present but you can instantiate as many of that plant as you wish.
Cool, that’s what I figured but wanted to be sure! That means once I get that far I’ll try creating some multi-instance widgets to test with first, already have a good one picked out for it 
But first, I’m having some difficulties importing a “simple macro” include file, such as the ones I’m using for color/style definitions etc. I didn’t see anything in the examples that helped me and I tried a few random ways with no success, so I have a few questions about that:
I’ve tried:
#include “includes/tg_colors.inc.csd”
#import(“includes/tg_colors.inc.csd”)
import(“includes/tg_colors.inc.csd”)
and having the import on the form declare like so, no luck yet.
form caption("GUI Test") size(380,294), pluginID("tgui"), import("includes/tg_colors.inc.csd"), $ROOT
Does a simple macro file need to be structured as xml too with a cabbage section?
Does it have any filename (purely naming here, ignoring actual content) requirements that distinguish the import behavior (such as .xml vs .inc vs .csd) that defines or alters how cabbage will treat it?
Should this be done as part of the form declaration like a widget import, or as a standalone cabbage section import statement, or is this somehow done differently?
Assuming the import is supposed to be done on the form declaration line, would the $ROOT usage in the above example be valid if ROOT had just been defined in the file that was just imported on that same line?
Unrelated to that, does cabbagelite not have anywhere to check the current running version? I ran into issues before I realized this version installed over cabbage1, not cabbage2… so I was puzzled by the wrong version message for a little bit in the full gui version.
Anyways… once I have simple imports working, I’ll start converting some widgets into importable versions to try out and give some feedback there. Very excited to start trying that out!
edit: just FYI, a bunch of things appear to be working as expected in c2, but not in c2lite. the “radiobutton” vs “radiobutton2” define order thing is still an issue. Not a big deal to me, just pointing out since it’s fixed in the full version Same goes for the instrument title not appearing when launched from sublime (aka via command line options/arguments), instead just getting “CabbageLite”. Both of these issues were discussed here, if you need more info: Cabbage2lite pre-testing: 1
It also seems like my plant woes may be specific to c2lite. I found that if I copied your new examples (along with the .xml files) to a new folder and tried to run them from there rather than from the builtin examples dir, it quietly fails to import and I get an empty screen. But if I switch my build system to the full c2, the imports work just fine.
This makes me wonder if the c2lite didn’t get rebuilt before making the package? But without a version #, there’s no way to be sure 
Yup, that’ll be what happened… let me cook you up a fresh version…
Can you try again? New version just in.
That’s the way to do it. I’ve put an example into the Instructional folder called macroImport.csd. See how that works.
No.
No, it’s treated as plain text. All that’s happening is a textual expansion.
I probably answered that one above, it should be part of the form declaration.
Hmm, my initial reaction is no, but it could be worth trying! We could be lucky 
Sorry about that, I should say it’s probably best to rename Cabbage 1 first! I will add an about dialog to CL to inform users of the version number. It will probably be the same as the main Cabbage just to keep things simple.
I get a 404 on the OSX installer now over here: Latest beta packages available here (updated links)
Was that the installer I should be trying?
And sorry, I actually answered a few of my own questions once I realized c2lite wasn’t updated and the new c2 was where c1 used to be. I had tried everything and nothing was working, but once finally actually testing in the new version of full c2 I was able to stumble through just fine.
Actually, my test last night with it seemed to work!
That’s fine, and probably the best bet. Just having somewhere to look tho would be useful, otherwise there’s no way to report bug against specific version, or make sure I’m actually running the updated one I meant to be 
Gees, sorry about that. I just updated the link. It was a long day at work. Try again and let me know. Relative paths in the import() stuff seem to work fine for me here. Hopefully it’s the same for you!
No worries at all. Installed and working… I’m in business now, thanks a bunch!
Relative paths are indeed working, and the $ROOT macro DOES expand when it’s imported on the same line, confirmed.
I’ll play with this for a bit today and make some importable widgets. I’ll probably start a new thread with any feedback and problems encountered later tonight.