Menu
▾
▴
gnuplot-beta
|
From: Joe K. <jko...@co...> - 2006-11-18 18:40:45
|
on 11/17/06 5:07 PM, Timoth=E9e Lecomte at tim...@en... wrote: > Timoth=E9e Lecomte wrote: >> Ethan Merritt wrote: >> =20 >>> On Friday 17 November 2006 01:33 pm, Joe Koski wrote: >>> =20 >>> =20 >>>> on 11/17/06 1:48 PM, Per Persson at per...@ma... wrote: >>>> =20 >>>> =20 >>>>> I still maintain my opinions that >>>>> 1) building an X11 based wxt terminal should be straightforward >>>>> 2) a "native" wxt terminal is going to take a lot of work. >>>>> =20 >>>>> =20 >>>> I think Per's assessment is correct. The problem is not with wxt, but >>>> with the necessity for "bundling" wxWidget applications for native >>>> use on the Mac. >>>> =20 >>>> =20 >>> You call it a necessity, where Per implies that it is simply a >>> matter of choice between X11 and "native". Which is it? >>> =20 >>> =20 >> A native one is for sure better since X11 is not installed by default on >> MacOS. The *only* problem we seem to get is this "no-input" issue, which >> is supposed to be related to bundling, as Joe mentioned. >> =20 >=20 > I went back to #wxwidgets on IRC, and got confirmed again that bundling > should be enough. Let's try to get it right this time. >=20 > To sum up: > *get 4.2rc1 from gnuplot.sf.net > *apply wxmac.diff to src/wxterminal > *run ./prepare, then ./configure with your favorite options, 'make', > 'make install' > You get a working gnuplot with the wxt terminal (assuming you have > cairo, pango and wxMac installed), but the plot windows don't get the foc= us >=20 > Then the bundling stuff: > *download the attached Icon.plist and wxmac.icns files > *run the following commands to create the bundle tree: > mkdir -p ./gnuplot.app/Contents/MacOS/ > mkdir -p ./gnuplot.app/Contents/Resources/ > mkdir -p ./gnuplot.app/Contents/Frameworks/ > cp ../src/gnuplot ./gnuplot.app/Contents/MacOS/gnuplot > echo -n 'APPL????' > ./gnuplot.app/Contents/PkgInfo > * retrieve the attached Icon.plist and wxmac.icns files, put them in the > current directory, and put them at their respective locations in the > bundle with the following commands: > cp ./Info.plist ./gnuplot.app/Contents/ > cp ./wxmac.icns ./gnuplot.app/Contents/Resources/ >=20 > Then, you're supposed to be all set. To launch gnuplot, do: > open gnuplot.app > or > ./gnuplot.app/Contents/MacOS/gnuplot >=20 > ... and it should be fine now, according to what I've been told on IRC. >=20 > Joe, could you try again with these instructions ? Thank you very much. >=20 > Best regards, >=20 > Timoth=E9e Lecomte Timoth=E9e, We're close to a solution, but no cigar yet. I followed your bundle instructions, and I think I have the correct bundle structure created and filled. I was a bit confused about which directory I should use to enter th= e command cp ../src/gnuplot ./gnuplot.app/Contents/MacOS/gnuplot The ../src indicates that I am in a subdirectory within the 4.2.rc1 build directory where the directory ./gnuplot.app exists. So I created a director= y called Mac_app in the 4.2.rc1 build directory. Correct? At least all your bundling commands then worked without complaint. When I try ./gnuplot.app/Contents/MacOS/gnuplot within Mac_app, gnuplot doe= s start, and I can plot, but I have the same lack of focus as before. One more problem. A while back you sent me a second patch to try: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff -Naur old/wxt_gui.cpp new/wxt_gui.cpp --- old/wxt_gui.cpp 2006-10-20 23:36:56.000000000 +0200 +++ new/wxt_gui.cpp 2006-10-20 23:39:36.000000000 +0200 @@ -1330,6 +1330,14 @@ wxApp::m_nCmdShow =3D SW_SHOW; #endif =20 +#ifdef __WXMAC__ + /* allow to get focus even if the app is not bundled */ + ProcessSerialNumber psn; + GetCurrentProcess( &psn ); + CPSEnableForegroundOperation( &psn ); + SetFrontProcess( &psn ); +#endif + if (!wxInitialize()) { fprintf(stderr,"Failed to initialize wxWidgets.\n"); wxt_abort_init =3D true; diff -Naur old/wxt_gui.h new/wxt_gui.h --- old/wxt_gui.h 2006-10-20 23:36:58.000000000 +0200 +++ new/wxt_gui.h 2006-10-20 23:39:32.000000000 +0200 @@ -159,6 +159,12 @@ # include "win/winmain.h" # endif =20 +#ifdef __WXMAC__ +/* focus hack */ +# include <Carbon/Carbon.h> +void CPSEnableForegroundOperation(ProcessSerialNumber* psn); +#endif + /* for cairo_t */ # include <cairo.h> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Do I need to rebuild my gnuplot without the second "focus hack" patch? Is that my problem? Joe |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-11-18 03:28:57
|
On Friday 17 November 2006 04:07 pm, Timoth=C3=A9e Lecomte wrote: > To sum up: > *get 4.2rc1 from gnuplot.sf.net > *apply wxmac.diff to src/wxterminal Most of wxmac.diff looks like an obvious accommodation to=20 Mac build options. However the bit below doesn't look like it has anything to do with the Mac, but rather Windows. Is this something that needs to go into the general code regardless of this Mac discussion? =20 diff -Naur old/wxt_gui.h new/wxt_gui.h =2D-- old/wxt_gui.h 2006-10-08 22:37:53.000000000 +0200 +++ new/wxt_gui.h 2006-10-08 22:48:38.000000000 +0200 @@ -127,6 +127,11 @@ # define IMAGE_SURFACE #endif =20 +/* by default, enable IMAGE_SURFACE */ +#if !defined(GTK_SURFACE)&&!defined(IMAGE_SURFACE)&&!defined(__WXMSW__) +# define IMAGE_SURFACE +#endif + /* temporarly undef GTK_SURFACE for two reasons : * - because of a CAIRO_OPERATOR_SATURATE bug, * - because as for now, it is slower than the pure image surface, > *run ./prepare, then ./configure with your favorite options, 'make',=20 > 'make install' > You get a working gnuplot with the wxt terminal (assuming you have=20 > cairo, pango and wxMac installed), but the plot windows don't get the foc= us >=20 > Then the bundling stuff: > *download the attached Icon.plist and wxmac.icns files > *run the following commands to create the bundle tree: > mkdir -p ./gnuplot.app/Contents/MacOS/ > mkdir -p ./gnuplot.app/Contents/Resources/ > mkdir -p ./gnuplot.app/Contents/Frameworks/ > cp ../src/gnuplot ./gnuplot.app/Contents/MacOS/gnuplot > echo -n 'APPL????' > ./gnuplot.app/Contents/PkgInfo > * retrieve the attached Icon.plist and wxmac.icns files, put them in the= =20 > current directory, and put them at their respective locations in the=20 > bundle with the following commands: > cp ./Info.plist ./gnuplot.app/Contents/ > cp ./wxmac.icns ./gnuplot.app/Contents/Resources/ >=20 > Then, you're supposed to be all set. To launch gnuplot, do: > open gnuplot.app > or > ./gnuplot.app/Contents/MacOS/gnuplot >=20 > ... and it should be fine now, according to what I've been told on IRC. >=20 > Joe, could you try again with these instructions ? Thank you very much. >=20 > Best regards, >=20 > Timoth=C3=A9e Lecomte >=20 >=20 =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2006-11-18 12:49:40
|
Ethan A Merritt wrote: > On Friday 17 November 2006 04:07 pm, Timoth=C3=A9e Lecomte wrote: > =20 >> To sum up: >> *get 4.2rc1 from gnuplot.sf.net >> *apply wxmac.diff to src/wxterminal >> =20 > > Most of wxmac.diff looks like an obvious accommodation to=20 > Mac build options. > =20 Exact. > However the bit below doesn't look like it has anything to > do with the Mac, but rather Windows. Is this something that needs > to go into the general code regardless of this Mac discussion? > =20 > > diff -Naur old/wxt_gui.h new/wxt_gui.h > --- old/wxt_gui.h 2006-10-08 22:37:53.000000000 +0200 > +++ new/wxt_gui.h 2006-10-08 22:48:38.000000000 +0200 > @@ -127,6 +127,11 @@ > # define IMAGE_SURFACE > #endif > =20 > +/* by default, enable IMAGE_SURFACE */ > +#if !defined(GTK_SURFACE)&&!defined(IMAGE_SURFACE)&&!defined(__WXMSW__= ) > +# define IMAGE_SURFACE > +#endif > + > /* temporarly undef GTK_SURFACE for two reasons : > * - because of a CAIRO_OPERATOR_SATURATE bug, > * - because as for now, it is slower than the pure image surface, > > =20 It is needed for Mac. Think about the '!defined(__WXMSW__)' as a=20 '!defined(__WINDOWS_SURFACE__)'. I think this patch can go to CVS. Best regards, Timoth=C3=A9e |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-11-19 00:26:48
|
On Friday 17 November 2006 01:33 pm, Joe Koski wrote: > I think Per's assessment is correct. The problem is not with wxt, but with > the necessity for "bundling" wxWidget applications for native use on the > Mac. Bizarre O/S design. > That requires either extensive modifications to the gnuplot make files, > or a special separate make file approach for the Mac. I don't think that's true. From what I have found via Googling, nothing special should be required in building the application (gnuplot). Creating the bundle is a separate step, and could have its own Makefile or installation script. I am hampered by never having had to install anything like this on a Mac, but it sounds to me from all your descriptions that the problem is that if you bundle gnuplot, its controlling terminal is not the one you launched it from. Rather, it must have a controlling terminal app as part of the bundle. I guess this is the iTerm approach that someone mentioned. Furthermore, I suspect that the info.Plist file must contain one or more lines that establishes that the gnuplot plot window gets the focus in parallel to, or instead of, the controlling terminal app. How one does any of that is beyond me. I found only one similar complaint about lack of focus via Googling. In that case the problem was that the application name in info.Plist did not precisely match the directory tree name in which the app had been placed. Just a thought. Anyhow, it sounds to me like this needn't hold up a 4.2 release, because it is a post-build installation problem, and probably doesn't require changes to the gnuplot code per se. If it turns out that minor changes are required in the wxt code, that can be a follow-on patch of relevance only to Mac users. Maybe fink or Darwin will bundle it with gnuplot (in the normal sense of the word, not this strange Mac-ish meaning of "bundle") and provide an easy installation source for general users. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Joe K. <jko...@co...> - 2006-11-19 02:30:19
|
on 11/18/06 5:26 PM, Ethan A Merritt at merritt@u.washington.edu wrote: > On Friday 17 November 2006 01:33 pm, Joe Koski wrote: >> I think Per's assessment is correct. The problem is not with wxt, but with >> the necessity for "bundling" wxWidget applications for native use on the >> Mac. > > Bizarre O/S design. > >> That requires either extensive modifications to the gnuplot make files, >> or a special separate make file approach for the Mac. > > I don't think that's true. From what I have found via Googling, nothing > special should be required in building the application (gnuplot). > Creating the bundle is a separate step, and could have its own Makefile > or installation script. > > I am hampered by never having had to install anything like this on a Mac, > but it sounds to me from all your descriptions that the problem is that if > you bundle gnuplot, its controlling terminal is not the one you launched > it from. Rather, it must have a controlling terminal app as part of the > bundle. I guess this is the iTerm approach that someone mentioned. > Furthermore, I suspect that the info.Plist file must contain one or more > lines that establishes that the gnuplot plot window gets the focus in > parallel to, or instead of, the controlling terminal app. How one does > any of that is beyond me. > > I found only one similar complaint about lack of focus via Googling. > In that case the problem was that the application name in info.Plist > did not precisely match the directory tree name in which the app had > been placed. Just a thought. > > Anyhow, it sounds to me like this needn't hold up a 4.2 release, because > it is a post-build installation problem, and probably doesn't require > changes to the gnuplot code per se. If it turns out that minor changes > are required in the wxt code, that can be a follow-on patch of relevance > only to Mac users. Maybe fink or Darwin will bundle it with gnuplot > (in the normal sense of the word, not this strange Mac-ish meaning of > "bundle") and provide an easy installation source for general users. Ethan, You are correct that this problem should not stop a gnuplot release. This is a Mac specific issue, and if the Apple folks want to ride with their "we're the best horse" attitude, that's OK. Without cairo/pango installed, gnuplot-4.2.rc1 builds without problems, and works with both X11 and AquaTerm. Neither MacPorts (formerly DarwinPorts) nor Fink do bundling. They basically modify open source make files and install into their own version of /usr/local/ that they call /sw or /opt for the "unstable" branch. For older "stable" stuff, they basically "make install" binary builds into /sw or /opt. To the new Mac user, this looks like magic, and they don't need to learn UNIX or navigate in /usr. As you suggested, I tried renaming the org.gnuplot.app to gnuplot.app in Info.plist. That did not solve the problem. We need a Mac "developer" to examine that file. Incidentally, there are literally thousands of .plist files on any Mac. There are some other things I can try like dragging the application into /Applications and changing the name to /Applications/gnuplot.app, but I'm just trying to out guess Apple about that. As to the terminal, keep in mind that the standard way to start any Mac application is via a double click of the icon. No terminal is assumed. For some other applications that I run in X11 (GMV and Geomview), I have simple AppleScript files that first start X11, and then invoke the application. We probably need a Mac native version of that with terminal.app or iTerm.app. On my old pre-OSX Mac, we had the "Macintosh Programmers Workshop" which was basically a terminal window into the OS. That was the only way to do command line stuff. I think that this problem is a legacy of that. No Mac user should ever be bothered with the need to use of a command line, or something like that. I'll keep trying, and if anything develops, I'll let folks know. Joe |
|
From: Mojca M. <moj...@gm...> - 2006-11-24 05:09:44
|
Just as a warning. This is how the last Mac version of gnuplot 4.0 fails here. > /usr/local/bin/gnuplot dyld: Library not loaded: /usr/local/lib/libaquaterm.1.0.0.dylib Referenced from: /usr/local/bin/gnuplot Reason: image not found Trace/BPT trap > locate libaquaterm /sw/lib/libaquaterm.1.0.0.dylib /sw/lib/libaquaterm.dylib /usr/local/lib/libaquaterm.1.0.1.dylib /usr/local/lib/libaquaterm.dylib Mojca |
|
From: Joe K. <jko...@co...> - 2006-11-24 16:59:07
|
on 11/23/06 10:09 PM, Mojca Miklavec at moj...@gm... wrote: > Just as a warning. This is how the last Mac version of gnuplot 4.0 fails here. > >> /usr/local/bin/gnuplot > dyld: Library not loaded: /usr/local/lib/libaquaterm.1.0.0.dylib > Referenced from: /usr/local/bin/gnuplot > Reason: image not found > Trace/BPT trap >> locate libaquaterm > /sw/lib/libaquaterm.1.0.0.dylib > /sw/lib/libaquaterm.dylib > /usr/local/lib/libaquaterm.1.0.1.dylib > /usr/local/lib/libaquaterm.dylib > > Mojca > Mojca, If you run the AquaTerm installer found via the AquaTerm website, it puts things into /Library/Frameworks/AquaTerm.framework and /usr/local/lib. You might try running the "official" AquaTerm-1.0.1 installer, rather than using the older Fink version of AquaTerm. Joe |
|
From: Mojca M. <moj...@gm...> - 2006-11-27 04:22:53
|
On 11/24/06, Joe Koski wrote: > on 11/23/06 10:09 PM, Mojca Miklavec wrote: > > > Just as a warning. This is how the last Mac version of gnuplot 4.0 fails here. > > > >> /usr/local/bin/gnuplot > > dyld: Library not loaded: /usr/local/lib/libaquaterm.1.0.0.dylib > > Referenced from: /usr/local/bin/gnuplot > > Reason: image not found > > Trace/BPT trap > >> locate libaquaterm > > /sw/lib/libaquaterm.1.0.0.dylib > > /sw/lib/libaquaterm.dylib > > /usr/local/lib/libaquaterm.1.0.1.dylib > > /usr/local/lib/libaquaterm.dylib > > > > Mojca > > > Mojca, > > If you run the AquaTerm installer found via the AquaTerm website, it puts > things into /Library/Frameworks/AquaTerm.framework and /usr/local/lib. You > might try running the "official" AquaTerm-1.0.1 installer, rather than using > the older Fink version of AquaTerm. I have that one as well. The problem is that gnuplot has been compiled with the older version and now it doesn't work any more. I have a working version of gnuplot at the moment, but such situations should be avoided in future if possible. On 11/24/06, Per Persson wrote: > >Just as a warning. This is how the last Mac version of gnuplot 4.0 fails here. > > > >/usr/local/bin/gnuplot > >dyld: Library not loaded: /usr/local/lib/libaquaterm.1.0.0.dylib > > Mojca, > this is an installer bug in AquaTerm 1.0.1 > > Unless you are on an Intel Mac, simply use the AquaTerm 1.0.0 installer to downgrade (only difference is that 1.0.1 is a "fat" binary containing both Intel and PPC code). > > If you have an Intel Mac, just create a symlink: > ln -s /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm /usr/local/lib/libaquaterm.1.0.0.dylib I don't think that it makes any sense to downgrade for me since I managed to create my own binary anyway, but I'm afraid of problems that other users might have (now or in future) if gnnuplot will remain highly dependant on versions of libraries used on a certain computer. I hope that the one in charge for preparing the latest binaries will also take care about such issues. Thanks, Mojca |
|
From: <tim...@en...> - 2006-10-09 20:09:27
|
Joe Koski wrote: > on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wrote= : > > =20 >> Hi Joe ! >> >> I'm sorry you did not succeed, but those errors are normal: wxWidgets >> comes in different flavours depending on the platform: wxGTK (as Ethan >> told you), wxMSW for Windows, wxMAC which you logically installed, and >> others. There are a couple of places where it is necessary to choose >> between two possible behaviours (two threads or one) in the terminal >> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW), I >> have chosen to enable the compilation for those two only. >> >> However, attached is a patch that enables the compilation for wxMAC. I >> will be very glad to see you try it. Apply it in src/wxterminal and tr= y >> to build again. Hopefully it will work. Don't hesitate to report any i= ssue. >> >> Thank you very much for your efforts. >> >> Best regards, >> >> Timoth=E9e >> =20 > > Timoth=E9e, > > I applied the patch, borrowed fontconfig from X11 with an export > PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt term= inal. > (I'll send you a screen shot separately.) > > To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x) = to > see what would happen. > =20 The plot is rendered properly, that's a good point ! > I got the plot, but I could not get "focus" or whatever you call it for= the > plot window. When I placed the cursor in the plot window area, all I ge= t was > a twirling icon telling me to wait. This happens any time the cursor cr= osses > the wxt window. Do you mean that the plot window is just like dead ? Is the cursor=20 position updated in the status bar for example ? If it's the case, there is probably an issue with the GUI loop running=20 in a separate thread. > When I quit gnuplot, the plot window also disappeared. > > During the build I saw > > (...)set.c: In function 'set_mouse': > set.c:2309: warning: pointer targets in passing argument 2 of 'map_posi= tion' > differ in signedness > set.c:2309: warning: pointer targets in passing argument 3 of 'map_posi= tion' > differ in signedness > > But I don't know if this is significant. It's not relevant to your problem. > What should I be looking for? > =20 Good question. I'll try to look at some wxMAC code in the next days, and=20 I'll send you a patch as soon as I see what could happen. > I'm available for further builds and testing. Let me know what to try n= ext. > > Joe > =20 Thank you very much. Best regards, Timoth=E9e |
|
From: Joe K. <jko...@co...> - 2006-10-09 20:39:40
|
on 10/9/06 2:07 PM, Timoth=E9e Lecomte at tim...@en... wrote: > Joe Koski wrote: >> on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wrote: >>=20 >> =20 >>> Hi Joe ! >>>=20 >>> I'm sorry you did not succeed, but those errors are normal: wxWidgets >>> comes in different flavours depending on the platform: wxGTK (as Ethan >>> told you), wxMSW for Windows, wxMAC which you logically installed, and >>> others. There are a couple of places where it is necessary to choose >>> between two possible behaviours (two threads or one) in the terminal >>> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW), I >>> have chosen to enable the compilation for those two only. >>>=20 >>> However, attached is a patch that enables the compilation for wxMAC. I >>> will be very glad to see you try it. Apply it in src/wxterminal and try >>> to build again. Hopefully it will work. Don't hesitate to report any is= sue. >>>=20 >>> Thank you very much for your efforts. >>>=20 >>> Best regards, >>>=20 >>> Timoth=E9e >>> =20 >>=20 >> Timoth=E9e, >>=20 >> I applied the patch, borrowed fontconfig from X11 with an export >> PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt termi= nal. >> (I'll send you a screen shot separately.) >>=20 >> To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x) t= o >> see what would happen. >> =20 >=20 > The plot is rendered properly, that's a good point ! >=20 >> I got the plot, but I could not get "focus" or whatever you call it for = the >> plot window. When I placed the cursor in the plot window area, all I get= was >> a twirling icon telling me to wait. This happens any time the cursor cro= sses >> the wxt window. > Do you mean that the plot window is just like dead ? Is the cursor > position updated in the status bar for example ? > If it's the case, there is probably an issue with the GUI loop running > in a separate thread. >=20 Timoth=E9e, I realized after I sent the message I should have been more clear on this point. Clicking inside the window does not get the focus, and the bar at th= e top is always grayed out as it is in the screen shot that I sent you. Your question about the screen being "dead" is a good description. The cursor position at the lower left is frozen as it shows in the screen shot, and does not change when you move the cursor. I have done a bit more testing. I can get octave-2.9.9 to open wxt windows, and display plots, which is good, but it doesn't display legend information that displays in both X11 and AquaTerm. Fixing that can wait until we have = a more workable arrangement. I'm still waiting for an answer for my fontconfig question about installation. Using the X11 fontconfig is not the best solution. Let me know if if I need to try something else. Joe >=20 >> When I quit gnuplot, the plot window also disappeared. >>=20 >> During the build I saw >>=20 >> (...)set.c: In function 'set_mouse': >> set.c:2309: warning: pointer targets in passing argument 2 of 'map_posit= ion' >> differ in signedness >> set.c:2309: warning: pointer targets in passing argument 3 of 'map_posit= ion' >> differ in signedness >>=20 >> But I don't know if this is significant. > It's not relevant to your problem. >=20 >> What should I be looking for? >> =20 > Good question. I'll try to look at some wxMAC code in the next days, and > I'll send you a patch as soon as I see what could happen. >=20 >=20 >> I'm available for further builds and testing. Let me know what to try ne= xt. >>=20 >> Joe >> =20 > Thank you very much. >=20 > Best regards, >=20 > Timoth=E9e |
|
From: <tim...@en...> - 2006-10-10 09:35:22
|
Joe Koski wrote: > on 10/9/06 2:07 PM, Timoth=E9e Lecomte at tim...@en... wrote= : > > =20 >> Joe Koski wrote: >> =20 >>> on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wro= te: >>> >>> =20 >>> =20 >>>> Hi Joe ! >>>> >>>> I'm sorry you did not succeed, but those errors are normal: wxWidget= s >>>> comes in different flavours depending on the platform: wxGTK (as Eth= an >>>> told you), wxMSW for Windows, wxMAC which you logically installed, a= nd >>>> others. There are a couple of places where it is necessary to choose >>>> between two possible behaviours (two threads or one) in the terminal >>>> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW),= I >>>> have chosen to enable the compilation for those two only. >>>> >>>> However, attached is a patch that enables the compilation for wxMAC.= I >>>> will be very glad to see you try it. Apply it in src/wxterminal and = try >>>> to build again. Hopefully it will work. Don't hesitate to report any= issue. >>>> >>>> Thank you very much for your efforts. >>>> >>>> Best regards, >>>> >>>> Timoth=E9e >>>> =20 >>>> =20 >>> Timoth=E9e, >>> >>> I applied the patch, borrowed fontconfig from X11 with an export >>> PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt te= rminal. >>> (I'll send you a screen shot separately.) >>> >>> To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x= ) to >>> see what would happen. >>> =20 >>> =20 >> The plot is rendered properly, that's a good point ! >> >> =20 >>> I got the plot, but I could not get "focus" or whatever you call it f= or the >>> plot window. When I placed the cursor in the plot window area, all I = get was >>> a twirling icon telling me to wait. This happens any time the cursor = crosses >>> the wxt window. >>> =20 >> Do you mean that the plot window is just like dead ? Is the cursor >> position updated in the status bar for example ? >> If it's the case, there is probably an issue with the GUI loop running >> in a separate thread. >> >> =20 > Timoth=E9e, > > I realized after I sent the message I should have been more clear on th= is > point. Clicking inside the window does not get the focus, and the bar a= t the > top is always grayed out as it is in the screen shot that I sent you. Y= our > question about the screen being "dead" is a good description. I'm not familiar at all with MacOS. Is it a behaviour that you've=20 already observed in other situations ? (with X11, when the application=20 is dead, the screen is no longer updated and you get gray surfaces when=20 you drag another app on top of the dead one, for example) > The cursor > position at the lower left is frozen as it shows in the screen shot, an= d > does not change when you move the cursor. > > I have done a bit more testing. I can get octave-2.9.9 to open wxt wind= ows, > and display plots, Can you display several plots successively ? That would be another=20 argument in favor of the dead gui thread, because the plot rendering is=20 done in the main thread. > which is good, but it doesn't display legend information > that displays in both X11 and AquaTerm. Do you mean the mouse cursor position as above ? Thanks, best regards, Timoth=E9e |
|
From: Joe K. <jko...@co...> - 2006-10-10 21:04:45
|
on 10/10/06 3:33 AM, Timoth=E9e Lecomte at tim...@en... wrote: > Joe Koski wrote: >> on 10/9/06 2:07 PM, Timoth=E9e Lecomte at tim...@en... wrote: >>=20 >> =20 >>> Joe Koski wrote: >>> =20 >>>> on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wrote: >>>>=20 >>>> =20 >>>> =20 >>>>> Hi Joe ! >>>>>=20 >>>>> I'm sorry you did not succeed, but those errors are normal: wxWidgets >>>>> comes in different flavours depending on the platform: wxGTK (as Etha= n >>>>> told you), wxMSW for Windows, wxMAC which you logically installed, an= d >>>>> others. There are a couple of places where it is necessary to choose >>>>> between two possible behaviours (two threads or one) in the terminal >>>>> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW), = I >>>>> have chosen to enable the compilation for those two only. >>>>>=20 >>>>> However, attached is a patch that enables the compilation for wxMAC. = I >>>>> will be very glad to see you try it. Apply it in src/wxterminal and t= ry >>>>> to build again. Hopefully it will work. Don't hesitate to report any >>>>> issue. >>>>>=20 >>>>> Thank you very much for your efforts. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Timoth=E9e >>>>> =20 >>>>> =20 >>>> Timoth=E9e, >>>>=20 >>>> I applied the patch, borrowed fontconfig from X11 with an export >>>> PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt >>>> terminal. >>>> (I'll send you a screen shot separately.) >>>>=20 >>>> To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x)= to >>>> see what would happen. >>>> =20 >>>> =20 >>> The plot is rendered properly, that's a good point ! >>>=20 >>> =20 >>>> I got the plot, but I could not get "focus" or whatever you call it fo= r the >>>> plot window. When I placed the cursor in the plot window area, all I g= et >>>> was >>>> a twirling icon telling me to wait. This happens any time the cursor >>>> crosses >>>> the wxt window. >>>> =20 >>> Do you mean that the plot window is just like dead ? Is the cursor >>> position updated in the status bar for example ? >>> If it's the case, there is probably an issue with the GUI loop running >>> in a separate thread. >>>=20 >>> =20 >> Timoth=E9e, >>=20 >> I realized after I sent the message I should have been more clear on thi= s >> point. Clicking inside the window does not get the focus, and the bar at= the >> top is always grayed out as it is in the screen shot that I sent you. Yo= ur >> question about the screen being "dead" is a good description. > I'm not familiar at all with MacOS. Is it a behaviour that you've > already observed in other situations ? (with X11, when the application > is dead, the screen is no longer updated and you get gray surfaces when > you drag another app on top of the dead one, for example) >=20 Timoth=E9e, Any time you drag the cursor across the wxt window, it changes from an arro= w pointer into a twirling color "pinwheel." Note that the red, yellow and green lights at the upper left of the wxt window are gray, an indication that the window is not active. Typically you see this behavior on the Mac when an application is hung, and you have to use "force quit" to exit the application. "Force quit" is probably the UNIX kill command with a nice gui. For wxt, the behavior is a different. The terminal.app window where the the interaction with gnuplot occurs, is still usable, and as soon as you exit gnuplot, the wxt window also disappears, as it should. This is not like any behavior I have observe= d with X11 on a Mac, but only about 10 percent of what I do is in X11, and those interactions are with well debugged applications. On a Mac, as with X11, one window at a time has, what I think X11 calls focus, i. e., only one window is interactive at a time. The wxt window refuses to become an interactive window, and you can't drag it around the screen with the cursor on the border like you can other windows. >=20 >> The cursor >> position at the lower left is frozen as it shows in the screen shot, and >> does not change when you move the cursor. >>=20 >> I have done a bit more testing. I can get octave-2.9.9 to open wxt windo= ws, >> and display plots, >=20 > Can you display several plots successively ? That would be another > argument in favor of the dead gui thread, because the plot rendering is > done in the main thread. >=20 Yes, several plots will stack up, but the only way to see the lower levels is to use Apple Expos=E9, which is a quick way (press F9) of displaying miniatures of all open windows, so you can click on the one to bring to the front. Each wxt plot window comes forward as it should for viewing. >> which is good, but it doesn't display legend information >> that displays in both X11 and AquaTerm. > Do you mean the mouse cursor position as above ? No, this is an additional problem that the legend text describing the lines is not displayed on the plot (usually upper right). This is a problem for later, and may be cured when we fix the other problems anyway. >=20 > Thanks, best regards, >=20 > Timoth=E9e This is getting wordy. Perhaps we should take this discussion off-list unti= l we have something significant to report. I should be available for trying things for the next few weeks. I'm an old Fortran programmer who uses octav= e and gnuplot for data analysis, so I can't be too helpful with C or C++ issues. Are there any questions that I should be asking of the wxwidgets folks? Let me know. Joe |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-10-10 21:23:50
|
On Tuesday 10 October 2006 02:04 pm, Joe Koski wrote: > > On a Mac, as with X11, one window at a time has, what I think X11 > calls focus, i. e., only one window is interactive at a time. The wxt > window refuses to become an interactive window, and you can't drag it > around the screen with the cursor on the border like you can other > windows. ??? That last bit is really strange. "Focus" controls where the input event go. If you type on the keyboard, who is listening? If you click the mouse, who gets first chance to respond? But dragging the window around the screen does not require the window to have focus; it is handled by the window manager / desktop, not by the program controlling the window. Can you use 'top' or 'ps' to see if the process controlling the wxt window is burning CPU cycles? Note that if it's a thread, you may have to give extra options on the command line: ps auxm -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Joe K. <jko...@co...> - 2006-10-11 02:59:13
Attachments:
capture.txt
|
on 10/10/06 3:23 PM, Ethan Merritt at merritt@u.washington.edu wrote: > On Tuesday 10 October 2006 02:04 pm, Joe Koski wrote: >> >> On a Mac, as with X11, one window at a time has, what I think X11 >> calls focus, i. e., only one window is interactive at a time. The wxt >> window refuses to become an interactive window, and you can't drag it >> around the screen with the cursor on the border like you can other >> windows. > > ??? That last bit is really strange. "Focus" controls where the > input event go. If you type on the keyboard, who is listening? > If you click the mouse, who gets first chance to respond? > When you have not selected a particular window, the Mac "Finder" is what you are interacting with. There are keyboard shortcuts you can use, and you always have your pull down menus at the top of the screen, the dock at the bottom of the screen, the trash, etc. All of these remain fully functional with the wxt window on the screen. You just can't select the wxt window and do anything with it (or drag it). > But dragging the window around the screen does not require the > window to have focus; it is handled by the window manager / desktop, > not by the program controlling the window. > > Can you use 'top' or 'ps' to see if the process controlling the > wxt window is burning CPU cycles? Note that if it's a thread, > you may have to give extra options on the command line: > ps auxm When you look at gnuplot while executing a script with top in another shell, you see a burst of gnuplot cpu usage to near 100 per cent (full use of one processor) for a brief time on my 2 cpu machine, then cpu usage falls to 0.2 per cent, and remains there while the wxt window is open. There is no big, churning 100 per cent process when gnuplot is just paused for display. While I was composing this, gnuplot continued to use 0.2 per cent of the cpu, and accumulated a few seconds of cpu time over several minutes of real time. When you enter ps auxm in another terminal shell while a wxt window is open, you see what I captured in the attached text file. To my untrained eye, it doesn't look like anything is wasting a large percentage of cpu cycles there either. In the past, I have also looked at the crash logs, and didn't see clues there either. I hope this helps, but I don't think so. My totally uneducated guess would be that something is wrong with the initial wxwidget calls that set up the wxt window with the Mac Finder. It's strange that everything else seems to be working, including pm3d. Joe |
|
From: <tim...@en...> - 2006-10-19 10:30:18
|
Joe Koski wrote: > on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wrote= : > > =20 >> Hi Joe ! >> >> I'm sorry you did not succeed, but those errors are normal: wxWidgets >> comes in different flavours depending on the platform: wxGTK (as Ethan >> told you), wxMSW for Windows, wxMAC which you logically installed, and >> others. There are a couple of places where it is necessary to choose >> between two possible behaviours (two threads or one) in the terminal >> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW), I >> have chosen to enable the compilation for those two only. >> >> However, attached is a patch that enables the compilation for wxMAC. I >> will be very glad to see you try it. Apply it in src/wxterminal and tr= y >> to build again. Hopefully it will work. Don't hesitate to report any i= ssue. >> >> Thank you very much for your efforts. >> >> Best regards, >> >> Timoth=E9e >> =20 > > Timoth=E9e, > > I applied the patch, borrowed fontconfig from X11 with an export > PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt term= inal. > (I'll send you a screen shot separately.) > > To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x) = to > see what would happen. > > I got the plot, but I could not get "focus" or whatever you call it for= the > plot window. When I placed the cursor in the plot window area, all I ge= t was > a twirling icon telling me to wait. This happens any time the cursor cr= osses > the wxt window. When I quit gnuplot, the plot window also disappeared. Joe, Can you tell me if you "bundled" gnuplot ? On Mac, it seems to be=20 important for GUI applications that are started from the command line.=20 If you didn't, can you try to do that ? Anyway, I'll give you a patch to=20 try later today or tomorrow that may overcome that particular problem. Timoth=E9e |
|
From: <tim...@en...> - 2006-10-19 11:28:29
|
Timoth=E9e Lecomte wrote: > Joe Koski wrote: > =20 >> on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wrot= e: >> >> =20 >> =20 >>> Hi Joe ! >>> >>> I'm sorry you did not succeed, but those errors are normal: wxWidgets >>> comes in different flavours depending on the platform: wxGTK (as Etha= n >>> told you), wxMSW for Windows, wxMAC which you logically installed, an= d >>> others. There are a couple of places where it is necessary to choose >>> between two possible behaviours (two threads or one) in the terminal >>> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW), = I >>> have chosen to enable the compilation for those two only. >>> >>> However, attached is a patch that enables the compilation for wxMAC. = I >>> will be very glad to see you try it. Apply it in src/wxterminal and t= ry >>> to build again. Hopefully it will work. Don't hesitate to report any = issue. >>> >>> Thank you very much for your efforts. >>> >>> Best regards, >>> >>> Timoth=E9e >>> =20 >>> =20 >> Timoth=E9e, >> >> I applied the patch, borrowed fontconfig from X11 with an export >> PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt ter= minal. >> (I'll send you a screen shot separately.) >> >> To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x)= to >> see what would happen. >> >> I got the plot, but I could not get "focus" or whatever you call it fo= r the >> plot window. When I placed the cursor in the plot window area, all I g= et was >> a twirling icon telling me to wait. This happens any time the cursor c= rosses >> the wxt window. When I quit gnuplot, the plot window also disappeared. >> =20 > > Joe, > > Can you tell me if you "bundled" gnuplot ? On Mac, it seems to be=20 > important for GUI applications that are started from the command line.=20 > If you didn't, can you try to do that ? Anyway, I'll give you a patch t= o=20 > try later today or tomorrow that may overcome that particular problem. > > Timoth=E9e > > =20 Just to confirm, I have just been told on IRC (#wxwidgets): " if it isn't bundled or you haven't ran rez on it, things don't receive=20 focus" Joe, the ball is in your hands... Timoth=E9e |
