Cannot create a fresh map

[runlow]

Expected: Going to File -> Fresh map should bring up a dialog box which should allow creating another map in the wad.

Actual: A dialog does open but it only has one input box. Changing the text string in it and pressing enter doesn't do anything. There's no "OK" button anywhere on the interface.

New-map-related options behave very similarly (dialog only has a text input box) so perhaps the other options are affected the same way:

• Fresh Map (already mentioned)
• Copy Map
• Rename Map

Everything else in the editor seems to be working fine.

Using Eureka 1.27b Tested it on Archlinux with the rapoison window manager.

A workaround I'm using is creating new map lumps in another program and then editing the new maps in the wad in Eureka (it works) but that's not very convenient.

It doesn't seem to output any errors to STDOUT or STDERR when this happens.

Possible solutions:

• I could maybe try an older version and try to pinpoint which commit introduced this problem
• the editor works fine other than this and so does every dialog box in it but there's an off chance that the ratpoison window manager is somehow doing this so I could try it on a different WM

[runlow]

What Fresh/Copy/Rename seem to have in common is that they all have references to UI_ChooseMap.

[ioan-chera]

It's a bit odd because the dialog would always generate buttons such as OK and Cancel. Does this happen with the latest master build too?

[runlow]

Just tested it now.

Yes it does still happen when I build the latest master.

Fresh/Copy/Rename open a dialog like on the screenshot.

Could it be some package is missing? If so why would all the other dialogs except those three work?

Are you able to reproduce this issue? Could you screenshot what the "Fresh map" dialog looks like for you on a Linux build and post your window manager - if possible?

Could it be that unlike the rest of the dialog boxes - these three rely on the window manager? I been trying to pinpoint what makes them different from the rest - haven't been able to figure it out yet but still looking.

I should maybe see if I can reproduce it in Xubuntu when ran from a VM.

Is there any other information you need? I'm testing it further, will post anything relevant I find.

[runlow]

Could someone please see if they can reproduce this bug on a Linux build?

[ioan-chera]

Then I guess I should build an Arch Linux virtual machine with your mentioned desktop environment. I hope it's not too much work to do.

[runlow]

There should not be that much difference between different Linux distributions for them to be relevant for the UI. I think it may be more relevant which window manager is used. Since you tested it on Xubuntu - I'm guessing you were running XFCE as your window manager. Was the "Fresh map" working OK when you tested it?

There may be no need for you testing it on Archlinux and ratpoison. It could be much work if you're not familiar with them. Consider testing it on the Manjaro distro if you want to - as it's based on Archlinux but has most things (including the WM) pre-configured.

Also it's possible to install ratpoison on Xubuntu. If you want to start it place exec ratpoison in ~/.xinitrc and start it with startx If you're not familiar with the GNU screen you may find it confusing to navigate though. If you are - most shortcuts are identical. prefix ? shows all the shortcuts (the prefix is Ctrl+t by default). Maybe if it doesn't work on ratpoison it may not work on other non-xfce window managers either.

[runlow]

Installed xfce4 and tested Eureka (build is from the release - v1.27b), and now "Fresh map" works! This is very good!

Strange because like I said - every other Eureka dialog box worked fine for me in ratpoison and it's just Fresh/Copy/Rename being a problem. Could it be that these dialog boxes are somehow created differently and somehow rely on the window manager - while the others don't?

[runlow]

This workaround will do for now but long-term I'd rather not have to start xfce4 just for those 3 menu options.

There's the greater problem of not only OS but window-manager/desktop-environment compatibility. FLTK claims to be cross-platform - so if I understand it correctly - running a different WM should not be necessary. Especially given that all the other dialogs work except for those three.

Personally I value the portability more than the upcoming features. People who want to make zdoom maps would probably not use Eureka to begin with but rather something like UDB or Slade. This is not to say that those can't be added but maybe not at the cost of portability. This is just my opinion. :thinking:

[ioan-chera]

People who want to make zdoom maps would probably not use Eureka to begin with but rather something like UDB or Slade.

I disagree with that personally. On macOS I cannot use UDB, and I prefer Eureka to SLADE, so I'd still use Eureka for Eternity UDMF maps for example. I will prioritize the bugs anyway, and this example is indeed a bug to fix.

[ioan-chera]

I've fixed it on my end. I managed to run ratpoison in Xubuntu. @runlow, let me know if it works for you as well now.

[runlow]

@ioan-chera built b188f2391a500d9d with cmake I'm afraid it's still the same as it was before.

Do you mean you managed to open and use File -> Fresh Map while running newest Eureka in ratpoison? For me it's still like in that screenshot. Map Slot: [ MAP02 ] and that's it when I select "Fresh Map".

When I run it in xfce4 - then it seems work OK - same as before.

