New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Application window can be dragged #38
Comments
I have found that this issue isn't present in the latest SugarLiveBuild, I think it is only on the Ubuntu FocalFossa Package from (http://lists.sugarlabs.org/archive/sugar-devel/2020-February/057763.html). |
Thanks. That's great. The difference in behaviour is probably important. I suggest using |
@quozl, you were right, both SugarLive Build and Ubuntu Build had v101 of the Write Activity. Apparently the issue of dragging fullscreen apps has been there in older versions of metacity, some update must have broken it again. I took a look at the metacity repo and 3.36 changelog had 'Fix fullscreen regression.' (GNOME/metacity@655f7c8 ), but it was the one with the issue. I compiled metacity 3.35 and ran it on the SugarLive Build and the issue seems to have gone. Video: ( https://drive.google.com/open?id=1b4qCv2lZhjQw3JNtqmgJ8dHsWqV_zjK6 ). |
Thanks. If it were Metacity alone, I'd be happy to close this issue as "not our problem", but I haven't been able to reproduce it with other activities. Have you? |
Neither have I. Have found it only in the write-activity. |
Interesting. If it doesn't happen with Hello World, and does happen with Write, then whatever is different may have contributed to the problem. Might proceed by removing user interface widgets and features from the Write activity until the problem stops happening. Is there a reliable and scriptable way to trigger the problem, like with |
I haven't used The only issue I see is that it might be difficult to make it work on different screen sizes, ratios. We can test it on some fixed screen size. We can also try writing the script such that it tests it for all activities at once. Something along the lines of |
Thanks, but that won't be necessary. I've tested further with It did not work with a QEMU KVM, but did work with a real laptop. I placed the cursor above the stop button, at X coordinate 1275 on a display of 1366x768 pixels. The responsive zone is four pixels wide, from Y coordinates 0 through to 3. At a Y coordinate of 4 the stop button highlights. Coordinates of the stop button are different than other activities. The mouseover highlight effect is different. Starting the activity from within Terminal it can be seen the stop button shifts downward and to the left slightly. This reminded me of a change made to fix flickering when AbiWord had a problem not yet fixed. GitHub deletes old issues, otherwise I'd reference it. By testing, I proved the problem is enabled by the GTK_THEME workaround, which was applied during packaging. I've removed it. From: James Cameron <quozl@laptop.org>
Date: Thu, 15 Sep 2016 08:05:14 +1000
Subject: add flicker workaround
---
AbiWordActivity.py | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/AbiWordActivity.py b/AbiWordActivity.py
index 6f9ff57..1b4b639 100644
--- a/AbiWordActivity.py
+++ b/AbiWordActivity.py
@@ -20,6 +20,10 @@ from gettext import gettext as _
import logging
import os
+# Workaround for https://bugs.launchpad.net/bugs/1574278
+# (flicker of abiword on first text entered)
+os.environ['GTK_THEME'] = 'adwaita'
+
# Abiword needs this to happen as soon as possible
from gi.repository import GObject
GObject.threads_init() By turning off the Sugar theme, a window management border was allowed. Fixed in sugar-write-activity 101-0~0quozl1, please upgrade. |
Reported in
http://lists.sugarlabs.org/archive/sugar-devel/2020-March/057890.html
The text was updated successfully, but these errors were encountered: