MT5 on Linux: Drag & drop issue when modifying orders/alerts (Wine) - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
FIXED mine!
Running Mint 22.2, Wine 10, MT5 build 6090
I use a T7 wired gaming mouse with variable dpi. 250 Hz polling rate.
I had to set the mouse to 1k dpi, the lowest available on this mouse, to get on-chart order dragging to work. Depending on your system, you may have a wider range of working dpi or polling rate settings.
I have only tested with dpi changes, but I would bet if the polling rate is too high, even at 1k dpi the drag fails would probably still occur. Just a guess on that, though.
I used libinput-tools to identify my device and mouse-dpi-tool to measure the dpi. AI will guide you in the use of these. Good luck!
MetaTrader 5 x64 build 6090 started for MetaQuotes Ltd.
@devthedev Thanks for the suggestion, but I tested various polling rate values for the mouse and it didn't help.
I'm using a simple Logitech M220 wireless mouse with no option to change the DPI.
The issue with modifying transaction via drag & drop still persists.
Additionally, the behavior is identical when using a touchpad or touchscreen (thinkpad t480s).
Currently testing on Fedora 44 (KDE Plasma) via Bottles 65.0 (tested runners: ge-proton11-1 , soda-9.0-1 ).
I do have a similar issue. I am using Fedora 44 (kernel 7.2.5-200.fc44.x86_64) using Wine 11.0 on KDE Plasma 6.7.5 with Wayland and installed the official package using the recommended procedure from this website.
In my case I can't click into buttons or change the colors of indicators. Sometime I can't even access the properties of the indicators. I can open the Indicators list but when clicking on indicators nothing happens. I do tried the same thing with a Bluetooth track pad without any results.
Please create a native Linux build. Nobody wants Winslop anymore.
Confirming this on another setup, and adding a test that I think narrows it down.
Environment
Symptom (identical to the original report) Grab a stop-loss or take-profit line on the chart and drag it. While the cursor keeps moving, the line follows normally. The moment the cursor is held still for roughly two seconds, the line disappears and the drag is cancelled — with the mouse button still physically held down.
Importantly: the modification is not applied. Releasing the button after the line has vanished leaves the SL/TP unchanged. So this is a cancelled operation, not merely a lost redraw.
Other chart objects (trendlines, rectangles, horizontal lines) drag correctly on the same chart, including when the cursor is held motionless for many seconds. Only order lines and alerts are affected, which matches earlier posts here.
What I ruled out None of the following made any difference:
The test that I think matters I have an MQL5 Expert Advisor on the same chart, in the same terminal, under the same Wine, that implements dragging by hand: it tracks button state and pointer position from CHARTEVENT_MOUSE_MOVE and moves its own price lines.
That custom drag does not exhibit the bug at all. Holding the cursor completely still for ten seconds or more mid-drag leaves the line exactly where it is, and releasing applies the value correctly.
Same terminal, same chart, same Wine, same mouse, same X server — the MQL5-level drag is unaffected while the terminal's built-in order-line drag cancels after about two seconds of no pointer movement.
That suggests the terminal's internal drag handling for order lines uses a different input path from the one exposed to MQL5, and that this path treats "no mouse movement" as a reason to abort, rather than waiting for an actual WM_LBUTTONUP. On Windows this presumably never surfaces because the message stream differs slightly.
If it would help, I am happy to run specific Wine debug channels or a test build and post the output.