Re: X wants to inhibit shortcuts on Wayland

[Jonas Ådahl]

On Wed, Dec 06, 2017 at 09:34:00PM +, Michael Aquilina wrote:
> I have noticed an application that I currently maintain, show this
> message after pressing the keyboard shortcut that activates it.
> 
> "Synapse wants to inhibit shortcuts"
> 
> You are given the choice to allow or deny, but both dont seem to do
> anything since the message pops up when the key combination is pressed
> again.
> 
> The project is written in Vala and can be found here
> https://github.com/MichaelAquilina/synapse-project
> 
> Is there something that I need to update to prevent this message from
> showing when using Wayland?

Hi,

In gtk+-3.22, the Wayland backend tries to guess whether the application
wants to actually inhibit shortcuts (e.g. if it's a virtual machine
viewer or remote desktop viewer etc). It does this by assuming that if
you explicitly grab the keyboard only on a toplevel window, it
translates this into a "inhibit shortcuts" request which eventually
results in the dialog you see.

The way to avoid this is to not take a keyboard-only grab on a
toplevel window.

However, looking at the available gtk+ 3.22.x releases, it seems that a
the "toplevel only" restriction in the above mentioned guessing
machinery is not available in any release; so check whether your
distribution includes the patch "gdk/wayland: Restrict shortcut
inhibition to keyboard grabs on toplevels".


Jonas

> 
> Mike
> 
> -- 
> Michael Aquilina
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[Alberts Muktupāvels]

On Wed, Jan 24, 2018 at 12:22 AM, Marco Trevisan (Treviño) 
wrote:

> Il 22/01/2018 14:34, mcatanz...@gnome.org ha scritto:
> > On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
> >> Were you actually using JHBuild to run integrated system components
> >> (gnome-shell, gnome-session)? If so, how? I was not aware that that
> >> was even possible nowadays.
> >>
> >> When developing these components,
> >
> > Sorry, trying again
> >
> > When developing components like gnome-shell and gnome-session, I've
> > found myself working in a VM and installing directly into /usr/bin. It's
> > the only way I'm aware of that works. (You can try /usr/local, but then
> > you have to hack executable paths in several projects)
>
> As said it's not like that, I'm just running everyday this to run
> gnome-shell
>
>   jhbuild run env XDG_SESSION_TYPE=wayland \
>   XDG_RUNTIME_DIR=/tmp/jhbuild-runtime \
>   dbus-run-session gnome-shell --wayland \
>--display-server
>
> Same works when using X11 or gnome-session (just replacing the command).
> So it looks like there's nothing similar to that yet.
>
> Maybe JHBuild could be a bst client for building only?
>

Seems that everyone has their own usage...

I have multiseat setup. On my main seat I do development and testing is
done on second seat. I have configured JHBuild to make it possible to build
multiple versions. For example `jhbuild build` will build/rebuild current
development version - 3.28 and `VERSION=3.26 jhbuild build` will rebuild
3.26 modulset. On second seat I can easily login in 3.28 session and if
needed also in 3.26.

I regularly do `jhbuild build` and/or `VERSION=3.26 jhbuild build` to
update with newest changes for development and last stable version. I also
use `VERSION=3.26 jhbuild checkbranches -b gnome-3-26` to make sure that
stable version build from correct branch. And mostly I do update jhbuild
modulesets if change is simple enough that I am sure that it is correct and
wont break anything...

Mentioned at-spi2-core "problem". I am pretty sure that I have done
`jhbuild done` in November and I don't remember that build has been broken
because of at-spi2-core. Any chance that jhbuild simply has re-used
previously generated configure file?:
https://git.gnome.org/browse/jhbuild/tree/jhbuild/modtypes/autotools.py#n111

To me this looks like tool that was able to do task x is replaced with tool
that is supposed to do y... Following this thread it clear that BuildStream
will never provide same functionality. So how developers are supposed to
test fixes/changes to apps? I could easily restart re-built app in jhbuild
session or logout and login to test bigger changes. How am I supposed to
achieve  something similar with BuildStream? Will I need to build VM
images, restart VM and then test my changes?

