iPad compatible?

nuklear.

2 Likes

Cool. I didn’t know this. Looks interesting. Thanks for the pointer.

it’s great in the sense that it literally has no dependencies. so one major pain point porting stuff is gone. i suppose the downside is that you’ll have to do many things yourself. i prefer this way, most of these things i had already (drawing stuff on a screen using a gpu, some event handling to zoom into an image, etc…).

if you’ve worked with dear imgui it feels very familiar. sometimes the api is better thought out (has a context, no global state, there are layouts). in general it is less polished/mature/feature rich, and there are often small quirks that surprise me. i might still have to learn how to do things most elegantly here.

also it doesn’t require c++.

2 Likes

The newest nightly Appimage of vkdt is already with nukear, right? (I don’t have a computer right now)

Do you think it’s possible to port RawTherapee or even darktable to this nuklear? If yes, how much work would it be?

At first glance, I think that would be really lots of work to replace GTK in dt with nuklear. dt makes hugely use of GTk from what I can see.

GTK also provides some easy to use GUI elements whereas nuklear appears to be more rudimentary in that respect.

Yet, I will dive deeper. Interesting idea.

unless nuklear already supports more platforms than GTK why would you want to port away from it?

if your goal is really being more portable then Qt might actually be a better target. it already supports e.g. iOS ( of which IPadOS is a flavor ).

I know that porting to GTK4 would be a lot of work. The problem is from my pov that GTK3 does not support 10 bit. So I thought this nuklear thing is maybe easier/less work.

From what I understand dt is very entangled with gtk. Someone has started the port to gtk 4 already tho.

yes, correct.

i still remember roman porting dt from gtk2 to gtk3 in a herculean effort. as kichererbse stated, gtk is a lot more entangled with dt’s source than you would like.

oh, nuklear is immediate mode, not retained mode. that means a lot of the internal state handling and widget initialisation and cleanup etc goes away. it’s very different and for my part i don’t want to go back. i think:

this is clearly untrue. immediate mode code i find much easier to write, and i don’t see a fundamental difference in how easy the resulting widgets are to interact with.

anyhow that also means such a thing would be more like a complete rewrite, and not only of isolated gui portions (since event handling and main loops need to be different as well). at which point there may or may not be other parts of the code that one might wish to replace while at it. certainly not the fast path to 10bit.

1 Like

Yes, but what would be more difficult: porting to gtk4 or porting to nuklear or something elsr? I heard from the Inkscape guys that porting Inkscape to gtk4 is/was a real pain because there were lots of bugs in gtk4 and it’s not 100% mature. Apparently Inkscape gtk4 still does not work well on windows and mac because of that.