Were you able to reproduce the bug before fixing it on/for your setup?

Was ratpoison the sole window manager or did you run it on top of another one like xfce4? Were you using .xinitrc or are you using a login manager to start ratpoison? (I think the default one on xubuntu is lightdm).

Could you take a screenshot of what happens after you select "Fresh Map" on ratpoison? (press Ctrl + T then ! then type in scrot but it needs to be installed)

Every other dialog works fine except for those three (Fresh/Copy/Rename) so I might later run through those dialog boxes with a fine comb to find out what it is exactly that breaks them. Sorry for not responding earlier.

[runlow]

Today I've noticed something even more bizarre which could be related.

When I tried b188f2391a500d9ddbf2 in ratpoison - everything worked fine (except for the issue reported here) but a new problem came up which was not there before.

I can no longer see textures for one-sided linedefs in b188f2391a500d9ddbf2. On the older v1.27b version which built via AUR a while ago - I was able to see them fine.

When tested b188f2391a500d9ddbf2 on xfce4 - it worked fine (could see texture previews on one-sided linedefs).

I realise that ratpoison is a relatively obscure/extreme window manager (not for everyone) but as I said - I think the mere fact that this problem exists for me at all is indicative of a potential greater issue. If it doesn't work for me on ratpoison - it may not on other wm's (and there are many on Linux). I may test this further on other window mangers (although the choice of window manger should not be an issue - nevertheless it could give some clues as to what's happening).

Whatever has changed for the texture preview (I mean that tiny square, not the "browser" with full sized textures) may have caused this. Another thing to check may be a git log -p on v1.27b..b188f2391a500d9ddbf2 to see what happened. (I'm guessing releases/versions are tagged). I'll see if I can find anything.

I could check if ratpoison outputs any errors into STDOUT/STDERR while I'm reproducing the bug. Could it be that those sections are somehow "asking" the window manager something that more advanced window managers are able to handle no problem? Could this be some correlation that has nothing to do with the window manager? (For example - xfce has a xfwm4 "composite manager" running with it while ratpoison by default doesn't have any - something like that) Edit: confirmed that running or not running a composite manager doesn't affect this in any way

Feel free to post any findings or ideas as to what might be happening.

[ioan-chera]

Yes, I was able to reproduce the initial problem (with the broken dialog boxes) with Ratpoison. I enabled this desktop environment in Xubuntu by following this tutorial. Most notably, I added the /usr/share/xsessions/ratpoison.desktop file with that content, then logged out and back in with the Ratpoison option in the menu at the top-right of the login screen.

It was caused by the unusual way FLTK programs define their GUI programmatically. Instead of having an intuitive "create container, add container to window, create a button, add button to container" mode, it works like "create a container and begin a global context, create a button and it automatically becomes part of container, create other controls and they also become part of container, finally end the global context". I don't know if this is broken in itself though. I might be tempted to customize FLTK at some point, but right now I'm sticking to stock FLTK. What caused your problem was a call to Fl::focus in the middle of this creation process, which somehow inhibited the creation of further controls in Ratpoison. What I did was try to disable it during Ratpoison. Problem is that I depended on some environment variables which I'm not sure are on your system. They're DESKTOP_SESSION and GDM_SESSION. Do you have them set to ratpoison? If not, it means I must find other ways to detect the manager, or just remove Fl::focus from there, because those cases work without it anyway.

As for the 1-sided texture not showing, that may be one of the many regressions caused by my code changing spree (I really should have started writing unit tests before going on a spree, but I acted like an amateur here). Might be something similar, I'll see.

[ioan-chera]

@runlow Let me know if either of these still happens:

1. The missing dialog box controls
2. The missing midtex tile from the sidedef panel.

Regarding 2, it was caused because the XY origin is different in Ratpoison compared to other desktops!

[runlow]

It works! (61a308bb48a25a195) Can open both 1) "Fresh map" and can see the 2) midtex tile now in ratpoison! Thanks so much!

They're DESKTOP_SESSION and GDM_SESSION. Do you have them set to ratpoison?

Neither are set for me. I don't use GDM (Gnome Display Manager) or any display manager. I'm afraid I don't know what would be a good way to detect if ratpoison is running. Removing calls to Fl::focus if they aren't needed sounds like a better solution to me although I'm not familiar with FLTK

I suppose I'll close the issue. Big thanks again, and thanks for the extra info - it should help in case anything like this comes up again. This is really great because I don't have to use other programs now for creating new maps or moving them.

[runlow]

@ioan-chera by the way, if still interested or if this comes up in the future http://ratpoison.nongnu.org/doc/Command-Line-Arguments.html#:~:text=environment

There is a $RATPOISON environment variable. I think it's pretty safe to assume that when it is set one is running ratpoison