On Fri, Jul 17, 2009 at 11:57 AM, Bill Hart<[email protected]> wrote: > > 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: >
Did you look at PyQt? I haven't used it for a long time, but it used Qt's Designer which worked pretty well and I think PyQt includes the Scintilla text editing library which does syntax highlighting, etc. > * 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 -~----------~----~----~----~------~----~------~--~---
