librelist archives

Re: [shoes] TreeView Component

From:

Nicholas White

Date:

2011-08-05 @ 22:32

I take your point that it's a little complicated :) However, while
using item= fixes the app I wrote it means you have to abide by
non-obvious rules or the view will get out of sync with the model.
Also, this doesn't address the fact that the are two copies of the
mode (one in the Ruby code & one in the GTK widget) - and using item=
means you have to clear and repopulate the entire GTK model every time
you want to do an update, no matter how trivial. This is not an issue
with the list_box as there's so few Strings in the model that the
performance & memory overhead is minimal, but in a TreeView with many
columns and tens of rows this would be noticeable. As an aside, the
GTK ComboBox behind the list_box stores its model in a TreeModel - the
same object behind the GTK TreeView[1]. This is why I think paying the
price of a complicated list_box implementation is necessary - the code
will generalise to an efficient TreeView implementation.

I've simplified my solution - what we really want for our model is
something that responds_to? exactly like an Array, but in fact is a
thing layer over (i.e. delegates the actual storage to) the GTK model.
This is a fairly useful idea - I've spent a while googling for
something like it previously when I was looking at object-relational
mapping (think Hiberate in Java) - I wanted something that looked like
an Array, but every time you accessed an element it would read it from
a database, and every time you set an element in the array it would
insert or update a row in the database. I've generalised this idea to
the below (implementation is incomplete - bear with me...):

# so you basically need at(i), set(i,val), size & delete_at(i)
# in your actual class to be an array
module ArrayLike
	include Enumerable
	
	def clear
		size.times{|i|delete_at 0}; self
	end
	
	# returns copy, so ok to be inefficient
	[:+, :-, :&, :*, :|].each{|m| instance_eval "def #{m} other;
to_ary.send :#{m}, other end"}
	
	def to_ary; ret = []; each{|x|ret<<x}; ret end
	
	def concat other; other.each{|x|push x}; self end
	
	def empty?; size == 0 end
	
	def push *args; args.each{|arg|set size, arg} end
	
	def join sep=$,
		each_with_object(""){|i,s|s.empty? ? (s<<i) : (s<<sep<<i) }
	end	
	
	def inspect; "[#{join(", ")}]" end
	
	def select! &blk
		off=0
		size.times{|i|
			if not blk.call at(i+off); delete_at (i+off); off-=1 end
		}
		self
	end
	
	def each; size.times{|i|yield at(i)} end
	
	def slice! *args; ret=self[*args]; self[*args]=nil; ret end
	
	def values_at *args
	  args.map{|a|a.class.included_modules.include?(Enumerable) ? a.to_a
: [a]}.flatten.map{|i|at(i)}
	end
	
	alias_method :<<, :push
	alias_method :index, :find_index
end

# todo
# [ "<=>", "assoc",  "choice", "collect!", "combination", "compact",
# "compact!", "delete",  "delete_if", "each_index",  "fetch", "fill",
# "flatten", "flatten!", "indexes", "indices", "insert",  "last", "length"
# "map!", "nitems", "pack", "permutation", "pop", "product",  "rassoc",
# "reject!", "replace", "reverse", "reverse!", "rindex", "shift",
# "shuffle", "shuffle!", "transpose", "slice",  "sort!", "uniq", "uniq!",
# "unshift" ]

I've left off a quite a few methods, but you get the idea; you
implement set, at, delete_at & size methods in your class that
delegate to your backing store, include this module and you act like
an array. All the implementations of the array methods are done so
that they only references these four delegating methods. You don't
even have to write unit tests for this - you can use the ones in
Rubyspec[2] to ensure this model is exactly interchangable with a
native Ruby Array. If you do implement the rest of this you should
consider releasing it as a separate gem - I unfortunately don't have
the time or I'd do this myself (above code BSD-licensed if you want it
:).

To use this in my example shoes app you still need some (although
less) monkey-patching:

class Shoes::ListBox < Shoes::Native
  def initialize args
    super args
    @remove_observer = lambda{} # to unwire the current model from the view
    self.items = @items || [] # wire up the initial model
  end

  def items= items
    # current implementation
    @items.length.times{real.remove_text 0}
    @items = items
    items.each{|item| real.append_text item.to_s}

    # wire view to model (note we do all this mangling of the
    # items object in case anyone has a reference to it).
    items.extend ArrayLike
    items.clear # might as well save some memory
    items.instance_variable_set :@real, real

    # and now the implementation of the ArrayLike interface
    def items.size; i=0; @real.model.each{i+=1}; i end
    def items.at i
      count=0
      @real.model.each{|model, path, iter|
        return model.get_value iter, 0 if i == count;
        count+=1
      }
    end
    def items.delete_at i; @real.remove_text (i<0 ? (i+size) : i) end
    def items.set i, val
      i+=size if i<0
      if i == size
        @real.append_text val.to_s
      else
        @real.remove_text i; real.insert_text i, val
      end
    end

    @remove_observer.call # remove old model
    @remove_observer = lambda{ # remove this model (for next time)
      new_items = items.to_a

      # re-implement the ArrayLike interface, pointing to the new_items Array
      def items.size; new_items.size end
      def items.at i; new_items.at(i) end
      def items.delete_at i; new_items.delete_at(i) end
      def set i, val; new_items[i] = val end
    }
  end
