Menu
▾
▴
gnuplot-beta
|
From: Mojca M. <moj...@gm...> - 2011-07-23 13:26:45
|
The situation of GUI support on Mac is as follows: - x11 is horrible (not because of x11 itself, but because of system integration of X11 in mac) - wxt is broken (more or less by design - quite some code is missing that would allow it to work; zero support) - qt is broken (to start with, the flags to compile it are broken; and if those are fixed manually, source files for gnuplot requested by #include in gnuplot src are missing; no response from developers about reports) - aquaterm compilation is broken So basically dummy is the only terminal on Mac that works reliably. Can someone *PLEASE* fix at least AquaTerm. if nobody cares about qt and wxt? Mojca |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2011-07-23 17:04:22
|
On 23.07.2011 15:26, Mojca Miklavec wrote: > The situation of GUI support on Mac is as follows: > - x11 is horrible (not because of x11 itself, but because of system > integration of X11 in mac) The way it looks, Aquaterm feels much the same. It's system integration that sucks there. > Can someone *PLEASE* fix at least AquaTerm. if nobody cares about qt and wxt? I think we have established quite convincingly that you're looking in the wrong place for people who might be able to do that. Fixing this needs expertise that quite apparently nobody on this mailing list has. We may be able to help with the autoconf internals, but that's about it. That whole -framwork concept is an Apple-ism that exists nowhere else. That, and the fact that Apple is the only platform this appears to ever break on, means it'll take an Apple specialist to find out what exactly goes wrong, and possibly fix it. You tried to find such specialists here a couple of times now, and came up empty. I think you need to concentrate your search elsewhere. |
|
From: Mojca M. <moj...@gm...> - 2011-07-23 18:06:40
|
2011/7/23 Hans-Bernhard Bröker wrote:
> On 23.07.2011 15:26, Mojca Miklavec wrote:
>>
>> The situation of GUI support on Mac is as follows:
>> - x11 is horrible (not because of x11 itself, but because of system
>> integration of X11 in mac)
>
> The way it looks, Aquaterm feels much the same. It's system integration
> that sucks there.
AquaTerm may lack some features like mousing events, but the terminal
still works perfectly fine.
>> Can someone *PLEASE* fix at least AquaTerm. if nobody cares about qt and
>> wxt?
>
> I think we have established quite convincingly that you're looking in the
> wrong place for people who might be able to do that. Fixing this needs
> expertise that quite apparently nobody on this mailing list has. We may be
> able to help with the autoconf internals, but that's about it.
I'm asking *exactly* about the autoconf help. I can tell you exactly
how gcc call has to be made and I can tell you exactly how ./conigure
script needs to look like, but:
- I cannot make any commits to repository
- I don't know how to write input for ./prepare script (for autotools)
> That whole -framwork concept is an Apple-ism that exists nowhere else.
Well, yes. But you could say the same for windows. (I'm sorry for a
bit of sarcasm and a not-exactly-true-statement - but the whole
autotools horror also only exists on gnu platforms :) :) :)
> That,
> and the fact that Apple is the only platform this appears to ever break on,
> means it'll take an Apple specialist to find out what exactly goes wrong,
Apple specialists will be able to tell you how to fix xcode projects
or how to fix the command line that compiles gnuplot. Apple
specialists won't be able to tell you how to work with autotools.
The *only* thing that needs to be fixed is to replace
-laquaterm
with
-framework AquaTerm
in LDFLAGS in any given call (both to test for existence of aquaterm
and to actually build it).
> and possibly fix it. You tried to find such specialists here a couple of
> times now, and came up empty. I think you need to concentrate your search
> elsewhere.
Matlab?
Mojca
|
|
From: Ethan M. <merritt@u.washington.edu> - 2011-07-23 17:52:08
|
On Saturday, 23 July 2011, Mojca Miklavec wrote: > So basically dummy is the only terminal on Mac that works reliably. That is simply not true. x11 works fine. Some [many?] Mac users are prejudiced against x11, but there's not much we can do about that. > Can someone PLEASE fix at least AquaTerm. if nobody cares about qt and wxt? Is AquaTerm 1.<latest> now at a state where it supports mousing? If not, then I think it's a waste of time compared to sorting out wxt or canvas. Have you tried this recently submitted patch? #3358726 wxt (wxWidgets) Mac support patch "(for both 4.4 stable & 4.5 CVS) let's wxt terminal work fine on Mac" https://sourceforge.net/tracker/?func=detail&atid=302055&aid=3358726&group_id=2055 If somebody confirms that it works, I'd be happy to apply it to CVS immediately. I already checked that it doesn't harm wxt support on linux. In any event, I'd be happy to take patch[es] that come with a note "apply this and aquaterm will work out of the box on OSX 10.whatever". But I'm not a Mac user, so I am dependent on contributions from elsewhere. The one pathway that I think I could manage on my own, if there is sufficient interest, is to document use of gnuplot's canvas and/or svg terminals with safari as an interactive viewer. Unless things have changed on the aquaterm side, that actually gets you more supported features anyhow. Ethan |
|
From: Mojca M. <moj...@gm...> - 2011-07-24 07:24:20
|
On Sat, Jul 23, 2011 at 19:51, Ethan Merritt wrote: > On Saturday, 23 July 2011, Mojca Miklavec wrote: >> So basically dummy is the only terminal on Mac that works reliably. > > That is simply not true. x11 works fine. > Some [many?] Mac users are prejudiced against x11, but there's not much > we can do about that. There is one thing that gnuplot could do for those who prefer x11: - enable building gnuplot without aquaterm (I wasn't able to figure out if that was possible at all; to disable X11 one simply uses "--without-x" which I often did) - add some configure-time option to set x11 (or any other terminal) as the default one Mojca Unrelated: is this important in any way? test -z "allterm.h " || rm -f allterm.h test -d htmldocs && rm -rf htmldocs make[1]: [clean-generic] Error 1 (ignored) rm -f *.o core *.core |
|
From: Mojca M. <moj...@gm...> - 2011-07-24 09:02:12
|
On Sat, Jul 23, 2011 at 19:51, Ethan Merritt wrote: > > Have you tried this recently submitted patch? > #3358726 wxt (wxWidgets) Mac support patch > "(for both 4.4 stable & 4.5 CVS) let's wxt terminal work fine on Mac" > https://sourceforge.net/tracker/?func=detail&atid=302055&aid=3358726&group_id=2055 > If somebody confirms that it works, I'd be happy to apply it to CVS immediately. > I already checked that it doesn't harm wxt support on linux. I cannot test because wxWidgets-devel port from MacPorts is broken and I'm not eager to compile wxWidgets by hand. The reason why I try to use wxWigdets-devel is because that one contains version 2.9.2 as opposed to 2.8.something and that one has considerably better (but mainly different) support for Mac and if anything it makes sense to test with the latest version. 2.9.2 was released in beginning of July. Mojca |
|
From: Mojca M. <moj...@gm...> - 2011-07-23 18:35:24
|
On Sat, Jul 23, 2011 at 19:51, Ethan Merritt wrote: > On Saturday, 23 July 2011, Mojca Miklavec wrote: >> So basically dummy is the only terminal on Mac that works reliably. > > That is simply not true. x11 works fine. > Some [many?] Mac users are prejudiced against x11, but there's not much > we can do about that. I never said that gnuplot could do anything about that. Apple has no interest in fixing or improving X any further from current situation. They want to push Cocoa to developers. >> Can someone PLEASE fix at least AquaTerm. if nobody cares about qt and wxt? > > Is AquaTerm 1.<latest> now at a state where it supports mousing? No. > If not, then I think it's a waste of time compared to sorting out > wxt or canvas. Canvas might work as it is already, but one needs to open web browser separately. wxt needs quite some coding to start working. (It would be nice to sort it out, but that *really* takes an apple specialist.) > Have you tried this recently submitted patch? > #3358726 wxt (wxWidgets) Mac support patch > "(for both 4.4 stable & 4.5 CVS) let's wxt terminal work fine on Mac" > https://sourceforge.net/tracker/?func=detail&atid=302055&aid=3358726&group_id=2055 > If somebody confirms that it works, I'd be happy to apply it to CVS immediately. > I already checked that it doesn't harm wxt support on linux. No, I didn't know about that patch. Thank you for this pointer. But I'm now working on Lion. I first need to check if I can get xwidgets to compile at all. And what about Qt? Last time when I tried it (after patching some flags) it was stuck at ./configure --enable-qt qtterminal/QtGnuplotWidget.cpp:280:34: error: ui_QtGnuplotSettings.h: No such file or directory I can only confirm that ui_QtGnuplotSettings.h was missing in gnuplot and that it was referenced from the file mentioned above. I'm willing to help to sort out the missing flags, but I cannot help if files are missing. > In any event, I'd be happy to take patch[es] that come with a note > "apply this and aquaterm will work out of the box on OSX 10.whatever". Just replace "-laquaterm" with "-framework AquaTerm". Everywhere. (Some users argued that one should better use "-Wl,-framework -Wl,AquaTerm". I can confirm that it works both ways and that some other projects use it as well, but I don't know why this is better. It probably really is, but I don't know why.) >From man page: -Wl,option Pass option as an option to the linker. If option contains commas, it is split into multiple options at the commas. MacPorts will have to apply an additional parameter "-F/opt/local/Library/Frameworks" to LDFLAGS (but I'm not sure where this can best be done; it can also be done in the same line as ./configure, but that can be sorted out by maports developers; they already have to add -L/opt/local/lib anyway). Mojca |
|
From: Ethan M. <merritt@u.washington.edu> - 2011-07-24 03:07:15
|
On Saturday, 23 July 2011, Mojca Miklavec wrote: > On Sat, Jul 23, 2011 at 19:51, Ethan Merritt wrote: > > On Saturday, 23 July 2011, Mojca Miklavec wrote: > >> So basically dummy is the only terminal on Mac that works reliably. > > > > That is simply not true. x11 works fine. > > Some [many?] Mac users are prejudiced against x11, but there's not much > > we can do about that. > > I never said that gnuplot could do anything about that. Apple has no > interest in fixing or improving X any further from current situation. > They want to push Cocoa to developers. > > >> Can someone PLEASE fix at least AquaTerm. if nobody cares about qt and wxt? > > > > Is AquaTerm 1.<latest> now at a state where it supports mousing? > > No. > > > If not, then I think it's a waste of time compared to sorting out > > wxt or canvas. > > Canvas might work as it is already, but one needs to open web browser > separately. > > wxt needs quite some coding to start working. (It would be nice to > sort it out, but that *really* takes an apple specialist.) > > > Have you tried this recently submitted patch? > > #3358726 wxt (wxWidgets) Mac support patch > > "(for both 4.4 stable & 4.5 CVS) let's wxt terminal work fine on Mac" > > https://sourceforge.net/tracker/?func=detail&atid=302055&aid=3358726&group_id=2055 > > If somebody confirms that it works, I'd be happy to apply it to CVS immediately. > > I already checked that it doesn't harm wxt support on linux. > > No, I didn't know about that patch. Thank you for this pointer. But > I'm now working on Lion. I first need to check if I can get xwidgets > to compile at all. > > And what about Qt? > > Last time when I tried it (after patching some flags) it was stuck at > > ./configure --enable-qt > > qtterminal/QtGnuplotWidget.cpp:280:34: error: ui_QtGnuplotSettings.h: > No such file or directory > > I can only confirm that ui_QtGnuplotSettings.h was missing in gnuplot > and that it was referenced from the file mentioned above. > > I'm willing to help to sort out the missing flags, but I cannot help > if files are missing. > > > In any event, I'd be happy to take patch[es] that come with a note > > "apply this and aquaterm will work out of the box on OSX 10.whatever". > > Just replace "-laquaterm" with "-framework AquaTerm". Everywhere. > (Some users argued that one should better use "-Wl,-framework > -Wl,AquaTerm". It appears a grand total of one place, in m4/apple.m4 So OK, I've changed this one place and commited it to CVS. Could you please confirm that it works from a fresh check-out? (I have a bad feeling that this may break previously-working setups that were indeed really using a dylib rather than a framework. But I guess someone will speak up, if so.) Ethan > I can confirm that it works both ways and that some > other projects use it as well, but I don't know why this is better. It > probably really is, but I don't know why.) > > From man page: > -Wl,option > Pass option as an option to the linker. If option contains commas, > it is split into multiple options at the commas. > > MacPorts will have to apply an additional parameter > "-F/opt/local/Library/Frameworks" to LDFLAGS (but I'm not sure where > this can best be done; it can also be done in the same line as > ./configure, but that can be sorted out by maports developers; they > already have to add -L/opt/local/lib anyway). > > Mojca > |
|
From: Mojca M. <moj...@gm...> - 2011-07-24 07:16:46
|
On Sun, Jul 24, 2011 at 05:05, Ethan Merritt <merritt@u.washington.edu> wrote: > On Saturday, 23 July 2011, Mojca Miklavec wrote: >> On Sat, Jul 23, 2011 at 19:51, Ethan Merritt wrote: >> > On Saturday, 23 July 2011, Mojca Miklavec wrote: >> >> So basically dummy is the only terminal on Mac that works reliably. >> > >> > That is simply not true. x11 works fine. >> > Some [many?] Mac users are prejudiced against x11, but there's not much >> > we can do about that. >> >> I never said that gnuplot could do anything about that. Apple has no >> interest in fixing or improving X any further from current situation. >> They want to push Cocoa to developers. >> >> >> Can someone PLEASE fix at least AquaTerm. if nobody cares about qt and wxt? >> > >> > Is AquaTerm 1.<latest> now at a state where it supports mousing? >> >> No. >> >> > If not, then I think it's a waste of time compared to sorting out >> > wxt or canvas. >> >> Canvas might work as it is already, but one needs to open web browser >> separately. >> >> wxt needs quite some coding to start working. (It would be nice to >> sort it out, but that *really* takes an apple specialist.) >> >> > Have you tried this recently submitted patch? >> > #3358726 wxt (wxWidgets) Mac support patch >> > "(for both 4.4 stable & 4.5 CVS) let's wxt terminal work fine on Mac" >> > https://sourceforge.net/tracker/?func=detail&atid=302055&aid=3358726&group_id=2055 >> > If somebody confirms that it works, I'd be happy to apply it to CVS immediately. >> > I already checked that it doesn't harm wxt support on linux. >> >> No, I didn't know about that patch. Thank you for this pointer. But >> I'm now working on Lion. I first need to check if I can get xwidgets >> to compile at all. >> >> And what about Qt? >> >> Last time when I tried it (after patching some flags) it was stuck at >> >> ./configure --enable-qt >> >> qtterminal/QtGnuplotWidget.cpp:280:34: error: ui_QtGnuplotSettings.h: >> No such file or directory >> >> I can only confirm that ui_QtGnuplotSettings.h was missing in gnuplot >> and that it was referenced from the file mentioned above. >> >> I'm willing to help to sort out the missing flags, but I cannot help >> if files are missing. >> >> > In any event, I'd be happy to take patch[es] that come with a note >> > "apply this and aquaterm will work out of the box on OSX 10.whatever". >> >> Just replace "-laquaterm" with "-framework AquaTerm". Everywhere. >> (Some users argued that one should better use "-Wl,-framework >> -Wl,AquaTerm". > > It appears a grand total of one place, in m4/apple.m4 > So OK, I've changed this one place and commited it to CVS. > Could you please confirm that it works from a fresh check-out? Thank you very much. But this wasn't quite enough and there are still a few problems. (It still works with the old setup, but not yet on the new one ...) checking for aqtInit in -laquaterm... no The configure script now looks as below and only applies "-framework AquaTerm" if it confirms that -laquaterm switch works. In other words: if -laquaterm works, then it compiles gnuplot with -Wl,-framework -Wl,AquaTerm: gcc -g -O2 -ObjC -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -o doc2gih doc2gih.o termdoc.o -Wl,-framework -Wl,AquaTerm -framework Foundation -L/opt/local/lib -lz -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl _ACEOF if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | $EGREP "yes" >/dev/null 2>&1; then : { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5 $as_echo "yes" >&6; } { $as_echo "$as_me:${as_lineno-$LINENO}: checking for aqtInit in -laquaterm" >&5 $as_echo_n "checking for aqtInit in -laquaterm... " >&6; } if ${ac_cv_lib_aquaterm_aqtInit+:} false; then : $as_echo_n "(cached) " >&6 else ac_check_lib_save_LIBS=$LIBS LIBS="-laquaterm -lobjc $LIBS" cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ /* Override any GCC internal prototype to avoid an error. Use char because int might match the return type of a GCC builtin and then its argument prototype would still apply. */ #ifdef __cplusplus extern "C" #endif char aqtInit (); int main () { return aqtInit (); ; return 0; } _ACEOF if ac_fn_c_try_link "$LINENO"; then : ac_cv_lib_aquaterm_aqtInit=yes else ac_cv_lib_aquaterm_aqtInit=no fi rm -f core conftest.err conftest.$ac_objext \ conftest$ac_exeext conftest.$ac_ext LIBS=$ac_check_lib_save_LIBS fi { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_aquaterm_aqtInit" >&5 $as_echo "$ac_cv_lib_aquaterm_aqtInit" >&6; } if test "x$ac_cv_lib_aquaterm_aqtInit" = xyes; then : LIBS="-Wl,-framework -Wl,AquaTerm $LIBS -framework Foundation" CFLAGS="$CFLAGS -ObjC" $as_echo "#define HAVE_LIBAQUATERM 1" >>confdefs.h > (I have a bad feeling that this may break previously-working > setups that were indeed really using a dylib rather than a > framework. But I guess someone will speak up, if so.) Even in previously-working setups: - libaquaterm.dylib is just a symlink to AquaTerm file in Framework - it didn't work with libaquaterm in /opt/local/lib without extra flags (it still doesn't since it dosen't apply the extra flag) - it was checking if aquaterm is installed on system dir and then used the one from MacPorts Also, Lutz Maibaum sent another patch which I thing should be applied: >>>>>>>>>> Could you try this one-line change in configure.in, run the prepare script, and then try to configure? 1357c1357 < if test "$is_apple" = yes; then --- > if test "$ac_cv_lib_aquaterm_aqtInit" = yes; then <<<<<<<<<< It doesn't really make any difference to the binary, but at least it properly reports whether the terminal will be used. Mojca |
|
From: Lutz M. <lut...@gm...> - 2011-07-25 06:07:01
|
On Sun, Jul 24, 2011 at 12:16 AM, Mojca Miklavec <moj...@gm...> wrote: > On Sun, Jul 24, 2011 at 05:05, Ethan Merritt <merritt@u.washington.edu> wrote: >> On Saturday, 23 July 2011, Mojca Miklavec wrote: >>> Just replace "-laquaterm" with "-framework AquaTerm". Everywhere. >>> (Some users argued that one should better use "-Wl,-framework >>> -Wl,AquaTerm". >> >> It appears a grand total of one place, in m4/apple.m4 >> So OK, I've changed this one place and commited it to CVS. >> Could you please confirm that it works from a fresh check-out? > > Thank you very much. But this wasn't quite enough and there are still > a few problems. (It still works with the old setup, but not yet on the > new one ...) I haven't had a chance to try Ethan's change yet, but I believe that the predefined AC_CHECK_LIB macro that is used in m4/apple.m4 generates the test in ./configure that attempts to link against the aquaterm dynamic library. To replace that by a test that links against the aquaterm framework, one would have to write a new macro (let's call it AC_CHECK_FRAMEWORK), which could probably be based on the predefined AC_CHECK_LIB macro. The other thread already mentions two possible solutions found on the web, another might be this one: http://trac.imagemagick.org/browser/ImageMagick/trunk/m4/framework.m4 This one seems to be very similar to the AC_CHECK_LIB macro that ships with autoconf: http://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/libs.m4 Hope this helps, Lutz |
|
From: Mojca M. <moj...@gm...> - 2011-07-24 10:10:34
|
I ran out of time (will be back in August), so here is a quick summary:
AquaTerm:
- needs another patch to check if aquaterm can be built at all
- needs a few more tweaks to replace -laquaterm with -framework
AquaTerm in ./configure
Qt:
- building worked for me after patching Makefile
- I will test if plotting works when I'm back home
- I will test if building works with Qt installed by MacPorts
- one needs to make sure that even if pkg-config doesn't return
anything about Qt, the libraries can still be included with proper
flags and that moc, uic, ... are taken from PATH
wxt:
- Thanks a lot for applying the patches. That makes testing zillions
of times easier.
- Version 2.9 doesn't compile with MacPorts. I'm waiting for
developers to reply, but it would be great if gnuplot supported
2.9(.2)
http://trac.macports.org/ticket/30340
- Once I'm back home I will try to test with 2.8.
- Once I'm back home I hope that the patch for MacPorts will be ready,
so that I will be able to try with 2.9 as well.
- I would strongly suggest to concentrate to make sure that 2.9 will
work since 2.8 uses outdated/abandoned technology that will 90% stop
working when Mac OS X 10.8 comes out (or whatever the next version
will be called; maybe iOS XI :) - that might be in year and a half or
two years at most.
Mojca
|
|
From: Mojca M. <moj...@gm...> - 2011-07-24 10:43:22
|
On Sun, Jul 24, 2011 at 12:10, Mojca Miklavec wrote: > > wxt: > - Once I'm back home I will try to test with 2.8. Or not. The port "cairo +universal" seems to be broken, so I cannot build wxwidgets on Lion at all at the moment. Not that this has anything to do with gnuplot, but it will take time until building xwidgets is resolved in macports. http://trac.macports.org/ticket/30135 http://trac.macports.org/ticket/29842 citing: >>>>> The problem as I understood it is that some of the cctools (e.g. lipo, libtool) don't understand LLVM bitcode. Specifically, they don't know how to determine the architecture of a bitcode file. So lipo, and anything that uses it to read/write fat Mach-O and archive files, are all useless right now for dealing with LLVM bitcode objects, as well as archives composed entirely of bitcode objects. Same for libtool. I filed radar 9087924 for this; so far, I haven't gotten a response. Mojca |
