Bug#861850: add pause shortcuts to GNOME Nibbles
Hi! New upstream co-maintainer here. This functionality is currently being worked on (both the “Pause” and the “Ctrl-P” shortcuts will be added), and will appear in the 3.38 stable release, planned for September. Thanks for the issue report! and please use the GNOME Gitlab instance[1] for that kind of bugs, it’s more easy to check for us developers. ;·) [1] https://gitlab.gnome.org/GNOME/gnome-nibbles/issues Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#715226: worms not cleaned on new game
Hi! New upstream co-maintainer here. I’ll assume this bug is not anymore present in current releases of the game. If you encounter something like that again with a more recent release, please report them to the GNOME Gitlab instance[1]. Thanks! [1] https://gitlab.gnome.org/GNOME/gnome-nibbles/issues -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#788884: gnome-tetravex: Game can win itself
Hi, I’m the (new) upstream maintainer of this application. I’m a bit surprised by the exact behavior you describe, but anyway, there was clearly some problems, with the game generating solved puzzles notably. ^^ So I’ve immediately started to hack a bit on it, fix some small things here and there, and do some small improvements. Related to this bug report: * the game does not generate solved puzzles anymore (or it’s a bug :·D); * when the game is solved on the right (per previous point, by the player), an arrow appears to move all tiles to the left, and game is said solved if the player presses this arrow. The “flash” that has is described looks like something that always exists in the “master” development branch, but if it’s the same thing, I consider it is a deeper bug (Gtk+, probably); a not-updated cache image of the (previous game) board is loaded when the dialog pops up. Hopefully, I’m working on a workflow of the game that avoids showing the dialog[1], and so where the bug is solved; if I’m not hit by a bus, it will be pushed before the next stable 3.36 release. [1] https://gitlab.gnome.org/GNOME/gnome-tetravex/issues/3#note_610513 Thanks for the issue report, I hope the 3.36 release (coming in March 2020) will satisfy yourself. :·) -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#873359: Gdk-WARNING "drawable is not a native X11 window"
Hi, upstream maintainer here. This was probably (as in other games) caused by libcanberra, the library used for emitting the sounds. It has been replaced by GSound before the 3.34 release; so if you confirm you cannot reproduce anymore with this release, the bug should be closed. Anyway, thanks for the issue report. :·) -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#727802:
Hi, I’m the upstream maintainer of Iagno. tldr: It’s fixed. I imagine the hang was “just” caused by the AI calculations. The AI has always been bad, until now. It was going (in hard level) in depth 6, calculating millions of positions, without really having goods results. I improved greatly the speed of this AI first (see unstable release 3.33.2), and then introduced a new AI that is mostly as hard (a bit harder), but only going in depth 3, so with only some thousands positions to estimate. It will be available in the next stable release, 3.34, in October. Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#778744: dconf-editor crashes by selecting an option
In fact, 3.22 have been released in October 2016, so it should be okay anyway. And as 3.20 was really different, I might not have backported a fix. Well, it’s fixed, that’s probably the important information. :) -- Arnaud Bonatti téléphone : +33(0)6 50 57 23 49 courriel : arnaud.bona...@gmail.com
Bug#784007: dconf-editor: Add reset function for entire dirs and entries
Upstream maintainer of Dconf Editor here. > A function to delete/reset entire dirs should be implemented. > Like the command line function: > "dconf reset -f /path/to/dir/" That function has been implemented as part of the new design, and added in May 2016[1], so available since the stable release 3.22. There’re of course no upstream plans to backport this function to previous releases, so I think we’re done there. [1] https://git.gnome.org/browse/dconf-editor/commit/?id=5fb045a1659688c7e024148cc8b3efb256593025 Thanks for the bug report! Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#778744: dconf-editor crashes by selecting an option
Upstream maintainer of Dconf Editor here. > dconf-editor crashes after selecting the option "org-> gnome -> lightsoff" Thanks for this bug report! (and thanks also for the workaround in Lightsoff). This bug has been fixed some time ago in Dconf Editor itself. I cannot find the exact commit, but I think it was around May 2016, so for now the only stable release with the fix should be 3.26 (there hasn’t been a 3.24). If someone has a 3.22 running, it might be easy to test, as the bug was 100 % reproducible; install “lightsoff” and try to browse to “/org/gnome/lightsoff/level”. -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#784008: dconf-editor: Show full path of current selected entry
Upstream maintainer of Dconf Editor here. > dconf-editor should show the full path of the current entry somewhere. For > example using a status bar at the bottom or some simple text label at the > top (right below the menu). Or as an extra field below the name-value-editor > where the other key infos are shown. This bug as been fixed by a new design, starting with the 3.22 release in (March?) 2016. The complete path is now displayed in a pathbar, in the headerbar of the window. As all releases before 3.22 are not in upstream scope anymore, we’re more or less done here. :) -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#813530: UTF8 characters are not rendered correctly
Upstream maintainer of Dconf Editor here. GLib.Settings/dconf doesn’t have a special storing type for URIs, the key you see has a string type, and Dconf Editor should have no problem to display strings that use UTF-8. The hard-to-read encoding is caused by how the application GNOME Screenshot stores its own settings. I don’t think that would really be a good idea for Dconf Editor to change the displayed encoding of keys, that could cause too many problems. So the bug should be reported against GNOME Screenshot instead. Having a URI storing type might also happen, but in a really distant future. Hope you understand! -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#702190: dconf-editor warnings
Upstream maintainer here. In the initial comment of the bug report, there are two different warnings. Both of them were displayed (I think) because historically (until release 3.20) Dconf Editor was using a custom schemas parser. The first: ** (dconf-editor:29681): WARNING **: dconf-schema.vala:330: Unknown property on , extends was a bug of Dconf Editor, as that property is valid. The second: ** (dconf-editor:29681): WARNING **: dconf-schema.vala:401: Unknown tag looks more weird to me, as the tag should never have been accepted when compiling the schema (see indicative DTD[1]). If you know what schema was causing that, please fix it and report a bug to glib-compile-schemas if it accepts even now to compile it. [1] https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gschema.dtd Anyway, as Dconf Editor uses GLib.Settings for two years, the warnings shouldn’t be displayed anymore. Are you sure 3.22 has been concerned at one point here? -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#648002: no way to add keys
Upstream maintainer here. That will probably never happen, because that’s not wanted. Applications should not depend on dconf directly, but should instead use a GLib.Schema that defines which keys could be used, and so makes manually adding keys meaningless. There has been a concern in all stable releases until now because of relocatable schemas, that were not mapped to their paths; that is solved (imperfectly, but people shouldn’t notice) in the future 3.28, that will be release in March 2018. The same problem will happen again with the growing use of Flatpak (or similar technologies), but the solution should be and will probably be (as I’m the maintainer…) to wait until a real fix is found, instead of allowing to add dconf keys manually. Hope you’ll understand this point of view. :) -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
Bug#704164: command line options
Upstream maintainer here. Dconf Editor will have such command-line options in the future 3.28, to be released in March 2018. You’ll be able to open a specific path: $ dconf-editor /ca/desrt/dconf-editor # fallback on /ca/desrt/dconf-editor/ $ dconf-editor /ca/desrt/dconf-editor/ $ dconf-editor /ca/desrt/dconf-editor/saved-view ; to open a specific schema with fixed path: $ dconf-editor ca.desrt.dconf-editor.Settings $ dconf-editor ca.desrt.dconf-editor.Settings saved-view ; and to open a relocatable schema: $ dconf-editor ca.desrt.dconf-editor.Bookmarks:/ca/desrt/dconf-editor/ $ dconf-editor ca.desrt.dconf-editor.Bookmarks:/ca/desrt/dconf-editor/ bookmarks ; all that with completion available (even if that is a little fragile). Hope that will help. :) -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com
