Arch Linux: Possible graphical bug?

[olorin92]

Hitting T never does anything you gotta hit t.

Problem solved!

But in all seriousness, I hadn't thought of that! Alas my shortcuts don't seem to be working still - some seem to work (like the function keys) but copy/paste and timing marks still seem to be doing nothing.

Perhaps I should build from the repo and see if I get any joy running directly from there...

EDIT: Timing marks seem to be working properly now! Now to figure out why it refuses to copy/paste...

[Gilrock]

I don't know if it'll solve all your problems but try closing Xlights and then delete your key binding file from your show folder then reopen Xlights.

Did you try this advice?

[olorin92]

I don't know if it'll solve all your problems but try closing Xlights and then delete your key binding file from your show folder then reopen Xlights.

Did you try this advice?

Sorry just realised I didn't explicitly state that - yes I did remove the bindings xml file. So my timings seem to be working properly now, just not copy/paste. I'll keep looking and see if there's any obvious reason why that is though

[keithsw1111]

Copy and paste do not refer to the keybindings.


Sent from my iPhone using Tapatalk

[olorin92]

Copy and paste do not refer to the keybindings.


Sent from my iPhone using Tapatalk

Ok so potentially something related to the graphical issues I'm getting, given that seems to be specific to my setup. I think I’ll do a build and see if I get any joy, if I do then there must be something weird with the way the AppImage is packaged and my environment.

If not, then just my environment!

[olorin92]

Ok finally got the depencies right on my machine to do the build successfully. After running the built binary, it seems to display the graphics fine, without having to use the dedicated graphics card.

Copy/Paste still isn't working, but I'm happy at least that the graphics seem to work properly now.

I do suspect this means there is something in the AppImage build process that my machine doesn't like. Finding out what that is might be the next step I suppose!

[Gilrock]

Linux sure seems like a troublesome OS and when I tried it I found it a pain that every program you wanted to use you had to figure out if it was compatible with the 8000 versions of Linux.  I just don't get love for that OS.

[olorin92]

Linux sure seems like a troublesome OS and when I tried it I found it a pain that every program you wanted to use you had to figure out if it was compatible with the 8000 versions of Linux.  I just don't get love for that OS.

Yep I can understand that view, some of us are masochists but to  be fair some things I’ve just found so much easier on a Linux box than windows - dev related setups especially

[olorin92]

OK so I think I've found the issue. The switch statement that is used to process the normal key bindings for copy and paste seems to depend on the preprocessor symbol __WXMSW__ being present - looking this up here: https://docs.wxwidgets.org/3.0/page_cppconst.html seems to suggest this will only be present when using Windows controls in the GUI - which I'm assuming won't be the case when using Linux?

I'm happy to fiddle with this and alter the code to handle my scenario (once I figure out what preprocessor symbol is actually present), then create a pull request if that helps?

[Gilrock]

I don't see where you mentioned exactly what you are trying to copy/paste.  I can tell you those wxWidgets docs probably have nothing to do with how our code works because we are capturing the keystrokes and executing copy/paste inside our code its not handled by wxWidgets.

[dkulp]

OK so I think I've found the issue. The switch statement that is used to process the normal key bindings for copy and paste seems to depend on the preprocessor symbol __WXMSW__ being present - looking this up here: https://docs.wxwidgets.org/3.0/page_cppconst.html seems to suggest this will only be present when using Windows controls in the GUI - which I'm assuming won't be the case when using Linux?

I'm happy to fiddle with this and alter the code to handle my scenario (once I figure out what preprocessor symbol is actually present), then create a pull request if that helps?

Umm.. where are you looking?   The MainSequencer::OnChar method that handles the copy/paste keys doesn't have a single #ifdef in it.

[olorin92]

Sorry - I'm doing the copy and paste in the layout view, not the sequencer. I'm attempting to copy and paste a model

[olorin92]

I don't see where you mentioned exactly what you are trying to copy/paste.  I can tell you those wxWidgets docs probably have nothing to do with how our code works because we are capturing the keystrokes and executing copy/paste inside our code its not handled by wxWidgets.

The keystrokes are being handled yes, but part of that handling (including the copy paste functionality) is wrapped in that ifdef - and the preprocessor symbol it's look for (at least for me) isn't present. The cases of the switch statement that handle the copy paste don't even get hit because the symbol is missing. If I remove that ifdef for instance, it works properly (not saying this is the solution, but that it's definitely causing it to not work).

I was trying to figure out why that ifdef was there as, like you said, the functionality in the switch statement doesn't seem like it would be broken without it because it's being done outside of wxWidgets

[Gilrock]

If would be best if you list filenames and line numbers when you start trying to describe a section of code.  When you say something like "the cases of the switch statement" I have no idea what code you are staring at.

Normally a copy/paste is done by clicking on the model's picture and not it's name in the list.  Which way are you trying to do it?  I'm just finding it hard to believe you are the first Linux user to ever try to copy a model.

[dkulp]

I was trying to figure out why that ifdef was there as, like you said, the functionality in the switch statement doesn't seem like it would be broken without it because it's being done outside of wxWidgets

It likely should be an "#if !defined(__WXOSX__)"

On the Mac, the Copy/Cute/Paste is handled by those menu items on the main menu.   The accelerators kick in and call the appropriate methods.   Thus, without the ifdef, we ended up getting double pastes.