We Keep Coding

is ist possible to combine lazarus forms and python procedures to an deliverable application?

At the moment I have to develop some python tools, because nearly every software I use (QGIS, FreeCAD, Gimp, probably my toothbrush ...) has a python interface.
I would like to write lazarus applications (with button, edits and all the nice components), that uses my python routines in the background and show the results in lazarus.
Is there a way?

Here's an example at the Lazarus forum how to use the Python for Lazarus package. From Lazarus Online Package Manager it installs automatically.
https://forum.lazarus.freepascal.org/index.php/topic,43557.msg305118.html#msg305118
Set PythonEngine.IO to PythonGUIInputOutput, then choose a control for PythonGUIInputOutput.Output to show data and your good to go.

You could try to use
https://github.com/pyscripter/python4delphi
that is a binding between the two.
There is also always available the possibility of implementing a web server with python and publish its services on http for use from lazarus.
Note however that if what you want is a GUI then Qt (using PyQt or PySide) is a very complete GUI library with a very good binding for Python... it has all the widgets you can imagine, and then some more.
In that case all the code you write is in Python.

Changing GUI library : QT, wxPython... anything else?

Actually working on a project in python with PyQT, we choose to create widgets that were "unpleasant" or that didn't have a good enough behaviour.
So, we finally found that QToolbox, QDate and some others had a behaviour non acceptable for the project, so we had to adapt these.
We had also to create a complete new widget : A scheduler.
As we were creating these, it has been decided that it took too much time. So we were asked to think about other libraries.
I actually found a project of a scheduler in wxPython, that actually looks like what we want ( but we believe that we'll have to adapt it a lot ). Here it is : http://code.google.com/p/wxscheduler/
So, I ask everyone that have some more experience than me in GUI programming in python : Do we need to start again the project in anything other than PyQT? I know the question is weird, but what you need to know is :
The project has now been going on for 2 months
I know only PyQT, and started working in python 2 month ago
We are currently 3 in the project, and we currently know only PyQT
We have currently managed a lot of the PyQT widgets, and were starting to code these new widgets.
Please help us =)
Thanks
Edit : I should have add that the project is opensource and multi-platform

Feel free to look at other libraries if you like. Robin Dunn, the creator of wxPython, recently started working on PySide and he found it somewhat similar to wx, so you might find that wxPython will fit your brain fairly well too. I certainly think wx's class names are more intuitive than PyQt's. The only way to know for certain is to actually experiment a little and see if it works. I will say that the wxPython community is one of the best Python communities I've dealt with over the years.

One possibility would be to use an HTML scheduler control via QtWebKit. If your UI can accommodate a QWebView in the place where you'd otherwise have a custom scheduler widget, there are probably a number of excellent scheduler widgets (implemented as jQuery plugins, etc.) you could choose from.

we choose to create widgets that were "unpleasant" or that didn't have
a good enough behaviour.
Why don't you create "pleasant" widgets ?
so we had to adapt these.
Yes. It is the solution.
it has been decided that it took too much time
Don't you think it would take much more time if you change the whole GUI API ?
As for i know, there is not such native Scheduler in any Python GUI library, especially one you could use with Qt. I don't think it would be so long to recreate one, unless you have very specific needs, that would confirm you wouldn't find a such existing thing in an existing library.
Concerning wxScheduler, i guess you can have a look to the code, even it uses wxWidget and you're working with Qt, to get an idea how to do it.

what suits the most for creating interface?

i have an application of text to speech convertor and now want to prepare an graphical interface for it.I did whole of the coding involved in python..i want to know which languages can be used for creating the GUI so that i can connect my python code to it easily..can python be used for creating the gui..
as i have no previous experience of creating the gui,would like to take ur suggestion for making the gui which is attractive not just plain thing such as we get using vb or anything else..
looking for your suggestion plz

There are many GUI toolkits for python:
http://wiki.python.org/moin/GuiProgramming
I would look at PyQT and wxPython first.

Yes, a GUI can be created in Python, I recommend wxPython.

You can find a list of GUI programming packages for Python in this page http://wiki.python.org/moin/GuiProgramming

If you're unfamiliar with Python GUI development, I recommend Glade. It's got a fairly intuitive interface, good documentation, and allows you to get things done quickly.

questions re: current state of GUI programming with Python

