I looked into spe, which uses wxGlade and XRC for GUI designers. Well wxGlade is actually really easy to use (much, much easier than BoaConstructor), though it too segfaults and drops you to the desktop from time to time. However it does have an autosave which works.
There are two problems, the styled text control is nowhere to be found and it just generates code. If you then modify that code you can't then go back to wxGlade and keep developing other parts of your GUI. All of these GUI developers also try to jam all the code in a single class. Instead of subclassing the relevant widgets and allowing you to customise the widgets for your own use, the entire GUI is created in one single top level constructor. I have to admit that wxGlade had an option for adding extra code to a widget. Perhaps this then subclasses for you when the code is generated, I didn't try that. Anyhow, no stc, no use. XRC was harder to use. It did look like it had a subclassing feature, but it isn't really WYSIWYG. The idea of including it in spe is obviously that you first put the structure down in XRC, then import it into wxGlade and adjust it to your liking, then generate the code. Then you go to work on your code. I suppose for some projects that may actually be feasible. But no stc in XRC either. Another bug I noted is that pychecker, which comes with spe, complains about perfectly working code generated by spe. Bill. 2009/7/17 Bill Hart <[email protected]>: > As will have been observed, I've been thinking hard over the last few > weeks as to how we can make MPIR contribution easier. In short it > would be good to have more core developers. In particular I've been > working on, or planning: > > * Set up a Git repo and encourage its use > * Write developer documentation > * Write an FAQ > * Write an MPIR digest detailing development progress every three weeks > * Write an MPIR most wanted list, of most needed contributions > * Write a set of scripts or a program which makes adding new files to MPIR > easy > > In this post I'll concentrate on the last of these which I've been > looking into for a couple of days. > > The idea I had was to begin work on a cross platform windows program > for MS Windows, OSX, KDE, etc, which would take the pain out of adding > new files and modules to existing C maths libraries. With a little > configuration it would essentially write all the boilerplate for the > user, including stubs for test code, the function being added, and > basically do all the configure and make stuff that needs to be done > automatically. > > I decided to look into writing a basic programmer's editor, linked > with Git, which would have this extra functionality of adding > boilerplate code for new functions. The first step was to write a > basic windows editor with C syntax highlighting and block folding. > > As python is cross platform I looked for libraries for Windows > development. Initially I found: > > * Python 2.6, which is cross platform > * pygments - for syntax highlighting text, outputting it to rich text format > * wxPython - a python port of wxWidgets, a cross platform windows library > * BoaConstructor - a RAD tool for fast development of wxPython code, > with a GUI designer and IDE > > Here are my notes per package: > > * Python 2.6 - installs fine on my Windows box. Has a command line and > a windows editor. No problems with this as far as I know. > > * Pygments - is distributed as a python egg. There is a version for > python 2.6. So I look up how to install a python egg. Apparently the > easiest way is to use easy_tools. To get that you have to get > setup_tools. There is no Windows version of this for python 2.6. But > you can get setup_tools for python 2.6. It is distributed as a python > egg. Arggh!! > > So I uninstal python 2.6 and install python 2.5. I install setup_tools > and pygments. If I need to use it, I probably can, but see below, as > stc may be a better option. > > * wxPython - installs fine and appears to work. Implements a styled > text control (stc) widget which has a built in lexer for C++ and the > ability to syntax highlight C++. It also provides options for block > folding. It has essentially been designed specifically for writing a > programmer's editor with all the standard features. Documentation > however, sucks. In order to implement syntax highlighting, one needs > to make use of options such as STC_C_COMMENTLINE, which as far as I > can find, are basically undocumented. > > In fact, there is basically no documentation on the wxPython website > for the stc control. However someone has gone to the trouble of > attempting to document it here: > > http://www.yellowbrain.com/stc/index.html > > However, the meaning of the various stc variables is not listed. Only > a list of possible variables is given, here: > > http://www.yellowbrain.com/stc/varwrap.html > > The stc also provides a lexer for asm syntax highlighting, though I > have no idea which asm format it highlights. Again that is > undocumented, and a google search does not help with finding proper > documentation for any of the stc. > > * BoaConstructor - Installs fine. But full of bugs. > > 1) You have to put all graphical widgets down in precisely the correct > order first go in the GUI designer, otherwise you have to do your > entire project from scratch, as there is no easy way to change it once > it is down. For example you can't remove a panel and replace it with a > sash window if at some point you change your mind. > > 2) When any widgets are moved around, they do not render properly. You > can't see them or they cause blag drag marks across all the other > widgets. > > 3) There's no easy way to select a widget to delete it. The only way I > have found is to click on it in the inspector, hope that some black > sizer dots appear, click precisely on one of those dots, then click > delete. There's no way to graphically select the widget you want to > delete. > > 4) It's impossible to move some widgets. Even selecting them via the > workaround in 3 does not allow one to move the widgets, as you cannot > move them by clicking on the sizer dots, you have to click in the > widget's center, which causes another random widget to be selected. > > 5) BoaConstructor crashes frequently, losing your work. And I don't > mean that python just gives some kind of error message. The whole > thing actually segfaults and drops you back to the desktop. > > 6) If you rename any of the default names, like frame1, that > BoaConstructor gives the widgets, it loses track of them and you have > to start your entire project from scratch. This is irrespective of > whether you rename them in code, the inspector or otherwise. > > 7) It is very difficult, though not impossible to figure out how to > associate menus with options on menubars. The logical way of doing > this via the inspector has not been implemented. > > 8) Many widgets come up with default sizes of zero, or panes of size > zero. Thus there is no way to see them, resize them, add things to > them, etc. > > 9) BoaConstructor regularly loses the connections between various > widgets, e.g. if you add a sash window into a split window and a text > control the other side of the sash in the split window, the inspector > frequently loses the association. > > 10) BoaConstructor checks your code for you, and helpfully prevents > you from entering the GUI designer if you have written correct code, > by telling you that you have supplied the incorrect number of operands > to various functions. If you supply the incorrect number as it wants > you to, it either doesn't compile, or BoaConstructor simply thinks you > still have the incorrect number of operands. > > So quite clearly BoaConstructor is still far too underdeveloped to be > stable. It's only a 10 year old project. Using it is pointless. > > So perhaps I made the wrong choice. What else is available for GUI > design which operates with xwPython? > > Two other highly recommended options are wxGlade and PythonCard. I > tried the latter. > > * PythonCard - The Windows installer failed. I went back to an earlier > version of python card. The Windows installer failed. This tells me > they have precisely zero users on Windows, and they don't know about > it. Eventually I got the source. I opened the documentation and went > to the install instructions. I clicked on Windows install and got a > dead link. I clicked on OSX install and got a dead link. I eventually > found a document somewhere telling me how to install on some weird OSX > variant. I got just enough info from that to tell me how to install > PythonCard. > > I started reading how to use it. Instead of being an IDE, it is a DE, > i.e. it is not integrated at all, but is a serious of completely > unrelated tools. The source code it emitted was also not doing import > wx, as I expected, but import card. So it is implemented as a library > on top of wxPython. Given that this was next to useless I gave up. > > * wxGlade - admits on their website that it is not an IDE, but simply > a designer and the generated code only displays the widgets, and no > more. It recommends that people after an IDE use PythonCard, > BoaConstructor or spe. > > So I look into that last option: > > * spe - the website is shocking. I couldn't make head nor tail of it. > It appears that you have to download the source code from > subversion.... Haven't tried that out yet. > > So I backtracked at this point and thought, perhaps wxPython is not > the best choice for a widget toolkit for cross platform windows > development. > > Everywhere I look however, I see two main options recommended. > wxPython and TkInter, the standard GUI toolkit distributed with > Python. Apparently every year it is a standing tradition to affirm > TkIinter as the standard GUI library distributed with Python, however > numerous people think it is dead, because of wxPython. > > Well maybe python is the wrong language for this sort of thing. But > what else is there Java? Yuck. C++, too much work, though wxWidgets is > available for C++ and was probably available for C++ first. But I've > looked for decent RAD and GUI designers for C++ before, and all the > good ones are commercial. > > Probably these days, the hot area to develop such cool tools is over > the wire, i.e. browser based stuff. But I don't want to reinvent the > wheel, and I have little experience with anything web related other > than Javascript, which is far too slow and difficult to code, from > experience. Too many systems to learn there otherwise. > > This is proving to be too frustrating. I'm going to look into spe, and > also see what the canonical option for RAD/GUI design with TkInter is, > including looking for an already implemented widget for source code > highlighting. If I don't find what I am looking for, I'm officially > giving up on the windows route. > > That would leave bash scripts maybe, or a command line C or python > program. But I've no idea how to make the very complex feature I want > to eventually implement, work from a command line interface. If I > start this project, I obviously want it to go a lot further than just > allowing one to add a few files to maths libraries. I want to add > parsers which will allow for simplification of various repetitive and > boring things we have to do over and over again when writing C maths > libraries. At the very least it will need to parse C code and assembly > code, but there's a whole lot more to what I had been thinking > through. > > Bill. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
