On Fri, Jul 17, 2009 at 2:47 PM, Bill Hart<[email protected]> wrote: > > 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.
I'll try to look at it this weekend, but IIRC, there was a utility that converted the XML file into Python code. > > 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 -~----------~----~----~----~------~----~------~--~---
