Skip to content
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

Closed
quozl opened this issue Mar 9, 2020 · 8 comments
Closed

Application window can be dragged #38

quozl opened this issue Mar 9, 2020 · 8 comments

Comments

@quozl
Copy link
Collaborator

quozl commented Mar 9, 2020

Reported in
http://lists.sugarlabs.org/archive/sugar-devel/2020-March/057890.html

@shaansubbaiah
Copy link
Member

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).

@quozl
Copy link
Collaborator Author

quozl commented Mar 10, 2020

Thanks. That's great. The difference in behaviour is probably important. I suggest using git bisect between the Write activity version in my Sugar Live Build and the version in my package for Ubuntu 20.04. If the version is the same (which is quite possible given the dates of commits), then the cause may be other packages, so we'll have to figure out which. Metacity 3.34 was used in Sugar Live Build, and Metacity 3.36 in Ubuntu 20.04. If it is a regression in Metacity, then git bisect can be used there. Another possible package is AbiWord.

@shaansubbaiah
Copy link
Member

@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 ).

@quozl
Copy link
Collaborator Author

quozl commented Mar 12, 2020

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?

@shaansubbaiah
Copy link
Member

Neither have I. Have found it only in the write-activity.

@quozl
Copy link
Collaborator Author

quozl commented Mar 12, 2020

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 xdotool? That would help with this style of feature-decimation bisection.

@shaansubbaiah
Copy link
Member

I haven't used xdotool before, reading the documentation I guess making the mouse reach the top right of the screen and drag down wont be difficult. I have used macro recorders like Autohotkey for windows or autokey for Linux which should also do the trick.

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 list view/ ctrl F2 -> <activity_name> -> enter -> move mouse to top right, drag down, repeat for every activity in the list.

@quozl
Copy link
Collaborator Author

quozl commented Mar 12, 2020

Thanks, but that won't be necessary.

I've tested further with xdotool.

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.

@quozl quozl closed this as completed Mar 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants