Build working Windows version

[vadz]

Right now it doesn't compile due to some issues with toascii(wxString[n]), but this shouldn't be difficult to fix. This will almost certainly not be the last problem, however.

[vadz]

Just FYI, I've fixed the issue with toascii(), but now it crashes on startup, so I'll need to debug this.

[esternin]

Vadim,

Sorry, I've been MIA, too busy with other things. The problem is I have no native Windows installation, so no way to generate a binary. Can I do this cross-compiling from Linux?

If not, can you upload a binary somewhere for me to try?

As to your specific questions:

1. Please, try using Browse dialog to select the file to execute. It can be in the distribution Scripts directory, or in another directory. This should just work.

After doing this once, @filename.pcm to this, or any other .pcm file in the same directory, should work from the command line. Relative directory specifications from Linux "../subdir/file.pcm" should be auto-translated into valid Windows paths, but if it does not work, that's a minor bug at worst.

2. wxToolBar: great, I did not know this was a possibility. I am assuming such code changes will not cause any trouble on the Linux side.

3. I do not really understand what the problem is, so I guess I need to see the Win version running. But, would it be possible to change the default greys globally, in one place, to bypass this problem of not specifying the background colour in pop-up windows?

[vadz]

Yes, "cross" compiling refers to compiling under a system different from the one the program runs on. In this particular case it means that you can compile it under Linux -- in fact, this is exactly what I did. You will still need a Windows machine to test it on, however...

As for the rest:

1. I understand how it's supposed to work. The problem is that it currently doesn't, almost certainly because the code doesn't account for ":" in Windows paths. If you think you could look into it, it would be great, otherwise I'll try to. But it's not a minor bug at all.
2. This shouldn't cause any trouble, but this will change the appearance. Normally it should be for the better, but we'd need to have the bitmaps in the right sizes for the toolbar buttons.
3. The problem is that all windows should really be created as children of wxPanel, not wxFrame directly. In wxGTK doing the latter actually does work just fine, but in wxMSW this results in 2 problems: the one with the mismatched background colours and also TAB navigation doesn't work. The best would be to create the intermediate panels everywhere, it's not difficult to do, just a bit time consuming because there are a few windows there.

[esternin]

Oh, I do have a minimal VirtualBox with Windows 7 I can launch, to test the executable. What was your configure to cross compile for Windows?

3: I think I understand the issue now, but I would not want to take this on. I can try to look into 1:, surely this has been an issue before, so why suddenly it's raising its head? 2: I am neutral on, but I think you have a clear plan, so please go ahead.

The button bitmaps I am happy to modify/replace, if you have any good generic candidates, and we talked about getting them in at least two different sizes (for high-dpi). Many of them are completely generic (file, run/stop, etc) so can we switch to using the GTK theme icons? I can then work on the missing ones, hopefully close in appearance to the GTK isons' look. What are the missing ones? just the five on the upper left? Maybe we can replace them with textual labels? '@', '=?','f(x)','[..]','U+03C0 '

[vadz]

Configure command should include --host=x86_64-w64-mingw32 option but is the same as usual otherwise, please see the "Building Microsoft Windows Version" section in the updated INSTALL file in #40.

Again, (1) is specific to MSW and is probably due to the fact that MSW paths include colons. I'll debug it to learn what's really going on there.

For the icons, I don't think there are stock GTK icons for everything we need, unfortunately. Also, this wouldn't help with the MSW version.

[esternin]

Following the modified INSTALL instructions:

~/triumf/wxWidgets-3.1.5$ ./configure --host=x86_64-w64-mingw32 --enable-static
configure: error: unrecognized options: --enable-static

[vadz]

Sorry, this was a brainless typo, it should be --disable-shared.

[esternin]

I have successfully compiled a mingw 32-bit versions of wxwidgets 3.1.5 and eXtrema. This is what I see under a VirtualBox/Windows 7 (32-bit):

There is replacement of / by \ on the fly, in all file names, which seems to be working when invoked from the command line, i.e. @Scripts/2yaxes.pcm correctly calls the file Scripts\2yaxes.pcm but not from the filename in the Browse dialog, where the slashes in the path are modified correctly but the filename itself is messed up - Z:.stk instead of 2yaxes.pcm. Note that the FIRST : is processed correctly, but something goes wrong with the end of that string.