Sorry if that already is posted somewhere, but is there at least some kind
of migration guide/tutorial?

-- 
Alberts Muktupāvels
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[Treviño]

Il 22/01/2018 14:34, mcatanz...@gnome.org ha scritto:
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
>> Were you actually using JHBuild to run integrated system components
>> (gnome-shell, gnome-session)? If so, how? I was not aware that that
>> was even possible nowadays.
>>
>> When developing these components,
> 
> Sorry, trying again
> 
> When developing components like gnome-shell and gnome-session, I've
> found myself working in a VM and installing directly into /usr/bin. It's
> the only way I'm aware of that works. (You can try /usr/local, but then
> you have to hack executable paths in several projects)

As said it's not like that, I'm just running everyday this to run
gnome-shell

  jhbuild run env XDG_SESSION_TYPE=wayland \
  XDG_RUNTIME_DIR=/tmp/jhbuild-runtime \
  dbus-run-session gnome-shell --wayland \
   --display-server

Same works when using X11 or gnome-session (just replacing the command).
So it looks like there's nothing similar to that yet.

Maybe JHBuild could be a bst client for building only?


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME/Librem 5 Diner Before FOSDEM

[Adrien Plazas]

Hi!

The Librem 5 team at Purism would like to meet GNOME folks at FOSDEM 
and to have a chat about the phone. The GTK+ hackfest is going to end 
on Friday 2, maybe we could organize a diner together that day?


Cheers,
Adrien Plazas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-shell 3.26 fedora 27 crashes all the time

[Treviño]

Hey Stephen,

Il 10/12/2017 18:58, Stephen Adler ha scritto:
> On 12/10/2017 06:49 PM, Andre Klapper wrote:
>> Hi Stephen,
>>
>> On Sun, 2017-12-10 at 18:01 -0500, Stephen Adler wrote:
>>> I know this is not the place to post this message, but I'm desperate.
>> Please feel free to report a bug in GNOME Bugzilla:
>> https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/Guidelines
>>
> Thanks Andre, I'll submit the bug to GNOME Bugzilla.

And please get a stacktrace (better after you've installed the debug
symbols in fedora) and a gjs dumpstack following this wiki:
  https://is.gd/wiki_gnome_shell_crash_debug
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Issue in gsd-media-keys when using power standby button of usb device ...

[mhoyer . gnome . list]

Hello,

I'm using a usb keyboard (microsoft wireless) and a usb remote control 
for controlling my home cinema device (earlier a lenovo notebook, now a 
minnow board max). The device is put into S3 (suspend to ram) when it is 
not used. I can wake it up again by pressing the suspend button of the 
keyboard again. However, in most of the times, the system goes back into 
suspend directly again. I've to repeat this some more times until the 
device suddenly stays active.


I debugged down the issue a bit more by enabling the verbose mode of 
gsd-media-keys. It looks as if the gsd-media-keys process is detecting 
the press of the suspend key which has been used to wake up the system 
and with it he is putting the system back to standby again. Following 
line in the logs points me to this assumption:


