gjs issueshttps://gitlab.gnome.org/GNOME/gjs/-/issues2020-05-31T19:51:04Zhttps://gitlab.gnome.org/GNOME/gjs/-/issues/323Can't use Gtk.Window.propagate_key_event(), etc.2020-05-31T19:51:04ZJohn FactotumCan't use Gtk.Window.propagate_key_event(), etc.# System information #
What is your operating system and version? Arch Linux
What is your version of GJS? 1.64.2
# Bug information #
## Steps to reproduce ##
```js
imports.gi.versions.Gtk = '3.0'
const { Gtk } = imports.gi
Gtk.init(nul...# System information #
What is your operating system and version? Arch Linux
What is your version of GJS? 1.64.2
# Bug information #
## Steps to reproduce ##
```js
imports.gi.versions.Gtk = '3.0'
const { Gtk } = imports.gi
Gtk.init(null)
const win = new Gtk.Window()
win.connect('key-press-event', (win, event) => {
win.propagate_key_event(event)
})
win.show_all()
Gtk.main()
```
Then press any key.
Also happens with `Gtk.Window.activate_key()` and `Gtk.bindings_activate_event()`.
## Current behaviour ##
```
(gjs:4487): Gjs-WARNING **: 11:44:27.236: JS ERROR: TypeError: Object 0x14e7de388e50 is not a subclass of GObject_Boxed, it's a GObject_Union
```
## Expected behaviour ##
Should be able to pass the event without errors.https://gitlab.gnome.org/GNOME/gjs/-/issues/311Follow-up from "Don't crash if a callback doesn't return an expected array of...2020-03-28T04:02:38ZPhilip ChimentoFollow-up from "Don't crash if a callback doesn't return an expected array of values"The following discussion from !405 should be addressed:
- [ ] @ptomato started a [discussion](https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/405#note_746534): (+2 comments)
> Well, I figured out why this is. The result of `JS...The following discussion from !405 should be addressed:
- [ ] @ptomato started a [discussion](https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/405#note_746534): (+2 comments)
> Well, I figured out why this is. The result of `JS::ToNumber()` on `undefined` is NaN. The return type of this vfunc is `glong` whereas the other vfuncs that return NaN are all `gfloat`, so that's why we get NaNs returned from all the other functions but not here. I suspect (from testing on godbolt) that the compiler is converting NaN to 64-bit int with `cvttsd2si` on x86-64, and that's where the value of –9223372036854775808 (0x8000000000000000) is coming from.
>
> Since this vfunc returns a glong, there's no way we can ever get a NaN from it. So I think it's sufficient to change this expectation to `.toBeDefined()` or something like that.
>
> This was pre-existing, however, with this merge request we are now introducing an inconsistency: we get 0x8000000000000000 if we return undefined as a lone integer return value, and 0 if we return undefined as one of multiple integer return values, as in `vfunc_return_value_and_multiple_out_parameters`. I think it's probably worth fixing this. Alternatively, I could be convinced that not returning the correct type from your vfunc is undefined behaviour as far as GJS is concerned, in that case we can just un-pend the test and expect the log message about the value being outside the range of a JS Number.
- @3v1n0:
> Ok, I've changed it to use `.toBeDefined()`, however you're right that this MR exposes an inconsistency (more than introducing it I think), given that this was already the behavior.
>
> So, I'm not sure how to fix that though, so given the MR was to focus on non-crashing mostly, maybe we can leave the two "simple `return undefined`" cases as `pend` in case we know how to make them behave the same way, and address it somewhere else.https://gitlab.gnome.org/GNOME/gjs/-/issues/97Impossible to inherit from class with composite template2018-08-24T19:14:23ZBugzillaImpossible to inherit from class with composite template## Submitted by Philip Chimento `@ptomato`
**[Link to original bug (#768790)](https://bugzilla.gnome.org/show_bug.cgi?id=768790)**
## Description
Created attachment 331453
Minimal script to illustrate the problem
It's not possible ...## Submitted by Philip Chimento `@ptomato`
**[Link to original bug (#768790)](https://bugzilla.gnome.org/show_bug.cgi?id=768790)**
## Description
Created attachment 331453
Minimal script to illustrate the problem
It's not possible to inherit from a class that uses a composite template, because gtk_widget_template_init() is called in the subclass's instance init rather than the parent's.
That's not a very clear explanation, so see attached script that illustrates the problem.
I am at a loss as to how to fix this. It seems that the code currently assumes that only one JS _instance_init() function is to be called per object construction and that it should be called from the most derived class's GObject instance init. As per the documentation of gtk_widget_init_template(), "This function must be called in the instance initializer for any class which assigned itself a template using gtk_widget_class_set_template()", which I interpret to mean that init_template() should be called from the superclass's GObject instance init. This might mean that we have to move template initialization to C.
**Attachment 331453**, "Minimal script to illustrate the problem":
[gtkhelloworld.js](/uploads/750fcd4cd6599400f7be94c6549676d7/gtkhelloworld.js)https://gitlab.gnome.org/GNOME/gjs/-/issues/64should not use guint-based GSource APIs2018-01-31T04:35:01ZBugzillashould not use guint-based GSource APIs## Submitted by Dan Winship `@danw`
**[Link to original bug (#687987)](https://bugzilla.gnome.org/show_bug.cgi?id=687987)**
## Description
memory-managed bindings should use the GSource*-based GSource APIs, not the guint-based ones,...## Submitted by Dan Winship `@danw`
**[Link to original bug (#687987)](https://bugzilla.gnome.org/show_bug.cgi?id=687987)**
## Description
memory-managed bindings should use the GSource*-based GSource APIs, not the guint-based ones, since
a) in some programs, the IDs may eventually overflow and get reused
([bug 687098](https://bugzilla.gnome.org/show_bug.cgi?id=687098))
b) g_source_remove() is O(n), whereas g_source_destroy() is O(1)
JS doesn't have a guaranteed-to-be-pointer-sized integer type, so to upgrade the existing APIs you'd have to make them return objects instead of integers, which could in theory break some users...