> Messages are written anywhere you like; by default they go to stdout/ > stderr. You can set the LogObject of dabo.infoLog and/or > dabo.errorLog to any object you want, so long as it has a write() > method. > > As mentioned before, it is likely that an IDE would have its own > output window for such messages, as does the Command Window. > > For fun, run a form and open the Command Window. Right-click on the > interpreter area (top half), and select 'Unsplit'. Now type something > like 'print 7' - note that the output is not inline with the > interpreter commands. Now rclick again, and select 'Split'. The > output area returns, and output is once again directed there. >
That's very cool, will definitely try that later. I think you can ignore most of my comments in this area, the more I think about it, the more I realise they're simply artifacts of an incomplete application- ie this stuff will be taken care of by the IDE. > This is a bit more problematic. If you are setting up a bizobj > without a PK defined, it *should* be throwing errors or at least > warnings. I'm not sure where the line between making things easy and > coddling should be drawn. I understand what you're saying, and that depends on where you see dabo fitting in- for use by db/gui/3-Tier design beginners (like me) who may not know what they need to know to get things working, or where to start, or if it's targeting experienced developers who are experienced with DB design, rads, GUI frameworks, and just need a sensible toolkit. I'm hoping there's room to meet the needs of both groups ;-) > mb = self._getMethodBase(mthd, None) > isEmpty = (txt.strip() == "") or (txt in mb) > Yay, something I fully understand. Hmmm, I wonder what I did. I definitely had a situation last night where the editor had no visible text present (other than mb). My guess is I may have accidentally added some white space in the mb text- eg. (self)->( self), or similar. I'd never notice that. Or, an invisible control character? (Typing on the bus is not the most accurate in the world!) > > * Help/documentation > > -could include static copy of wiki docs (e.g. captured via wget) > > Where? As a separate download? > > > -api doc generated with something like epydoc with graphviz > > You mean like http://paul.dabodev.com/doc/api/dabodoc/ ? > Yes (and I just discovered the link to the API docs this morning- what are you using to generate them?) I think it'd be useful to have them available as a tarball, especially for those not blessed with always on high-speed interweb ;-) > > -in ClassEditor help- introspect dabo libraries and present doc > > strings in a tree widget-like thing? > > Not sure what you mean. Example? > Erg, sorry, will try to be more clear. I've played a little with introspecting(? terminology) - eg using dir() on classes, modules, etc, and then looking at things inside them- such as docStrings. I was wondering if it would be relatively easy to import dabo, dabo.ui, in turn, and then go through them and pull out the docstrings for each item. Then this info could be displayed as a live tree of current API documentation, even with search functionality. > > * Better code round-trip support with external editors > > -include needed/used imports in the generated code (so editors > > can auto-complete based on imports.) > > Import statements are indeed included in the code file. > They weren't for me- ended up adding them by hand, until I added them to the 'managed imports' in the class editor source editor. > > -would be useful if generated code from form was runnable, > > without needing extra wrapper script. > > The wrapper is for the .cdxml, which is what is getting run. The > separate .py file is an artifact designed to make it possible to edit > the code in your favorite Python editor instead of having it inside > the XML. I guess it would be possible to add some code inside an 'if > __name__ == "__main__":' block, but that would take some testing. > Please add a tracker issue for this. > > > e.g. dApp instance is in wrapper, so again, editors can't do full > > autocompletion > > Again, I'm not sure what you mean here. > I just bought wingware's IDE on the weekend, and I've been very impressed with it. There was something I was playing with in the generated code (sorry, now of course I can't remember what) for which it couldn't infer the type/couldn't provide completion hints. It was fixed when I manually added app=dabo.dApp() in the generated code file. Being curious, I wondered where this line was defined, and found it in the wrapper. Which made me wonder if the wrapper couldn't (optionally) be combined with the generated form code. But it's not a really big point! > > Also, should be possible to save class ui data seperately from > > code. Eg so class editor can be used to tweak ui positioning, > > labels, etc, and an external editor can be more easily integrated. > > That's exactly what is being done now. Sorry, again, I didn't explain myself properly. I meant in the menus it'd be great if there was a save current xml file only, and not save the code. i.e. save, open, and revert do these operations on both the code and the layout at the same time. If I'm editing the code in an external editor, I want to re-load the code in dabo, but not the form definition. But again, it's not a big thing; I've learned to save everything in dabo, then save the code in wingIDE, then revert in dabo- this picks up the latest code & form definition quite nicely. > Ummm... forms *are* custom, re-usable classes. They just can't be > added to other forms, since, well, they're both forms. > Sorry, that's my inexperience showing. > > and if the custom class is created with code, if that code will be > > also be imported when inserted into another form (I believe not?), > > Of course it will. What good is a custom class if you can't save > behaviors? > > > and if it is, wheiter edits are local to this instance, or affect > > all instances in the application into which it's inserted. > > This is more complex, and depends on inheritance. If you edit > anything in the instance of a custom class, that changed value is > preserved. Otherwise, the class definition will determine what is in > the instance, and if that changes, so will the instance the next time > it is run. > > Example: you create a custom panel-based class, and set the panel > background to red. In your new form, you add two instances of the > panel-based class, and change the BackColor of one to blue. Now let's > save your new class, then open the custom panel class and change its > BackColor to green. Save the panel class, and then re-open your new > class. The instance that you had changed to blue is still blue, but > the one that you hadn't changed is now green, just like the superclass. > Wow- that is so cool (and a very good explanation!) So from the form (the thing into which I'm inserting the custom class) editor I can't see the code/behavior built into the custom class. But it is there. Any code I put into the methods of the custom panel from the forms editor will actually override that code. That's beautiful. Small suggestion; maybe there could be a GUI element that appears in this case that can display the original code for that method in the custom class (or opens the custom class), or at least indicates that there is some default behavior for this method. > > * Insertfrom DE in Class Editor- would be nice to have an 'insert > > in table order' option, not just alpha-order > > The order of columns in a table is undefined in SQL. I know that > several backends do preserve column order, but it really is > meaningless. Alpha sort just helps you find the ones you want easier; > you then arrange them the way you want. > Oh. I didn't know that, though it does make sense. I'm learning a lot today! > > * Sizers in class editor- after deleting content from a slot, keeps > > size of last contents. Might be better if it repacked/ > > redistributed the sizes. > > It might in some cases; in others it would be annoying. > Yip, I can see that. Now I have a better idea of what's going on this doesn't bother me anymore. Thanks again Ed- Julian _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
