> Usually it is only slow the first time it is launched.
This is right, too. Even if I quit XQuarts, gnubg starts fine subsequently.
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg
On 2017-12-22 21:08, Marcell Fulop wrote:
> You are actually right. I never gave it long enough time before killed
> the seemingly unresponsive gnubg process but after waiting about 2
> mins on a mid-2012 MacbookPro, it just started with XQuartz as it used
> to work before.
Thanks for trying it
* I mean it, the dmg installed 1.04 based version.
On Sat, Dec 23, 2017 at 3:08 PM, Marcell Fulop wrote:
> I'll give it a try with macports as you described.
>
>> it does seem to work on High Sierra as it did on versions 10.10
>
> You are actually right. I never gave it long enough time before ki
I'll give it a try with macports as you described.
> it does seem to work on High Sierra as it did on versions 10.10
You are actually right. I never gave it long enough time before killed
the seemingly unresponsive gnubg process but after waiting about 2
mins on a mid-2012 MacbookPro, it just sta
On 2017-12-22 19:59, Michael Petch wrote:
> (which I believe doesn't use quartz
> windows manager as a gtk+2 backend (at least by default)
I meant to say:
(which I believe doesn't use Xquartz
windows manager as a gtk+2 backend (at least by default)
Xquartz is the x11/quartz back end. Qaurtz (w
On 2017-12-22 17:47, Marcell Fulop wrote:
> Did you do that with XCode? Can you share details of the this build please?
Reading your response tells me a couple of things that we have done
differently. You used Homebrew (which I believe doesn't use quartz
windows manager as a gtk+2 backend (at le
Hi Michael,
Thanks
> I've been able to build GNUBG 1.06.001 (from CVS) on MacOS High Sierra.
> I had to coerce it with similar options as Macports uses for the
> project. When it was finished and installed it seems to work fine.
Did you do that with XCode? Can you share details of the this buil
