wxMaxima (please update that program!)

[gunterkoenigsmann (Gunter Königsman)]

Several universities have contacted me that their mac-using students have a hard time using the 2-year-old wxMaxima macports installed, namely on MacOs Ventura (for a minor case see ​https://github.com/wxMaxima-developers/wxmaxima/issues/1749) => requesting wxMaxima to be updated.

If there is a problem that hinders wxMaxima from being updated please tell me so I can fix it.

What I already tried to prepare is

• Better locale handling
• if the problem is that cmake doesn't find wxWidgets that might be an indication that wxWidgets didn't come with a module we request. In case that is wxWebView (found a bug report about it missing from macports) the git master of wxMaxima offers the following configure-time switch: -WDXM_DISABLE_WEBVIEW=OFF.

In order to prevent bit rot from accumulating I would like to enable automatic gui tests on the mac on every commit to the wxMaxima repo on the Github Actions ci. Currently if after building I run ctest the test stops when wxMaxima is opened for the first time. My guess is that it opens a warning window the user has to close manually. If that indeed is the problem please tell me which dialogue to get rid of so I can add the tests.

Thanks in advance,

Gunter.

[MSoegtropIMC]

Hi Gunter,

sorry for the long delay. Indeed I had issues compiling later versions of wxMaxima and didn't have time to investigate the issues. Your hint on webview should be helpful - I will see.

The dialog box appearing should be the one which asks if maxima should be allowed to create a network port - I think it is for maxima and not for wxMaxima, but I never looked into the details.

I will look into an update the next days.

Best regards,

Michael

[MSoegtropIMC]

Hi Gunter,

I am highly confused by this webview thing. In wxMaxima master, the word "webview" does not appear at all (case independent search). In the latest tag Version-23.02.0 it does appear, but the option you mentioned does not exist. I also guess there is a typo in the option (should probably start with -D) and I guess one has to set it to ON to disable webview.

Best regards,

Michael

[MSoegtropIMC]

Sorry - please ignore the note on DISABLE_WEBVIEW - I was still on master instead of main. After switching to main I see the option.

One more note: I require wxWidgets 3.0 because 2 years back with 3.2 the scrolling was completely broken.

[MSoegtropIMC]

I now tried with the latest commit on main and WXM_DISABLE_WEBVIEW=ON. It configures now, but fails to compile with:

wxmaxima-c90f7b2b37878324f9428f2512315636c1aef729/src/HelpBrowser.h:67:3: error: unknown type name 'wxWebView'; did you mean 'WebView'?

[gunterkoenigsmann (Gunter Königsman)]

I was hoping that my ticket were read by a whole team of macports maintainers that come to our help. ...and in the meantime actually Tomio-san came as a deus ex machina ​https://github.com/wxMaxima-developers/wxmaxima/issues/1749#issuecomment-1437841451 and helped me to (hopefully) resolve several issues.

The scrolling has been drastically simplified about a year ago so maybe the wx-3.2 issue has been resolved by accident - and I've just added a commit to wxMaxima's main branch that should resolve the wxWebView error: wxWidgets tries to offer all functionality most operating systems have in common using a common API - and for dockable sidebars with browsers they have named their API wxWebView. But wxWidgets on macPorts somehow is compiled without that functionality.

[gunterkoenigsmann (Gunter Königsman)]

If you tell me to do so I will make a wxMaxima release with all the mac changes that are already part of its main git branch.

[MSoegtropIMC]

Thanks! Let me first try latest main wit wxWidgets 3.2

[MSoegtropIMC]

It does compile now and start (didn't test much as yet) but I get an error dialog stating that maxima was not found as /Applications/maxima or /Applications/Maxima. A while back I introduced the defines OSX_MACPORTS_PREFIX and OSX_MACPORTS_PREFER, which are patched by the port file to the proper values. If OSX_MACPORTS_PREFER is 1, one can assume that maxima is found under OSX_MACPORTS_PREFIX "/bin/maxima" and that this is the preferred location. So in

#if OSX_MACPORTS_PREFER
  wxLogMessage(notFound, maximaLocation.mb_str());
  maximaLocation = OSX_MACPORTS_PREFIX "/bin/maxima";
  if (wxFileExists(maximaLocation))
    return maximaLocation;
#endif

the wxLogMessage does not make sense - at least not before one checked if maxima is there.

[MSoegtropIMC]

Except for the issue with the Maxima not found dialog box, it looks fine. Scrolling is OK with wxWidgets 3.2, so I will use this now.

I will do some more testing in the commuter train (I regularly use Maxima there). If you don't hear from me otherwise before 7 PM German time today, please create a tag.

[gunterkoenigsmann (Gunter Königsman)]

That sounds like being good news! The thing with the dialog box I don't understand: If maxima isn't found in the first attempt one does not get a message in the "log messages" sidebar, but a dialog box, instead?

Perhaps I found a reason why that might happen: I have now instructed wxWidgets to suppress debug dialogues in one place that perhaps produces debug messages before a debug messages sidebar is available.

[MSoegtropIMC]

Besides showing a dialog box, the main issue is that wxLogMessage is called before the preferred location for Maxima is even tried. If OSX_MACPORTS_PREFER is 1, wxMaxima should first look into OSX_MACPORTS_PREFIX "/bin/maxima".

What happens above is that it first issues a (non fatal) error message and then checks if it can find Maxima if OSX_MACPORTS_PREFER=1.

I don't think you need to change anything about reporting the error - it should not occur at all.

[MSoegtropIMC]

Opening the preferences dialog still gives several debug asserts and then crashes. It looks like it couldn't find some bitmap.

[MSoegtropIMC]

With the cursor line placement in parenthesis, it is a bit hard to judge were exactly the cursor is. But I think it was always like this and this is just an effect of the code font being italics by default - I usually set it to non italic. These settings got lost with the update and cause of the previous issue I can't change it right now.

[gunterkoenigsmann (Gunter Königsman)]

Gaah! I still am a bit at loss why the bitmaps are invalid here. Are the toolbar bitmaps and the bitmaps in the bottom right corner rendered correctly, instead?

In the meantime I have made a commit that should make invalid configuration bitmaps turn out blank, instead of causing errors. Does that change anything? If not: Have you a method of getting a backtrace of the crash?

[MSoegtropIMC]

I just tried latest main (eefe6d1a5155327cffa8034f55406b9231879a3b). It fails to compile with:

:info:build wxMaxima/work/wxmaxima-eefe6d1a5155327cffa8034f55406b9231879a3b/src/HelpBrowser.h:52:55: error: use of undeclared identifier 'm_configuration'
:info:build   bool AllowOnlineManualP(){return AllowOnlineManualP(m_configuration, this);}
:info:build                                                       ^

[gunterkoenigsmann (Gunter Königsman)]

I believe I have fixed that now - and don't understand how the program compiled on my computer with wxWebKit disabled. Once this is over we'll should try to add the list of command-line calls that compile wxMaxima under MacPorts to ​https://github.com/wxMaxima-developers/wxmaxima/tree/feature/KoenGu/MacPorts in order to avoid compilation problems on MacPorts to happen.

[MSoegtropIMC]

I can compile again, but the issue with the preferences dialog remains. I attached a screen shot (for whatever reason one cannot copy/paste the text from the dialog box):

[MSoegtropIMC]

stack trace screen shot

[MSoegtropIMC]

The issue with the preferences dialog has to do with the contents of the preferences file. Unfortunately I lost the offending one. I started wxMaxima in a debugger, where I then stepped over the assertion and closed the program, so that a new settings file was written. After that the issue was no longer reproducible. I also tried a few older settings files I saved, but without success.

I see that the settings file stores the settings tab last opened. Maybe a tab name changed and then things go wild? Anyway: more validation of the preferences file should fix this.

This is btw. about "/Users/<user>/Library/Preferences/wxMaxima Preferences". If you have users who can reproduce this, please ask them to send you this file.

I also tried to install the old 21.02 wxMaxima and create a new prefeences file, but this also did not help to reproduce the issue.

[gunterkoenigsmann (Gunter Königsman)]

That I couldn't have possibly found without your help! Thanks a lot!

I actually validated the number of the current configuration dialog tab. But I failed to recognize that the tab numbers begin with #0 (and therefore reach only up to NumberOfTabs -1). Have corrected that now, too.

[gunterkoenigsmann (Gunter Königsman)]

Have added more configuration validation for the case that one downgrades wxMaxima or edits the config file by hand.

[MSoegtropIMC]

Did the number of tabs change? Could you reproduce the bitmap issue issue with a bad tab number?

I will do another test build now.

[MSoegtropIMC]

Looks good (well I can't test the preferences issue any more).

One thing I noticed and that might be new: when I enable just the main tool bar, the table of contents and the history, then the history window is gone after a restart. That did work in 21.02 (but had similar issues before testing).

The left panel area is also a bit distorted in an intermediate stage when I remove the left side pandels (greek letter, math symbols, ...) one by one.

I will do some more testing ...

[gunterkoenigsmann (Gunter Königsman)]

I have no mac I can reproduce issues with. But

• the only images in the config dialogue are the bitmaps shown on the notebook pages
• I have indeed changed the number of notebook pages at one point
• The bitmaps of all existing tabs are guaranteed to be valid and of the correct resolution, now. The worst case that might happen is that some bitmaps are blank.
• I made an off-by-one error when validating the number of the last notebook page that was active.
• And the error is that the image of the tab that is to be activated is invalid.

=> with all your debugging results sherlock holmes would have settled for this solution.

The other issues are with wxWidget's AUI module. Most of them I cannot work around ;-(

=> Will create the release.

[MSoegtropIMC]

I don't quite give up on AUI yet. There were also issues with it in the 21.02 release, but we were able to resolve them.

Possibly the AUI issue is related to the "Integrated help browser"? When I disable / enable it, nothing does change in the UI appearance - possibly something is wrong with it. Is this the question mark and the drop down menu at the top right (in the main toolbar, but to the very right)? The question mark works (opens help in browser), but the drop down arrow doesn't do anything.

[gunterkoenigsmann (Gunter Königsman)]

The integrated help browser is disabled when there is no wxWebKit. Where did I forget to remove it from the GUI?

[MSoegtropIMC]

The menu "View/sidebars" shows an entry "The integrated help browser". Possibly it is also partly there in AUI management which then confuses AUI.

[gunterkoenigsmann (Gunter Königsman)]

In the AUI management it isn't present if there is no wxWebView.

The AUI problem on the mac has been there from the beginning: Issuing SavePerspective() saves the position of all sidebars on closing the program and LoadPerspective() loads them again on re-opening it - which works without big bugs on Linux and on Windows. On the mac some toolbars that were hidden on closing the program are restored not as hidden, though, but as half-transparent toolbars at a fixed screen position that (perhaps since they technically shouldn't be clickable) ignore any input. I kind of work around this by hiding and unhiding toolbars on start-up. But I guess the problem has to be resolved on the wxWidgets side.

[MSoegtropIMC]

The AUI problem is a bit of a deja-vu. I am sure we had the same on 21.02 and somehow fixed it. Let me see if I can find the discussion.

[gunterkoenigsmann (Gunter Königsman)]

The history bug I believe I have resolved in the main branch. For the rest I have no idea what I did the last time. But with a few more hints on how the problems look like I probably will find the error: The last times you described complex problems so accurately that it was possible to narrow down the problem to a few lines of code without being able to reproduce it.

[gunterkoenigsmann (Gunter Königsman)]

That means: The AUI stuff (everything that has to do with the dockable sidebars) doesn't react instantly if I tell it to do something - but waits for a

  m_manager.Update();

before redrawing the screen (which saves us from doing redraws in the middle of a complex multi-sidebar action). I remember to have forgotten to issue that command in one place.

Then the functions that hide and unhide sidebars expect a int as their arguments and depending on the int find the sidebar with the right name and hide or unhide it. That, too, is manual stuff that can go wrong.

[gunterkoenigsmann (Gunter Königsman)]

I have reviewed the AUI code - and since I haven't found any bug in it I have rewritten it. Let's hope that if the issues were on our side this has resolved them. If not it at least has made wxMaxima about 300 lines shorter.

[MSoegtropIMC]

Thanks - I very much appreciate your efforts to make this work on MacOS!

Unfortunately I tried d7513cabf2350966057eee310b68dbdee898f289 and it asserts immediately - even after removing the ~/Library/Preferences/wxMaxima.plist file and removing the AUI block from ~/Library/Preferences/wxMaxima Preferences. I attached a screen shot. Was this the right commit to test?

[MSoegtropIMC]

Assert screen shot

[gunterkoenigsmann (Gunter Königsman)]

It was the right commit and I always try to construct things in a way that they, if they are broken, break immediately at startup.

Perhaps this time I went a bit over-the-top with that => removed two asserts.

[MSoegtropIMC]

This assert seems to be gone, but I get another one - likely a try to check a menu item for the non existing help panel.

[MSoegtropIMC]

Assert menu check

[gunterkoenigsmann (Gunter Königsman)]

Ok... ...found a way to resolve that and to tell the CI to test the case that there is no wxWebView.

[gunterkoenigsmann (Gunter Königsman)]

With a bit of luck it works with the current main.

[MSoegtropIMC]

distorted display

[MSoegtropIMC]

It is getting better. It doesn't assert any more and as far as I can see it does properly store the panel configuration now. Just the panel display is distorted. It draws some debug messages over the greek letters and also in a spacer for the history and table of contents panel.

This is also a deja vu - I have seen the same in preparation of 21.02.

I attach a screen shot.

[gunterkoenigsmann (Gunter Königsman)]

Thad is exactly the issue that has caused us to do wild things with the display: some sidebars instead of being hidden turn up in the foreground, but aren't clickable and without window frame. If you find out which sidebars cause the problem I can unhide and hide them again at startup. Or - a wild guess - does removing the config file resolve this problem and the problem in the end is a stale config from a buggy version?

[gunterkoenigsmann (Gunter Königsman)]

Now wxMaxima enables all sidebars on start-up, doesn't force a display refresh and then hides the sidebars that are to be hidden. Let's hope that helps.

And I've found out how to tell GitHub actions to compile the program on macports. But a bug on their side causes that to eat up 90 minutes of cpu time for every commit. that maybe is a bit much...

[MSoegtropIMC]

It looks better, but there is still an overlay of some debug log window. Your modifications changed the size and position of if, but did not remove it. So it might be that if this window is removed, the changes are not required.

The preferences window is back btw. This time I can reproduce it even when I delete the settings file.

I attach 2 screen shots.

[MSoegtropIMC]

debug message overlay

[MSoegtropIMC]

preferences assert

[gunterkoenigsmann (Gunter Königsman)]

Ok... ...found a difference between the dockable "debug messages" window and all other dockable windows: I cause it to be layout using the SetSizerAndFit() command, not by the FitInside() command like I do with the other sidebars. Other differences I haven't found => Changed that command hoping that the debug messages dialog can now be properly hidden.

[gunterkoenigsmann (Gunter Königsman)]

In the "compile_mac" workflow in ​https://github.com/wxMaxima-developers/wxmaxima/actions the .dmg file resulting from each commit to the wxMaxima repository is now uploaded as an "artifact". No idea if that artifact is any useful, as it is not signed.

[MSoegtropIMC]

I just tried latest master (ca7efd27c86e8d7ab3a486cd3830560d671b760e). The preferences dialog works again, but the issue with the debug messages window is still there. I btw. can't find a menu option to switch it on and off - maybe having such an option would help to play with it. As is if I have anything in the left panel, it gets distorted. I also think that the frame window background gets distorted by it. Areas which should be gray are white. I somehow think the debug window becomes the frame background.

[gunterkoenigsmann (Gunter Königsman)]

It should be one of the checkboxes in the "view/ show sidebars" menu. Perhaps I shouldn't have put the checkboxes into a submenu. But the menus grew too long...

Will search for more potential causes in the next few days.

[gunterkoenigsmann (Gunter Königsman)]

Have now tried to modified the code to add the worksheet before adding the debug messages sidebar.

[gunterkoenigsmann (Gunter Königsman)]

This morning I Looked at every line of code the debug messages window is involved in. I still claim: the log messages sidebar does do nothing bad - and is never used as a parent of a window. Sherlock Holmes would now say that this is impossible as something clearly is different with that window so I have replaced all constructs I used there and that differ slightly from what I use in the other windows with constructs I use in the other windows. If that happens to help I still don't know why, though.

[MSoegtropIMC]

I just compiled latest master - the issue is still the same. After starting the debug messages window is disabled, but it somehow fills the frame background. Enabling and disabling the debug messages window (I found it - I was just confused that it was switched off while being visible) fixes the display. But after closing and opeing again, it is broken again. I attached 3 screen shots - one after start, one after enabling and one after disabling debug messages. In the first it is clearly visible that also the frame background on the right is distorted.

I can't say what is special about the debug messages window. Possibly the issue is that it receives redraw messages from receiving messages very early in the start up process and then it does something unintended. Possibly it helps to block certain activities of the debug messages window when it is not enabled.

[MSoegtropIMC]

Safter start up - debug messages disable but visible

[MSoegtropIMC]

After enabling debug messages

[MSoegtropIMC]

After disabling debug messages

[MSoegtropIMC]

P.S.: observe how the color of all parts of the frame window is white and not gray in the first screen shot and has some letters in it even on the right hand side.

[MSoegtropIMC]

One more issue: the saving of font names and sizes does not seem to work (it used to work in 2021.02). It does save attributes like bold, italic and underline.

[gunterkoenigsmann (Gunter Königsman)]

Ok... ...now I have changed the code to try to not update the log sidebar's contents until the whole window has been built. If that doesn't work perhaps we should just make the program hit the "toggle" button for that sidebar twice on startup: That isn't a clean solution, but it should at least work...

[MSoegtropIMC]

Thanks, I will do a new build.

One more oddity: when I change the font for code to normal "not bold, not italic" it works, until I select a code block and press Cmd+X to cut it. This makes the code font bold / italcs again.

[MSoegtropIMC]

I just tried the new version - the debug stuff still does not work.

I think it is better if I debug this. This kind of hack is not very "sustainable". I might find some time tomorrow for this.

[gunterkoenigsmann (Gunter Königsman)]

Wolfgang has told me a few days ago to send you a invitation link to the wxMaxima developers group. If you accept this one you have write access to the code.

[MSoegtropIMC]

Yes, I have seen this. I won't have that much time to work on it - my main open source baby is ​https://github.com/coq/platform - but I can have a look at wxMaxima on MacOS once or twice a year.

[gunterkoenigsmann (Gunter Königsman)]

Any help on the mac is extremely welcome!

For the the font issues I currently fail to reproduce them. But I will look out for them: In theory everything that is platform-specific should have been abstracted away, there, by wxWidgets.

---

coq looks like being both a very usable and a very advanced program.

[MSoegtropIMC]

I had a look at the debug panel issue. IMHO the issue is clearly that m_logPane = new LogPane is called before wxPersistenceManager::Get().RegisterAndRestore(this) in wxMaximaFrame::wxMaximaFrame. If I move the panel constructor directly after the persistance manager init, it works fine.

A fix is unfortunately tricky. You need the log target early - otherwise you get message boxes for early messages. I would say the only solid fix is to introduce a kind of document / view split for the log. You should have one object "LogData" which is constructed early and serves as error message handler, but this object just stores them and doesn't display them. Then you create the LogPane when appropriate in the GUI flow and connect it to the earlier create "LogData" object.

We have a family gathering this weekend, so I won't have time to fix it myself.

[gunterkoenigsmann (Gunter Königsman)]

The persistence manager should only save and restore the position and size of the main windowl. On ms windows if you close the program, disconnect your high dpi screen and then re-open the program on your smal lores laptop screen it is opened outside of the screen. If je just get rid of using the persistence manager here, instead of fixing one problem with it?

[gunterkoenigsmann (Gunter Königsman)]

That means: perhaps I've just found one thing we did wrong: we did create the wxPersistenceManager in wxMaximaFrame and should have done so in wxMaxima, which is its child class. With a bit of luck that resolves that issue.

[MSoegtropIMC]

It is quite clear that opening the LogPane before the persistance manager does not work and after does work. According to the doc of wxPersistenceManager it is responsible for managing persistence for all wx entities, so I would assume that thus also applies to AUI. Actually it might be that this changed betweem wxWidgets 3.0 and 3.2 - the structure of what is saved looks different.

I will try the latets build, but I believe the fundamental problem is that you start to send log messages to the log pane before AUI is properly initialised. wxWidgets then can't do much besides manifesting the window. Looking at the Window structure at the point you send the first log message, the structure is such that the LogPane is the only child of the frame window, so it ends up to fill the frame window. The AUI manager then overlays this in Mac.

[MSoegtropIMC]

The latest version (34f5cba290a5582cbe552519c454591a27373715) does not compile on Mac:

:info:build In file included from /opt/local/var/macports/build/_Users_msoegtrop_MacPorts_macports-local_math_wxMaxima/wxMaxima/work/wxmaxima-34f5cba290a5582cbe552519c454591a27373715/src/AutocompletePopup.cpp:32:
:info:build In file included from /opt/local/var/macports/build/_Users_msoegtrop_MacPorts_macports-local_math_wxMaxima/wxMaxima/work/wxmaxima-34f5cba290a5582cbe552519c454591a27373715/src/wxMaximaFrame.h:45:
:info:build In file included from /opt/local/var/macports/build/_Users_msoegtrop_MacPorts_macports-local_math_wxMaxima/wxMaxima/work/wxmaxima-34f5cba290a5582cbe552519c454591a27373715/src/Worksheet.h:45:
:info:build /opt/local/var/macports/build/_Users_msoegtrop_MacPorts_macports-local_math_wxMaxima/wxMaxima/work/wxmaxima-34f5cba290a5582cbe552519c454591a27373715/src/Notification.h:64:42: error: only virtual member functions can be marked 'override'
:info:build   bool Show(int duration = Timeout_Auto) NOTIFI_OVERRIDE;
:info:build                                          ^~~~~~~~~~~~~~~
:info:build /opt/local/var/macports/build/_Users_msoegtrop_MacPorts_macports-local_math_wxMaxima/wxMaxima/work/wxmaxima-34f5cba290a5582cbe552519c454591a27373715/src/Notification.h:40:25: note: expanded from macro 'NOTIFI_OVERRIDE'
:info:build #define NOTIFI_OVERRIDE override
:info:build                         ^
:info:build /opt/local/var/macports/build/_Users_msoegtrop_MacPorts_macports-local_math_wxMaxima/wxMaxima/work/wxmaxima-34f5cba290a5582cbe552519c454591a27373715/src/Notification.h:70:16: error: only virtual member functions can be marked 'override'
:info:build   bool Close() NOTIFI_OVERRIDE;
:info:build                ^~~~~~~~~~~~~~~
:info:build /opt/local/var/macports/build/_Users_msoegtrop_MacPorts_macports-local_math_wxMaxima/wxMaxima/work/wxmaxima-34f5cba290a5582cbe552519c454591a27373715/src/Notification.h:40:25: note: expanded from macro 'NOTIFI_OVERRIDE'
:info:build #define NOTIFI_OVERRIDE override

[gunterkoenigsmann (Gunter Königsman)]

But I haven't even touched that part of the code, nor does have anybody else ?!?

Anyway: I have now removed the override that was only there on the mac, which removes an #ifdef. Let's hope that this corrects that problem.

[gunterkoenigsmann (Gunter Königsman)]

On the CI that compiles with MacPorts the build error isn't reproducible which means that I cannot verify if it has really disappeared. But any #ifdef we can get rid of and that helps is a good thing.

On Linux the persistance options for the maxima window are as follows:

[Persistent_Options/Window/wxMaxima]
x=171
y=57
w=1024
h=600
Maximized=0
Iconized=0

Why do they do more than that on the mac?

[gunterkoenigsmann (Gunter Königsman)]

If the current commit doesn't work I remove the persistence stuff from the main window and use the code from ​https://forums.wxwidgets.org/viewtopic.php?f=1&t=32297 instead.

[MSoegtropIMC]

Sorry - after doing my tests I switched back to "master" rather than "main" and got an old build from 2021. I now deleted the old master branch locally.

The AUI management works fine in the latest build 80ddb65edaaebf8d87841b56b27a7218400b65e6 :-)

What remains is that I cannot set the style for "Style/Default" / "Code Default". When I change it to not bold not italic in preferences, it has an effect. This is also correctly saved in the preferences file as:

[Style/Default]
color=black
bold=0
italic=0
underlined=0

But when I close and reopen wxMaxima, the setting is gone and on closing again the preferences file becomes:

[Style/Default]
color=black
bold=1
italic=1
underlined=0

So I guess that there is something wrong with reading this preference pr translating it to internal data structures.

[gunterkoenigsmann (Gunter Königsman)]

Already found something: we use wxString here as a variadic argument. That works in 95% of the cases and sometimes fails. Will look into that tomorrow.

But the other news is great news: how did you find out the thing about the persistence manager causing trouble?

[gunterkoenigsmann (Gunter Königsman)]

Without your help repairing any of those bugs would have been next-to-impossible: The AUI stuff that could not be fixed even by a re-write (since I didn't know what to re-write, too) - and reading the text styles that overwrote a few out-of-border bytes of memory which on my system happened to actually restore the style even if a spurious "if" should have prevented that from happening properly. I am convinced that those bugs are resolved now (along with a few others I found while searching for those bugs). Thanks a lot!

[MSoegtropIMC]

I say thank you! The font stuff seems to work now as well. Let me test it for a few days and then I would say it is good for a release. I would prefer, though, that the commit I tested is tagged then. Maybe you can already create a tag on 4fdc4eaceb9c4c76f618294ae76d3351d91c86e4 and if I find something else we can create a new tag.

how did you find out the thing about the persistence manager causing trouble?

Essentially binary intersection search. It was obvious that the main issue with the log pane is that it is created so early and that it receives actions before the AUI layout is manifested. But it is only a small number of lines of code to the creation of the other panes. So I just moved around the construction of the log pane to see what happens. Luckily wxMaxima compiles in a few seconds.

[gunterkoenigsmann (Gunter Königsman)]

Wow... ...on my computer compiling wxMaxima requires several minutes.

Ok... ...created the tag.

[MSoegtropIMC]

The M1/M2 Macs are quite fast for compilation and the like.

Some bad news: I got the bitmap assert again in the preferences dialog. I now believe it depends on if a monitor is connected or not. It seems to work fine on a monitor, but not on the integrated MacBook display (which has a very high resolution in dpi and might require different icons). I don't have a monitor around right now, will double check later.

[MSoegtropIMC]

Two more notes:

• saving fonts in preferences works now, also font size
• if I close the "bitmap assert" dialog box with the close box I can get to the preferences dialog - it does not have any of the icons in the tabs.

[MSoegtropIMC]

I can confirm that the bitmap issue most likely depends on screen resolution.

My monitor has about 110 ppi - here the icons and preferences dialog work. My laptops integrated display has (afaik) about 220ppi - here the icons and preferences dialog do not work. It might be that I have it slightly scaled, so that the virtual ppi is even larger.

I guess you can emulate this on Windows by setting the display ppi to something else than the physical one.

[MSoegtropIMC]

There is one more thing which would be nice to have on Mac: the ability to disable zoom by Ctrl+Scroll. I am using a magic mouse which has sort of a touch pad integrated and when I have Ctrl pressed and come only near to it, it zooms widely. This happens to me at least 5 times a day. Besides the scroll is so sensitive, that it is unusable (moving 1mm on the mouse zooms a factor of 2 at least). A simple setting to disable zoom by Scroll+mouse wheel would fix this.

[gunterkoenigsmann (Gunter Königsman)]

I have found a way to get a tabbed thingy without images. If you don't have a better idea I would remove the #ifdef in that Dialogue and if that doesn't help switch to the image-lwss config dialogue on the Mac.

[gunterkoenigsmann (Gunter Königsman)]

Removed the #ifdef. If that doesn't help I am all for removing the images in the Mac platform.

[MSoegtropIMC]

@Gunter: let me have a look at the icons when I am home - I should have the tools to fix them such that they work on any platform.

[MSoegtropIMC]

Any chance to get the "zoom my mouse scroll" disable (or did you already implement it?)

[gunterkoenigsmann (Gunter Königsman)]

Unfortunately until now I could not find any place we handle that kind of event. My guess is that we just get zoom events and that the program just listens to them.

Currently my son has a headcold and my girlfriend is getting suspicious what I do at the computer at odd times around the day and night => I guess I'll have to look more after my family in the next few days.

[gunterkoenigsmann (Gunter Königsman)]

Perhaps we should tweak the following function:

void Worksheet::OnZoom(wxZoomGestureEvent &event) {
  if (event.IsGestureStart())
    m_zoomAtGestureStart = m_configuration->GetZoomFactor();

  SetZoomFactor(m_zoomAtGestureStart * event.GetZoomFactor());
}

[gunterkoenigsmann (Gunter Königsman)]

I seem to have no hardware that generates zoom events for me => no good way to test if the zoom is fast enough/too fast.

[gunterkoenigsmann (Gunter Königsman)]

Experimentally I've introduced a zoom factor exponent into that function. Let's hope that it helps.

[MSoegtropIMC]

Thanks - I will try it! No worries - it is not urgent for me. I prefer to do things properly, even if it takes time.

There is one more issue I found during testing: in the old version (21.02) when I do a wxDraw3d, I could right click on the image and do "pop outinteractively", which opens aquaterm. I could rotate the coordinate system there.

In the current version, I can still open aqua term this way, but it seems to get a 2D image (a 2D render of the 3D scene) rather than a 3D scene. I can't manipulate it in any way.

[gunterkoenigsmann (Gunter Königsman)]

The non-reactive 3d plot looks like a gnuplot bug to me: Gnuplot spawns 2 processes. One draws the plot - and the other is supposed to care about the user interaction. If that one stops the plot cannot be rotated.

[gunterkoenigsmann (Gunter Königsman)]

...and for me it feels kind of urgent as a report in the maxima mailing list seemed to indicate that thousands of students with shiny new ARM mac computers currently cannot use wxMaxima. Not sure how critical things really are, though.

[gunterkoenigsmann (Gunter Königsman)]

Haven't heared from you for a long time. My guess is that you are waiting for a new tag and I was waiting for feedback for the last changes => found out how to create a tag without creating a release - and named that tag "test/macports_2023_04_01"

This time I hope I completely got rid of the config dialogue images on MacOs. Additionally wxMaxima should be more responsive now and I tried to improve its lisp part, that was subject to bit rot and was missing a few quotes for XML special chars.

[gunterkoenigsmann (Gunter Königsman)]

Ok... ...have now made a release that completely removes the bitmaps from the config dialogue on the mac. There should be no way that this version fails...

[papadil]

Portfile for wxMaxima update

[papadil]

Included portfile update to the latest wxMaxima compiled with wxWidgets-3.2. Works fine on my mac.

[ryandesign (Ryan Carsten Schmidt)]

@papadil, thank you for the updated Portfile. In the future, it is more helpful to attach a diff rather than a full Portfile; that way, we can see what changes you're proposing. Filing a pull request is even better than attaching a patch. I've converted your patch to a PR with some additional changes:

​https://github.com/macports/macports-ports/pull/19528

[ryandesign (Ryan Carsten Schmidt)]

In 0e7d8a7fa1884b444ff6198058ce4232728d31f3/macports-ports (master):

wxMaxima: Update to 24.01.0 and use wxWidgets 3.2

Move maxima to be a library dependency because CMake checks for it.

Indicate C++14 requirement as indicated in CMakeLists.txt and enforce
even newer compiler than that due to build failure on earlier compilers.

Removed no longer current comments and messages.

Closes: #66914

Co-authored-by: papadil <papadil@…>