Thread: RE: [Bojangles-devel] dynamic widgets
Status: Alpha
Brought to you by:
nehresma
From: Wesley W. <ka...@om...> - 2002-08-25 14:17:49
|
Just a preliminary thought... Shouldn't the page widget be auto-added in bojangles? Every application will need one, and I don't think we can import xml into other xml (which would be cool), all apps will need to be edited as a whole (so every app will have a page widget that encompasses everything else. And now thoughts ordered by the questions from Nathan: From this line of thinking, why do we even need a max_per_document for anything other than a page? I think the default size of a widget would be something that centrallix could use as well. So adding that to the widget.xml would makes sense (IMHO). As far as other things that would be bojangles-specific, like border status and such, I like the idea of a widget_definitions directory with XML files defining this sort of thing. I think the bgcolor is something that (again) centrallix could use as well for lazy app designers that want to just create default-colored widgets and don't want to mess with making things fancy (the same can be said for imagebuttons). In summation, I think we should put some default properties in the widget.xml file as a prevenitive measure against someone hand-coding an app file and forgetting a property or two. However, since html nativly knows what to do with buttons, imagebuttons, checkboxes, and textboxes/areas. I think we should keep these definitions to ourselves (actually I see this as the only thing we would need to keep separate from centrallix). ---- ---Wesley Widner -- - -----Original Message----- From: boj...@li... [mailto:boj...@li...] On Behalf Of Nathan Ehresman Sent: Saturday, August 24, 2002 11:29 PM To: boj...@li... Subject: [Bojangles-devel] dynamic widgets hey guys, i was working on getting bojangles to work with widgets.xml from centrallix-doc. i'm running into more and more issues with dynamic widgets and want to hash some of this out on the list. the problem i'm running into is that i need all kinds of data about each widget that maybe shouldn't go into centrallix's widgets.xml. things like this: - max_per_document - how many of this widget can be in an application (example: widget/page should only be 1) - width and height for widgets like the checkbox where it isn't a centrallix property but is needed by the ide for drawing purposes - speaking of drawing purposes, another thing is how each widget presents itself to the IDE. for example, textbuttons should have a raised border, edit boxes should be lowered, imagebuttons should be able to display the image, that kind of thing. - what does a particular property mean (like bgcolor -- call setBackground method on widget). i'm not sure that all this kind of stuff should be going into centrallix for bojangles' use only. here's my current line of thinking: what if we would have subclasses of the Widget class to handle things such as the widget's visual representation in bojangles and use the widgets.xml def to handle properties and individual property types, etc.? this does mean the widgets in bojangles need to be synced with those in centrallix when new ones are added, but leaves the us with the dynamic property list functionality. what do you guys think? bad idea? good idea? i like 100% dynamic, but we just can't be 100% dynamic without adding all kinds of crazy stuff to widgets.xml for handling drawing in bojangles that i can see. other ideas? nre |
From: Jonathan R. <jo...@cs...> - 2002-08-25 14:52:20
|
Hey all, > Just a preliminary thought... > Shouldn't the page widget be auto-added in bojangles? Every application > will need one, and I don't think we can import xml into other xml (which > would be cool), all apps will need to be edited as a whole (so every app > will have a page widget that encompasses everything else. sounds like a good idea to me > And now thoughts ordered by the questions from Nathan: > > >From this line of thinking, why do we even need a max_per_document for > anything other than a page? > > I think the default size of a widget would be something that centrallix > could use as well. So adding that to the widget.xml would makes sense > (IMHO). The only widgets that have an implicit size that don't allow the designer to specify a size is the checkbox (I think). I think we _should_ add the size to widgets.xml for these. There will be some widgets that _dont_ have a size though, because they are non-visual. How to handle that is another problem :) > As far as other things that would be bojangles-specific, like border > status and such, I like the idea of a widget_definitions directory with > XML files defining this sort of thing. I would actually vote for one file with all the data in it -- it just seems cleaner to me. > I think the bgcolor is something that (again) centrallix could use as > well for lazy app designers that want to just create default-colored > widgets and don't want to mess with making things fancy (the same can be > said for imagebuttons). bgcolor is in widgets.xml because it's a property of objects. However, widgets.xml doesn't tell bojangles how to represent it. Now you could just write the code that maps bgColor to SetBackgroundColor() and background to SetBackgroundImage() (I don't know the real function calls, but you get the picture), or you could put that stuff in a definition file and do the mapping at run time. Just a thought. > In summation, I think we should put some default properties in the > widget.xml file as a prevenitive measure against someone hand-coding an > app file and forgetting a property or two. Yes, default values (the values that centrallix will assume if you don't fill anything else in), should go in widget.xml. > However, since html nativly > knows what to do with buttons, imagebuttons, checkboxes, and > textboxes/areas. I'm not sure what you meant by this... centrallix does not use HTML buttons, imagebuttons, checkboxes, textboxes, or textareas. > I think we should keep these definitions to ourselves > (actually I see this as the only thing we would need to keep separate > from centrallix). Do you mean the special things (like border status, mapping of attributes to function calls, etc.)? -- If so, then yes, I agree -- don't clutter the centrallix documentation with things for bojangles. Jonathan |
From: Luke E. <leh...@cs...> - 2002-08-25 18:27:04
|
On Sun, Aug 25, 2002 at 09:52:08AM -0500, Jonathan Rupp wrote: > Hey all, > > > Just a preliminary thought... > > Shouldn't the page widget be auto-added in bojangles? Every application > > will need one, and I don't think we can import xml into other xml (which > > would be cool), all apps will need to be edited as a whole (so every app > > will have a page widget that encompasses everything else. > > sounds like a good idea to me FYI, it is possible for the frameset widget to be present before the page widget. And in that case, it is possible for there to be more than one page widget in the same app. ;) Just thought I'd confuse things a bit more for you. |
From: Nathan E. <neh...@cs...> - 2002-08-25 18:59:29
|
> FYI, it is possible for the frameset widget to be present before the > page widget. And in that case, it is possible for there to be more > than one page widget in the same app. ;) Just thought I'd confuse > things a bit more for you. the reason i originally made it so you can start with any container widget was so that you can use bojangles to write just part of an application. say most of it is already done but you needed a GUI to design a new window or something quickly. bojangles away (i love using it as a verb) and then just copy the output code into your application where you want it. i like your ideas guys as far as having two xml defs: the one from centrallix, and then the one we use that handles the mapping of properties into something recognizable for graphical representation. we could probably even remove some of that data that i asked jon to put into the widgets.xml file in centrallix if we handle it ourselves. i'm thinking of the subelements "class" and "visible". cool. i think i'll start working on this. btw, i needed to get some stuff straightened out before i could finish up the adding and removing of properties and that's why i'm working on this right now instead of finishing up that project. thanks for the ideas. nre |
From: Jonathan R. <jo...@cs...> - 2002-08-25 22:07:53
|
Hey all, > > FYI, it is possible for the frameset widget to be present before the > > page widget. And in that case, it is possible for there to be more > > than one page widget in the same app. ;) Just thought I'd confuse > > things a bit more for you. > > the reason i originally made it so you can start with any container widget > was so that you can use bojangles to write just part of an > application. say > most of it is already done but you needed a GUI to design a new window or > something quickly. bojangles away (i love using it as a verb) > and then just > copy the output code into your application where you want it. Ah, ok -- that makes sense. We also might want to get the XSLT to convert it to centrallix structured file format then too. > i like your ideas guys as far as having two xml defs: the one from > centrallix, and then the one we use that handles the mapping of properties > into something recognizable for graphical representation. > > we could probably even remove some of that data that i asked jon > to put into > the widgets.xml file in centrallix if we handle it ourselves. > i'm thinking > of the subelements "class" and "visible". They might not be a bad idea to leave in there -- that kind of information would be useful to know regardless, and might even facilitate the grouping of the docs at some point if we get too many widgets :) > cool. i think i'll start working on this. sweet. :) Jonathan |