More GUI backends about wgpu-py HOT 35 CLOSED

Integration with pyimgui would also bring very interesting user interface elements to the table.

from wgpu-py.

I was wondering how wgpu-py and pyimgui would fit together

they both have a GLFW backend, is there maybe some way to render them as different passes into the same window canvas?

otherwise this appears to be a native wgpu renderer for imgui: https://github.com/Yatekii/imgui-wgpu-rs

from wgpu-py.

TkInter would be interesting, I had not thought of it yet because it does not support GL. But it might work with wgpu, IF we can get the native window id.

from wgpu-py.

Not at all a priority, but, pyglet is another lib that we could target.

from wgpu-py.

Alright, thanks! I'll see if I can get something working. Open pull request then, correct?

from wgpu-py.

Hi,

Very nice project guys.

i have one question :
why dont tkinter ?
it will be awesome if it is possible, as tkinter is part of standard python, no additional dependencies,, no licences etc...
i think standard python really need to have great solution for 3d.

from wgpu-py.

@almarklein

Hi,

Very nice project guys.

Thank you!

i have one question : why dont tkinter ? it will be awesome if it is possible, as tkinter is part of standard python, no additional dependencies,, no licences etc...

We did have it at some point but it had some issues, see #69 for some history.

Maybe @almarklein can comment here as well.

If you (or anyone else) feel like working on it, you can find the last version of the code we had for tk here, to use as a starting point: https://github.com/pygfx/wgpu-py/blob/7977a0688a462eeed3ef555000596db8a423ab42/wgpu/gui/tk.py

i think standard python really need to have great solution for 3d.

We agree, this is the main motivation behind this project!

from wgpu-py.

Look very nice, good job, (i am fan of Blender nodes).
This will 100% motivate me to investigate wxPython :)

from wgpu-py.

i am looking at dearpygui right now ...
They try to make looks like a retained mode in their approche of wrapping and additional callback scenario, but it is definitely direct mode under the hood.
it is one other beast very close to dearimgui.

The node editor is simple wrap of imnodes, the minimalistic core functions are here.
The rest need to be custom writed, the interesting thing is that any widgets can be embedded inside the node frame

from wgpu-py.

This seems to be maintained (somewhat): https://github.com/marcusva/py-sdl2

from wgpu-py.

Yeah, but I think you still need to install the native sdl2 libs manually.

from wgpu-py.

Ah right. That sucks. OK!

from wgpu-py.

In that case, I think we can just drop SDL, until a better package comes along in the ecosystem.

from wgpu-py.

yeah. glfw is very similar in providing a solid lightweight window. So there's not really a use-case except maybe someone wanting to use sdl2 already for something else, or something.

from wgpu-py.

Also added PySide/PyQt4. It should not be too hard to make the Qt backend work for these as well.

from wgpu-py.

https://beeware.org/ is apparently also a thing nowadays :)

from wgpu-py.

How hard would this be to implement for wxPython Phoenix? What's required? I'd consider helping, if possible.

from wgpu-py.

@Correct-Syntax that would be great! There is not that much "stuff to wrap", but how hard it is depends a lot on how easy the toolkit makes it to e.g. obtain the window id. And there can be tricky edge-cases like this.

That said, the idea is to keep the wrapping minimal to what's needed to have a canvas to draw to. E.g. we don't try to create a unified event system or something.

from wgpu-py.

So, what exactly from wgpu needs to be put into wxpython? I guess I need a bit more context to help.

Getting the window id with wxpython is as simple as thewindowobject.GetId(). Not sure if that's what you mean.

from wgpu-py.

It looks like the qt widget subclasses WgpuCanvasBase. Would I be right to say that all that should be needed is to basically translate that qt.py into wxpython?

from wgpu-py.

Yeah, the qt version could be a good staring point, but you may not need to do the trick with two classes for wx. Also have a look at base.py which shows the messages that must be implemented. Don't hesitate to ask for help if things are unclear - you'd be the first to create a gui backend except ourselves.

from wgpu-py.

Yes, a PR would be great. We could discuss further there :)

from wgpu-py.

Updated the opening post, thanks @Correct-Syntax

I also added ipynotebook static and interactive

from wgpu-py.

is there maybe some way to render them as different passes into the same window canvas?

ImGUI says that it "outputs optimized vertex buffers that you can render anytime in your 3D-pipeline enabled application", so maybe this could work? This would need some research. I know that Datoviz (which is based on Vulkan) has imgui integration of some sort.

from wgpu-py.

