GNOME Bugzilla – Bug 590996
Remove Bonobo usage
Last modified: 2011-08-01 08:55:54 UTC
Bonobo will be removed for GNOME 3. I am aware that GHex is not an official part of GNOME but it would be more than welcome to clean up the codebase, also for GNOME distributors. For automated statistics see http://www.gnome.org/~fpeters/299.html .
AFAICT, most part of this bug is a straight-forward migration to GtkUIManager, with two notable exceptions. 1. DnDNewWindow_cb and DnDCancel_cb should probably just disappear, as unless libbonoboui imposed those as defaults, they don't seem to be used at all now 2. ghex_window_add_doc_to_list and ghex_window_remove_doc_from_list seem to be a major problem, as unmerging ui element happens by merge_id, which is known only as the merge happens - as such, for the moment it seems each top level window would need a list of pairs (merge_id, hex_document), so the correct ui element is unmerged when the hex_document is destroyed 1. just needs a confirmation of my suspicions 2. seems quite a bit of pain - either adding such list to each window, or completely redesign how toplevel windows and hex documents are being tracked
Maybe ghex can just be stripped down to a simple widget that doesn't try to do menu merging? Who is still using it anyway, and what do they need from it?
Well, the widget part obviously doesn't need menu merging, but the catch lies in what ghex used menu merging for. It was something akin of office suites do: one app that opens multiple files, allows them to be viewed in separated windows and allows multiple views of a single file. Due to the nature of this app, a file can be opened only once. Depending on ones workflow, a significant number of files might be opened. Perhaps a listview would be a valid alternate approach ? That's more of a design choice, than a simple porting problem.
Ah, I didn't realize that it's an app too. Well, what parts of the menu are merged? Just the Windows menu which lists the open files? As a shortcut, you could just remove that menu and let each window be an independent process. Or use GtkApplication, and use its API to discover the application's list of windows.
(In reply to comment #1) > 1. DnDNewWindow_cb and DnDCancel_cb should probably just disappear, > as unless libbonoboui imposed those as defaults, they don't seem to be used > at all now Looks like the person who introduced support for GDK_ACTION_ASK (asking user what to do with the dragged file) forgot to add parts of the implementation. I did some git history digging and I believe this has never worked. Pushed this to master: commit 95ecb061478cc8c3c7f0e2edea6e1c55e967fc91 Author: Kalev Lember <kalevlember@gmail.com> Date: Sun Jul 31 22:47:53 2011 +0300 Remove support for broken GDK_ACTION_ASK It was entirely broken with the popup dialog completely missing from the bonobo UI file. Apparently it has never worked and nobody has noticed either for the past 10 years. Removed the whole thing. Bonobo-WARNING **: Can't find path '/popups/DnD' for popup widget
(In reply to comment #1) > 2. ghex_window_add_doc_to_list and ghex_window_remove_doc_from_list > seem to be a major problem, as unmerging ui element happens by > merge_id, which is known only as the merge happens > - as such, for the moment it seems each top level window > would need a list of pairs (merge_id, hex_document), so the correct > ui element is unmerged when the hex_document is destroyed I solved this by storing all the open document UI entries under the same merge_id. Each time a new entry is added to the GtkActionGroup that stores the open documents actions, I remove all the old actions which share the same merge_id and then rebuild the UI based on the actions in GtkActionGroup. > 2. seems quite a bit of pain - either adding such list to > each window, or completely redesign how toplevel windows > and hex documents are being tracked A separate GtkActionGroup for open document actions was natural to store such list.
Pushed bonobo removal to master as e65bd05; closing the ticket.