Nov 20 21:07:18 wohnzimmer gsd-media-keys[1482]: Received accel id 114 
(device-id: 3, timestamp: 241835, mode: 0x1


I see this log line twice. Once when I put the system into standby and a 
second log when I activated it back with the key.


-> Is this issue known to someone?
-> Can someone confirm to see this issue as well? Should be reproducable 
with any usb keyboard with a standby key.


If yes. What would be a good solution to overcome this issue?

I'd suggest the following. Since gsd-media-keys is already connecting 
with systemd-logind, it's easy to register for signals for standby and 
reactivation. One could implement a sort of "Ignore standby keys 1s 
after wakeup" logic.


What do you think? Other ideas?

I'd provide a patch once it is clear that the issue is actually an issue 
and we agree on an appropriate solution.


Thx in advance.

Marko Hoyer


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

X wants to inhibit shortcuts on Wayland

[Michael Aquilina]

I have noticed an application that I currently maintain, show this
message after pressing the keyboard shortcut that activates it.

"Synapse wants to inhibit shortcuts"

You are given the choice to allow or deny, but both dont seem to do
anything since the message pops up when the key combination is pressed
again.

The project is written in Vala and can be found here
https://github.com/MichaelAquilina/synapse-project

Is there something that I need to update to prevent this message from
showing when using Wayland?

Mike

-- 
Michael Aquilina
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: g_object_ref() now propagates types

[Paul Davis]

On Fri, Dec 8, 2017 at 6:26 AM, Philip Withnall 
wrote:

> Hi all,
>
> We just landed a patch in GLib which propagates the type from the
> argument of g_object_ref() to its return type:
>
> https://git.gnome.org/browse/glib/commit/?id=3fae39a5d
> https://bugzilla.gnome.org/show_bug.cgi?id=790697
>
> The idea here is that it will catch invalid implicit casts which the
> compiler otherwise wouldn’t have noticed because g_object_ref()
> previously operated entirely on gpointers. This will eliminate a whole
> class of bugs: bugs which are unlikely to exist, but are a complete
> pain to track down if they do.
>

​Great work. Another 3 or 4 or 200 of these and we'll almost have a C++
compiler!

tongue firmly and warmly in cheek :))) ​
​
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: paste.gnome.org

[Gabriel Ivașcu]

On Mon, Dec 4, 2017 at 9:36 PM,   wrote:
> paste.gnome.org is great, except for:
>
> "You must select a language other than 'text' for this paste."
>
> where is the source code? Can we get rid of this?

Another thing that I find mildly annoying is that paste.gnome.org
doesn't remember your login for more than a few hours. I've tried it
in different browsers, and it's the same: I have to log in again
almost every time I visit the website.

Gabriel
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Making media key management more user friendly.

[Zephaniah E. Loss-Cutler-Hull]

Media keys in gnome are handled through a combination of settings, and
the media-keys plugin to gnome-settings-daemon.

They fall into a couple of different groups:

Media keys that are configured with a default setting, and which the
user can change.  This includes things like logout, eject, home,
control-center, volume-mute, volume-up/down, etc.

Media keys which are hard coded to a special key setting.  This includes
keys like 'XF86TouchpadToggle', (and On and Off), XF85AudioRewind,
XF86PowerOff, XF85RFKill, and other such things.

Media keys which have both a hard coded special key setting and a user
controlled setting, this includes things like
'screensaver'/'XF86ScreenSaver'.  There are not a lot of settings that
fall into this group.

Media keys which have a hard coded key value that you can actually type
on a standard keyboard, or which you can type with a somewhat
non-standard keyboard or a special keymap:

MIC_MUTE_KEY has F20 and the special name 'XF86AudioMicMute'.

HELP_KEY has a configurable key setting 'help', but also 'F1'.

ROTATE_VIDEO_LOCK_KEY has 'o'


My contention is that the last group simply shouldn't exist, instead all
three options should be given setting names where they don't exist, and
the defaults should be set to the current hard coded values.

('help' is the only one with an existing setting, and that has no
current default.  I have not checked how things behave, but if we need
to add a second default setting just to get upgrading users to have it I
still consider that a better solution.)

That is a fairly easy change, it only impacts 3 settings.


With that said, I also believe that we should provide key binding
settings for every other media key option that lacks one.  If someone
doesn't have a keyboard with a button for mic mute, they should be able
to bind something.

I would be happy to write and provide patches for these changes,
assuming that there is some support for the idea.

Regards,
Zephaniah E. Loss-Cutler-Hull.



signature.asc
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: All stable flatpak builds moved to flathub

[Tirifto]

Is it of no concern that the main repository through which GNOME is to
distribute all stable flatpaks (Flathub) contains several malicious,
non-libre programs? (With nothing reminiscent of radical separation
from the libre ones, too, from what I’ve noticed.)

