Re: GtkCellRendererToggle toggles when clicking on other cell renderers in same column



I take that back; my solution caused another problem: now the
GtkCellRendererToggle does not fire the toggle event unless the row is
selected prior to clicking on the checkbox. I don't even understand why this
might be happening. Does anybody have a solution for this new problem? This
is getting a little ridiculous. Shouldn't it be fairly easy to have a
treeview containing items with checkboxes and text without the checkbox
being toggled when the text is clicked?

On Sat, Aug 15, 2009 at 5:15 PM, Grumpy Buffalo
<grumpybuffalo+gtk gmail com<grumpybuffalo%2Bgtk gmail com>
wrote:

I came up with a solution.

I changed the GtkCellRendererText to a GtkCellRendererCombo. I didn't add
any items to the combo or even set the model of the combo; the only property
I set was the "editable" property to true. This created exactly the
functionality I was looking for. The user can't even tell that the cell
renderer is a combo box, because it has nothing in it. Clicking on the combo
does not toggle the GtkCellRendererToggle. I suppose this is because GTK no
longer considers the column one activatable entity.


On Wed, Aug 12, 2009 at 12:38 AM, Grumpy Buffalo <
grumpybuffalo+gtk gmail com <grumpybuffalo%2Bgtk gmail com>> wrote:

Hi,

I understand why this behavior occurs; I do realize that it would be
what is wanted in most circumstances. In this particular case,
selecting the row causes one action to occur and toggling the checkbox
causes another action to occur. Because all of the cell renderers are
considered one activatable entity, it is very difficult to select the
row without toggling the checkbox; the user would have to click in
another column. I considered having the GtkCellRendererToggle in a
separate column, but this is not acceptable either, because the
checkbox, pixbuf, and text must all be indented together when a row in
the tree is expanded.

I suppose overriding the activate method is probably going to be the
easiest way of doing this. I'm not looking forward to it; it seems
like there should be a more elegant solution to the problem.

Thanks a lot for your help.

On Wed, Aug 12, 2009 at 12:16 AM, Kristian Rietveld<kris gtk org> wrote:
Hello,

On Wed, Aug 12, 2009 at 2:32 AM, Grumpy
Buffalo<grumpybuffalo+gtk gmail com <grumpybuffalo%2Bgtk gmail com>>
wrote:
Hi, I am working on a C++ GTK project. I have a GtkTreeView containing
several columns. In the first column, I have packed in 3 cell
renderers - the first, a GtkCellRendererToggle; the second, a
GtkCellRendererPixbuf; the third, a GtkCellRendererText. Everything
works fine, except that clicking on the text in the
GtkCellRendererText causes the 'toggled' event to fire on the

This is happening because the column that you have created has a
single activatable cell renderer.  The column is then seen as a single
activatable entity.  (It is more clearly seen in keyboard navigation,
when this column gets focus it will draw the focus indicator around
all cell renderers instead of around a single cell renderer, again
because there is only a single cell renderer that can be activated).
Often this is the behavior you want, for example when you pack a text
renderer next to the toggle renderer.  It will act the same as a
regular toggle button which also allows clicking on the text.

GtkCellRendererToggle. This is no good in this particular case. Is

Why exactly is it no good in this case?  The contents packed together
in a column surely belong together in some way?


there any way, besides keeping track of where the mouse pointer is, to
determine whether the user clicked on the checkbox itself or another
cell renderer in the same column? Thanks in advance for any ideas.

The only way I can think of so quickly to work around this is probably
to subclass GtkCellRendererToggle and override the activate method to
check the event coordinates that are provided with the cell_area or
background_area coordinates. (GtkCellRendererToggle itself does not do
this and immediately emits the toggled signal).


regards,

-kris.


--
Grumpy Buffalo




--
Grumpy Buffalo




-- 
Grumpy Buffalo



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]