AddAT sounds odd as a function name to me. How about "RegisterAT" instead?
I was going for something similar to existing D-Bus nomenclature, but I am in no way sold on any name.
Would it be useful to include some kind of categorization
Probably, yes; we may also want to have a human readable name for the AT, unless we mandate that the identifier must match a desktop file.
Possible changes:
ListATs
could return a dictionary of identifiers, connections, in case we want toolkits to watch ATs directlyThe identifier should probably be defined in terms of reverse DNS, like org.gnome.orca
, as well.
The shared bus topology mandates that every toolkit start shouting into the void, even if there's nothing on the other side. This ends up being expensive, as toolkits must register accessible objects, update states, and emit signals even if nothing is going to use them. We cannot enumerate the list of clients on the accessibility bus, because we have no mechanism to determine if a peer is an application or an actual assistive technology.
Ideally, ATs should register themselves on the Registry, and the Registry should provide an API to query the presence of ATs on the bus; if no ATs are available, toolkits could delay the initialization of the accessibility data. If an AT registers on the bus, the Registry should emit a signal, causing the toolkit to present itself and submit its current state.
A rough sketch of the API:
<?xml version="1.0" encoding="UTF-8"?>
<node>
<interface name="org.a11y.atspi.Registry">
<!--
AddAT:
@identifier: a unique identifier for the assistive technology
Registers a new assistive technology for the given identifier.
If an assistive technology with the same identifier has already
been registered, this method raises a D-Bus error.
The registry will associate the sender id of this method with
the identifier, and will automatically remove the identifier
once the sender disappears from the bus.
-->
<method name="AddAT">
<arg direction="in" name="identifier" type="s"/>
</method>
<!--
ListATs:
Lists all assistive technologies registered.
Returns: an array of identifiers
-->
<method name="ListATs">
<arg direction="out" name="identifiers" type="as"/>
</method>
<!--
ATChanged:
@identifiers: a list of identifiers
This signal is emitted every time the list of assistive technologies changes.
-->
<signal name="ATChanged">
<arg name="identifiers" type="as"/>
</signal>
</interface>
</node>
This was erroring on recent GCC because struct heap_dict
is smaller than
the publicly provided size (guintptr[16]) in the header for GVariantDict.
../../../../Projects/glib/glib/gvariant.c: In function ‘g_variant_dict_new’:
../../../../Projects/glib/glib/gvariant.c:3981:8: warning: allocation of insufficient size ‘32’ for type ‘GVariantDict’ {aka ‘struct _GVariantDict’} with size ‘128’ [-Walloc-size]
3981 | dict = g_slice_alloc (sizeof (struct heap_dict));
| ^
Emmanuele Bassi (33251eb8) at 18 Mar 14:50
Emmanuele Bassi (33251eb8) at 18 Mar 13:48
Add note about accessibility in GTK 4.14
... and 55 more commits
I'm not super on board with adding back the app menu in a generic code path; maybe we need something a bit more magic, like a resource path that gets automatically loaded. That would prevent programmatically built menus, but at the end of the day apps on macOS are used to XML/plist files.
Re-exporting the generic app menu API also brings back publishing the menu over the D-Bus session, which is somewhat more interesting for Linux/Unix-like systems, in case we end up with way to include that menu in the desktop actions and/or background applications UI.
Just opening a thread so we remember before merging, if we decide to merge.
GDK_AVAILABLE_IN_4_16
GDK_AVAILABLE_IN_4_16
Thanks!
In Debian and Ubuntu we are currently transitioning 32-bit architectures (aside from i386) to 64-bit time_t. As part of this, I found that pygobject fails on armhf (i.e. 32-bit ARM) in this test case:
def test_time_t_in(self):
GIMarshallingTests.time_t_in(1234567890)
A bit of gdb makes it clear that this is confusion about how to pass the first argument. A bit of grepping finds this line in giscanner/ast.py:
type_names['time_t'] = TYPE_LONG
which is obviously a bit of a red flag in this context.
Changing this definition to TYPE_INT64 makes the pygobject test pass but clearly that isn't going to be universally correct either.
I don't know how to fix this, practically speaking. I think a full fix would mean adding something like GI_TYPE_TAG_TIME_T and then the code in places like gi_type_tag_get_ffi_type_internal can check the value of the preprocessor macro _TIME_BITS to decide what to do or something like that. This seems like a fair bit of work though...
girparser: Don't assume sizeof(size_t) == sizeof(void *)
We don't actually need to use the results of configure-time checks here: sizeof is a perfectly reasonable integer constant expression, so we can use that directly.
Equivalent to glib!3966 in GLib.
girparser: Make sizes in integer_aliases more obviously correct
We don't actually need to use the Meson-detected size macros here,
because the result of sizeof()
is an integer constant expression.
No functional change. Equivalent to glib!3970 in GLib.
girparser: Allow time_t, off_t, etc. to appear in GIR XML
g-ir-scanner currently maps these to lower-level types at scan time by assuming that time_t is an alias for long, off_t is an alias for size_t and so on. This is not always accurate: some ILP32 architectures have 64-bit time_t (for Y2038 compatibility) and 64-bit off_t (for large file support).
One option for resolving this g-ir-scanner bug is to have it pass these
types through to the GIR XML, and teach g-ir-compiler and its replacement
gi-compile-repository to convert them to the corresponding concrete
type tag, as they already do for abstract types such as long long
and
size_t
.
This is a gobject-introspection equivalent of glib!3967 and glib!3972, which in turn are based on part of !451 by Shuyu Liu.
giscanner: treat time_t and off_t as standalone types
From: @liushuyu
g-ir-scanner previously mapped these to lower-level types at scan time by assuming that time_t is an alias for long and off_t is an alias for size_t. This is not always accurate: some ILP32 architectures have 64-bit time_t (for Y2038 compatibility) and 64-bit off_t (for large file support).
[smcv: Added longer commit message]
Resolves: #494
Co-authored-by: @smcv
tests: fix the tests after time_t and off_t are standalone types
From: @liushuyu
tests: Add coverage for off_t
girparser: Don't assume sizeof(size_t) == sizeof(void *)
We don't actually need to use the results of configure-time checks here: sizeof is a perfectly reasonable integer constant expression, so we can use that directly.
Equivalent to glib!3966 in GLib.
girparser: Make sizes in integer_aliases more obviously correct
We don't actually need to use the Meson-detected size macros here,
because the result of sizeof()
is an integer constant expression.
No functional change. Equivalent to glib!3970 in GLib.
girparser: Allow time_t, off_t, etc. to appear in GIR XML
g-ir-scanner currently maps these to lower-level types at scan time by assuming that time_t is an alias for long, off_t is an alias for size_t and so on. This is not always accurate: some ILP32 architectures have 64-bit time_t (for Y2038 compatibility) and 64-bit off_t (for large file support).
One option for resolving this g-ir-scanner bug is to have it pass these
types through to the GIR XML, and teach g-ir-compiler and its replacement
gi-compile-repository to convert them to the corresponding concrete
type tag, as they already do for abstract types such as long long
and
size_t
.
This is a gobject-introspection equivalent of glib!3967 and glib!3972, which in turn are based on part of !451 by Shuyu Liu.
giscanner: treat time_t and off_t as standalone types
From: @liushuyu
g-ir-scanner previously mapped these to lower-level types at scan time by assuming that time_t is an alias for long and off_t is an alias for size_t. This is not always accurate: some ILP32 architectures have 64-bit time_t (for Y2038 compatibility) and 64-bit off_t (for large file support).
[smcv: Added longer commit message]
Resolves: #494
Co-authored-by: @smcv
tests: fix the tests after time_t and off_t are standalone types
From: @liushuyu
tests: Add coverage for off_t
Crashed json_generator_to_data() when node does not have any object.
At json 1.2.8, test case does not crashed but at json 1.3.2 ~ 1.4.2, crashed.
// Error Case
printf("Error Case Test\n");
root = json_node_new (JSON_NODE_OBJECT);
generator = json_generator_new();
#if 0
object = json_object_new ();[glibTest.c](/uploads/d39c72ac33369bf150298cf677af79ac/glibTest.c)
char* key = "key";
char* data = "data";
json_object_set_string_member(object, key, data);
json_node_take_object (root, object);
#endif
json_generator_set_root (generator, root);
data = json_generator_to_data (generator, &len);
at json-generator.c, need to null check logic for members.
442+++ if( members != NULL ){
443 for (l = members->head; l != NULL; l = l->next)
444 {
445 const gchar *member_name = l->data;
446 JsonNode *cur = json_object_get_member (object, member_name);
447
448 dump_node (generator, buffer, level + 1, member_name, cur);
449
450 if (l->next != NULL)
451 g_string_append_c (buffer, ',');
452
453 if (pretty)
454 g_string_append_c (buffer, '\n');
455 }
456+++ }
simple test.c
code:
#include <json-glib/json-glib.h>
#include <glib.h>
static inline JsonNode* get_json_from_file(const char* file)
{
JsonParser* parser = json_parser_new();
g_assert_nonnull(parser);
g_assert_true(json_parser_load_from_file(parser, (const gchar*) file, NULL));
JsonNode* node = json_parser_get_root(parser);
g_assert_nonnull(node);
node = json_node_copy(node);
g_assert_nonnull(node);
g_object_unref(G_OBJECT(parser));
return node;
}
int main(int argc, char* argv[])
{
JsonNode* node = get_json_from_file(argv[1]);
g_assert(node);
JsonReader* reader = json_reader_new(node);
g_assert(reader);
json_reader_read_member(reader, "UUID");
json_reader_end_member(reader);
json_reader_read_member(reader, "trans");
json_reader_read_element(reader, 0);
json_reader_read_member(reader, "coin");
json_reader_end_member(reader);
json_reader_end_element(reader);
json_reader_end_member(reader);
return 0;
}
compiling in Ubuntu 18.04:
gcc test.c -o test -O0 -ggdb -Wall $(pkg-config --cflags --libs json-glib-1.0)
and then, run it with:
./test searchbyuuid.json
which json file is the attachment
and then an error occurs:
(process:24519): Json-CRITICAL **: 20:15:58.099: json_node_get_parent: assertion 'JSON_NODE_IS_VALID (node)' failed
which caused by executing last json_reader_end_member(reader);
and the reader change its state into error, but json_reader_get_error
returns NULL
:)
Emmanuele Bassi (2bc063f3) at 17 Mar 14:52
The following Merge Request (MR) has been forwarded from GitHub in order to prevent the GNOME Project from losing contributions coming from un-official channels. And for contributors to not see their valuable contributions not being accounted for.
Relevant information:
Github handle: r-barnes
MR URL: https://github.com/GNOME/json-glib/pull/3
Patch URL: https://github.com/GNOME/json-glib/pull/3.patch
Body of the MR:
Fixes a -Wshift-sign-overflow
warning