Bug 2371 - Port to GTK+3.0
Summary: Port to GTK+3.0
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: UI (show other bugs)
Version: 3.7.9
Hardware: PC Linux
: P3 enhancement
Assignee: users
: 3036 3037 3710 (view as bug list)
Depends on:
Reported: 2011-02-24 15:18 CET by Laurent Bigonville
Modified: 2020-10-30 14:31 CET (History)
14 users (show)

See Also:

step 1: use accessor functions (155.17 KB, patch)
2011-10-05 11:44 CEST, Hanno Meyer-Thurow
no flags Details | Diff
step 2: GDK_KEY_ vs GDK_ (71.15 KB, patch)
2011-10-05 12:56 CEST, Hanno Meyer-Thurow
no flags Details | Diff
step 1: use accessor functions: fix gtkcmclist realize (541 bytes, application/octet-stream)
2011-10-06 01:04 CEST, Hanno Meyer-Thurow
no flags Details
hack: remove gtkshruler (6.87 KB, patch)
2011-10-06 01:08 CEST, Hanno Meyer-Thurow
no flags Details | Diff
step 3: porting guide passed (untested) (63.66 KB, patch)
2011-10-06 22:42 CEST, Hanno Meyer-Thurow
no flags Details | Diff
GtkRuler import: GtkSHRuler needs fixing/porting (81.57 KB, patch)
2011-10-11 21:37 CEST, Hanno Meyer-Thurow
no flags Details | Diff
Add output for enable-gtk3 (528 bytes, patch)
2015-02-08 12:18 CET, al-clawsmail
no flags Details | Diff
GTK3 patch (487.65 KB, patch)
2017-03-06 04:27 CET, rezso
no flags Details | Diff
Error messages from not ported parts (20.24 KB, text/plain)
2017-03-06 04:28 CET, rezso
no flags Details
partial GTK3 patch v2 (50.06 KB, patch)
2017-03-07 03:31 CET, rezso
no flags Details | Diff
folderview rewrite using GtkTreeView, v2 (165.53 KB, patch)
2017-07-25 17:17 CEST, Andrej Kacian
no flags Details | Diff
fancy plugin "cid:" handler and POC of web extension (7.95 KB, patch)
2019-02-20 14:12 CET, tonich.sh
no flags Details | Diff
fancy plugin "cid:" handler and POC of web extension (9.84 KB, patch)
2019-02-20 14:20 CET, tonich.sh
no flags Details | Diff

Description Laurent Bigonville 2011-02-24 15:18:22 CET

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.

Comment 1 Colin Leroy 2011-02-24 16:44:20 CET

Good luck to whoever tries to work on that task.
Comment 2 Michael Rasmussen 2011-02-24 20:40:39 CET
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.
Comment 3 Holger Berndt 2011-02-24 20:59:26 CET
Support for the notification area is not gone in GTK+3.
Comment 4 Colin Leroy 2011-02-24 21:15:12 CET
That may well be the only thing not gone, barring GtkWidget. From what I saw trying to build the stuff.
Comment 5 Andrej Kacian 2011-02-24 21:24:50 CET
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?
Comment 6 Holger Berndt 2011-02-24 21:27:05 CET
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.
Comment 7 Andrej Kacian 2011-02-24 21:35:45 CET
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.
Comment 8 Hanno Meyer-Thurow 2011-10-05 11:44:13 CEST
Created attachment 1020 [details]
step 1: use accessor functions

This patch applies to cvs HEAD.

Build with the additional CFLAGS:

There are three things I am curious about:
1. DND: how to properly find the correct GdkAtom with the API:
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.
Comment 9 Hanno Meyer-Thurow 2011-10-05 12:56:47 CEST
Created attachment 1021 [details]
step 2: GDK_KEY_ vs GDK_

This one should be harmless?!
Comment 10 Colin Leroy 2011-10-05 14:08:31 CEST
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...
Comment 11 Hanno Meyer-Thurow 2011-10-05 14:28:07 CEST
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.
Comment 12 Hanno Meyer-Thurow 2011-10-06 01:04:52 CEST
Created attachment 1022 [details]
step 1: use accessor functions: fix gtkcmclist realize
Comment 13 Hanno Meyer-Thurow 2011-10-06 01:08:24 CEST
Created attachment 1023 [details]
hack: remove gtkshruler

Just to finish compilation.
Comment 14 Hanno Meyer-Thurow 2011-10-06 22:42:22 CEST
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!

- ssl_manager already uses GtkTreeView

- 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 ...
Comment 15 Colin Leroy 2011-10-06 22:51:21 CEST
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.
Comment 16 Hanno Meyer-Thurow 2011-10-06 23:52:24 CEST
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.
Comment 17 Hanno Meyer-Thurow 2011-10-07 00:10:58 CEST
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
Comment 18 users 2011-10-07 11:10:36 CEST
Changes related to this bug have been committed.
Please check latest CVS and update the bug accordingly.
You can also get the patch from:

2011-10-07 [colin]	3.7.10cvs19

	* 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 !
Comment 19 users 2011-10-07 11:18:36 CEST
Changes related to this bug have been committed.
Please check latest CVS and update the bug accordingly.
You can also get the patch from:

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_*.
Comment 20 users 2011-10-07 11:41:36 CEST
Changes related to this bug have been committed.
Please check latest CVS and update the bug accordingly.
You can also get the patch from:

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)
Comment 21 Hanno Meyer-Thurow 2011-10-07 11:50:40 CEST
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?
Comment 22 Colin Leroy 2011-10-07 12:15:28 CEST

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 :)
Comment 23 Colin Leroy 2011-10-07 17:49:05 CEST
The problem of the current undeprecation is that some stuff is not too old.

