Re: start-editing signal?
Allin Cottrell wrote: On Mon, 24 Sep 2007, Kristian Rietveld wrote: On Fri, Sep 21, 2007 at 06:05:15PM -0400, Allin Cottrell wrote: My expectation: the unfinished edit will still be in place. Actual behaviour: the bottles of coke cell is as it was before I started; my edit-in-progress is gone. This may not be a bug as such, but I would like to know if there's a way of preserving the state of the cell-editing process, in face of the treeview window temporarily losing focus. The behavior you describe is indeed the current behavior in GTK+ = 2.10 (and actually has some kind of history, but I won't bother you with that ;). OK, thanks. I've now updated myself on some of the history via bugzilla. At this moment there is no code in GTK+ to automatically preserve the value on focus out. However, since there are multiple different cases in which a focus-out should commit the new value and also a lot of cases in which a focus-out should *not* commit the new value, we are thinking of adding a property to GtkCellRendererText which will control whether the input the user has entered should be committed on focus-out or not. I haven't studied all the reports on this, but I have looked at several of them. I'll venture this opinion: The default behavior should just be to preserve state (the edit remains in progress; it is neither automatically finalized nor automatically destroyed). Isn't this what users generally expect of any GUI element that temporarily loses focus? Surely loss of focus should not, of itself and in general, DO anything, either positive (commit the edit) or negative (lose the edit). Absolutely! I run my window manager with a 'focus follows mouse' policy. So a widget losing focus might mean that my cat has moved the mouse or it might mean I've gone to another application to look for information, perhaps to copy some text to paste into the widget. It might mean the system has popped up a completely unrelated alert that has grabbed the focus. It seems a no-brainer that loss of focus should do *nothing* to the edit state, nor should a subsequent regaining of focus. Explicit keyboard or mouse actions on the widget itself should be used to change state, or method invocations by associated widgets because of user actions on them. That's fundamental for a sane user experience, I believe. Yes, there are programming issues associated with abandoning a widget in an editing-in-progress state but they just need careful coding. JMHO, Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: start-editing signal?
On Fri, Sep 21, 2007 at 06:05:15PM -0400, Allin Cottrell wrote: My expectation: the unfinished edit will still be in place. Actual behaviour: the bottles of coke cell is as it was before I started; my edit-in-progress is gone. This may not be a bug as such, but I would like to know if there's a way of preserving the state of the cell-editing process, in face of the treeview window temporarily losing focus. The behavior you describe is indeed the current behavior in GTK+ = 2.10 (and actually has some kind of history, but I won't bother you with that ;). At this moment there is no code in GTK+ to automatically preserve the value on focus out. However, since there are multiple different cases in which a focus-out should commit the new value and also a lot of cases in which a focus-out should *not* commit the new value, we are thinking of adding a property to GtkCellRendererText which will control whether the input the user has entered should be committed on focus-out or not. We are still comtemplating whether the scope should be broadened to the value should only be accepted after the user has pressed Return rather than just dealing with focus-out. A good default here is by no means easy to decide because of the conflicting use cases. We will be tracking this on #164494 at bugzilla.gnome.org, the idea for a property was first mentioned in #462814. For now you could try to work around this by hooking into the start-editing, editing-done and edited signals -- unfortunately I have no cut-n-paste ready solution for you here. Hope this helps. regards, -kris. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: start-editing signal?
On Mon, 24 Sep 2007, Kristian Rietveld wrote: On Fri, Sep 21, 2007 at 06:05:15PM -0400, Allin Cottrell wrote: My expectation: the unfinished edit will still be in place. Actual behaviour: the bottles of coke cell is as it was before I started; my edit-in-progress is gone. This may not be a bug as such, but I would like to know if there's a way of preserving the state of the cell-editing process, in face of the treeview window temporarily losing focus. The behavior you describe is indeed the current behavior in GTK+ = 2.10 (and actually has some kind of history, but I won't bother you with that ;). OK, thanks. I've now updated myself on some of the history via bugzilla. At this moment there is no code in GTK+ to automatically preserve the value on focus out. However, since there are multiple different cases in which a focus-out should commit the new value and also a lot of cases in which a focus-out should *not* commit the new value, we are thinking of adding a property to GtkCellRendererText which will control whether the input the user has entered should be committed on focus-out or not. I haven't studied all the reports on this, but I have looked at several of them. I'll venture this opinion: The default behavior should just be to preserve state (the edit remains in progress; it is neither automatically finalized nor automatically destroyed). Isn't this what users generally expect of any GUI element that temporarily loses focus? Surely loss of focus should not, of itself and in general, DO anything, either positive (commit the edit) or negative (lose the edit). Nonetheless, there's at least one sort of case where a focus-out probably should be _associated_ with finalizing the edit, namely if the user moves the pointer from a treeview cell to click on a GUI element such as an OK button, which has the obvious interpretation of finalizing things (even if the edit has not been technically committed by pressing Return). In the latter case, though, the pertinent aspect is not the loss of focus on the treeview per se, but rather the clicking on OK (or similar). So shouldn't this be handled by a specifically coded callback? Since GTK+ 2.6 we can attach to the editing-started signal. This gives the means to implement the following: * When OK is clicked (or whatever), see if editing of a cell is in progress. If it is, commit the edit before proceeding, if this seems like the sensible thing to do. (This obviously requires that the edit-in-progress is _not_ destroyed by the loss of focus.) To my mind, this makes more sense than implementing an automatic commit when focus is lost routine. Loss of focus may be correlated with circumstances where we want to commit an edit, but it's not logically connected. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
start-editing signal?
I'm trying to connect a callback to start-editing on a cell
renderer, but I must be doing something wrong. My code is
basically
static void create_cell_renderer (gpointer p)
{
GtkCellRenderer *r;
r = gtk_cell_renderer_text_new();
g_object_set(r, ypad, 1,
xalign, 1.0,
mode, GTK_CELL_RENDERER_MODE_EDITABLE,
NULL);
g_signal_connect(r, start-editing,
G_CALLBACK(cell_edit_start), p);
}
When this code is invoked, I'm getting
GLib-GObject-WARNING **: gsignal.c:1669: signal `start-editing' is
invalid for instance `0x822a5f0'
I've verified that 0x822a5f0 is indeed the return value from
gtk_cell_renderer_text_new.
Can anyone tell me how to make a valid hook-up? Thanks!
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: start-editing signal?
On Fri, 21 Sep 2007, Allin Cottrell wrote: I'm trying to connect a callback to start-editing on a cell renderer, but I must be doing something wrong. Duh, sorry, that should be editing-started, not start-editing. Then it works. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: start-editing signal?
On Fri, Sep 21, 2007 at 03:11:12PM -0400, Allin Cottrell wrote:
I'm trying to connect a callback to start-editing on a cell
renderer, but I must be doing something wrong. My code is
basically
static void create_cell_renderer (gpointer p)
{
GtkCellRenderer *r;
r = gtk_cell_renderer_text_new();
g_object_set(r, ypad, 1,
xalign, 1.0,
mode, GTK_CELL_RENDERER_MODE_EDITABLE,
NULL);
g_signal_connect(r, start-editing,
G_CALLBACK(cell_edit_start), p);
}
When this code is invoked, I'm getting
GLib-GObject-WARNING **: gsignal.c:1669: signal `start-editing' is
invalid for instance `0x822a5f0'
I've verified that 0x822a5f0 is indeed the return value from
gtk_cell_renderer_text_new.
Can anyone tell me how to make a valid hook-up?
Start with the correct signal name:
http://library.gnome.org/devel/gtk/stable/GtkCellRenderer.html#GtkCellRenderer-editing-started
Looking at the documentation should be first thing when you
get a GObject complaint about invalid signal/property name.
Yeti
--
http://gwyddion.net/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: start-editing signal?
On Fri, 21 Sep 2007, David Ne?as (Yeti) wrote: Start with the correct signal name... Yes, sorry about that. But here's a real question about cell editing in a treeview. I can make the point by reference to gtk-demo: 1. Start gtk-demo and select Editable cells under Tree View. Double-click to get the demo. 2. Click on the bottles of coke cell to edit it. 3. Type foo (and only that, no Enter). 4. Move the pointer out of the treeview window, then move it back in. My expectation: the unfinished edit will still be in place. Actual behaviour: the bottles of coke cell is as it was before I started; my edit-in-progress is gone. This may not be a bug as such, but I would like to know if there's a way of preserving the state of the cell-editing process, in face of the treeview window temporarily losing focus. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: start-editing signal?
On my machine, it did not revert back to bottles of coke. Depending on where I moved the pointer, it either made the change to foo or it left foo and I was still able to edit the cell. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: start-editing signal?
On Fri, 21 Sep 2007, Prewitt, Nathan C ERDC-ITL-MS Contractor wrote: On my machine, it did not revert back to bottles of coke. Depending on where I moved the pointer, it either made the change to foo or it left foo and I was still able to edit the cell. Interesting. The machine from which I reported this is running Ubuntu 7.04, with gtk 2.10.11. When I move the mouse pointer out of the treeview window, the cell edit-in-progress immediately disappears and bottles of coke comes back. I have another machine running GTK 2.12; I'll check on that, though I'm pretty sure the effect was the same. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: start-editing signal?
On Fri, 21 Sep 2007, Prewitt, Nathan C ERDC-ITL-MS Contractor wrote: On my machine, it did not revert back to bottles of coke. Depending on where I moved the pointer, it either made the change to foo or it left foo and I was still able to edit the cell. A relevant question occurs to me: Do you have your window manager set on click to focus or focus follows mouse? I have the latter. In any case, I think the behaviour that most users would expect is: when the window you left with an uncommitted edit regains focus, the uncommitted edit would still be there, and still uncommitted. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