Regards
// Tirifto

> The goal of flathub (https://flathub.org/) is to be a single location
> where you can find builds of the latest stable version of linux
> desktop applications, ideally maintained by the upstream author. That
> way the experience for flatpak users is much nicer, just add one
> remote and you can then find all apps via e.g. gnome-software.
> 
> In line with this, I last week moved all the remaining applications
> from the gnome-apps-nightly stable branch to flathub and disabled
> further builds from the stable branch. gnome-apps-nightly is still
> used for the semi-automatic nightly builds from git master though.
> 
> This means that in the future, stable releases that wants to be
> flatpaked should be built via flathub. I wrote some docs on how do to
> this on the flathub wiki:
> 
>   https://github.com/flathub/flathub/wiki/Maintaining-an-application-
> on-flathub
> 
> This week mail out all the maintainers of the current apps and ensure
> they have access to the new repos. If anyone wants to add new apps to
> flathub, the instructions for that are here:
> 
>   https://github.com/flathub/flathub/wiki/Submission-Guidelines

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Suggestions for librsvg's COMPILING.md

[David Michael]

Hi,

In librsvg's COMPILING.md, there are two inconsistencies around cross-compiling.

  * The option --target=TRIPLE is passed to cargo, not --host.
  * RUST_TARGET_PATH should be set for make, not configure.

An alternative to writing a target JSON file could be to override
CARGO_TARGET_ARGS and RUST_TARGET_SUBDIR (if RUST_LIB used the
variable) when a compatible builtin target is available.  For example:

./configure --host=x86_64-redhat-linux-gnu ...
make CARGO_TARGET_ARGS=--target=x86_64-unknown-linux-gnu ...

Is that worth maybe adding a --with-rust-target option to configure
that defaults to $host when cross-compiling?  (I didn't think of that
for the cross-compiling patch since I was only building for a new
target with no builtin support.)

As a side note, here is one way to generate a JSON spec from a similar
builtin target.  It may not be helpful including this in documentation
since it uses unstable options, so I'm just throwing it out there.

RUSTC_BOOTSTRAP=1 rustc -Z unstable-options \
--print=target-spec-json \
--target=x86_64-unknown-linux-gnu |
sed -e /is-builtin/d -e s/unknown/redhat/g \
> "${RUST_TARGET_PATH%%:*}/x86_64-redhat-linux-gnu.json"

Thanks.

David
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro]

On Mon, Jan 22, 2018 at 3:12 PM, Bastien Nocera  
wrote:

Or c) nobody's needed to recompile at-spi-core2 because it hasn't
changed in significant ways in years and the distro provided versions
work just fine.

My at-spi-core checkout dates back from 2013.

I, and I suspect a majority of folks that hack on more than a few
modules, usually install the build dependencies from my distribution,
and then try to compile the application or library ("buildone") that I
want to work on. glib and gtk+ are probably the only 2 libraries that 
I

recompile at least once a week.


Hi,

It sounds like you never use 'jhbuild build', but instead manage your 
dependencies manually and use 'jhbuild buildone'. Although I wouldn't 
recommend that to newcomers, if that works for you, then great. But if 
you never use 'jhbuild build' then you're also not using the 
dependencies specified in the modulesets at all, so I don't think this 
change would even affect you, except when you want to build a new 
module that's not currently in the modulesets, which is easy to add.



Furthermore, you're the one that asked developers switching to meson
not to change the jhbuild moduleset until a tarball release with meson
existed, so you could run the releases.

Damned if you do...


Hm, maybe my request was too confusing. Yes, changing the moduleset is 
an inconvenience for us if there's no new tarball release come GNOME 
release day. But that's not a good reason to leave JHBuild broken. It's 
a reason to make a new tarball release.


The same problem actually still exists with BuildStream. The solution 
is to just pay special attention to the GNOME release cycle when you're 
switching gnome-build-meta to use the new build system. This is a 
one-time issue, so not a big deal IMO.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[Tristan Van Berkom]