And, presumably for the same reason, none of the Images\ or Help\ files are found (I placed extrema.exe and the .dll's in the top-level directory, so these are all valid relative paths).

Is this the same as what you see?

[esternin]

refresh on resize does not work, but it does refresh if I cover and then uncover the whole visualization window.

[esternin]

My bad: I forgot to define EXTREMA_DIR. With that, and moving .exe and .dll into the bin subdirectory of that, the program finds its icons. They also look reasonable, with a slightly grey background looking acceptable, and no extra frames floating about, although some of the text buttons seem inappropriately sized:

Should I revert to 3.0.4 ?

[esternin]

The problem in https://github.com/esternin/eXtrema/issues/12#issuecomment-883522917 may be with wxfn.GetPathSeparator(). Under Linux it's : under windows, it's ; and the : of the disk part of the path (Z:) is confusing the parser. But why would it suddenly become an issue now...

[esternin]

Repeated for Windows XP, similar results. The buttons look just fine...

[vadz]

Sorry for the late answers.

It turns out that the problem with icons was due to a bug in the version of wx I was using. It has been fixed in wxWidgets/wxWidgets@75d508b6e6adfaa58289aba4a8d35c1025c21792 and now they do look fine. OTOH I didn't, and still don't, see the issue with the truncated buttons.

The problem in #12 (comment) may be with wxfn.GetPathSeparator(). Under Linux it's : under windows, it's ; and the : of the disk part of the path (Z:) is confusing the parser. But why would it suddenly become an issue now...

Sorry, I don't understand what do you mean by "now" -- did this ever work under Windows before? In any case, please let me know if you want me to spend time looking into this.

For now I've just pushed another commit adding panels in all places where I could see them missing. To show what differences it makes, compare the screenshot of the "Read vectors" dialog before: and after: this change (don't pay attention to the icons, this is due to rebuilding with the new wx version fixing the previously mentioned bug).

BTW, another thing it would be nice to do is to add SetIcon() calls as now all the application frames have no icons at all and so use the ugly generic one.

[vadz]

P.S. In many places, including the screenshot above, things still look weirdly due to the wild (and inconsistent) use of default borders. I didn't change this because I have no idea what kind of personal preference could have resulted in it, but I'd just remove all occurrences of wxSUNKEN_BORDER and wxRAISED_BORDER in the code, I don't think there are ever any use cases for them nowadays.

[esternin]

I didn't, and still don't, see the issue with the truncated buttons.

See the "Process Command" button in the Execute dialog, it's too small for the text. Not seen in Linux versions, or in 4.4.5 Windows version.

I don't understand what do you mean by "now" -- did this ever work under Windows before?

Yes, in the 4.4.5 (2012) version the Browse-selected file would execute without problems. Since we did not change any of this code, I don't think, it's somewhat mysterious why it's failing now.

another thing it would be nice to do is to add SetIcon() calls as now all the application frames have no icons at all and so use the ugly generic one.

Oh, I agree, but note how in 4.4.5 version it is the case. Was there some other mechanism used to ensure it, that no longer works?

In many places, including the screenshot above, things still look weirdly due to the wild (and inconsistent) use of default borders. I didn't change this because I have no idea what kind of personal preference could have resulted in it, but I'd just remove all occurrences of wxSUNKEN_BORDER and wxRAISED_BORDER in the code, I don't think there are ever any use cases for them nowadays.

I never noticed before, I guess I am not sensitive enough to this, but looking at your last screenshot, I would say there is a certain consistency: buttons (to be pressed) are raised, while input fields (to be filled) are sunken. But defaulting them all is fine by me, and may produce a more consistent look.

Here are the two of them side-by-side, 4.4.5 on the left, under Win7. On the right, the latest (4.6.1?). Your changes actually make the file-list manipulation buttons visible, they were simply missing in 4.4.5, but note the "Process Command", the black drag trails from moving the "Fatal error" pop-up across the Visualization Window, and the generic icon in the top left corner on the right. The buttons look very different, it looks to me like from 2.8 to 3.0 additional attributes showed up (or defaults changed) in wxWidgets. Both are fine by me, the 4.4.5 versions look cleaner to me, as now only the textual buttons ("Browse", "Apply", etc) are rectangular while image buttons now have grey backgrounds and rounded corners. It looks like the white colour is transparent in bitmaps of 4.4.5, maybe we need to use different button bitmaps, if transparency is supported in .bmp.

