GNOME Bugzilla – Bug 518315
Details/List: copy, paste, cut menu items are always sensitive.
Last modified: 2021-07-05 10:53:01 UTC
glom 1.6.8 ubuntu 7.10 - copy/paste doesn't work developer or operator I have copied some text from another application. I click in text field in Detailview and try to paste the text with ctrl+v, the meny option and mouse middle button. The application I copied from is still open. Nothing is Pasted. If I instead paste in a *.txt document, the text is pasted so it works with other applications and the copy part has worked. Also I: as developer Developer/Fields I highlight a text field and click open. Default formating Activate Custom Choice List Click +Add I write a word, 2click and Copy it and then hit Enter. Click +Add and I try to Paste in all the different ways as above but it doesn't paste anything. Also II: as developer Detailview I click Add to add a new Post. I start to fill out different fields. I click on the back arrow to go to my Post before this one. I 3click to highlight all the text ina textfield. ctrl+c Click on the Forward arrow to go back to my new Post. I click in a text field and then ctrl+v, nothing gets pasted. I have tried using the menues or the middle button on the mouse but it doesn't work. /Göran
> - copy/paste doesn't work > developer or operator > I have copied some text from another application. > I click in text field in Detailview and try to paste the text with ctrl+v, the > meny option and mouse middle button. > The application I copied from is still open. > Nothing is Pasted. I tested this with some text copied from gedit and then pasted into a description field in a Glom system created from the Music Collection example. It worked fine for me. Could you please try this with gedit?
> I tested this with some text copied from gedit and then pasted into a > description field in a Glom system created from the Music Collection example. > It worked fine for me. > > Could you please try this with gedit? > As long as the text is highlighted I can get it pasted with the middle mouse button. If it's not highlighted it doesn't work. ctrl+c and ctrl+v or the meny options doesn't work at all, if it's highlighted or not. It doesn't work between fields either. This problem with ctrl+c and ctrl+v not working in/between all applications (it works here in firefox) I have noticed before. Sometimes middle button works but not all the time. I don't know if this is a thing with my installation or as I thought before was how Ubuntu works.
> Could you please try this with gedit? > > ctrl+c and ctrl+v or the meny options doesn't work at all. I can't reproduce this so there's not much I can do. Sorry. If anyone else has the same problem in future, please add a comment here. Are you using a "clipboard manager" such as klipper?
> Are you using a "clipboard manager" such as klipper? > No nothing like that.
I do have the same problem. I think the problem is that the ctrl+c and ctrl+v commands are used by the accelerators from the UI manager. I temporarily removed the cut, copy and paste actions in bakery, and copy+pasting in entries worked again. Does glom actually use these actions?
> I temporarily removed the cut, copy and paste actions in bakery, and > copy+pasting in entries worked again. Does glom actually use these actions? No, but it should, at least for doing copy/paste in the entries, but I don't know how to make them do that.
*** Bug 606171 has been marked as a duplicate of this bug. ***
Retitling because I believe that copy/pasting generally works, though you need to use the context menu. It's just that ctrl-c and ctrl-v don't work.
Note that ctrl-c and ctrl-v work in /glom/utility_widgets/test_flowtable so this is not a general problem with the FlowTable widget used in the Details view. Note also that this is a problem in both the list view (in the treeview) and the details view (in the entry widgets in the FlowTable). It does seem to work in the various modal dialogs that can be opened via the Developer menu.
(In reply to comment #6) > > I temporarily removed the cut, copy and paste actions in bakery, and > > copy+pasting in entries worked again. Does glom actually use these actions? > > No, but it should, at least for doing copy/paste in the entries, but I don't > know how to make them do that. As a GtkEntry is a GtkEditable, calling gtk_editable_copy_clipboard() (and the paste and cut variants) on the entry should work. It should be possible to use gtk_window_get_focus() to get the currently-focussed widget inside the handlers for the clipboard actions, then perform the requested action if the widget is a GtkEditable. (In reply to comment #9) > Note that ctrl-c and ctrl-v work in /glom/utility_widgets/test_flowtable so > this is not a general problem with the FlowTable widget used in the Details > view. Accelerator groups, such as the one created by GtkUIManager in the main window, are specific to a GtkWindow. The behaviour described in this bug seems to occur because the cut, copy and paste accelerators are swallowed by the main window before reaching the FlowTable. > Note also that this is a problem in both the list view (in the treeview) and > the details view (in the entry widgets in the FlowTable). It does seem to work > in the various modal dialogs that can be opened via the Developer menu. This is not a problem for a dialog, which does not have the GtkUIManager containing the actions.
> It should be possible to use > gtk_window_get_focus() to get the currently-focussed widget inside the handlers > for the clipboard actions, then perform the requested action if the widget is a > GtkEditable. I guess that could be done, but I am surprised that this is necessary. You might try adding a GtkEntry or two to gtkmm-documentation/examples/book/menus_and_toolbars to see if it has the same problem.
Created attachment 204136 [details] [review] preliminary fix (In reply to comment #11) > > It should be possible to use > > gtk_window_get_focus() to get the currently-focussed widget inside the handlers > > for the clipboard actions, then perform the requested action if the widget is a > > GtkEditable. This approach worked, as can be tested with the attached preliminary patch. It needs a little bit of cleanup before it should get merged. > I guess that could be done, but I am surprised that this is necessary. You > might try adding a GtkEntry or two to > gtkmm-documentation/examples/book/menus_and_toolbars to see if it has the same > problem. OK, I will work on that next, then come back to this patch and tidy it up.
Indeed, it seems that this is expected behaviour, as the following modification to the menus_and_toolbars gtkmm-documentation example acts in the same way, swallowing the keybindings for clipboard actions: diff --git a/examples/book/menus_and_toolbars/examplewindow.cc b/examples/book/menus_and_toolbars/examplewindow.cc index 6b389de..14affd5 100644 --- a/examples/book/menus_and_toolbars/examplewindow.cc +++ b/examples/book/menus_and_toolbars/examplewindow.cc @@ -103,6 +103,9 @@ ExampleWindow::ExampleWindow() //Add the MenuBar to the window: m_Box.pack_start(*pToolbar, Gtk::PACK_SHRINK); + Gtk::Entry *entry = manage(new Gtk::Entry()); + m_Box.pack_start(*entry); + show_all_children(); }
Review of attachment 204136 [details] [review]: Just some comments about stuff that you probably already know. ::: glom/bakery/app_withdoc_gtk.cc @@ -569,1 +569,5 @@ +void App_WithDoc_Gtk::on_edit_copy_activate() +{ + const Gtk::Widget* widget = this->get_focus(); + if (!widget) No space before the (, please. @@ -570,0 +570,7 @@ +void App_WithDoc_Gtk::on_edit_copy_activate() +{ + const Gtk::Widget* widget = this->get_focus(); ... 4 more ... C++ should be fine here. Put the * next to the type, please.
> Indeed, it seems that this is expected behaviour Please do clean up that patch and push it to master and glom-1-20, even if it's just a temporary solution. But I'm still a little surprised and I wonder that I have only encountered this problem in glom and regexxer, which both use gtkmm. Could you try a C test case, please?
(In reply to comment #15) > > Indeed, it seems that this is expected behaviour > But I'm still a little surprised and I wonder that I have only encountered this > problem in glom and regexxer, which both use gtkmm. Could you try a C test > case, please? gedit would seem to be a good test case, and the developers took a similar approach to the clipboard actions: http://git.gnome.org/browse/gedit/tree/gedit/gedit-commands-edit.c#n103 http://git.gnome.org/browse/gedit/tree/gedit/gedit-view.c#n859 Epiphany, likewise: http://git.gnome.org/browse/epiphany/tree/src/window-commands.c#n747 regexxer does a very similar thing too: http://git.gnome.org/browse/regexxer/tree/src/mainwindow.cc#n451 I do not think that a separate test case is necessary, given the examples above. I will work on tidying up the patch according to the review comments in comment 14.
Created attachment 204259 [details] [review] tidied patch to add simple clipboad handlers
Thanks. But other menu item signal handlers there have an on_menu*() prefix. Please change that and then commit to both branches.
Comment on attachment 204259 [details] [review] tidied patch to add simple clipboad handlers Modified patch pushed to master and glom-1-20 branches as commits c3a42416dbbe0b83b65ab4974af909cd72fc7a6f and 1539ae43a1a7523fe7d747f5bfa5393cd454ce5c.
The end result was unnecessarily strange. I fixed it: http://git.gnome.org/browse/glom/commit/?id=984ccb57069d75000f624691b8bf33b0acac6038 However, it still did not work for GtkTextViews (used for multi-line fields such as comments). This commit fixes that: http://git.gnome.org/browse/glom/commit/?id=7ecb09e33e20c600d0f125711bf5c415a4c91371 It already worked for GtkTreeView (used for related records). We still need to enable/disable the paste menu depending on whether anything suitable is in the clipboard, so I will keep this bug open until that is fixed.
We should also disable cut and copy if no text is selected. This is what gedit does.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/glom/-/issues/ Thank you for your understanding and your help.