Hi all,

This will be a long email, so TL;DR:

   o At this time you can keep using JHBuild for these few cases where
 testing is very difficult, you can even do so indefinitely.

   o For these few modules who dont benefit directly at development
 time from the release team's official build metadata, the effort
 should be very low.

   o We will have a way for you to test core components soon, and it
 will be superior in many ways, but will inevitably lose *some*
 of the convenience which JHBuild offered.


On Mon, 2018-01-22 at 14:31 -0600, mcatanz...@gnome.org wrote:
> > On Mon, Jan 22, 2018 at 12:56 PM, Carlos Soriano  
> wrote:
> > What's the workflow for those before a proper solution is done? Or 
> > are the developers of those modules expected to maintain JHbuild on 
> > the meantime?
> 
> Thanks Carlos; this is an important question. Let me provide a bit more 
> context for our decision to stop maintaining JHBuild now, even though 
> BuildStream is not yet be usable for running some modules.
> 
[...]

   I'd like to thank Michael for chipping in here while I was enduring
a travel itenerary which takes over 20 hours all told, and recovering f
rom it's side effects.

There have been some discussion about the pain points for testing the
few, albeit very important and central components of the GNOME UX on
your own developer laptop.

First of all, to avoid blowing things out of proportion, we are talking
about the maintenance of a few configure arguments for a handful
modules here. These modules are not easily verifiable and testable on
your laptop using BuildStream, *yet*.

Yes the release team demands that you update the gnome-build-meta
repository for these for our purposes of delivering integrated builds
and releases of GNOME as a whole, and these few core modules might not
yet be benefiting from those builds as developers - but these configure
arguments don't change immensely often, and whatever work the release
team did before in terms of maintaining them (mostly this is manually
checking the status of tarball converted builds at release time), is
not benefiting your experience as a developer on these modules
anyway.

A better way to test an integrated GNOME is coming, but for the time
being:

  Please update the gnome-build-meta repository to help us ensure that
  it's building. And feel free to continue to use JHBuild modulesets
  without those modulesets being considered in the integrated releases.


With that out of the way, in the long term; yes it's also fine if you
continue to use JHBuild for your own development workflow preferences,
but I am very driven to convince you that ultimately we will have a
better way of doing things both for the release team and for all GNOME
developers, and these visions should be aligned. So, I'll try to
alleviate some of your concerns regarding the long term picture of
development.


To start, here is a general outline of how the tooling differs in their
core values, and how these tools are effectively crossed in purposes:


   On JHBuild
   ~~
   JHBuild is a tool which prioritizes developer convenience,
   attempting to build the "latest of GNOME" on top of a loosely
   defined abstract system.

   Various tricks are in place in the GNOME modulesets, for instance
   modules which we *can* build, but avoid trying if we have the chance
   to determine that a local pkg-config file is found for it.

   The result is that you can mostly test your software on your
   machine, and for the majority of high level apps, this is good
   enough for the developer to test and cover the majority of use cases
   in manual testing.


   On BuildStream
   ~~
   BuildStream is a tool which puts determinism of builds first and
   allows absolutely no room for unknown factors contaminating your
   integrated build result.

   Various safe guards are put in place to ensure that you are never
   building or testing a result that cannot be reproduced exactly on
   another laptop.

   The result is that you are never uncertain about which module
   changed from one build to the next when a bug was introduced,
   and you are never writing software against the old version of
   a changed component which happens to be lying around on your
   system, causing last minute pain at release time.

   Whether GNOME is broken or is working well, you always know that
   the integrated result of a GNOME build is exactly what you expect
   it to be.


I should also point out that from a release team perspective, our
priority has to be delivering an integrated GNOME where it's components
always work well with eachother at release time, not a hand full of
components which happened to work well in their respective maintainers
hacked distro setups.


Developers in FOSS have historically filed the integration work under
the "not my problem" category, and the result of that is a lot of back
and forth with the downstream distros which ensues