Release 2.6.0 ...

Kick off for discussions for release v2.6.0

Related tracker v2.6.0, v3.0.0 and general feature overview
- https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Objectives_for_the_release_2.6.0
- https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Objectives_for_the_release_3.0.0
- https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Feature_Objectives_Overview

We will move items between the version as appropriate.

Some progress ..
https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Objectives_for_the_release_2.6.0

There is no hurry but is it the right time to work on relative mouse move? Anyway, it could be done in the version 3.

Well noted dear Julien! Rightly so.

Right now I still working on smoothing some rough edges
plus giving my darling GraphUI a more usable Group behavior.
The latter to allow move + resize, but then still able to select/click on members (actions).

Yeah, this Group thing just crossed me when making my own use case
of creating a UI element in demo code, grouping elements duh, pretty standard :)
And the encapsulated things must still be usable via click and the like, of course
- but benefitting from the Group's matrix node for position + scale.

While this is all so trivial .. I missed it :)

And of course, the demo use case uses videos .. and I trapped myself in AV Sync issues lol.
Happy hacking it is.

I'll probably write something in the wiki to help using JogAmp APIs to be used efficiently with APIs heavily relying on java.lang.foreign (Foreign Function & Memory API). MemorySegment.asByteBuffer() converts a memory segment into a byte buffer, MemorySegment.ofBuffer(Buffer) converts a buffer into a memory segment.

Maybe I haven't looked at the right place. The supported architectures are displayed on the homepage but what about the supported versions of Java depending on the combinations of operating systems and architectures? For example, it's difficult to guarantee that JogAmp works well on Apple OS X with Apple Silicon and Java 8 as even Eclipse Temurin OpenJDK doesn't support that:
https://adoptium.net/supported-platforms/

Yes, this is a good bug report to document:
- supported platform's and JRE range per RELEASE (i.e. build for .. etc)
- general support for platform and JRE, including the non-build platforms by us

GraphUI MediaButton Grid with Grouped Controls (GLMediaPlayer)
https://jausoft.com/blog/2023/10/16/graphui-mediabutton-grid-with-grouped-controls-glmediaplayer/

Resolving Bug 1472, enhance GLMediaPlayer’s AV Synchronization, I produced another demo for the Graph Type Rendering and UI saga exposing multiple GLMediaPlayer utilizing FFMpeg and our JOAL/OpenAL ALAudioSink with PTS accurate System Reference Clock (SCR).

(demo video within blog post)

+++

Bug 1472 https://jogamp.org/bugzilla//show_bug.cgi?id=1472

Sven Gothel wrote

GraphUI MediaButton Grid with Grouped Controls (GLMediaPlayer)
https://jausoft.com/blog/2023/10/16/graphui-mediabutton-grid-with-grouped-controls-glmediaplayer/

(demo video within blog post)

I took the freedom and added our 2012 Siggraph BOF photos / video snippets
at second 45 - good times & nostalgic.
Thank you all!

A little GraphUI widget progress ..

Pushed GraphUI's MediaUI01 media widget, screenshot.

This is part of Bug 805

Sneaking in my 2024 Christmas & New Year Greetings here ..

From the bottom of my heart, I hope that things can become better around us in the world for once.
Not a splish splash greeting, but you guys might know me by now.

Without diving too much into details, may some peaceful spiritual awakening
stop the (mass) murdering and allow us to get along with our neighbors.
Such awakening may come from each of us individually from the heart
and our free will, similar to Jesus of Nazareth's Mount Sermon.

+++

In regards to JogAmp for 2024 we shall have at least Release 2.6.0,
fixed reported basic (platform) bugs and my GraphUI enhancements
rendering it usable for basic immersive UI.
https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Objectives_for_the_release_2.6.0

Other potential tasks/goals are as usual visible under
https://jogamp.org/wiki/index.php?title=SW_Tracking_Report_Feature_Objectives_Overview

