[Kde-bindings] qtruby: ListView::takeItem segfault

Richard Dale Richard_Dale at tipitina.demon.co.uk
Tue Jun 29 07:07:39 UTC 2004


On Monday 28 June 2004 18:32, Hans Fugal wrote:
> /* Quoth Richard Dale <Richard_Dale at tipitina.demon.co.uk>
>    on Mon, 28 Jun 2004 at 17:23 +0100
>    in <200406281723.37068.Richard_Dale at tipitina.demon.co.uk> */
>
> > On Monday 28 June 2004 16:29, Hans Fugal wrote:
> > > listview.takeItem(item) results in a segfault. I'd like to see this
> > > fixed or figure out another way to remove an item from a ListView. The
> > > C++ docs say to delete it, this is obviously not the thing to do in
> > > ruby (or other GC languages).
> >
> > I've had a look at the docs for takeItem() and it doesn't sound too safe:
>
> Agreed, but according to the docs it should be save to takeItem and
> subsequently insertItem somewhere else. This seems to be the only way to
> move an item around, unless I'm missing something.
>
> > I've just confirmed it crashes - oh dear!
> >
> > The QtJava bindings have a dispose() method although they have automatic
> > garbage collection so it's only optional. Perhaps it would be a good idea
> > to add that to the QtRuby runtime. Or maybe Qt::ListView.takeItem()
> > should actually call delete on the Qt::ListViewItem.
>
> The problem is Qt wants you to delete a QListViewItem to remove it from
> the tree. It probably seemed like a neat trick in C++. But in GC
> languages the GC happens after you lose all refernces to it, not the
> other way around. I'm assuming that if you use takeItem and then drop
> it, the GC will take care of it. If not, well at least it would 'work',
> even if there's a memory leak there. Having takeItem actually call
> delete would break the takeItem/insertItem semantics in the docs.
I've added dispose() and isDisposed() to QtRuby, please find attached an 
example program

		item0.takeItem(item1)  
		item0.insertItem(item1)  

		item2.dispose
		if item2.isDisposed
			puts "item2 is disposed"
		end

I think qtruby needs a way to tell if a QListViewItem is in 'takeItem' state, 
although it seems ok as long as you immediately do an insertItem as above.

-- Richard
-------------- next part --------------
#!/usr/bin/env ruby

require 'Korundum'
include KDE
include Qt

class MainWindow < KDE::MainWindow
  def initialize( *k )
    super( *k )
		topLayout = Qt::VBoxLayout.new( self )
    	topLayout.setAutoAdd( true )
                        
        kListView = KDE::ListView.new(self, "")
        kListView.addColumn("Content")
#        kListView.setFullWidth(true)
        kListView.setSorting(-1)
        
        item0 = KDE::ListViewItem.new(kListView)
        item0.setText(0, "Root")
        item0.setOpen(true)
                
        item3 = KDE::ListViewItem.new(item0)
        item3.setText(0, "Level 1, Third Item")
        
        item1 = KDE::ListViewItem.new(item0)
        item1.setText(0, "Level 1, First Item")

        item2 = KDE::ListViewItem.new(item0, item1)
        item2.setText(0, "Level 1, Second Item")
		
		item0.takeItem(item1)  
		item0.insertItem(item1)  
#		item3.insertItem(item1)
		item2.dispose
		if item2.isDisposed
			puts "item2 is disposed"
		end
	end
end

about = AboutData.new("listview", "KDE::ListView Test", "0.1")
CmdLineArgs.init(ARGV, about)
a = UniqueApplication.new()

listview = MainWindow.new(nil, "listviewtest")
a.mainWidget = listview
listview.show
# Qt::Internal::setDebug Qt::QtDebugChannel::QTDB_ALL
a.exec


More information about the Kde-bindings mailing list