Closed mMerlin closed 4 years ago
Does it work fine with X11 display? Try running it via flatpak run --env=QT_QPA_PLATFORM=xcb org.fritzing.Fritzing
YES!!
Thanks. That gets around the immediate issue. Should probably support Wayland at some point?
Better ask upstream about it. I'm not sure what's wrong in this case, but Qt on Wayland bugs are not uncommon.
@grulja Can this be something similar to flathub/org.telegram.desktop#133?
This looks like a bug in drag and drop, maybe this one [1], but I have no idea why the application cannot be closed.
We had an issue reported in connection with wayland, but I closed it because it seemed to not happen anymore, and the user did not follow up: https://github.com/fritzing/fritzing-app/issues/3264
This looks like a bug in drag and drop, maybe this one [1], but I have no idea why the application cannot be closed.
This case is not all drag and drop that fails (visibly). If I open an existing sketch, I can drag existing parts around in the views. It is only new parts from the library that vanish. And something was registered on mouse up, because the image of the part being dragged was deleted from the screen. Though if this is related, not being able to close could be because something is waiting for either a drop or a cancel event.
We had an issue reported in connection with wayland, but I closed it because it seemed to not happen anymore, and the user did not follow up: fritzing/fritzing-app#3264
The referenced issue seems to be fixed. I can use open and save dialogs. In my environment. Although, after opening, dragging, saving, the application did not fully close again. Also, dragging an existing part, then close did the same thing, and did not pop up the requester to save changes. Opening the saved after drag sketch did show the part in the new location, so the drag was registered. Could still be that the move events were seen, but not the drop, which causes an outstanding pending event
, which prevents application shutdown.
closing this, as having a usable work around. The underlying QT/Wayland issues that apparently caused the problem can be dealt with some place else.
@mMerlin Maybe we should enable this workaround bu default for all users?
That would prevent some issues. What detection is available to decide when to invoke the environment override? What I know is a problem, is Fedora 31, with a strong case for Fedora 29 and 30, plus Debian 10. What I suspect is anything using Wayland. The downside being figuring out when to turn that default off again. Supposedly, Qt will start being (more) compatible with Wayland at some point. When it works, using the system default would be the preferred way to go. Now, if there is specific feature test that can detect when the problem will occur, that would be the way to dynamically fix the problem. Like some feature detection and monkey patching down in javascript for browser compatibility.
Fritzing 0.9.4b is not working in flatpak on Fedora 31 and some other distro versions. I have the same symptoms with 3 different physical machines running Fedora 31, plus Virtual Box VMs for Fedora 30, Fedora 29, Debian 10. It works properly on Ubuntu 18.04, both physical and virtual machines.
The symptom on the failing cases, is that the application starts just fine. It can open existing sketches and view them. However, when a part is dragged from the library to a view, when it is dropped, it just vanishes instead of being placed. The application is also now unable to be fully closed. After attempting to place a part, closing the application "looks" like it worked, but after a bit, a notification pops up that "Fritzing is running in the background". The flatpak run command never exits in the terminal window the application was started. Using a separate terminal window…
Force closing the terminal window kills the processes.
So far the thing I see common for the failing environments is Wayland. As soon as the mouse pointer is moved over the breadboard view,
QWaylandShmBuffer: mmap failed (Invalid argument)
messages start repeating in the terminal window. The same lack of placement, and unable to close occurs if the part placement is done in the schematic or pcb views as well, but the wayland message to does not get generated that way.I haven't yet worked backward far enough to get a Fedora (or Debian) environment that is not using Wayland by default.
This works with Ubuntu 18.04