[vadz]

I didn't, and still don't, see the issue with the truncated buttons.

See the "Process Command" button in the Execute dialog, it's too small for the text. Not seen in Linux versions, or in 4.4.5 Windows version.

Just to be clear, I do see it with your screenshots, but not with my own version. I don't use exactly the same wx version, but if it doesn't happen with wx 3.1.6 (to be released relatively soon), it's probably not worth spending time on this.

I don't understand what do you mean by "now" -- did this ever work under Windows before?

Yes, in the 4.4.5 (2012) version the Browse-selected file would execute without problems. Since we did not change any of this code, I don't think, it's somewhat mysterious why it's failing now.

The current code uses wxFileName::GetPathSeparator(), 4.4.5 didn't use wx at all, so it looks like the code is pretty different.

another thing it would be nice to do is to add SetIcon() calls as now all the application frames have no icons at all and so use the ugly generic one.

Oh, I agree, but note how in 4.4.5 version it is the case. Was there some other mechanism used to ensure it, that no longer works?

Again, this version didn't use wx at all, so yes, it did use a different mechanism and we do need a proper resource file too, but we still need to call SetIcon().

Here are the two of them side-by-side, 4.4.5 on the left, under Win7. On the right, the latest (4.6.1?). Your changes actually make the file-list manipulation buttons visible, they were simply missing in 4.4.5,

This is not really related to my changes, this was fixed when transitioning to wx, I guess, due to the use of sizers rather than hardcoded control sizes.

the black drag trails from moving the "Fatal error" pop-up across the Visualization Window,

I don't see this one, how exactly can I reproduce it?

and the generic icon in the top left corner on the right.

This should be fixed by just adding SetIcon() calls to all frames.

The buttons look very different, it looks to me like from 2.8 to 3.0 additional attributes showed up (or defaults changed) in wxWidgets. Both are fine by me, the 4.4.5 versions look cleaner to me, as now only the textual buttons ("Browse", "Apply", etc) are rectangular while image buttons now have grey backgrounds and rounded corners. It looks like the white colour is transparent in bitmaps of 4.4.5, maybe we need to use different button bitmaps, if transparency is supported in .bmp.

No, transparency is not supported by BMP. But beyond this I remain very confused by your comparisons of 4.4.5, which was not using wx at all, with the current wx-based version. Yes, some styles differ, but then the code is entirely different too...

Anyhow, please let me know what would you like me to do in (little) remaining time that I have.

[esternin]

I had not appreciated that 4.4.5 (Windows version) was not using wxWidgets. I thought the switch occurred earlier. Ignore all my comments stemming from that.

I turned white transparent in fit.GIF (the middle button) and I think that's all that's needed - unless there is a wxWidgets flag to do that on the fly, at import. If not, I will change all .GIFs, and re-process all .bmp images into .gif, with white set to be transparent.

