bojangles-devel Mailing List for bojangles
Status: Alpha
Brought to you by:
nehresma
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(39) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Wesley W. <ka...@te...> - 2003-06-23 00:51:42
|
I've noticed a lot of activity on the centrallix lists lately and I'm wondering if we need to get back to developing the bojangles WYSIWYG editor. Can we start off by listing what still needs to be done and such? ---- ---Wesley Widner -- - |
From: Wesley W. <ka...@om...> - 2002-09-12 14:07:48
|
After reading Nathan's post on the statusbar, I've decided to make this a prefrence option with a doAlert() method to decide how the message get's displayed. Wes Widner Network Administrator ------------------------------------------------------------------------ Gabriel Resources Toll-free USA: 8-MORE-BOOKS Division of OM Literature Outside USA: 706-554-1594 P.O. Box 1047 Extension: 201 Waynesboro, GA 30830-2047 Fax: 706-554-7444 ka...@om... www.omliterature.org, www.gabriel-resources.com -----------------------------------<>----------------------------------- |
From: Nathan E. <neh...@cs...> - 2002-09-12 13:09:59
|
hey wes, actually i disagree with showing the error in a status bar vs a popup dialog box. an application i used to use day in and day out did its error handling this way and it was one of the most annoying things about that program. i would do something and i had the only indication that the process completed or failed was on the status bar, unlike all the other apps i used. most applications do provide user feedback on errors and such via dialog boxes (microsoft is especially fond of them). if you have your heart set on this way of error handling, maybe we can make it a user preference or something. nre kai5263499 wrote: > kai5263499 Wed Sep 11 20:20:11 2002 EDT > > Modified files: > /bojangles MainWindow.java > Log: > Added a statusbar to display information we want the user to see without interrupting their workflow (like the "only one page" thing) WW |
From: Nathan E. <neh...@cs...> - 2002-09-05 19:31:41
|
hehe.. cool.. i think we'll wanna make this a command line option though rather than the default. ;) nre |
From: Nathan E. <neh...@cs...> - 2002-08-29 13:24:28
|
Wesley Widner wrote: > I?m having trouble with opening and deleting widgets and their > properties. I can remove them from the document DOM but it eludes me as > to how to tell the GUI that a widget has been added/removed. well to visually remove the widget you can just call the setVisible(false) method on the widget object. however, to actually remove it from its parent container you must call the remove(Component) method of the parent container passing it the widget to remove. but remember to do this depth first to remove all the widgets beneath the widget you wish to removing or you'll have resource leaks. also, don't forget to remove the widget, its treepath and DOM path from the correlation table. work has been pretty busy getting things ready for the begining of classes here next week so i haven't had many evenings to work on bojangles. things should slow down in the next week or two once classes start (i'm hoping :)). later, nre |
From: Wesley W. <ka...@te...> - 2002-08-29 00:23:10
|
I'm having trouble with opening and deleting widgets and their properties. I can remove them from the document DOM but it eludes me as to how to tell the GUI that a widget has been added/removed. ---- ---Wesley Widner -- - |
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 |
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: 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: 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: 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 03:48:05
|
hey, > 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) well, there's only one widget that can only appear once (that I can think of right now anyway) -- widget/page. Maybe you could just add some special handling for it? > - width and height for widgets like the checkbox where it isn't a > centrallix property but is needed by the ide for drawing purposes hmm... didn't think of that one.... if we allow custom images (which I forget if we do), maybe we _should_ have height and width specifers, even if it's just to be more constitent. > - 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). again -- I think there's only a limited number of these. Maybe there should be another definition file that maps a property to what to do with it. (ie, the image property sets the background image, the bgColor property sets the background color, the background property sets the background image, etc.) > > i'm not sure that all this kind of stuff should be going into > centrallix for > bojangles' use only. neither do I. I think Greg would concur. > 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. see my comment above about a definition file providing a mapping of properties to methods/actions/etc. > 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. I'd like 100% dynamic for basic functionality, with additional information needed added to a special file bojangles maintains about the widgets. IE, when a new widget is added to centrallix that bojangles has never seen, have it read the centrallix definition and provide basic functionality. Later, the bojangles developers can decide how to render it in it's full glory, and add 'extra' definition info the the bojangles definition file (while still getting the basic info from the centrallix one) That's the extent of my thoughts for the evening.. Jonathan |
From: Nathan E. <neh...@cs...> - 2002-08-25 03:28:50
|
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: Nathan E. <neh...@cs...> - 2002-08-25 00:35:46
|
> doc = SAXReader().read(); yeah, i'm a moron. i realized that you probably meant to instantiate SAXReader and weren't actually calling the function in XmlHandler. anyway, i fixed it and committed to CVS. nre |
From: Nathan E. <neh...@cs...> - 2002-08-25 00:19:39
|
hey wes, in the loadXML file you are calling a function named SAXReader with no parameters for which there is no method definition: doc = SAXReader().read(); i'm commenting it out and updating CVS to get it back into a working condition for now until we can get it straightened out. later, nre |
From: Nathan E. <neh...@cs...> - 2002-08-23 13:16:18
|
Wesley Widner wrote: > Yeah I got the email about the picturebutton class, and no, I didnt really > need the picturebutton class. cool. i'll take it outta CVS then so we don't have a cluttered repository. i think i'll also take out the textbutton and page widget classes since those are also not used anymore. sound good? > I can create the document and all but I can't figure out how to add elements > to it. You can see how far I got in MainWindow.java's loadprefs function. > Also I can't seem to convince bojangles to display the prefs dialog. oops. i misunderstood. to create elements (starting with the root element, of which there can only be one): Document d = DocumentHelper.createDocument(); Element rootElement = d.addElement("indiana"); Element subElement = root.addElement("basketball"); subElement.addAttribute("is_cool", "true"); that's all there is to it.. just keeping adding elements and so forth. > As far as what I want prefs.xml to hold... It needs to hold the full path to > the browser (i.e. /usr/bin/netscape), the hostname with centrallix on it, > the port, the dir where the test xml is held, and the last known save path. > The prefs.xml should have this in it. cool beans. sounds good. it'd be cool to have the prefs also save the setup of the GUI (like how big each splitpane is, etc.) eventually. that drives me crazy right now cause i'll change the size of the tree but i have to do it every time. :) oh well. prefs are our friends. later, nre |
From: Wesley W. <ka...@om...> - 2002-08-23 12:55:57
|
Yeah I got the email about the picturebutton class, and no, I didnt really need the picturebutton class. I can create the document and all but I can't figure out how to add elements to it. You can see how far I got in MainWindow.java's loadprefs function. Also I can't seem to convince bojangles to display the prefs dialog. As far as what I want prefs.xml to hold... It needs to hold the full path to the browser (i.e. /usr/bin/netscape), the hostname with centrallix on it, the port, the dir where the test xml is held, and the last known save path. The prefs.xml should have this in it. Wes Widner Network Administrator ------------------------------------------------------------------------ Gabriel Resources Toll-free USA: 8-MORE-BOOKS Division of OM Literature Outside USA: 706-554-1594 P.O. Box 1047 Extension: 213 Waynesboro, GA 30830-2047 Fax: 706-554-7444 ka...@om... www.omliterature.org, www.gabriel-resources.com -----------------------------------<>----------------------------------- -----Original Message----- From: boj...@li... [mailto:boj...@li...]On Behalf Of Nathan Ehresman Sent: Thursday, August 22, 2002 6:33 PM To: boj...@li... Subject: Re: [Bojangles-devel] dom4j help sure. i suggest that first we decide what kind of stuff will go into the prefs and maybe the structure of the document. did you have any particular settings in mind you would like retained between bojangles sessions? as far as the actual mojo to create an instance of org.dom4j.Document, this should do the trick: Document doc = DocumentHelper.createDocument(); that'll create an empty document to which elements can be added and queried. did you get my previous email about the PictureButton class? nre ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Bojangles-devel mailing list Boj...@li... https://lists.sourceforge.net/lists/listinfo/bojangles-devel |
From: Nathan E. <neh...@cs...> - 2002-08-22 22:33:11
|
sure. i suggest that first we decide what kind of stuff will go into the prefs and maybe the structure of the document. did you have any particular settings in mind you would like retained between bojangles sessions? as far as the actual mojo to create an instance of org.dom4j.Document, this should do the trick: Document doc = DocumentHelper.createDocument(); that'll create an empty document to which elements can be added and queried. did you get my previous email about the PictureButton class? nre |
From: Wesley W. <ka...@om...> - 2002-08-22 21:19:23
|
I'm trying to create a prefs.xml file but I can't seem to create the document and I can't find much help on the dom4j website. Can someone give me a hand? Wes Widner Network Administrator ------------------------------------------------------------------------ Gabriel Resources Toll-free USA: 8-MORE-BOOKS Division of OM Literature Outside USA: 706-554-1594 P.O. Box 1047 Extension: 201 Waynesboro, GA 30830-2047 Fax: 706-554-7444 ka...@om... www.omliterature.org, www.gabriel-resources.com -----------------------------------<>----------------------------------- |
From: Nathan E. <neh...@cs...> - 2002-08-22 02:31:40
|
Hey Wes, Did you run into anything in particular where you needed to have a PictureButton subclass of Widget? The reason I'm asking is because the main reason behind having the widgets dynamically defined in an XML document is so we don't have to create Widget subclasses for each widget centrallix has. So when they make a change to a widget, we don't have to modify any source code -- we just use the widget xml defs generated from the centrallix project. That's another item to add to the todo list i guess: finishing support for direct importing of the centrallix widget defs instead of using our own XML. :) nre |
From: Rupp, J. <Jon_Rupp@TAYLORU.EDU> - 2002-08-21 15:38:26
|
Wes and Nate, > > Do we want to include on-the-fly gzipping (and ungzipping=20 > when we get > > opening functionality)? I don't think this will have a=20 > major impact on the > > sizes of generated files but it would be interesting to=20 > implement...=20 Actually it will have a major impact.... $ ls -al kardia.* -rw-rw-r-- 1 centrall centrall 25692 Aug 21 10:35 kardia.app -rw-rw-r-- 1 centrall centrall 3797 Aug 21 10:35 kardia.app.gz -rw-rw-r-- 1 centrall centrall 42110 Aug 21 10:35 kardia.xml -rw-rw-r-- 1 centrall centrall 4599 Aug 21 10:35 kardia.xml.gz > I guess > > another advantage would be for posting the XML to=20 > centrallix via the web. As nate pointed out, it would be a PUT, not POST, but this would = _really_ be cool... Especially once we can open from it too... Of course, the other option is to impliment BDQS ;) > Yeah, on the fly gzipping would be cool to have as an option at save=20 > time, and autodetected at open. yeah, especially with 42k applications :) > > Also, what is the URL to get the source of a displayed=20 > kardia app? That would be: http://server:port/kardia/kardia.app?ls__type=3Dtext%2fplain (or if = there's a chance it could be gzipped, application%2foctet-stream might = be more appropriate) However, this wouldn't be too useful on a .app file (unless you write = that converter into bojangles :), but would on a .xml one... Jonathan |
From: Nathan E. <neh...@cs...> - 2002-08-21 14:59:23
|
Wesley Widner wrote: > Do we want to include on-the-fly gzipping (and ungzipping when we get > opening functionality)? I don't think this will have a major impact on the > sizes of generated files but it would be interesting to implement... I guess > another advantage would be for posting the XML to centrallix via the web. Yeah, on the fly gzipping would be cool to have as an option at save time, and autodetected at open. > Any of you centrallix developers know how we could accomplish posting an app > through an HTML POST command? actually, an HTTP PUT would be more straight forward for this kind of thing since centrallix supports PUTs. we san use the HttpURLConnection class with setRequestMethod("PUT") to handle the dirty work for us. > Also, what is the URL to get the source of a displayed kardia app? Could we > modify this same routine that spits out the source to accept incomming file > POSTS? nah, those are two different functions of the HTTP protocol (GET and POST). i suggest using PUT instead. here's a list of the HTTP RFCs that define how the HTTP protocol works if interested: http://www.w3.org/Protocols/Specs.html nre |
From: Wesley W. <ka...@om...> - 2002-08-21 14:46:05
|
Do we want to include on-the-fly gzipping (and ungzipping when we get opening functionality)? I don't think this will have a major impact on the sizes of generated files but it would be interesting to implement... I guess another advantage would be for posting the XML to centrallix via the web. Any of you centrallix developers know how we could accomplish posting an app through an HTML POST command? Also, what is the URL to get the source of a displayed kardia app? Could we modify this same routine that spits out the source to accept incomming file POSTS? </RANDOM THOUGHTS> Wes Widner Network Administrator ------------------------------------------------------------------------ Gabriel Resources Toll-free USA: 8-MORE-BOOKS Division of OM Literature Outside USA: 706-554-1594 P.O. Box 1047 Extension: 201 Waynesboro, GA 30830-2047 Fax: 706-554-7444 ka...@om... www.omliterature.org, www.gabriel-resources.com -----------------------------------<>----------------------------------- |
From: Jonathan R. <jo...@cs...> - 2002-08-21 02:58:08
|
Wes, > I am trying to figure out how to completely remove a widget from the IDE > (I'm focusing on tying it to the delete menuitem that appears on the > widgettree menu now) but I can't figure out that exactly gets added. > Nathan (or anyone else familiar with it) can you tell me how widgets are > created on the screen and if it would be prudent to include a Suicide() > method in the Widget class to completely remove any instance of a widget > (and it's children) from the screen and the dynamically generated XML. Hmm... interesting name for a class method... > Does anyone want to see true XML printing (to a printer) added? You mean the kind that spits paper everywhere? -- or is that some kind of java terminology that's over my head.... > Can someone give a overview of what would need to be added to include SQL > functionality. I'm presuming we would need to make connector widgets that > are invisible (according to the current Centrallix > specifications) populated > with an SQL query... Has anyone looked into this yet? Hmm.. I'm not really sure what you mean... the OSRC and dropdown both take an attribute (I think it's called sql) that gives the SQL query to run to get the needed information. > Could someome provide > me with a copy of kardia.app ported to xml? The script I used to build one is attached -- let me know if you have any problems with it (it's the exact same as the one I sent to centrallix-devel a few minutes ago). Hope that made some sense.... Jonathan |
From: Nathan E. <neh...@cs...> - 2002-08-21 00:34:59
|
Wesley Widner wrote: > I am trying to figure out how to completely remove a widget from the IDE > (I'm focusing on tying it to the delete menuitem that appears on the > widgettree menu now) but I can't figure out that exactly gets added. > Nathan (or anyone else familiar with it) can you tell me how widgets are > created on the screen and if it would be prudent to include a Suicide() > method in the Widget class to completely remove any instance of a widget > (and it's children) from the screen and the dynamically generated XML. yeah, basically for each widget there are four things that have to be removed that i can think of off the top of my head without looking back at the code. basically the 3 elements in the correlation table for each widget will need to be removed as well as the Node element in the xmlHandler's Document. items in the correlation table (and the xmlHandler's Node objects) will need to be removed using depth first traversal through the XML tree to be sure that all sub elements are removed in the correct order. the correlation table correlates a String path with a TreePath (maybe a TreeNode -- i forget without looking) with a Widget object and provides overloaded accessor methods to return a Hashtable containing all objects defining different aspects of the same widget based on the incoming parameter (String, TreeNode, Widget). This provides for easy access to the respective objects for each pane in the IDE (tree, form editor, and property list). > Anything else for the wish-list at the moment? Sure! :) Eventual things that need to be done: * open ability for an existing project * a DTD defining valid centrallix apps so that we can run our produced XML through a validator to see how we're doing. * save directly to centrallix using the HTTP's PUT (or maybe use POST) functionality * open directly from centrallix over HTTP * direct browsing of a centrallix objectsystem so we can know where to save to * an editor (and validator) to allow the user to directly modify the XML from within bojangles and see his changes immediately in the IDE (big project here) * a color chooser TableCellRenderer (that displays the color RGB hex value) and a color chooser TableCellEditor (that allows for graphically choosing the color desired) * an SQL editor allowing you to optionally browse datasources for attributes and so forth > Can someone give a overview of what would need to be added to include SQL > functionality. I'm presuming we would need to make connector widgets that > are invisible (according to the current Centrallix specifications) populated > with an SQL query... Has anyone looked into this yet? Could someome provide > me with a copy of kardia.app ported to xml? I'm not sure what all is going to be involved in that. I haven't even thought about this stuff yet (forms/connectors/objectsource widgets). I think these widgets will be the trickier ones to do. Shouldn't be too bad if we think through everything beforehand. nre |