Wayland support for NEWT was also a topic in discussions as of late.

+++

In case companies and organizations desire to accelerate, have features added or
perhaps could use another helping hand in their awesome related or unrelated projects,
just contact https://jogamp.org/wiki/index.php?title=Maintainer_and_Contacts#Commercial_Support

+++

In this sense .. let's hope for the best and keep up our life & work.

Cheers,

~Sven

Happy new year.

I don't see the bug 1484 in the lists, it would be nice to have the necessary hardware/software combination to reproduce it.

This JEP will affect JOGL as we use JNI:
https://openjdk.org/jeps/8307341

Thanxs for the heads up, Julien.

gouessej wrote

This JEP will affect JOGL as we use JNI:
https://openjdk.org/jeps/8307341

not really

- JNI will stay alive, removal a non-goal

- They threaten with warnings or even exceptions if an optional future commandline option is not given

IMHO a pure FFI PR, fake security 'pump' and I question whether its worth for them
to really risk another commandline disaster to reach compatibility like with the modules.
Well .. sure they might just do that :)

Perhaps we provide our own convenient JVM launcher for all supported platforms
setting the required module options and so forth.
We will see ..

Yes I agree with you. In my humble opinion, it gives a false feeling of security, it's like putting many security cameras into the streets without treating the social causes of delinquency, it makes some people believe they are safe without taking care of the root causes.

We'll have to mention those flags in the wiki and to take them into account when modularizing JogAmp.

The Project Galahad might help to provide executable files with no need of a JRE, we'll see.

Hello,

recently I've been working on publishing properly the natives with Gradle and I'd like to fix that for the upstream libraries I come in contact with, Jogamp included

using a properly configured Jogamp publication, Gradle users could just write

        implementation("org.jogamp.gluegen:gluegen-rt:2.6.0")
        implementation("org.jogamp.jogl:jogl-all:2.6.0")

and then Gradle will automatically fetch the corresponding native for the underlying system and add them to the runtime configurations

in my case on Ubuntu:

> Task :checkClasspath
=== COMPILE ===
gluegen-rt-2.6.0.jar
jogl-all-2.6.0.jar
=== RUNTIME ===
gluegen-rt-2.6.0.jar
gluegen-rt-2.6.0-linux-amd64.jar
jogl-all-2.6.0.jar
jogl-all-2.6.0-linux-amd64.jar

The idea would be to inject the Gradle in the publication process, by adding the generated metadata into the publication.

You can take a look at the Scijava POM here, where the .module file is the metadata file I'm talking about

When the Gradle clients parse the xml pom and finds, at the begin, this line

do_not_remove: published-with-gradle-metadata

like here, then it will ignore the pom and consume directly only the metadata file, which is a richer format and can express these kinds of relations

if interested, I can provide a PR

Hello

I'm interested in this suggestion. I'd like to know Sven's opinion.

By the way, I have used Gradle for years and I haven't needed to make such changes. Please can you clarify what it brings and what the current workaround is?

gouessej wrote

Hello

I'm interested in this suggestion. I'd like to know Sven's opinion.

By the way, I have used Gradle for years and I haven't needed to make such changes. Please can you clarify what it brings and what the current workaround is?

Now you have to know which is the classifier for your platform and write something like this:

    implementation("org.jogamp.gluegen:gluegen-rt:2.6.0")
    runtimeOnly("org.jogamp.gluegen:gluegen-rt:2.6.0:natives-linux-amd64")
    implementation("org.jogamp.jogl:jogl-all:2.6.0")
    runtimeOnly("org.jogamp.jogl:jogl-all:2.6.0:natives-linux-amd64")

the natives should be a dependency automatically injected in the runtime configuration by the build tools, but unfortunately the Maven format doesn't have the capabilities to express such a relationship..
and this is where Gradle comes in: by properly specifying its metadata file, Gradle users won't have anymore this small burden

and also all the downstream Gradle projects consuming Jogamp transitively..