Adding `setIcon()`` using a 64x64 .png icon (if .svg is not usable in this context; which is what I used to create the icon/desktop link in the "distribution" zip file ) is great, and would take you little time by the sound of it.

Could you adjust makefile to have a way to create a binary windows distro .zip - I did it by hand. I'll push my .ico .bat and .lnk files up. I use ln -s to "add" the .exe and .dll to the bin directory (e.g. ln -s src/extrema.exe ../bin/), not sure if github will understand these, so that - or a straight cp/mv needs to be a part of make winbin or whatever you want to call it, conventionally. The distribution should have this .bat:

set EXTREMA_DIR=%~dp0
start /B bin\extrema.exe

and a desktop link that points to this .bat and has the correct icon, in %EXTREMA_DIR%icons/extrema.ico, in addition to Scripts/, Help/, and bin/ subdirectories. In this way, there is no "installation", just unpack and run.

The Browse dialog parsing and the backing storage issue are the only bugs I have found so far. The second one: very strange that you cannot reproduce it. What happens if you resize the VisWin with something on it? This is what I see when I drag the lower right corner in the SE direction: What happens if you drag a pop-up dialog (like an error) across it, then off it? Does the plot in VisWin remain unmolested? Then the issue is with WinXP/Win7, and was probably fixed in the current Windows (you are using 10?)

Perhaps an extra refresh is needed somewhere, since you've eliminated the excessive refreshes with every re-draw. Maybe, we need one on every window action (resize, minimize/maximize, drag off-screen, cover/uncover). You are the best person to know where one is needed.

If you have time after that, then the last thing is the Browse dialog parsing. Why it's working under Linux and is failing here, if the separator is properly identified for each system. If you run out of time for this, I will try my hand, but I do not want to do it now, to avoid duplication of effort.

[esternin]

Another small bug: under Windows, red cross pulls up the yes/no dialog, but fails to exit when yes is pressed. File->Exit does the same, and exits normally.

I fixed one typo in wxForms/AnalysisWindow.cpp: E&xit --> &Exit but that was just decoration, I think. I tried

-{ extrema_->QuitApp(); }
+{ ::wxGetApp().QuitApp(); }

but this did not fix it, and neither did ExGlobals::QuitApp().

I am confused how the same YES_NO dialog is being called but yields different outcomes in the two cases.

[esternin]

I tried chasing down the execute/browse bug, but wxLogDebug() does not seem to work under windows?

"Note that on Windows,"X:" refers to the current working directory on drive X." ref so the problem may be in ExGlobals::GetCurrentPath() returning z: when I run

z:
cd \triumf\eXtrema\bin
set EXTREMA_DIR=z:\triumf\eXtrema
extrema.exe

rather than the full z:\triumf\eXtrema\bin

[vadz]

OK, I do see the missing refresh when resizing the visualization window, so something is definitely wrong here, I'll look at it.

I also see the problem with the "exit" button not working.

Concerning wxLogDebug(): under Windows, its output goes to "debug output" which is something you can see under debugger or using a tool such as DebugView++.

[esternin]

Concerning wxLogDebug(): under Windows, its output goes to "debug output" which is something you can see under debugger or using a tool such as DebugView++.

Under DebugView++, I File->Run extrema.exe and see no messages by wxLogDebug() calls. Even after I re-make clean, not just re-make the objects that have wxLogDebug calls...

[vadz]

Just to confirm, did you use --enable-debug when building?

[esternin]

../configure --host=i686-w64-mingw32 --disable-shared --with-wx-config=../../wxWidgets-3.1.5/wx-config --enable-debug
make clean; make

[esternin]

Ah, interesting. I compiled the msw-build code under linux and the same non-exit behaviour is observed in the linux x86_64 version! So some change you introduced in inserting the panel layer between buttons and top-level frames has created this change.

Interestingly, the File->Exit->yes/no dialog-> yes generates these (but does exit):

(extrema:255231): Gtk-CRITICAL **: 19:14:59.287: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar

[vadz]

I've fixed the problem with the "Exit" button by simply reusing the same QuitApp() function that was already used elsewhere instead of (imperfectly) duplicating it in the button handler in AnalysisSpeedButtonPanel.

I've also added a proper resource file, so that the application binary has the proper icon now, and set this icon for at least the main frame under MSW (under Linux we could either also embed the PNG into the application binary or load it during run-time, not sure what do you prefer). This also defines a proper manifest, which should avoid a number of other problems, sorry for forgetting to do it initially.

I think the msw-build branch should be ok to merge now.

[esternin]

Awesome. Yes, let's merge.

Under Linux, I do not think we need to do anything, I see this as a purely Win quirk.

We are distributing the .desktop file which establishes the icon as the .svg (or png if .svg is not supported, like on Debian) as well as multiple resolutions of .png. All decent window managers make use of that to tag the windows with an icon:

[esternin]

I've also added a proper resource file, so that the application binary has the proper icon now, and set this icon for at least the main frame under MSW

This did not seem to work under Win 7 32-bit wx 3.1.5, is there a compiler switch to ensure inclusion of the new src/extrema_res.rc? Or do we need to add SetIcon()?

The buttons look OK, and the Exit button works fine. The refresh of the page and of the canvas is OK, but not of the frame of the VisWIndow, it gets mangled on resize or drag and is missing the units button and x/y coordinate reporting. The pathway to scripts is still not working.

[vadz]

Just to be clear: the resource file defines the icon shown for the executable in the Explorer (Windows file manager). To use an icon for a frame, SetIcon() is definitely needed. .desktop files are not used under Windows.

I forgot about the refresh problem, sorry. I'll fix this.

As for the paths handling, I thought you were looking into it, so I didn't...

[esternin]

Ah, I misunderstood the Windows bit, because under Linux the same "resource" file (.desktop) determines both. If you feel strongly about little window frame icons under Windows, we could add SetIcon(); I do not.

Refresh: great.

Path handling: I tried, but could not get the debug and/or console messages to report anything under Windows, so I simply do not have the tools to do it at the moment.

[vadz]

The path handling problem is due to ParseLine::ParseIt() handling \ specially, it switches to state 19 which corresponds to something called "qualifier symbol". So when it parses a line like EXECUTE c:\foo, it creates 3 fields: EXECUTE,c:and\foo. The code executing this later interpretsc:` as the file name and it doesn't work, of course.