end

 Shoes.app do
   para "Choose a number:"
   @num = 1
   @box = list_box items: [@num.to_s]
   button "Add Next" do @box.items << (@num += 1).to_s end
   button "Remove Odd" do @box.items.select!{|num|num.to_i%2==0} end
   button "Sysout Items" do puts @box.items.inspect end
 end

The code that interacts with the GTK ComboBox is grossly inefficient
(lots of looping) but I couldn't find a "size" method in the API. I'm
also not sure that this would work as-is with multiple list_boxes (or
tree_views) sharing the same model - you'd have to have another layer
between the items Array (now ArrayLike) and the ComboBoxes / TreeViews
that implemented the Observer pattern (and so all the views could be
observers of a single model).

What do you think?

Nick

[1] http://ruby-gnome2.sourceforge.jp/hiki.cgi?Gtk%3A%3AComboBox#model
[2] https://github.com/rubyspec/rubyspec/tree/master/core/array

On 4 August 2011 13:26, ashbb <ashbbb@gmail.com> wrote:
> Hi Nick,
>
>> I've had to do quite a bit of hackery to get this to work as expected
> Wow, awesome code using observer and diff. I've not used the gem. :-P
>
> But wait a moment. We have the `ListBox#items=` method.
> So, let me revise your first code a little bit. ;-)
>
> require 'green_shoes'
> Shoes.app do
>   para "Choose a number:"
>   @num = 1
>   @box = list_box items: [@num]
>   button "Add Next" do
>     @box.items += [@num += 1]
>   end
>   button "Remove Odd" do
>     @box.items = @box.items.select{|num|num%2==0}
>   end
>   button "Sysout Items" do puts @box.items.inspect end
> end
>
> It seems to work as expected. ;-)
>
>> Also, I've noticed you duplicate the data in the model - there's
>> one copy in the GTK widget and another copy in the "items"
>> instance variable of the list_box.
> Yes, you are right.
> Hence, you can write without `to_s` like the above code. ;-)
>
> Cheers,
> ashbb
>
>

Hi Nicholas,

> using item= means you have to clear and repopulate the entire GTK model
> every time you want to do an update
Yes, you are right.

> but in a TreeView with many columns and tens of rows this would be
> noticeable.
In general, that's true.
But there are very few Shoes apps which need so much high performance, IMHO.
:-P

As you know, the `:item` attribute is just an array.
So, if you accept using `item=` method when you update each time,
you can use whole methods of Array.

ashbb

> But there are very few Shoes apps which need so much high performance, IMHO.

I do! But seriously, that's why I started this thread - I'm writing
GUIs that display and aggregate large amounts of data to make it
"useful" (think H2's database HTML viewer[1] or excel's pivot
tables[2] that let you drill into aggregate rows). No ruby GUI
toolkits really support this yet (I could use the GTK2 bindings
directly, but I want concise GUI code, and WxRuby's wxGrid only
supports 2D data) - so I thought I'd help shoes out as it's by far the
easiest toolkit to work with. I'm not trying to be difficult by
thinking of theoretical edge cases - the functionality I've been
sketching out is pretty much a requirement for my use case.
However, I appreciate that this isn't shoes' usual use-case, and so
will understand if you don't want to over-complicate the shoes
implementation by supporting it...

[1] http://img.skitch.com/20101127-fbacj94arqxfbkqnph7g733r5u.png
[2] http://www.mssqltips.com/tipimages2/1716_pivot_table.jpg

On 7 August 2011 08:54, ashbb <ashbbb@gmail.com> wrote:
> Hi Nicholas,
>
>> using item= means you have to clear and repopulate the entire GTK model
>> every time you want to do an update
> Yes, you are right.
>
>> but in a TreeView with many columns and tens of rows this would be
>> noticeable.
> In general, that's true.
> But there are very few Shoes apps which need so much high performance, IMHO.
> :-P
>
> As you know, the `:item` attribute is just an array.
> So, if you accept using `item=` method when you update each time,
> you can use whole methods of Array.
>
> ashbb
>

Hi Nicholas,

>> But there are very few Shoes apps which need so much high performance,
IMHO.
> I do!

Oh, yeah. :)
Okay, let me try to check treeview performance with Green Shoes.

Look at this: https://gist.github.com/1131773

- Line 23-33: Set up a table with about 10000 rows.
- Line 36-45: Open TreeView Window button launches a treeview window.
- Line 47-52: Modify Data button replaces two values to 9999
  and executes `tree_view_text=` method.
- Line 5-18: The tree_view_text= method does just clear all treeview rows
  and append all new rows again.

Look at this flush video:
http://www.rin-shun.com/shoes/green_shoes_treeview_performance_check.swf.html

The performance (response) is not so quick, but not so bad, IMHO.
Can't you bear it?

ashbb