I recently did some work modifying a Python gui app that was using wxPython widgets. I've experimented with Python in fits and starts over last six or seven years, but this was the first time I did any work with a gui. I was pretty disappointed at what seems to be the current state of gui programming with Python. I like the Python language itself a lot, it's a fun change from the Delphi/ObjectPascal programming I'm used to, definitely a big productivity increase for general purpose programming tasks. I'd like to move to Python for everything.
But wxPython is a huge step backwards from something like Delphi's VCL or .NET's WinForms. While Python itself offers nice productivity gains from generally programming a higher level of abstraction, wxPython is used at a way lower level of abstraction than the VCL. For example, I wasted a lot fo time trying to get a wxPython list object to behave the way I wanted it to. Just to add sortable columns involved several code-intensive steps, one to create and maintain a shadow-data-structure that provided the actual sort order, another to make it possible to show graphic-sort-direction-triangles in the column header, and there were a couple more I don't remember. All of these error prone steps could be accomplished simply by setting a property value using my Delphi grid component.
My conclusion: while Python provides big productivity gains by raising level of abstraction for a lot of general purpose coding, wxPython is several levels of abstraction lower than the gui tools available for Delphi. Net result: gui programming with Delphi is way faster than gui programming with Python, and the resulting ui with Delphi is still more polished and full-featured. It doesn't seem to me like it's exaggerating to say that Delphi gui programming was more advanced back in 1995 than python gui programming with wxPython is in 2009.
I did some investigating of other python gui frameworks and it didn't look like any were substantially better than wxPython. I also did some minimal investigation of gui formbuilders for wxPython, which would have made things a little bit better. But by most reports those solutions are buggy and even a great formbuilder wouldn't address my main complaints about wxPython, which are simply that it has fewer features and generally requires you to do gui programming at a much lower level of abstraction than I'm used to with Delphi's VCL. Some quick investigating into suggested python gui-dev solutions ( http://wiki.python.org/moin/GuiProgramming ) is honestly somewhat depressing for someone used to Delphi or .NET.
Finally, I've got a couple of questions.
First, am I missing something? Is there some gui-development solution for Python that can compare with VCL or WinForms programming? I don't necessarily care if it doesn't quite measure up to Delphi's VCL. I'm just looking for something that's in the same league.
Second, could IronPython be the direction to go? I've mostly tried to avoid drinking the .NET koolaid, but maybe IronPython gives me a reason to finally give in. Even then, does IronPython fully integrate with WinForms, or would I need to have the forms themselves be backed by c# or vb.net? It looks to me like that definitely is the case with SharpDevelop and MonoDevelop (i.e, IronPython can't be used to do design-time gui building). Does VS.NET fully integrate IronPython with gui-building?
It really seems to me like Python could "take over the world" in a way similar to the way that Visual Basic did back in the early 1990's, if some wonderful new gui-building solution came out for Python. Only this time with Python we'd have a whole new paradigm of fast, cross platform, and open source gui programming. Wouldn't corporations eat that up? Yeah, I know, web apps are the main focus of things these days, so a great Python-gui solution wouldn't create same revolution that VB once did. But I don't see gui programming disappearing and I'd like a nice modern, open source, high level solution.

seems your complains are about wxPython, not about Python itself. try pyQt (or is it qtPython?)
but, both wxPython and pyQt are just Python bindings to a C / C++ (respectively) library, it's just as (conceptually) low level as the originals.
but, Qt is far superior to wx

PyQt is a binding to Qt SDK from Nokia, and PyQt itself is delivered by a company called RiverBank.
If licence is not important for you you can use PyQt under GPL or you 'll pay some money for commercial licence.
PyQt is binding Qt 4.4 right now.
Qt is not just GUI, it's a complete C/C++ SDK that help with networking, xml, media, db and other stuff, and PyQt transfer all this to python.
With PyQt you'll use Qt Designer and you 'll transfer the .ui file to .py file by a simple command line.
You 'll find many resources on the web about PyQt and good support from different communities, and even published books on PyQt.
Many suggestions consider that RiverBank has no choice but to release the next version which 'll depend on Qt 4.5 under LGPL, we are waiting :).
Another solution is Jython with Java Swing, very easy and elegant to write (specially under JDK 6), but not enough resources on internet.

You may want to look at Jython (Python on the Java VM). It is very similar to Iron Python, and you can fore go the .Net koolaid.

dabo puts wxPython programming at a higher level like what you're looking for.

You're probably going to have to use the .net or java pythons, but check this out first and see if it meets your requirements:
Kiwi

Short answer: Don't try Tkinter - it's got all the problems described above.
Long answer: Tkinter is not useful for large programs. Handling the various pieces with it somehow invariably degenerates to juggling (which never happens otherwise) and the resulting output doesn't look native or particularly polished.

You are right, wxPython can definetely be improved. But i think Robin Dunn has done a great job so far, and still is.
Especially the wxPython community is open to improvements, like recent inclusion of the widgets by Andrea, so like many community projects pick the one you like most, and improve it while using it.

We've been quite happy using Python.Net to build our UIs in WinForms and using CPython for Presenter, Model. IronPython is also a good tool if you want to do python on Windows.

There is Wax, whose purpose was to create a more pythonic interface to wxWidgets, but it seems its development has stalled.

Glade or no glade: What is the best way to use PyGtk?

I've been learning python for a while now with some success. I even managed to create one or two (simple) programs using PyGtk + Glade.
The thing is: I am not sure if the best way to use GTK with python is by building the interfaces using Glade.
I was wondering if the more experienced ones among us (remember, I'm just a beginner) could point out the benefits and caveats of using Glade as opposed to creating everything in the code itself (assuming that learning the correct gtk bindings wouldn't exactly be a problem).