For now I've avoided the problem by just using the file name, rather than path, as the code already used ExGlobals::SetCurrentPath() so using just the name works too. But more generally something would need to be done to either not handle backslashes inside paths specially in ParseIt() or replace all backslashes with slashes in the command lines.

[esternin]

replace all backslashes with slashes in the command lines.

Yes to this. In all Scripts, the relative file references use / and not \ and they parse properly, so for MS builds we should just replace all \ in filenames. \ are strictly for command switches, graph\overlay ... etc.

[vadz]

The problem is that it's going to be difficult to find all the filenames (and only filenames). E.g. what do you do with the interactive entry? It's supposed to be parsed by this function, but it doesn't parse it correctly... Unfortunately fixing this doesn't seem to be trivial, as we'd need to keep track of the previous token and whether it's supposed to be followed by a file name or not.

For now I've pushed c1dd9d7 which at least allows the "Execute" dialog to work, but you still need to enter slashes (and not backslashes) in the @ commands in the main window.

[esternin]

you still need to enter slashes (and not backslashes) in the @ commands in the main window.

I actually LIKE this! Coming from Linux, I expect this. And it is consistent with macro language, which should not change when it encounters a stupid OS.

[vadz]

I mean, you can always use slashes, of course, but there is not much to like in the fact that you get a rather confusing error message if you use backslashes which really ought to work in any Windows program (if only because any path copied from somewhere else would have them).

[esternin]

The same refresh bug is back (on Win7, mingw-i686), now that we committed to 3.1.5 and merged back into main. I do not see any commits that were missed compared to when it was working for a while. but just like above, resizing VisWindow no longer refreshes the display.

This is unrelated to your latest fix of aspect ratio as it behaves the same way with and without it.

[esternin]

The fonts have raised their ugly head again.

I installed FreeFont .TTF family in my Windows 7 (and even rebooted after), but extrema fails to find SERIF or MONO, everything keeps coming out in some SANS-like font, not even sure which one, as I still cannot see messages from wxLogDebug under Windows.

Thus the Windows version has no font control at the moment. This code seems OK, but is not working:

$ grep -R SERIF ../src
../src/Graphics/GRA_fontControl.cpp:    fonts_.push_back( new GRA_font(wxT("SERIF")) );
../src/Graphics/GRA_fontControl.cpp:    psFontNames_.insert( { "SERIF", "FreeSerif" } );

FreeFonts are definitely installed:

Do I need to specify "FreeSerif.ttf" and not just "FreeSerif" ? Or is something more fundamental is missing?

@test_fonts and hit Enter 3 times to test.

[vadz]

I've fixed the refresh on resize issue under MSW in 7ff5a7867dadca1d8a7377bb698ec3f679b18947 (which I've pushed directly because it's clearly the right thing to do and can't break anything), sorry for missing this one before.

[esternin]

Aside from some minor leftover work with font handling (sorry, @vadz , for misunderstanding the issue for so long... my bad), a working Windows version can now be generated from the main code branch.

Closing the issue, with massive kudos to @vadz !