GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2024-02-03T17:02:05Zhttps://gitlab.gnome.org/GNOME/gimp-help/-/issues/388Remove / reduce contribution guide from appendix2024-02-03T17:02:05ZTim SabschRemove / reduce contribution guide from appendixThe appendix contains instructions on how to contribute to gimp-help: https://gitlab.gnome.org/GNOME/gimp-help/-/blob/master/src/appendix/contributing.xml
I believe this should be removed or rather rewritten such that it just links to t...The appendix contains instructions on how to contribute to gimp-help: https://gitlab.gnome.org/GNOME/gimp-help/-/blob/master/src/appendix/contributing.xml
I believe this should be removed or rather rewritten such that it just links to the contribution guidelines in gimp-help repository. In my opinion it doesn't make sense to provide contribution instructions in multiple places, since it's duplicated work and easy to forget updating one of the places. For example, the latest additions to the [documentation guidelines](https://gitlab.gnome.org/GNOME/gimp-help/-/blob/master/documentation-guidelines.md) have not been added to the appendix. Since new contributors will unavoidably have to visit the repository, it makes sense to store the contribution guidelines there.
As a side note, I would have expected that the contribution guide in the appendix is about contributing to GIMP, not gimp-help.3.0https://gitlab.gnome.org/GNOME/gvfs/-/issues/667no install guide is included in readme file2023-03-10T09:18:53Zelias tsno install guide is included in readme fileno install guide is included in readme file
You may include that for the latest version (taken from glib).
```
meson _build configure the build
ninja -C _build build GLib
# Become r...no install guide is included in readme file
You may include that for the latest version (taken from glib).
```
meson _build configure the build
ninja -C _build build GLib
# Become root if necessary
ninja -C _build install
```https://gitlab.gnome.org/GNOME/gtk/-/issues/5648gtk_css_provider_load_from_data() doesn't load images with absolute file path2024-03-17T11:08:11ZZoltán Böszörményigtk_css_provider_load_from_data() doesn't load images with absolute file pathThe comment at https://gitlab.gnome.org/GNOME/gtk/-/issues/5628#note_1692435 stated that relative file paths don't work with gtk_css_provider_load_from_data().
Now the problem is that using a CSS with `background-image: url()` with abso...The comment at https://gitlab.gnome.org/GNOME/gtk/-/issues/5628#note_1692435 stated that relative file paths don't work with gtk_css_provider_load_from_data().
Now the problem is that using a CSS with `background-image: url()` with absolute file path doesn't work either.
gtk_css_provider_load_from_file() works with both absolute and relative paths.https://gitlab.gnome.org/GNOME/glib/-/issues/2899Stop using TRUE and FALSE literals in the API reference2024-01-08T00:52:26ZEmmanuele BassiStop using TRUE and FALSE literals in the API referenceThe following discussion from !3216 should be addressed:
- [ ] @pwithnall started a [discussion](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3216#note_1648644): (+1 comment)
> ```suggestion:-0+0
> * Returns: %TRUE if...The following discussion from !3216 should be addressed:
- [ ] @pwithnall started a [discussion](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3216#note_1648644): (+1 comment)
> ```suggestion:-0+0
> * Returns: %TRUE if the file name was replaced, and %FALSE otherwise
> ```
>
> Or if we’re not supposed to use `%` prefixes any more, then backticks and capitalisation would be good, so that the `TRUE` and `FALSE` constants are differentiated from the surrounding prose.
I'd really like to drop `%TRUE` and `%FALSE`: it's not like they have a proper documentation entry anyway. But, more to the point, I think we should actually move to prose, for two reasons:
1. we actually return "truthy" and "falsy" values
1. we explicitly document never to perform direct `gboolean` comparisons with `TRUE` and `FALSE`, only assignments
By telling people we return `TRUE` and `FALSE` we send mixed messages, as it nudges people into doing things like:
```c
if (g_path_buf_set_filename (buf, "foo") == FALSE)
// ...
```
when we *really* don't want that to happen.
I have actually added a section to the [developers documentation style guidelines](https://developer.gnome.org/documentation/guidelines/devel-docs.html#callable-symbols) specifically for that:
> For boolean parameters that describe an action, start the sentence with *if true…* or *if false…*
>
> For boolean parameters that describe a state, use the format *true if…; false otherwise* In these contexts, do not capitalize “true” and “false”, and do not use code style with constants
>
> For boolean return values, use the format *true if…; false otherwise*
In short, turn:
> %TRUE if condition, and %FALSE otherwise
into:
> true if condition, and false otherwisehttps://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/105Add a chapter about ATs2023-01-19T18:24:02ZFederico Mena QuinteroAdd a chapter about ATsThe devel guide has a chapter on toolkits, which serves as a quick reference of links to each toolkit's accessibility-related source code.
I think we should also have a chapter on ATs. Orca, Odilia, [xalia](https://github.com/madewokhe...The devel guide has a chapter on toolkits, which serves as a quick reference of links to each toolkit's accessibility-related source code.
I think we should also have a chapter on ATs. Orca, Odilia, [xalia](https://github.com/madewokherd/xalia), accerciser, dogtail (not an AT but smells like one). What else?Federico Mena QuinteroFederico Mena Quinterohttps://gitlab.gnome.org/GNOME/libsoup/-/issues/321Docs: Improve documentation for content-sniffed signal2023-01-09T20:09:51ZlovetoxDocs: Improve documentation for content-sniffed signalThe docs dont mention any circumstances under which the signal is *not* raised. Which led me to the assumption its always raised. (It even is apparently raised if the Sniffer is *disabled*, i didnt test this)
I just found a server where ...The docs dont mention any circumstances under which the signal is *not* raised. Which led me to the assumption its always raised. (It even is apparently raised if the Sniffer is *disabled*, i didnt test this)
I just found a server where when i make a PUT request, the response received does not raise this signal.
Maybe because there is no content in the response?
Maybe this is so obvious that it needs no mention, but it would have saved me time if it were mentioned.
If this is no documentation issue but a bug, i can supply more information.
Thankshttps://gitlab.gnome.org/GNOME/libsoup/-/issues/320Docs: Improve description for Message.finished Signal2022-12-29T18:44:03ZlovetoxDocs: Improve description for Message.finished SignalThe description in the docs now says
> Emitted when all HTTP processing is finished for a message.
> (After SoupMessage::got-body).
I can reproduce that the finished signal is also emitted when a message is cancelled.
Not sure if a "f...The description in the docs now says
> Emitted when all HTTP processing is finished for a message.
> (After SoupMessage::got-body).
I can reproduce that the finished signal is also emitted when a message is cancelled.
Not sure if a "for example after got-body" is missing here, or if this is a bug.
Either way it would be helpful to know exactly when the signal is raised.https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2014Create and use Software emblem2022-12-29T16:37:23ZPhilip Gotophilip.goto@gmail.comCreate and use Software emblemMany GNOME apps have an emblem that is used for their Matrix room and GitLab page that helps with their branding. It would be nice if Software also has this. Some examples of how that could look like (inspired by app icon colors, generat...Many GNOME apps have an emblem that is used for their Matrix room and GitLab page that helps with their branding. It would be nice if Software also has this. Some examples of how that could look like (inspired by app icon colors, generated with [Emblem](https://apps.gnome.org/app/org.gnome.design.Emblem/)):
<img src="/uploads/5da2851ed203a30d33c4e6bd5145f32a/emblem_software_red_yellow.png" width=64px>
<img src="/uploads/20412045a991bcbf171763ba199b1a15/emblem_software_blue_purple.png" width=64px>
<br>
<img src="/uploads/b9aa68bb81e5acc3bc95a735a5edcd11/emblem_software_green_blue.png" width=64px>
<img src="/uploads/6e48f92f6ba200a154358b62f1d4a4ac/emblem_software_gray_white.png" width=64px>https://gitlab.gnome.org/GNOME/pygobject/-/issues/562Add a guide to get started with development to the gitlab repo2022-12-24T12:37:27ZChristophe Van den AbbeeleAdd a guide to get started with development to the gitlab repoI read the article on the need for extra developers for pygobject.
One of the first things that I noticed once I went to the gitlab is that the readme is very limited.
It might help if we add some **basic info (dependencies, build steps)...I read the article on the need for extra developers for pygobject.
One of the first things that I noticed once I went to the gitlab is that the readme is very limited.
It might help if we add some **basic info (dependencies, build steps)** to make joining development easier.
Similar to the (now probably outdated) [development guide](https://pygobject.readthedocs.io/en/latest/devguide/index.html).
I also believe that it would be better to keep this starter info in this repo (e.g. the readme or a second file) to keep the info more centralized.
I would like to help with this, though I'm new to pygobject from an internal development perspective (I have used it for a few Gtk projects though).https://gitlab.gnome.org/GNOME/librsvg/-/issues/922Test that rsvg-convert's man page actually lists all the options2022-11-28T15:57:12ZFederico Mena QuinteroTest that rsvg-convert's man page actually lists all the options[This talk](https://simonwillison.net/2022/Nov/26/productivity/) has a nice idea about automated documentation testing: for rsvg-convert, have the automated tests ensure that [`rsvg-convert.rst`](rsvg-convert.rst) (the man page) has an e...[This talk](https://simonwillison.net/2022/Nov/26/productivity/) has a nice idea about automated documentation testing: for rsvg-convert, have the automated tests ensure that [`rsvg-convert.rst`](rsvg-convert.rst) (the man page) has an entry for each of rsvg-convert's options.
The test can of course not guarantee that each option has reasonable documentation, but it *can* ensure that each option is mentioned in the man page. Options are listed like this in that file:
```
``-f`` *format*, ``--format=[png, pdf, ps, eps, svg]``
Output format for the rendered document. Default is ``png``.
``--top`` *<length>*
Distance between top edge of the page and the rendered image. Default
is 0.
```
I.e. two backticks, option name, two backticks, and a small paragraph. For the ones like ``--format=[blahblah]``, the test can probably ignore a suffix that starts with `=`, or we can tweak the way that is written in the .rst file.
In `rsvg-convert.rs`, there is already a `build_cli()` function that returns a `clap::Command`. This can be iterated with [`.get_opts()`](https://docs.rs/clap/4.0.27/clap/builder/struct.Command.html#method.get_opts) and tested against the contents of `rsvg-convert.rst`.https://gitlab.gnome.org/GNOME/gimp/-/issues/8824GIMP_PLUGIN_DEBUG requires plug-in name including ".exe" on Windows2022-11-11T13:53:59ZJacob BoeremaGIMP_PLUGIN_DEBUG requires plug-in name including ".exe" on WindowsOnly tested on Windows and the master branch.
For debugging plug-ins we have the environment variable GIMP_PLUGIN_DEBUG which allows you to tell what plug-in you want to debug and what settings for debugging.
According `devel-docs/debu...Only tested on Windows and the master branch.
For debugging plug-ins we have the environment variable GIMP_PLUGIN_DEBUG which allows you to tell what plug-in you want to debug and what settings for debugging.
According `devel-docs/debug-plug-ins.txt` we need to specify the name, in examples it mentions `blur` and `file-psd`, which seems to suggest that the `.exe` extension should not be mentioned. However, trying to run something like this doesn't work until I add `.exe` to the plug-in name:
```
GIMP_PLUGIN_DEBUG=file-jpeg,run,quit gimp-2.99
```
I am not sure what the expected behavior is: either we should update the documentation, or fix the code to exclude the extension.https://gitlab.gnome.org/GNOME/pygobject/-/issues/555Add documentation for calling a virtual method of the super class2022-10-15T00:27:24ZMyoung-serp ShinAdd documentation for calling a virtual method of the super classI am calling a GObject virtual method of the super class like this.
```
class TestWin(Gtk.Window):
def do_map(self):
Gtk.Window.do_map(self)
```
I am not sure this is correct, but it works.
I can't found any documentation on...I am calling a GObject virtual method of the super class like this.
```
class TestWin(Gtk.Window):
def do_map(self):
Gtk.Window.do_map(self)
```
I am not sure this is correct, but it works.
I can't found any documentation on this. I am looking at these documents.
- [GObject.Object](https://pygobject.readthedocs.io/en/latest/guide/api/gobject.html)
- [Objects](https://python-gtk-3-tutorial.readthedocs.io/en/latest/objects.html)https://gitlab.gnome.org/GNOME/gimp/-/issues/8665Add classes in the API to improve documentation2024-03-22T13:09:09ZLloyd Konnekerkonnekerl@gmail.comAdd classes in the API to improve documentationThe API is being changed to be more object oriented.
For example, the GimpImage class was added to libgimp.
(The class already exists in core, the class added to libgimp is a proxy to the core class,
over the wire, more or less.)
There ...The API is being changed to be more object oriented.
For example, the GimpImage class was added to libgimp.
(The class already exists in core, the class added to libgimp is a proxy to the core class,
over the wire, more or less.)
There are several conceptual classes that have not yet been added to libgimp.
For example, GimpContext class is not defined in libgimp.
The symptom or smell is that the API reference document (devel-docs/Gimp-3.0)
has very many "Functions" where the functions seem like they should be methods of a class
in the "Class" section.
The enhancement is to define such classes in libgimp.
The enhancement has these benefits, mainly to the documentation.
1. methods are grouped under a "Class" instead of appearing in the "Functions" section.
2. The class gives a place to document the concept
There are several cases for the classes:
1. Conceptual superclass, where there is no actual inheritance, but there could be.
For example, GimpParamSpec, GimpValue
2. Singleton class, where there are no actual instances in libgimp,
and the class is a proxy to core where there may or may not be an actual instance.
GimpContext
3. Class with only class methods (no instances or instance methods.) GimpMessage
There should be little impact on performance.
It should just add a few types to the GType runtime.
You can think of it as a trick or kludge on the documentation tools,
using the GObject naming conventions.
The defined classes will be empty of data and methods.
The defined classes can be generated by a tool in Python.
I have done some experiments and can submit an MR.
Its not as rosy and simple as it sounds above.
For example, GimpMessage doesn't work without changing the API a little,
and GimpParamSpec may require changing to actual inheritance of a superclass.
Related is !740, to add GimpResource class to libgimp.https://gitlab.gnome.org/GNOME/glib/-/issues/2765Descriptions for GSourceFuncs structure's members do not appear in generated ...2022-10-11T20:18:03ZLuca Bacciluca.bacci@outlook.comDescriptions for GSourceFuncs structure's members do not appear in generated docsIn https://docs.gtk.org/glib/struct.SourceFuncs.html, under the **Structure members** paragraph, there's no description.
Actually those members are documented, see https://gitlab.gnome.org/GNOME/glib/-/blob/2.74.0/glib/gmain.h#L102-132In https://docs.gtk.org/glib/struct.SourceFuncs.html, under the **Structure members** paragraph, there's no description.
Actually those members are documented, see https://gitlab.gnome.org/GNOME/glib/-/blob/2.74.0/glib/gmain.h#L102-132https://gitlab.gnome.org/GNOME/gsound/-/issues/5Link to documentation in README.md returns 4042022-09-08T18:41:30ZAlexander LebenLink to documentation in README.md returns 404In [README.md+12](https://gitlab.gnome.org/GNOME/gsound/-/blob/master/README.md?plain=1#L12) the link to the documentation points to https://developer.gnome.org/gsound/stable - but this returns 404 when I try to access it. Also I was una...In [README.md+12](https://gitlab.gnome.org/GNOME/gsound/-/blob/master/README.md?plain=1#L12) the link to the documentation points to https://developer.gnome.org/gsound/stable - but this returns 404 when I try to access it. Also I was unable to find the new location within https://developer.gnome.org.https://gitlab.gnome.org/GNOME/gimp/-/issues/8571Export As exports to incorrect file name for file with changed name.2022-09-07T17:27:43ZJohn M. AstellExport As exports to incorrect file name for file with changed name.### Environment/Versions
- GIMP version: GIMP 2.10.32 (revision 1)
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->Installer from gimp.org
- Operating System: <...### Environment/Versions
- GIMP version: GIMP 2.10.32 (revision 1)
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->Installer from gimp.org
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->Windows 10
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->Open an exist GIMP file. Revise it and save it with a new name. Export it to PNG. The Export Image dialog will use the base name of the original file for the PNG, not the new base name.
Example: Open Sample1.xcf, Save As Sample2.xcf, then Export As png, dialog shows Sample1.png as default name, not Sample2.png
This has happened to me repeated, and in earlier versions of GIMP as well as 2.10.32. If I don't notice the wrong default name, I end up writing over an existing PNG with with the wrong image.
It does not seem to always use the wrong default name for export, but usually does.
I expect this is not restricted to PNG exporting, but I have not tried other exporting to other file formats.
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)-->Randomly
Reproduction steps:
1. Open an existing GIMP xcf file. Example: Sample1.xcf
2. Revise it and save it (Save As) with a new name. Example: Sample2.xcf
3. Export it (Export As) to PNG. Dialog will appear using original file as base name, not new base name. Example: Sample1.png Should be: Sample2.png
…
Expected result: Default name in dialog should use new base name.
Actual result: Default name in dialog use original base name.https://gitlab.gnome.org/GNOME/gdm/-/issues/813Documentation is too old2022-08-28T20:32:41ZSeong-ho ChoDocumentation is too oldManual currently says that it describes version 2.x of GDM and GConf-based settings.
There is also many missing latest things such as theming, styling for GDM 3.x.
I do not know how and why GDM can be shows another appearance by editing...Manual currently says that it describes version 2.x of GDM and GConf-based settings.
There is also many missing latest things such as theming, styling for GDM 3.x.
I do not know how and why GDM can be shows another appearance by editing some scripts such as css,
some of distribution does not basically provide their own style-sheet file,
which helps made easy to change style of GDM greeter screen.
another number of some distributions handle their own filesystem for GDM
and they distributions show it's own image and many color.
many unofficial things should not let be it as is, it would better to be documented.
who someone can update obsolete manual for all of users, all of the world?
I really would like to appreciate in advance.https://gitlab.gnome.org/GNOME/libsoup/-/issues/288Migration guide doesn't explain what to do about XML-RPC support2022-07-06T16:23:31ZBastien NoceraMigration guide doesn't explain what to do about XML-RPC supportIt just says "This is a list of APIs that have been removed: XML-RPC support."
(the SoupSocket line could also do with some explanation)It just says "This is a list of APIs that have been removed: XML-RPC support."
(the SoupSocket line could also do with some explanation)https://gitlab.gnome.org/GNOME/gtk/-/issues/5023Documentation lies about gtk_list_box_drag_highlight_row()2022-07-02T15:13:02ZAntónio Fernandesantoniof@gnome.orgDocumentation lies about gtk_list_box_drag_highlight_row()The GTK4 documentation still says the same as in GTK3:
> The row will also be unhighlighted when the widget gets a drag leave event.
https://docs.gtk.org/gtk4/method.ListBox.drag_highlight_row.html
However, this is no longer true sinc...The GTK4 documentation still says the same as in GTK3:
> The row will also be unhighlighted when the widget gets a drag leave event.
https://docs.gtk.org/gtk4/method.ListBox.drag_highlight_row.html
However, this is no longer true since commit aa276a181e33f92915957ed74c9ff905675e70fa
GtkPlacesSidebar still relies on the documented behavior ─ drag highlight sticks around.
Either the documentation must be fixed or a GtkDragControllerMotion must be added.
Is `gtk_list_box_drag_highlight_row()` likely to be deprecated?https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/69Document the XML interfaces2022-08-17T00:46:49ZFederico Mena QuinteroDocument the XML interfacesHow to document DBus XML: see the ["XML Comments" section in the DBus API Design Guidelines](https://dbus.freedesktop.org/doc/dbus-api-design.html#documentation).
It seems that the little documentation that there was in the `didl` files...How to document DBus XML: see the ["XML Comments" section in the DBus API Design Guidelines](https://dbus.freedesktop.org/doc/dbus-api-design.html#documentation).
It seems that the little documentation that there was in the `didl` files (see 5ff3694f) was lost when those files were removed in favor of the more up-to-date XML. Maybe we can rescue the useful docs from there?
Documentation progress:
- [x] Accessible
- [x] Action
- [x] Application
- [x] Cache
- [ ] Collection
- [ ] Component
- [ ] DeviceEventController
- [ ] DeviceEventListener
- [ ] Document
- [ ] EditableText
- [ ] Event
- [ ] Hyperlink
- [ ] Hypertext
- [ ] Image
- [ ] Registry
- [ ] Selection
- [x] Socket
- [ ] TableCell
- [ ] Table
- [ ] Text
- [ ] Value