Using GTK+2.20, these are undefined:

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...
Comment 24 Hanno Meyer-Thurow 2011-10-07 19:23:48 CEST
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
Comment 25 Holger Berndt 2011-10-08 00:22:20 CEST
> 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?
Comment 26 Colin Leroy 2011-10-08 11:28:39 CEST
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.
Comment 27 Hanno Meyer-Thurow 2011-10-08 13:57:42 CEST
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.
Comment 28 Gerard Seibert 2011-10-08 14:53:35 CEST
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¢.
Comment 29 Brian Morrison 2011-10-08 18:06:29 CEST
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.
Comment 30 Hanno Meyer-Thurow 2011-10-09 11:41:56 CEST
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?
Comment 31 Colin Leroy 2011-10-09 14:25:29 CEST
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.

summaryview.c:2898:TIMING summary_sort : 0s137ms
same folder, sorted by date (which is just an int compare so much faster), unthreaded.
Comment 32 Hanno Meyer-Thurow 2011-10-09 15:15:34 CEST
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
Comment 33 Paul 2011-10-09 15:21:43 CEST
Just a suggestion:
why not take this enhancement request, now that it has become a full blown conversation, to the developers' mailing list?
Comment 34 Michael Rasmussen 2011-10-09 17:46:11 CEST
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.
Comment 35 Salvatore De Paolis 2011-10-09 23:18:23 CEST
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.
Comment 36 Paul 2011-10-09 23:28:27 CEST
Certainly it is too early to drop GTK2 support, imo.
CVS is capable of branches.
Comment 37 Hanno Meyer-Thurow 2011-10-11 21:37:49 CEST
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]
Comment 38 Ricardo Mones 2013-12-17 19:16:48 CET
*** Bug 3036 has been marked as a duplicate of this bug. ***
Comment 39 Ricardo Mones 2013-12-17 19:18:06 CET
*** Bug 3037 has been marked as a duplicate of this bug. ***
Comment 40 al-clawsmail 2015-02-08 12:17:27 CET
let's see if --enable-gtk3 was given at ./configure

Comment 41 al-clawsmail 2015-02-08 12:18:34 CET
Created attachment 1482 [details]
Add output for enable-gtk3
Comment 42 James Le Cuirot 2015-09-09 12:18:47 CEST
Time to stoke up this fire?

Comment 43 Paul 2016-10-09 13:46:02 CEST
*** Bug 3710 has been marked as a duplicate of this bug. ***
Comment 44 Paul 2016-10-09 14:36:51 CEST
*** Bug 3710 has been marked as a duplicate of this bug. ***
Comment 46 Klaus Kusche 2017-02-03 14:32:09 CET
(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.
Comment 47 flo.xfce 2017-02-03 14:46:18 CET
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.
Comment 48 Paul 2017-02-03 14:54:30 CET
(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

Comment 49 rezso 2017-03-04 18:58:46 CET
This plus sign causes compilation error with GTK3:

error: called object is not a function or function pointer
Comment 50 rezso 2017-03-06 04:27:39 CET
Created attachment 1723 [details]
GTK3 patch

Not ported:
- ldap
- jpilot
- enchant
- archive
- notification
- poppler
- vcalendar
Comment 51 rezso 2017-03-06 04:28:57 CET
Created attachment 1724 [details]
Error messages from not ported parts

Error messages from not ported parts
Comment 52 Paul 2017-03-06 19:40:18 CET
(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?
Comment 53 rezso 2017-03-07 03:31:34 CET
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.
Comment 54 Christopher Head 2017-07-22 10:15:11 CEST
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?
Comment 55 Hanno Meyer-Thurow 2017-07-22 11:01:41 CEST
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.
Comment 56 Christopher Head 2017-07-22 20:05:36 CEST
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?
Comment 57 Hanno Meyer-Thurow 2017-07-23 00:26:39 CEST
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. :-)
Comment 58 Klaus Kusche 2017-07-23 08:51:53 CEST
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.
Comment 59 Andrej Kacian 2017-07-25 17:17:20 CEST
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.
Comment 60 Andrej Kacian 2017-07-25 17:21:49 CEST
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/
Comment 61 James Le Cuirot 2017-07-25 17:27:31 CEST
(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.
Comment 62 Holger Berndt 2017-07-25 23:48:26 CEST
(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".
Comment 63 Andrej Kacian 2019-01-03 01:01:42 CET
Reopening this, as development is ongoing in the "gtk3" branch of our git repo.

Patches are still welcome. :)
Comment 64 tonich.sh 2019-02-20 14:12:46 CET
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).
Comment 65 tonich.sh 2019-02-20 14:20:16 CET
Created attachment 1958 [details]
fancy plugin "cid:" handler and POC of web extension
Comment 66 Andrej Kacian 2019-02-25 22:23:55 CET
(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.
Comment 67 rezso 2019-03-28 01:00:52 CET
Just a note: libcanberra support requires libcanberra-gtk3, not the libcanberra-gtk.
Comment 68 Paul 2020-05-18 15:30:48 CEST
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'

Note You need to log in before you can comment on or make changes to this bug.