[prev in list] [next in list] [prev in thread] [next in thread]
List: pykde
Subject: Re: [PyKDE] pyqt and new-style classes
From: Ulrich Berning <ulrich.berning () desys ! de>
Date: 2004-02-20 15:15:13
Message-ID: 40362481.7020404 () desys ! de
[Download RAW message or body]
Roland Schulz schrieb:
> I understood this, but I thought incorretly that there are classes more
> apropriate to use then directly using QMetaObject. But I was wrong and
> you're
> right QMetaObject should be implemented if someone wants to write
> something
> like designer in pyqt. But why not just using desinger like eric or
> kdevelop
> do? I think I read that something like kpart is also planned for qt,
> so one
> could integrate designer in the app.
The designer is a great tool for developers, but only for developers.
Our goal is to implement dialog customization facilities into our
commercial application, so our customers can create new dialogs or
modify existing dialogs of the application inside the application. The
resulting dialog definition (XML format, maybe exactly the .ui format)
is stored in a database together with the resulting python code created
by a kind of user interface compiler. But this is only one part of the
customization facilities. Another one is an editor (base on QScintilla)
to create or modify the python code of all the use cases, dialog
controllers and utilities (library functions). Our application is a
general Product Data Management (PDM) framework containing an Integrated
Development Environment (IDE). This framework is developed by our core
development team, the customer specific PDM applications (every customer
has different requirements, different workflows, use cases, object types
and attributes ...) are created by our project team inside this PDM
framework with the integrated IDE. So we have a clean separation between
the framework development, where we need good programming skills and the
project development, where we need good PDM and engineering skills. It
doesn't matter if our customers never use the customization facilities
themself, telling them they could is a really big marketing argument.
Somehow, you can compare our PDM framework to Microsoft Access and the
PDM Projects to applications created inside Access.
So now, it should be clear, why we can't integrate the designer into our
PDM framework (not talking about licensing issues here). The designer is
a general tool to create any kind of Qt dialog applications but it needs
a good knowledge of Qt and is oversized for our specific needs. Our
project team or our customers never create a QMainWindow for example,
because this is provided by the framework.
I should mention, that our PDM framework is currently in the development
phase (it is completely written in Python), the integrated IDE is
planned for the future.
Ulli
_______________________________________________
PyKDE mailing list PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic