Bug 3381 - MacOS: integration with native OSX GTK
Summary: MacOS: integration with native OSX GTK
Status: NEW
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: Other (show other bugs)
Version: other
Hardware: PC Mac OS X 10.1
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2015-02-06 18:39 CET by Igor Mammedov
Modified: 2017-11-22 17:38 CET (History)
1 user (show)

See Also:


Attachments
[PATCH v2 1/5] osx: fix configure's runtime check for python library (2.26 KB, patch)
2015-02-06 18:39 CET, Igor Mammedov
no flags Details | Diff
[PATCH v2 2/5] osx: fix python plugin build error (1.01 KB, patch)
2015-02-06 18:40 CET, Igor Mammedov
no flags Details | Diff
[PATCH v2 3/5] osx: add OSX integration with native GTK library (5.54 KB, patch)
2015-02-06 18:41 CET, Igor Mammedov
no flags Details | Diff
[PATCH v2 4/5] osx: set address book specific menubar as application (766 bytes, patch)
2015-02-06 18:42 CET, Igor Mammedov
no flags Details | Diff
[PATCH v2 5/5] osx: add 'make bundle' target to build OS X (260.64 KB, patch)
2015-02-06 18:43 CET, Igor Mammedov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Igor Mammedov 2015-02-06 18:39:37 CET
Created attachment 1477 [details]
[PATCH v2 1/5] osx: fix configure's runtime check for python library

Changes since v1:
  * move bundle specific scripts/files to osx subdirectory
  * squash enchant patch into bundle patch
  * disable quartz accelerators and drop menuless patches
    since with GTK bindings input works as expected

It makes possible to build claws-mail with native OSX GTK build
which is provided by gtk-mac-intergration project. It allows to
make a distributable OSX application bundle which doesn't depend
on any external libraries.

But mainly it allows to use native display server, i.e. no need
to run X server, no dependency on any fink provided libraries
and integration with OSX application menu.
In addition patch 3/8 beside integration also provides support
for OSX fullscreen mode.

--
there is an additional off-tree patch 
 https://github.com/imammedo/claws/commit/571607983158ddcef02ccde59dfd4a35924424ed
to help build claws-mail inside jhbuild environment
which is used for GTK. With it claws-mail could be build
as simple as executing:
  jhbuild build claws-mail

I'll try to merge this patch to gtk-mac-intergration project
when these patches are accepted.

PS:
there is enchant bug https://bugzilla.gnome.org/show_bug.cgi?id=742208
that makes spellcheck not usable, patch to fix issue in process
of merging into gtk-mac-intergration project.

PS2:
enchant patch has alrready been merged
Comment 1 Igor Mammedov 2015-02-06 18:40:31 CET
Created attachment 1478 [details]
[PATCH v2 2/5] osx: fix python plugin build error
Comment 2 Igor Mammedov 2015-02-06 18:41:53 CET
Created attachment 1479 [details]
[PATCH v2 3/5] osx: add OSX integration with native GTK library
Comment 3 Igor Mammedov 2015-02-06 18:42:32 CET
Created attachment 1480 [details]
[PATCH v2 4/5] osx: set address book specific menubar as application
Comment 4 Igor Mammedov 2015-02-06 18:43:17 CET
Created attachment 1481 [details]
[PATCH v2 5/5] osx: add 'make bundle' target to build OS X
Comment 5 Igor Mammedov 2015-04-07 13:55:37 CEST
Hi, Is there any plans to merge this series?
Comment 6 Ricardo Mones 2015-04-08 02:50:32 CEST
The attached set of patches fails to build on my Debian sid at linking phase:

compose.o: In function `compose_create':
/home/devel/claws/git/b-claws/src/compose.c:8055: undefined reference to `claws_mail_osx_set_menu'
addressbook.o: In function `addressbook_create':
/home/devel/claws/git/b-claws/src/addressbook.c:1333: undefined reference to `claws_mail_osx_set_menu'
collect2: error: ld returned 1 exit status
Makefile:1188: recipe for target 'claws-mail' failed
make[5]: *** [claws-mail] Error 1

Anyway, do you plan to support some OSX build yourself, like providing binaries and handle related bug reports?

Because AFAIK none of the current developers have a recent OSX system to test this. All we can test is that it doesn't break building under supported systems, and that doesn't sound like a good plan for supporting a new platform, does it? :)
Comment 7 Igor Mammedov 2015-04-08 09:54:00 CEST
(In reply to comment #6)
> The attached set of patches fails to build on my Debian sid at linking phase:
> 
> compose.o: In function `compose_create':
> /home/devel/claws/git/b-claws/src/compose.c:8055: undefined reference to
> `claws_mail_osx_set_menu'
> addressbook.o: In function `addressbook_create':
> /home/devel/claws/git/b-claws/src/addressbook.c:1333: undefined reference to
> `claws_mail_osx_set_menu'
> collect2: error: ld returned 1 exit status
> Makefile:1188: recipe for target 'claws-mail' failed
> make[5]: *** [claws-mail] Error 1
opps, I've never tested patches on other systems,
I'll fix it and attach fixed patch.

> 
> Anyway, do you plan to support some OSX build yourself, like providing
> binaries and handle related bug reports?
I can provide binaries but I don't have much capacity for fixing bugs,
especially taking in account that I don't know how GTK and related GUI stuff works.

In addition after this series merged, I plan to integrate claws-mail into gtkosx
build as a module to make building process simple for others.
Maybe additional build testing could be made in gtkosx build process
once it's integrated. I'll need to talk to its maintainers about it when I submit integration patch.

> 
> Because AFAIK none of the current developers have a recent OSX system to
> test this. All we can test is that it doesn't break building under supported
> systems, and that doesn't sound like a good plan for supporting a new
> platform, does it? :)
As for build testing I can setup build-bot in VM for weekly builds from claws git repo and maybe handle trivial builds breakage on it.
Comment 8 alt.rw-9o6f8p42 2017-01-03 19:07:57 CET
> It makes possible to build claws-mail with native OSX GTK build
> which is provided by gtk-mac-intergration project. It allows to
> make a distributable OSX application bundle which doesn't depend
> on any external libraries.

Is this still on the radar? A readily available official MacOS bundle that does not depend on external libraries would be really cool.
Comment 9 Igor Mammedov 2017-01-09 18:17:32 CET
(In reply to comment #8)
> > It makes possible to build claws-mail with native OSX GTK build
> > which is provided by gtk-mac-intergration project. It allows to
> > make a distributable OSX application bundle which doesn't depend
> > on any external libraries.
> 
> Is this still on the radar? A readily available official MacOS bundle that
> does not depend on external libraries would be really cool.

Currently, I don't have free time to rebase it so feel free to pick project up.
It could be cloned from my git repo:
 https://github.com/imammedo/claws
use "osx_integration_v1" branch
Comment 10 alt.rw-9o6f8p42 2017-01-10 15:00:27 CET
(In reply to comment #9)

Unfortunately I am not a programmer and this seems to surpass my skills.

I am currently at the point where I am trying to understand what is missing to make a native claws mail built for MacOS happen.

You seem to have run into issues in 2015 while trying to make it possible:

>Current patchset breaks build on other systems,
It's on my TODO list, but I don't have spare time
to fix it right now.

I have troubles understanding how severe these issues were/are. On the one hand it sounds like not much was missing, on the other hand I see indications that it may be pretty difficult.

> it's trivial missing non MacOS stub

>It might be not so simple, since it depends on gtkosx project,
which has it's own build system where I was planning to integrate
claws-mail into, to make building it trivial.

In addition to your comments I have seen bugs #3664 and #3665, of which bug #3664 sounds rather discouraging ("impossible").

Ricardo Mones wrote in 2015:

>> The support problem is to triage and fix the bugs reported against such binaries because of that testing, specially if they're platform specific.

I understand that. No binary and no gathering of bug reports unless someone can actually take care of if.

I was happy to see Perry Metzger's comment in May 2015 but realize that it does not solve the problem. Would it help to maybe approach other developers, e.g. from the gtkosx project?