On Friday 08 September 2006 01:51, David Boddie wrote:
> Although KDE 4 looks like it's starting to take shape, I can't believe that
> there's not going to be a lot of flux in the APIs before they stabilize
> into a form that provides the features that have been promoted in various
> places. I don'
thank you for the advice, I have read the doc again (and again and again).Now, I use a QTreeView ,what i have to do ?QTreeView::rowsAboutToBeRemoved(param) treeviewobj.model().removeRow(param)
QTreeView::rowsRemoved(param)
or just call removeRow() that call itself beginRemoveRow and endRemoveRow
On 08.09.06 10:38:51, Oscar Cossu wrote:
> thank you for the advice, I have read the doc again (and again and again).
> Now, I use a QTreeView ,what i have to do ?
>
> QTreeView::rowsAboutToBeRemoved(param)
>
> treeviewobj.model().removeRow(param)
>
> QTreeView::rowsRemoved(param)
No.
> or ju
Hi,
I'm porting an app from PyQt3 to PyQt4 but can't find any obvious replacement
for
QTable.setColumnReadonly() in QTableWidget. Any ideas? (BTW I can't use the SQL
module for
licensing reasons)
If the solution requires some sub-classing etc. then a short code snippet of a
simple example
woul
On 08.09.06 04:29:21, Chris Dunscombe wrote:
> I'm porting an app from PyQt3 to PyQt4 but can't find any obvious replacement
> for
> QTable.setColumnReadonly() in QTableWidget.
Use QTableWidgetItem::setFlags and don't include the Qt.IsEditable flag.
> Any ideas? (BTW I can't use the SQL module f
Ok, I have to post my code because your suggest doesn't work (probably i miss something). class DomModel(QtCore.QAbstractItemModel): def __init__(self, document, parent = None): QtCore.QAbstractItemModel.__init_
_(self, parent) self.domDocument = document ##this is a QDomDocument
On 08.09.06 15:23:50, Oscar Cossu wrote:
>def removeRows(self,arow,count,parent):
>
> self.beginRemoveRows(parent,arow,arow+count-1)
>
>for ii in range(count):
> ##code for removing a row from QDomDocument here
>
> self.endRemoveRows()
>
class DomItem: def __init__(self, node, row, parent=None): self.domNode = node # Record the item's location within its parent. self.rowNumber = row self.parentItem = parent
self.childItems = {} def node(self): return self.domNode def parent(self):
--- Andreas Pakulat <[EMAIL PROTECTED]> wrote:
> On 08.09.06 04:29:21, Chris Dunscombe wrote:
> > I'm porting an app from PyQt3 to PyQt4 but can't find any obvious
> > replacement for
> > QTable.setColumnReadonly() in QTableWidget.
>
> Use QTableWidgetItem::setFlags and don't include the Qt.Is
On 08.09.06 07:53:36, Chris Dunscombe wrote:
>
>
> --- Andreas Pakulat <[EMAIL PROTECTED]> wrote:
>
> > On 08.09.06 04:29:21, Chris Dunscombe wrote:
> > > I'm porting an app from PyQt3 to PyQt4 but can't find any obvious
> > > replacement for
> > > QTable.setColumnReadonly() in QTableWidget.
>
On 08.09.06 16:29:32, Oscar Cossu wrote:
>def child(self, i):
>if self.childItems.has_key(i):
>return self.childItems[i]
>
>if i >= 0 and i < self.domNode.childNodes().count():
>childNode = self.domNode.childNodes().item(i)
>childItem = DomIt
On Friday 08 September 2006 00:26, Sebastian Kügler wrote:
> It would be nice, however, to have something to play with in the meantime,
> especially for those, that would like to ship their PyKDE when KDE4 is
> released, or shortly thereafter. But then I'm not the one who has to run
> after an unst
On Friday 08 September 2006 01:51, David Boddie wrote:
> On Thursday 07 September 2006 23:03:14 +0200, Simon Edwards wrote:
> While it would be nice to have ready made bindings for each new KDE release,
> it's going to take some willingness on the part of the core KDE developers
> to plan for this
On Friday 08 September 2006 02:48, Jim Bublitz wrote:
> I'm completely in favor of synching KDE and PyKDE
:-)
> Seriously - 2 or 3 maintainers splitting up module responsibilities would
> probably do it with decent communication and source control. I'm perfectly
> willing to provide help. I don
On Friday 08 September 2006 01:26, Sebastian Kügler wrote:
> On Friday 08 September 2006 01:51, David Boddie wrote:
> > Although KDE 4 looks like it's starting to take shape, I can't believe
> > that there's not going to be a lot of flux in the APIs before they
> > stabilize into a form that provid
On Friday 08 September 2006 18:53, Joshua J. Kugler wrote:
> Let's get PyKDE in KDE SVN and get movin'. :)
There is already a spot in SVN for PyKDE and friends.
After Akademy I want to start playing with KDE4 and porting over some of my
stuff, and working on PyKDE at the same time to make that p
On Friday 08 September 2006 12:11, Simon Edwards wrote:
> On Friday 08 September 2006 01:51, David Boddie wrote:
> > On Thursday 07 September 2006 23:03:14 +0200, Simon Edwards wrote:
> > While it would be nice to have ready made bindings for each new KDE
> > release, it's going to take some willin
On Friday 08 September 2006 12:46, Simon Edwards wrote:
> On Friday 08 September 2006 02:48, Jim Bublitz wrote:
> > I'm completely in favor of synching KDE and PyKDE
> >
> :-)
> :
> > Seriously - 2 or 3 maintainers splitting up module responsibilities would
> > probably do it with decent communicat
On Friday 08 September 2006 21:11:25 +0200, Simon Edwards wrote:
> On Friday 08 September 2006 01:51, David Boddie wrote:
> > Reading through the SIP files for PyKDE, you find lots of information
> > about the way the KDE APIs have evolved over time. If the bindings were
> > too closely tied to so
On Friday 08 September 2006 08:53:52 -0800, "Joshua J. Kugler" wrote:
> Right now, it seems the Ruby bindings have quite a bit of momentum, as
> evidenced by the extensive page above. Whereas the python bindings page
> has just a few links: http://developer.kde.org/language-bindings/python/
Most
On Friday 08 September 2006 05:07:49 +0100 (BST), jim j wrote:
> I have a problem while compiling the following code.
> the code is given below:
>
> %Module pyMyTimer
>
> typedef void (*TIMERFP)(long);
>
> struct _time
> {
> %TypeHeaderCode
> #include
> %End
>
> long expiryTime;
>
21 matches
Mail list logo