Yeah, it looked like it was not possible to get the window id on some OS's, and where it did work, it did not work well at all. Together with the lack of proper support for hidpi displays this simply is not worth it. I would not recommend anyone trying to make it work. I would be reluctant to accept PR's that add support for it, because we'd be stuck maintaining a flaky backend.

Glfw is now widely available, easy to install, stable, lightweight, libre license ... there is really no need for a tk backend.

from wgpu-py.

Glfw is now widely available, easy to install, stable, lightweight, libre license ... there is really no need for a tk backend.

I guess there is a need in places where you don't control the environment you are running in, and you are stuck with tk. On the other hand, in those cases you also don't have access to wgpu-py, so... yeah. I guess you're right, Almar.

from wgpu-py.

Hi,

Thx for the details answer.
Ok ... Yes, sadly tk seem not to be the easiest when it came to customize and mixed with other tech.

Just to precise my context :
My need for gui with python it is at work, for the new program i work on.

Previusly i was using python only in two scenario :

• As script inside other programs (blender, motionbuilder, maya, etc...), the gui need is provided by the hosting program.
• As files to run from cmd for automated processing with no need for gui.

So, i never use tk before this new standalone program demand with the requirement to use python only.
To be autonomous and packaged as portable exe (no deployment or installer) and don't have any licencing issue.

Mainly, tk was feeting the bill for this program until now, the demand evolute to the need for 3d visualisation capability, and ... tk dont feet the bill anymore.

At the end it is sad the standard python stick with tk and seem not looking to integrate one other more modern and friendly framework in his standard distro.

from wgpu-py.

So, i never use tk before this new standalone program demand with the requirement to use python only.
To be autonomous and packaged as portable exe (no deployment or installer) and don't have any licencing issue.

For the record, Glfw still fits these requirements. If you can install wgpu-py, you can also install glfw.

from wgpu-py.

HI,

Yes, i can use additional python library in regard to the need of no licence.
For that i am looking at what is existing etc...
Glfw as nice it can be, will not suit my need because is not a gui framework but just a windowing layer.

And i have a complete and complex program to create, the 3d viewer part is just one part of.
Also, the program run on Windows and due to the current pandemic is primarily used on standard remote session witch simply disqualify any openGL backend.

Your solution look sweet to me because is using the correct backend per platform, so directx for my case on windows.
Also is a solution to integrate with an gui framework of choice.

Anyway, thanks for answering and the talking point.

from wgpu-py.

Glfw as nice it can be, will not suit my need because is not a gui framework but just a windowing layer.

Good point :)

What about PySide6 though? That's lgpl and stable.

from wgpu-py.

hehehe

Yes, i have an experience with Qt (c++) it is a massive framework.
To correctly use Qt it is need to use Qt, i mean all Qt and the editor too.
They have an Qt something class for allmost anything, at the end the experience is not really c++ anymore, is ... Qt ++ :)

So i guess the python wrapper (pyside6 or QtPython as they call it too) follow the same quality and logic.

But, the licencing is becoming the problem with Qt. And they have send signals to any compagny who use Qt for small or big project to ensure the licencing is well understood and applied.
The company who employ me have decided to cut of all sort of Qt use.

i am looking at dearpygui ... have you a point of view about ?

from wgpu-py.

@llluuulll Sorry if I misunderstood your use case, but would wxPython work? See license here https://wxpython.org/pages/license/index.html It's about the only one not mentioned so far.

from wgpu-py.

Haha, yes you right, still have to investigate wxPython ... i don't know why i am not attracted by ... but i will do.

Sorry me i have not fully precise my need case.
i develop a program to create and manage and run a multy purpose nodal programmable pipelines.
To centralise and monitoring all sort of automatable processing, mutithreading, subprocessing, parallal cpu gpu, etc...

Tk as old it is and looks, fulfil my need for the program main gui, the node graph, the nodes params, the code editor, the logging and so on ...
Surprisingly the canvas of tk is extremely flexible and convignant for the nodal part.

from wgpu-py.

Funny you should mention a node graph. If you decide to go with wxPython, there's https://github.com/GimelStudio/gsnodegraph for the nodegraph (yep, it's one of my projects). Free free to use it/hack it for your use.

I think dearpygui has a node graph as well if you decide to go with that. Thinking about your use case, it seems dearpygui is used quite a bit for that sort of stuff so that may be the better solution (??).

from wgpu-py.

Closing this as we don't have a direct need for the remaining GUI backends (and we also don't see a need in the community based on issues created here).

If anyone reads this in the future, and feels like they need support for one of the missing GUI backends (or a new one!), they are free to open a new issue and/or pull request.

from wgpu-py.