I would say that it depends: if you find that using Glade you can build the apps you want or need to make than that's absolutely fine. If however you actually want to learn how GTK works or you have some non-standard UI requirements you will have to dig into GTK internals (which are not that complicated).
Personally I'm usually about 5 minutes into a rich client when I need some feature or customization that is simply impossible through a designer such as Glade or Stetic. Perhaps it's just me. Nevertheless it is still useful for me to bootstrap window design using a graphical tool.
My recommendation: if making rich clients using GTK is going to be a significant part of your job/hobby then learn GTK as well since you will need to write that code someday.
P.S. I personally find Stetic to be superior to Glade for design work, if a little bit more unstable.

Use GtkBuilder instead of Glade, it's integrated into Gtk itself instead of a separate library.
The main benefit of Glade is that it's much, much easier to create the interface. It's a bit more work to connect signal handlers, but I've never felt that matters much.

Glade is very useful for creating interfaces, it means you can easily change the GUI without doing much coding. You'll find that if you want to do anything useful (e.g. build a treeview) you will have to get familiar with various parts of the GTK documentation - in practice finding a good tutorial/examples.

I started out using glade, but soon moved to just doing everything in code. Glade is nice for simple things, and it's good when you're learning how GTK organizes the widgets (how things are packed, etc). Constructing everything in code, however, you have much more flexibility. Plus, you don't have the glade dependency.

I usually start with Glade until I come to a point where it doesn't have the features I need, e.g. creating a wizard. As long as I'm using the standard widgets that Glade provides, there's really no reason to hand-code the GUI.
The more comfortable I become with how Glade formats the code, the better my hand-coding becomes. Not to mention, it's real easy to use Glade to make the underlying framework so you don't have to worry about all the initializations.

If you're writing a traditional GUI application which reuses a lot of standard components from GTK+ (buttons, labels, containers etc.) I'd personally go with Glade + Kiwi (a convenience framework for building GTK+ GUI applications).
The single greatest advantage to using Glade is that it greatly reduces layout/packing code. Here's an extremely simply example which already shows the issues with manually laying out a GUI (without using any helper functions):
container = gtk.HBox()
label = gtk.Label(str="test")
container.add(label)
For more examples take a look here. Even if you're writing a complicated custom widget you can always create a placeholder in Glade and replace that after instantiation.
It shouldn't be all too long now for the Glade team to release a new version of the designer (3.6.0). This new version will add support for GtkBuilder, which replaces libglade (the actual library that transforms the Glade XML files into a widget tree). The new Glade designer also once again adds support for defining catalogs (sets of widgets) in Python, so you can easily add your own custom widgets.

First, start to put this in perspective.
You will be using GTK. This is a huge C library built in 1993 using the best traditions of 1970s coding style. It was built to help implement the GIMP, a Photoshop competitor wanna-be with user interface blunders of legend. A typical gui field might have forty or more parameters, mostly repetitive, having getters and setters. There will be pain.
The GTK itself manages a complete dynamic type system in C using GObject. This makes debugging a special joy that requires manually walking through arrays of pointers to methods full of generic argument lists with implicit inheritance. You will also be jumping through Pango libraries when you least expect it, e.g., using a Pango constant for where in a label the ellipsis go when the page is small. Expect more pain.
By now, you are probably vowing to wrap all your GTK interactions in a Model-View-Controller architecture specific to your application. This is good.
Using Glade, or gtkBuilder, or Stetic, will help coral the huge coupling problem of forty parameters to a function. Glade provides a basic GUI builder to drag and drop components together. The parameters and inherited parameters are somewhat separated out. The output of Glade is .glade XML file which you will then read in, attach your callbacks ("signal handlers") to identically named functions, and query or update the in-memory version of that XML to get widgets that you then use pyGTK to manipulate. Glade itself is a creaky and not well maintained.
Using pyGTK gives you annoyingly fine grained control in order to build your GUI. This will be verbose, copy-and-paste code. Each attribute will be a separate function call. The attribute setter does not return anything, so chaining the calls is out of the question. Usually, your IDE will give only minimal help on what functions mean and you will be constantly referring to DevHelp or some other tool.
One would almost expect GTK GUIs were meant to fail.

I recommend using Glade for rapid development, but not for learning. Why? because some times you will need to tune up some widgets in order to work as you want they to work, and if you don't really know/understand the properties attributes of every widget then you will be in troubles.

For quick and simple screens I use Glade. But for anything that needs finer levels of control, I create a custom classes for what I actually need (this is important, because it's too easy to get carried away with generalisations).
With a skinny applications specific classes, I can rapidly change the look and feel application wide from a single place. Rather like using CSS to mantain consistency for web sites.

Personally I would recommend coding it out instead of using Glade. I'm still learning python and pyGtk but I will say that writing out the UI by hand gave me a lot of insight on how things work under the hood.
Once you have it learned I'd say to give glade, or other UI designers a try but definitely learn how to do it the "hard" way first.

You may use glade-2 to design, and use glade2py.py to generating the pure pygtk code,
it use pygtkcompat to support gtk3