Hi, It would be great if claws-mail could support GTK+3.0. I guess some plugins (notification plugins) will require some works or will be disabled as the notification area is gone. Cheers
Hi, Good luck to whoever tries to work on that task.
Besides agony and pain I see no real benefits of doing this transition. And since RHEL 6 does not have end of life until November 30, 2017 GTK 2.x will be maintained for many years to come.
Support for the notification area is not gone in GTK+3.
That may well be the only thing not gone, barring GtkWidget. From what I saw trying to build the stuff.
Why don't we give gtk3 a few point releases (even better, few minor ones as well) before even beginning to consider it? We will most likely have to carry over the GtkSC* and GtkCM* widgets anyway, since gtk3 doesn't seem to provide usable alternatives. Besides, what's wrong with gtk2? It's still a strong toolkit with years of life ahead. What is there to be gained with gtk3?
I don't think it will be possible to carry over old list and tree widgets. Well, possible of course, but you'll have to invest a lot of work in oder to port them. Which is work spent on zombies. The replacement for those is GtkTreeView. It's been around for years now.
Regarding GtkTreeView, it's not nearly as fast as GtkCMCTree. I have tried replacing one instance of GtkCMCTree with it, and difference in how long it takes to simply populate the the treeview's model with thousands of entries (I partially replaced the NNTP newsgroup subscription widget) is several seconds with GtkTreeView, vs. fraction of a second with GtkCMCTree.
Created attachment 1020 [details] step 1: use accessor functions This patch applies to cvs HEAD. Build with the additional CFLAGS: "-DGTK_DISABLE_SINGLE_INCLUDES -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGSEAL_ENABLE" There are three things I am curious about: 1. DND: how to properly find the correct GdkAtom with the API: http://developer.gnome.org/gtk/2.24/gtk-Drag-and-Drop.html#gtk-drag-dest-find-target 2. How to replace the direct access of GtkButton in_button. I checked the local focus instead. 3. GTK_IS_COMBO_BOX_ENTRY is no more. I did instead: 'if(GTK_IS_COMBO_BOX(widget) && gtk_combo_box_get_has_entry(GTK_COMBO_BOX(widget)))' Unfortunately, I get a segfault in folderview_init (folderview=0xb6dd20) at folderview.c:677 (gtk_widget_set_style(ctree, normal_style); ctree's GdkWindow is NULL. class: gtksctree) I wonder, if it is because of gcc 4.6 or missing deprecated symbols or ... Another note: I wonder what gtk version these changes require. At least that combo box change requires gtk 2.24 that you may '#ifdef'. Any help or pointers to improve or fix the issue(s) are welcomed.
Created attachment 1021 [details] step 2: GDK_KEY_ vs GDK_ This one should be harmless?!
Hi Hanno, Your work is appreciated, thanks ! I wonder if your segfault could come from the fact the GtkCMCTree, GtkCMCList and GTKSCTree are so old that they rely on unsupported drawing methods. I thought GdkGC and friends were no more in GTK+3.0...
Yes, GdkDC, GdkImage and the functions involved with them are gone. That would be my next step; moving them to cairo. Though, I still build against gtk-2.x. These steps are at least gtk-2.24 compliant. But yes, the drawing functions throw an implicit-function-declaration warning but link just fine in the end. I will see.
Created attachment 1022 [details] step 1: use accessor functions: fix gtkcmclist realize
Created attachment 1023 [details] hack: remove gtkshruler Just to finish compilation.
Created attachment 1024 [details] step 3: porting guide passed (untested) First round of Gtk-3.0 porting. Open to others: - excluded GtkCMOptionMenu & GtkSHRuler for gtk3 Feel free to port! Noticed: - ssl_manager already uses GtkTreeView Questions: - I wonder about the Makefile magic for gtk2 / gtk3 - I will try to port the Trees to GtkTreeView; ideas; alternatives available? I am open for any help ...
Hi Hanno Thanks again for your patches. They're really big and I want to get some time to be able to give them the attention they deserve, that's why they didn't land in CVS yet. Concerning the trees, you'll see that most of them are already ported to the new APIs, and only the most difficult ones are left, FolderView and SummaryView :) Concerning Makefile magic, I don't really know if that would be really difficult, but if I were you, I'd keep that for the last part - normally, all of the porting should be usable on gtk2, so then it'll just be some PKG_CHECK_MODULES voodoo to make it work on either version.
Sure, take the time necessary. I have not checked CVS since. So you say, that even for gtk2 you want to use GtkTreeView everywhere? A patch for configure.ac and src/gtk/Makefile.am is already in step 3. Though, if it is corrent and the best way to handle, I wonder. So, the best would be, if you send me a mail after the patchsets landed in CVS. Then, I could sync my codebase and ask for changes from my code if necessary. After that I would look into the trees. Though, I won't have much time to spare starting from next week.
O, JFYI, two typos happened on step 3. - configure.ac: needs proper description for Gtk+ 3.0 and strings may be surrounded by " - did a bad sed on gtk3 preprocessor checks: should obviously be: '#if !GTK_CHECK_VERSION(...)' versus '#ifdef ...' and same for without the exclamation mark
Changes related to this bug have been committed. Please check latest CVS and update the bug accordingly. You can also get the patch from: http://www.colino.net/claws-mail/ 2011-10-07 [colin] 3.7.10cvs19 * AUTHORS * src/account.c * src/action.c * src/addr_compl.c * src/addressbook.c * src/alertpanel.c * src/compose.c * src/edittags.c * src/folderview.c * src/grouplistdialog.c * src/image_viewer.c * src/mainwindow.c * src/mimeview.c * src/noticeview.c * src/prefs_filtering_action.c * src/prefs_folder_column.c * src/prefs_msg_colors.c * src/prefs_summary_column.c * src/prefs_toolbar.c * src/printing.c * src/stock_pixmap.c * src/summaryview.c * src/textview.c * src/undo.c * src/wizard.c * src/gtk/about.c * src/gtk/authors.h * src/gtk/colorlabel.c * src/gtk/colorsel.c * src/gtk/gtkcmclist.c * src/gtk/gtkcmctree.c * src/gtk/gtkcmoptionmenu.c * src/gtk/gtksctree.c * src/gtk/gtkutils.c * src/gtk/gtkvscrollbutton.c * src/gtk/inputdialog.c * src/gtk/logwindow.c * src/gtk/menu.c * src/gtk/prefswindow.c * src/gtk/progressdialog.c * src/plugins/pgpcore/passphrase.c * src/plugins/trayicon/trayicon.c Bug #2371, "Port to GTK+ 3.0": Use accessor functions. Patch by Hanno Thurow-Meyer, many thanks to him !
Changes related to this bug have been committed. Please check latest CVS and update the bug accordingly. You can also get the patch from: http://www.colino.net/claws-mail/ 2011-10-07 [colin] 3.7.10cvs20 * src/account.c * src/action.c * src/addr_compl.c * src/addrcustomattr.c * src/addrduplicates.c * src/addressadd.c * src/addressbook.c * src/addressbook_foldersel.c * src/addrgather.c * src/alertpanel.c * src/browseldap.c * src/compose.c * src/editaddress.c * src/editaddress_other_attributes_ldap.c * src/editbook.c * src/editgroup.c * src/editjpilot.c * src/editldap.c * src/editldap_basedn.c * src/edittags.c * src/editvcard.c * src/exphtmldlg.c * src/expldifdlg.c * src/export.c * src/foldersel.c * src/folderview.c * src/grouplistdialog.c * src/import.c * src/importldif.c * src/importmutt.c * src/importpine.c * src/mainwindow.c * src/message_search.c * src/messageview.c * src/mimeview.c * src/prefs_actions.c * src/prefs_customheader.c * src/prefs_display_header.c * src/prefs_filtering.c * src/prefs_filtering_action.c * src/prefs_folder_column.c * src/prefs_matcher.c * src/prefs_msg_colors.c * src/prefs_other.c * src/prefs_summaries.c * src/prefs_summary_column.c * src/prefs_summary_open.c * src/prefs_template.c * src/prefs_toolbar.c * src/printing.c * src/sourcewindow.c * src/ssl_manager.c * src/summary_search.c * src/summaryview.c * src/textview.c * src/uri_opener.c * src/gtk/about.c * src/gtk/colorsel.c * src/gtk/combobox.c * src/gtk/description_window.c * src/gtk/foldersort.c * src/gtk/gtkaspell.c * src/gtk/gtkcmclist.c * src/gtk/gtkcmctree.c * src/gtk/gtkcmoptionmenu.c * src/gtk/gtkutils.c * src/gtk/icon_legend.c * src/gtk/inputdialog.c * src/gtk/logwindow.c * src/gtk/pluginwindow.c * src/gtk/prefswindow.c * src/gtk/quicksearch.c * src/plugins/pgpcore/passphrase.c * src/plugins/pgpcore/select-keys.c Bug #2371, "Port to GTK+ 3.0". Monster-patch by Hanno Meyer-Thurow to replace GDK_* by GDK_KEY_*.
Changes related to this bug have been committed. Please check latest CVS and update the bug accordingly. You can also get the patch from: http://www.colino.net/claws-mail/ 2011-10-07 [colin] 3.7.10cvs21 * configure.ac * src/action.c * src/addr_compl.c * src/addrgather.c * src/compose.c * src/compose.h * src/editldap.c * src/mainwindow.c * src/message_search.c * src/mimeview.c * src/mimeview.h * src/prefs_account.c * src/prefs_compose_writing.c * src/prefs_filtering_action.c * src/prefs_folder_item.c * src/prefs_logging.c * src/prefs_matcher.c * src/prefs_message.c * src/prefs_other.c * src/prefs_receive.c * src/prefs_summaries.c * src/prefs_wrapping.c * src/printing.c * src/ssl_manager.c * src/statusbar.c * src/stock_pixmap.c * src/summary_search.c * src/textview.c * src/gtk/Makefile.am * src/gtk/colorlabel.c * src/gtk/gtkutils.c * src/gtk/gtkutils.h * src/gtk/logwindow.c * src/gtk/menu.c * src/gtk/menu.h * src/gtk/quicksearch.c * src/gtk/spell_entry.c * src/plugins/bogofilter/bogofilter_gtk.c * src/plugins/dillo_viewer/dillo_viewer.c * src/plugins/pgpcore/prefs_gpg.c * src/plugins/spamassassin/spamassassin_gtk.c Bug #2371, "Port to GTK+ 3.0". Third patch from Hanno, starting the real job. GtkCMOptionMenu and GTKHSRuler disabled, should be ported (especially GtkCMOptionMenu)
On a second thought after reading a bit about GtkTreeView's MVC design, I am not going to port the remaining trees next but rather evaluate the use of an implementation of GtkTreeModel for claws-mail. Maybe there is one out there already I could start with. Is it that uncommon to have tens or hundreds of thousands of elements in a tree?! I found a mail on a gnome list saying that GtkTreeStore is too slow managing 250,000 elements. Sadly, no answer. At least for the summaryview, the tree will grow too big for the simple GtkTreeStore I guess. The folderview may manage with a simple GtkTreeStore, though. Would that be the right direction? Comments?
Hi, I've applied your patches (and modified it a bit so that Claws builds with --disable-deprecated on GTK+2.24 -- although there are warnings). You should get 3.7.10cvs23 :) Concerning GtkTreeStores, yes, the summaryview one would need some performance and that's part of why we still didn't move away from the old CTree-based widgets... The Folderview does not need performance (it just needs to avoid counting and recounting mails in folders, but that is already cached). Thanks for your work, again :)
The problem of the current undeprecation is that some stuff is not too old. Using GTK+2.20, these are undefined: gdk_drag_context_get_selected_action gdk_drag_context_get_actions gtk_combo_box_get_has_entry gtk_text_view_get_vadjustment gdk_drag_context_get_suggested_action gtk_button_get_event_window gtk_text_view_get_vadjustment We support (until now) GTK +2.10, where probably a bunch more are undefined. I'll see whether adding compat stuff is possible, if not, we'll have to decide what version of GTK+ we want to support. 2.10 is from july 2009 2.20 May 2010 2.22 Nov 2010. Maybe 2.20 would be OK. Paul, any opinion on this ? I know we historically supported old GTKs, but that'll start to be difficult...
JFYI, I prepared a small testcase[0] for GtkTreeModel implementations that you may help to extend. Well, actually, nothing useful yet; testing a GtkListStore. Though, it would be of great help, if anyone could send me some data, or point me to an URL, with a big ASCII table (>100000 entries) to fill the model with columns like in the summary view. In the end, the GtkTreeStore may just do fine ... I wonder, how the data for that tree is managed? Is it stored exclusively in that tree? Or is it saved somewhere else in memory, too? I read that a (custom) GtkTreeModel could perform better by only referencing that data already available. [0] http://code.google.com/p/gekis-playground/source/browse/trunk/scripts/gtktreemodel_performance.c
> I know we historically supported old GTKs, but that'll start to be difficult... I don't remember the port to GTK+2 keeping on supporting GTK+1. It it's starting to get difficult, maybe it's time for a clean cut?
The difference was worse, and at the time we all had much more time to handle syncs and merges and everything. That's why I'm not sure it's necessary this time.
I should not step in that management discussion, though, I would move to 2.20 or even 2.24. Leave a news message ahead of time of a new release that the move to GTK+ 3.0 started with code cleanups to latest API. So, if any distribution wants old Gtk+ 2.x API being supported, they may send patches. Well ... I shut up again.
Purely my own observation, but I have found that continued support for multiple versions can significantly lead to program "bloat" and in some situations case a "regression" in application performance and/or stability. Plus, it causes the developers resources to be further strained. A significantly improved version, GTK 3.x is now available. To ignore it would seem asinine. I would propose that it be incorporated into claws-mail at a moderate rate, cumulating in the removal for support for the GTK 2.x versions withing 2 years. In that manner, everyone has time to make the required accommodations and modifications to their systems. Then again, that is just my 2¢.
You are assuming that everyone wants to use GNOME 3, and that it will become the dominant desktop environment. A lot of people are very upset with GNOME over the current direction of the desktop and it may fail to gain enough support to continue. Please don't encourage the removal of GTK2 support at this early stage in the life of GNOME 3.
Update on preliminary performance tests. The sort is quite slow, as expected. So, I wonder if there is someone who could test sorting of ~5000 messages, unthreaded. With my test names, it takes a quite noticable time, .3 seconds. I also wonder what the current state of Claws Mail is. Is sorting done within GtkCMCList/Tree or is the tree simply rebuilt with the proper order?
The tree is rebuilt with proper order. Sorting reloads the folder. Here, I have: summaryview.c:2898:TIMING summary_sort : 6s522ms for 23k mails, sorted by subject, unthreaded. And summaryview.c:2898:TIMING summary_sort : 0s137ms same folder, sorted by date (which is just an int compare so much faster), unthreaded.
So, there is no need for any sorting within the GtkTreeView? Great! To simply rebuilt seems faster anyway, good. I wonder if it is possible to add callbacks for the GtkTreeView column button clicked events. Or if there needs to be an own GtkSortable implementation to manage that. I hope not ... On a sidenote, I added a GtkTreeModel based on GtkTreeStore from gtk git 3.2 branch. For now I only removed the GtkSortable implementation. Now, one can start to fiddle with the underlying data containers. Hopefully, this stays somewhat close to upstream to sync with their changes/fixes. Well, will be semi-difficult anyway for various reasons. One would need to fix the CMTreeStore for Gtk+ 2.x: cmtreestore.c: In function 'cm_tree_store_tree_model_init': cmtreestore.c:203:8: error: 'GtkTreeModelIface' has no member named 'iter_previous' A quick test result here for ~5000 entries: tree populate takes 250ms vs list 30ms
Just a suggestion: why not take this enhancement request, now that it has become a full blown conversation, to the developers' mailing list? http://lists.claws-mail.org/cgi-bin/mailman/listinfo/devel
I also would object to skipping GTK+2 support since this implicit means to abandon support for claws-mail on all Enterprise Linux distributions like RHEL, CentOS, Scientific Linux and Suse. The same goes for Debian Stable, Ubuntu 10.04 LTS as well as all *BSD distroes, the Windows and OSX port.
I think as well GTK2 support should be maintained for a while also because GTK3 is still a newborn baby. Not sure whether CVS is capable of branches but this could be a good case of having two separate branches with separate code to me.
Certainly it is too early to drop GTK2 support, imo. CVS is capable of branches.
Created attachment 1026 [details] GtkRuler import: GtkSHRuler needs fixing/porting I got around to add a standalone GtkRuler based on Gimp's GimpRuler and Gtk 2.24 GtkHRuler. Now, GtkSHRuler needs fixing for the changed API. I wonder if the standalone GtkRuler could be used instead of the GtkHRuler/GtkSHRuler combo; to simplify things. Btw, GtkRuler and GtkHRuler compiled here with sealed Gtk 2.24. GtkSHRuler errors left: gtkshruler.c: In function 'gtk_shruler_class_init': gtkshruler.c:88:14: error: 'GtkRulerClass' has no member named 'draw_ticks' gtkshruler.c:91:14: error: 'GtkRulerClass' has no member named 'draw_pos' gtkshruler.c: In function 'gtk_shruler_draw_ticks': gtkshruler.c:142:29: error: 'GtkRuler' has no member named 'backing_store' gtkshruler.c:154:29: error: 'GtkRuler' has no member named 'backing_store' gtkshruler.c:163:69: error: 'GtkRuler' has no member named 'max_size' gtkshruler.c:163:79: warning: left-hand operand of comma expression has no effect [-Wunused-value] gtkshruler.c:128:7: warning: variable 'width' set but not used [-Wunused-but-set-variable]
*** Bug 3036 has been marked as a duplicate of this bug. ***
*** Bug 3037 has been marked as a duplicate of this bug. ***
let's see if --enable-gtk3 was given at ./configure configure-ac.patch
Created attachment 1482 [details] Add output for enable-gtk3
Time to stoke up this fire? https://archives.gentoo.org/gentoo-dev/message/b7557da35aae07b6906f8a64f626f64c
*** Bug 3710 has been marked as a duplicate of this bug. ***
This is becoming an increasingly urgent issue: http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3763 http://lists.claws-mail.org/pipermail/users/2017-January/018540.html https://forums.gentoo.org/viewtopic-t-1026670-start-0.html https://lists.macports.org/pipermail/macports-users/2017-January/042570.html
(In reply to comment #45) > This is becoming an increasingly urgent issue: > > http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3763 > http://lists.claws-mail.org/pipermail/users/2017-January/018540.html > > https://forums.gentoo.org/viewtopic-t-1026670-start-0.html > https://lists.macports.org/pipermail/macports-users/2017-January/042570.html Not only an issue in arch and fedora, but also in Gentoo: The old webkit-gtk2 (used by fancy-plugin) is an unmaintained security nightmare (dozens of unfixed remote exploits) and is definitely going away sooner or later.
I was looking into the gtk3 port and came across some issues. Could somebody explain to me what the plus sign in the following line does? alertpanel(_("Warning"), msg, GTK_STOCK_CANCEL, "+" GTK_STOCK_YES, NULL) This snippet can be found in compose.c, line 12047.
(In reply to comment #47) > I was looking into the gtk3 port and came across some issues. Could somebody > explain to me what the plus sign in the following line does? > alertpanel(_("Warning"), msg, GTK_STOCK_CANCEL, "+" GTK_STOCK_YES, NULL) > This snippet can be found in compose.c, line 12047. This is not the place to ask but it's used to trigger gtk_widget_grab_default(); gtk_widget_grab_focus();
This plus sign causes compilation error with GTK3: error: called object is not a function or function pointer GTK_STOCK_NO, "+" GTK_STOCK_YES, ^~~
Created attachment 1723 [details] GTK3 patch Not ported: - ldap - jpilot - enchant plugins: - archive - notification - poppler - vcalendar
Created attachment 1724 [details] Error messages from not ported parts Error messages from not ported parts
(In reply to comment #50) > Created attachment 1723 [details] > GTK3 patch > > Not ported: > - ldap > - jpilot > - enchant > plugins: > - archive > - notification > - poppler > - vcalendar Your patch has a load of whitespace changes which are not needed and make it hard to see what you actually changed. Can you resubmit it with just worthwhile changes?
Created attachment 1725 [details] partial GTK3 patch v2 My text editor automatically removes the extra whitespaces, but you are right. The cleaned patch is done.
Hello folks! I might be interested in helping out with the GTK3 porting effort (I have a moderate amount of GTK+ experience, albeit almost of all if it using gtkmm instead of pure C). Is there any kind of plan or checklist of particular tasks that would make sense to parcel out?
The task I had on my list back in 2011 was the GtkStyle -> GtkStyleContext port. Next to the Gtk documentation I would recommend looking at libreoffice gtk3 code[0] in general and especially for the gtk style context, the native widget code[1]. [0] https://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/gtk3 [1] https://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/gtk3/gtk3salnativewidgets-gtk.cxx Licensing - taking code - should be no problem since LO uses some weak licensing. Ok to reuse in GPL code.
OK. I might take a look at that. Although, might I ask something? According to the documentation, GtkStyle is deprecated but still exists in 3. Does that mean that Claws is expected to build and run properly with 3 already, and the remaining work is just undeprecation? I agree that undeprecation work is worth doing, but if it’s relying on something completely missing in 3, then wouldn’t it make more sense to fix that first?
It is not just undeprecation. Getting it to compile with current Gtk3 is a prerequisite. See step 1 and 3. See comment #8 for additional sanitizing CFLAGS to add for proper access to Gtk structures. No more direct access to members of structures. I guess code deteriorated again; therefore the afore-mentioned CFLAGS and revisiting steps 1 and 3. Deprecated code is just no good. Full stop. There is GtkRcStyle next to GtkStyle, which is just no more available AFAIR. Therefore the Gtk(Rc)Style refactoring. (#ifdef'ing) I was able to compile and run Claws-Mail with Gtk3 back then. Though, the UI was just completely unusable. There, the fun begins. :-)
Don't forget to port the fancy plugin: The webkit interface has changed significantly from gtk2 to gtk3. The fancy plugin is the main reason why gtk3 is needed urgently: gtk2 webkit is going away really soon now in most distributions for security reasons.
Created attachment 1766 [details] folderview rewrite using GtkTreeView, v2 For what it's worth, about a month ago I rewrote folderview to use GtkTreeView&co. almost completely. There are a few things missing (mainly drag&drop functionality and column visibility configuration), but it mostly works for day to day use. There are a few issues with it, though, which stopped me from continuing: - when opening a folder by clicking on it, the focus sometimes does not stay in summaryview - it seems impossible to make the rows as dense as with the old tree widget If anyone is interested in continuing this work, I am attaching a patch of what I have so far. Feel free to contact me for more info e.g. about the mentioned issues - they are caused mostly by insufficient API, and some kludgy design within the GtkTreeView widget code.
Note that even with --enable-gtk3, Python and Fancy plugins still seem to use GTK2 CFLAGS. In Fancy's case, we already know that it will require additional porting, but I don't believe Python plugin has been mentioned here yet. Looks like there is no PyGTK3 - instead, PyGObject will need to be used for GTK3: https://python-gtk-3-tutorial.readthedocs.io/en/latest/
(In reply to comment #60) > Looks like there is no PyGTK3 - instead, PyGObject will need to be used for > GTK3: https://python-gtk-3-tutorial.readthedocs.io/en/latest/ Porting from PyGTK2 to PyGObject is very easy. I did it for another application recently and I don't even know Python that well. This a migration script that covers the basics.
(In reply to comment #61) > Porting from PyGTK2 to PyGObject is very easy. I did it for another > application recently and I don't even know Python that well. This a > migration script that covers the basics. I guess you are talking about porting PyGtk-based Python code to PyGObject-based Python code. That might be helpful for some scripts users have written based on the Python plugin, but it's not helpful for the plugin itself - which is written in C, and uses the C-API of PyGtk and CPython. So the task is to port from the C-API of PyGtk to the C-API of PyGObject (in case there is one, or whatever magic stuff needs to be done for gobject introspection). Also, a port from the C-API of CPython2 to the C-API of CPython3 is probably required. It sounds doable, but I wouldn't call it "very easy".
Reopening this, as development is ongoing in the "gtk3" branch of our git repo. Patches are still welcome. :)
Created attachment 1957 [details] fancy plugin "cid:" handler and POC of web extension Implemented "cid:", "mid:" handlers. Adden a proof of concept web extension for filtering content loaded (filtering not implemented).
Created attachment 1958 [details] fancy plugin "cid:" handler and POC of web extension
(In reply to comment #65) > Created attachment 1958 [details] > fancy plugin "cid:" handler and POC of web extension Um, I'm pretty sure we do not want webextensions in a simple HTML emails rendering - that sounds like a recipe for security disasters. The cid/mid handling stuff looks cool, though.
Just a note: libcanberra support requires libcanberra-gtk3, not the libcanberra-gtk.
Closing this now as GTK3 work is ongoing in the gtk3 git branch. Any future patches and bug reports should use the 'Claws Mail (GTK3)' bugzilla 'Product'