Hi Case, yes I actually found out about that. There is pyuic4.
Here's the thing, from my point of view now after doing a lot more reading, there are only 3 options: 1) Qt Designer + pyqt4 + pyuic4 + QScintilla2 Advantages: good documentation, less buggy than other options Disadvantages: who knows whether pyuic4 can handle scintilla UI elements, look and feel is not fully native, IDE not integrated with GUI designer 2) wxPython + Glade Advantages: fully native look and feel, reasonable documentation Disadvantages: glade does not support scintilla, though wxPython has it, IDE not integrated with GUI designer 3) wxdevcpp Advantages: definitely has full scintilla support, everything in one place, the GUI designer, scintilla, the IDE Disadvantages: writing C++ is harder than writing python for this sort of project due to lack of decent standard libraries, I had some trouble with the GUI designer in wxdevcpp, portability is not all it is cracked up to be Bill. 2009/7/18 Case Vanhorsen <[email protected]>: > > 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 -~----------~----~----~----~------~----~------~--~---
