The extra vocab ui.gadgets.controls contains a lot of random stuff (with no relation to each other than concerting gadgets) which are each too small for a vocab of their own.
Rather than unthinkingly moving all the pieces to their respective parents in basis (as I did before- sorry), I would like to ask which parts should be kept (and might be merged), which parts should be changed, which parts should be pitched, and which parts would do better in their own vocab. Please respond with any suggestions you have. Examples mentioned can be found at http://github.com/bogiebro/factor/tree/master Image buttons ============= 2 lines syntax: [ quotation ] IMG-BUTTON: filename Buttons in toolbars usually have images, not text. When deploying, it seems easier if the picture doesn't need to be bundled with the app, so I load the picture (to be found in the "icons" subdirectory of the vocab) into factor's image at parse time and keep it there. Models for buttons ============= 4 lines syntax: "label" <button*> Though buttons have a model, they don't use it be default. However, it can be useful to use the clicks of the button as the updates of the model, especially when you would otherwise have to curry other objects into the button's quot. (Contrast merger (quot style) to sudokus (model style)). Better model-fields ============= 6 lines syntax is exactly the same Model-fields don't work quite right. When the model you give changes, they won't update. In fact, the only time the use the model is to set it themselves, or to look at it at the start. Further more, their not watching the model means model-fields have to have a special field-model slot, going in the face of the gadget convention of using the model slot. Misc refactoring ================== 10 lines no syntax changes Model and action fields have the use of "editor" as their underlying editor built in. I parameterized it. Look at the poppers vocab for an example usage. Scrollers use sliders internally. I once again parameterized the constructor to take a slider class. Slider has no parameterized constructor like the rest of the gadgets. I made one. Output models ============= 4 lines syntax: gadget output-model All gadgets have a model. But the model that other gadgets can use might be something different. Rather than knowing all the ad hoc deviations, one can just use output-model on an object to get the model it intends to be use by other gadgets. Quot tables =========== 17 lines syntax: model <quot-table> Having to make a separate renderer for every table you make gets to be a pain. Rather, like buttons, it seems easier to just have a quot that gets called. That's what these do. Also, they have "actions" and "hooks" slots, which function like the button's models (changes the models on updates rather than calls a hook). Lists ===== 2 lines syntax: model <list> A very common type of table is a list: it takes an array of objects, and displays them one to a row. That's what these do. That's the lot. Thanks! ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
