The other two serious options for cross platforms Windows development are Qt and GTK.
Qt looks like it is basically in C++. Actually it has a very fancy looking website which makes it look like a really nice product. I didn't actually try it out. To develop with Python, one uses PyQt4, which does include support for the scintilla text control object. But of course there is no GUI designer for PyQt4 which spits out python code. Instead, my guess is that at best you could use the Qt designer and either it spits out C++ or XML. How you would use the latter I don't know. The one big drawback of Qt is it defines its own windows style or theme, instead of using the native one of they system. GTK has a very similar list of drawbacks. There, most definitely XML code is generated, not python or C++ code as such. One then uses libglade to parse the XML and draw the GUI. I can't quite get my head around how this works with a GUI designer. So you design your GUI with their designer. That gives you a quantity of XML. You then fire up python and import pygtk. You pass the XML to the library to draw the GUI. But then I'm not sure I understand how you capture all the events from the GUI in your python code. Anyhow, one big problem with GTK is it is entirely unclear whether scintilla is available with the latest PyGTK. There's some version on the net with no documentation whatsoever and a very scant website which claims to work with version 2, but doesn't tell you whether it supports the latest version 2.4 of the toolkit. Again GTK provides its own styles instead of using the native styles of the system. You can select styles that are supposed to look like the native styles of various systems, but I'm not sure that is the same thing. Basically if I understood correctly, you could select an XP theme, and every system it runs on, it would use a theme which looks like XP. Dunno. Doing this whole project in C++ looks infinitely more viable than doing it in python. In python you have to rely on someone having ported all the relevant C++ libraries for you or providing comprehensive python bindings and complete documentation. You also have to rely on one of only a handful of GUI designers, which all seem very rudimentary and broken. This all surprises me a lot. I imagined python with its massive library support to be a more thorough option for windows development. I am sure there are people who have successfully used it for Windows development, even for things similar to what I want to do, but I suspect they had to put in a lot of very hard work. Basically IDLE does syntax highlighting (for python) with the TkInter library. But from what I have read, that is to be avoided at all costs. I will have to think hard about whether I want to write anything in C++. I haven't written any for years, and it isn't a terribly nice language. It can make things much harder than say python. Remarkably the most popular language for this sort of stuff is apparently Java. But I'm not going to use Java as I've written less than 10 lines of Java in my life and didn't feel comfortable with the language at all. If I decide to do any Windows development it will be with a capable GUI designer on C++ or Python. Python would have been nice as a language choice, but it seems ill supported for this particular task. Someone should fix BoaConstructor. wxPython is very capable and extremely well implemented as far as I can tell. Even better, someone should make wxGlade into a proper IDE and extend its capabilities somewhat. The design philosophy of spe seems to be to stick a python IDE on the front end of wxGlade. But that isn't going to cut it, though it was a nice idea. I notice the project seems to not be under active development any more. Bill. 2009/7/17 Bill Hart <[email protected]>: > 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 -~----------~----~----~----~------~----~------~--~---
