Using the current R version (4.5.1), current Jamovi version (2.6.44), and the current jmvtools version (2.7.2 as per repo.jamovi.org), I get the following deprecation warning when compiling a home-grown Jamovi module, at least on Windows:
(node:5524) [DEP0128] DeprecationWarning: Invalid 'main ...
Search found 4 matches
- Thu Jun 26, 2025 9:23 am
- Forum: jamovi development
- Topic: Deprecation warning when compiling a module with current R
- Replies: 1
- Views: 140025
- Fri Sep 16, 2022 11:25 pm
- Forum: Module development
- Topic: Bubble help from modules?
- Replies: 2
- Views: 11247
Re: Bubble help from modules?
Dear Maurizio,
Ah, I see my question was phrased ambiguously. I am sorry!
In fact, I indeed meant the second case, i.e., can I offer bubble help/tooltips for a module I am developing. (The module will be used for teaching, and some help may make students happier.)
Yes, I am comfortable programming ...
Ah, I see my question was phrased ambiguously. I am sorry!
In fact, I indeed meant the second case, i.e., can I offer bubble help/tooltips for a module I am developing. (The module will be used for teaching, and some help may make students happier.)
Yes, I am comfortable programming ...
- Thu Sep 15, 2022 11:44 pm
- Forum: Module development
- Topic: Bubble help from modules?
- Replies: 2
- Views: 11247
Bubble help from modules?
Is it possible (with reasonable effort) to have jamovi display some bubble help when the user hovers the mouse over some field either in the input section on the screen, or maybe over a field (or table) in the output section on the screen?
(Motivation: bubble help for an input element could give ...
(Motivation: bubble help for an input element could give ...
- Tue Sep 13, 2022 11:06 pm
- Forum: Module development
- Topic: Why persistentItems in .u.yaml rather than in .a.yaml?
- Replies: 1
- Views: 10129
Why persistentItems in .u.yaml rather than in .a.yaml?
Here's a newbie question:
I thought I had understood that the .a.yaml file provides a highly abstract, clutter-free specification of the UI, while the .u.yaml (which, in its basic form, is "compiled" from the .a.yaml) can be augmented for low-level visual fine-tuning and/or more complex behaviour ...
I thought I had understood that the .a.yaml file provides a highly abstract, clutter-free specification of the UI, while the .u.yaml (which, in its basic form, is "compiled" from the .a.yaml) can be augmented for low-level visual fine-tuning and/or more complex behaviour ...