'Better' editing / focus policy in a TreeView

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

'Better' editing / focus policy in a TreeView

Daniel Kasak
I'd like to set up TreeViews with a different behaviour when editing
stuff in cells.
Currently, you have to hit the Enter key to start editing ( or click in
the cell ). You also have to hit Enter ( or click in another cell ) to
end editing. Then you have to use the cursor keys to move the focus
along, and finally hit Enter to start editing again.

I'd like to get something much more like MS Access' datasheet behaviour,
ie when you hit enter, the focus goes to the next cell and editing
begins. I've been able to get a crippled version of this behaviour
working by connecting a sub to the 'edited' signal of the text renderer
and using $treeview->set_cursor to move the focus along and start
editing. The problem is that this only works well if I only use the
keyboard. If the focus moves somewhere else ( eg if I click in some
other cell or outside the treeview completely ), things get messy. Is
there any way of avoiding this with the current method I'm using ...
connecting to the 'edited' signal of the renderer ... can I detect at
this point that editing has finished for a reason *other* than a
keyboard event? I barely remember making some simple modifications to a
custom CellRendererSpinButton that trapped keypress events and moved the
focus along - this worked much better than my current solution, but I'd
rather not have to have a custom cell renderer in every single cell, as
it over complicates things and performance suffers quite badly with
large data sets.

--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [hidden email]
website: http://www.nusconsulting.com.au
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: 'Better' editing / focus policy in a TreeView

muppet-6

On Jun 7, 2005, at 7:58 PM, Daniel Kasak wrote:

> I'd like to set up TreeViews with a different behaviour when  
> editing stuff in cells.
...
> Is there any way of avoiding this with the current method I'm  
> using ... connecting to the 'edited' signal of the renderer ... can  
> I detect at this point that editing has finished for a reason  
> *other* than a keyboard event?

IIRC, the only sure-fire way to customize that behavior is to use  
custom renderers.  The cell renderer is the only place where you can  
get access to the editable in order to hook into its focus-out signal  
and such.

If performance is a big problem, and you don't mind an XS dependency,  
you can implement that custom renderer in C and bind it rather easily.


I'd be quite happy if somebody proved me wrong. ;-)


--
How come hair colors for women take an hour, but "wash out the gray"  
stuff for men only five minutes?  This is so unfair!
     -- Elysse, complaining about commercials

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: 'Better' editing / focus policy in a TreeView

Daniel Kasak
muppet wrote:

>
> On Jun 7, 2005, at 7:58 PM, Daniel Kasak wrote:
>
>> I'd like to set up TreeViews with a different behaviour when  editing
>> stuff in cells.
>
> ...
>
>> Is there any way of avoiding this with the current method I'm  using
>> ... connecting to the 'edited' signal of the renderer ... can  I
>> detect at this point that editing has finished for a reason  *other*
>> than a keyboard event?
>
>
> IIRC, the only sure-fire way to customize that behavior is to use
> custom renderers.  The cell renderer is the only place where you can
> get access to the editable in order to hook into its focus-out signal
> and such.
>
Damn!
See if you can guess the topic of the next couple of questions from me :)
I will go as far as I can with the SpinButton renderer example, but I'll
be back - mark my words.

Thanks muppet.

--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [hidden email]
website: http://www.nusconsulting.com.au
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: 'Better' editing / focus policy in a TreeView

Torsten Schoenfeld
On Wed, 2005-06-08 at 11:15 +1000, Daniel Kasak wrote:

> > IIRC, the only sure-fire way to customize that behavior is to use
> > custom renderers.  The cell renderer is the only place where you can
> > get access to the editable in order to hook into its focus-out signal
> > and such.
>
> Damn!
> See if you can guess the topic of the next couple of questions from me :)
> I will go as far as I can with the SpinButton renderer example, but I'll
> be back - mark my words.

You might want to take a look at Odot[1] and its custom renderers and
editables.  They implement a lot of the things you mentioned.

--
Bye,
-Torsten

[1] http://home.arcor.de/kaffeetisch/odot.html

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list