Discussion about pyimgui future #237
Comments
|
Hey, Some random ideas:
|
|
Thanks for your answer,
Yes this is a good idea
I am not yet familiar with every possibility but if it is possible it would make sense to do it like that indeed. I will spend some time studying that.
In my experience upgrading to a new version of dearimgui does not require too much work if it is done meticulously. It is when we have to jump several upgrades that it becomes a bit more cumbersome, thus my idea of having a branch that tries to continuously match to the latest dearimgui release. I don't think this should be in the master branch, neither necessarily in the "next release" branch. I was thinking of a side branch that keeps only the incremental upgrading and in which we can base future updates of pyimgui.
I agree, for now, we have to focus on releasing a new stable version with a much more recent version of dearimgui. Basing it on 1.82 makes perfect sense since the upgrade is mostly done and tested. |
|
Hello @KinoxKlark, first of all: thank you very much to take over responsibility for this project! You wrote:
I'd do this in a two step process:
(Dropping support for EOL Python is announced for 2.0.0 in the 1.3.0 Release.) |
|
Yes, it is indeed a good idea. Thanks. |
|
Sorry to answer so late to that, but so about the DLL question, I believe we could use a pattern similar to what's being used for PySDL2: the DLL is distributed by itself as a separate package (could be pyimgui-dll or something), and then the bindings are a python pure wrapper around it, making the package way simpler to deploy and update (no need for building wheels and such) |
|
I like that idea as well, it is simple and flexible. I will have to give it a deep thought, try some things, and choose the best option. I think I will soon push a minor release with recently merged PR and start putting the new major release together. I'll create a branch for the upgrade where I'll merge #192 and where we will try to solve the DLL question. Since it seems to be a major manipulation of the library architecture I think it is best fitting the new major release. It will push the release date a little bit but I think it is better if all possible breaking changes comes simultaneously on a major release. |
|
Shouldn't the DLL question be addressed in a later major release? The next major release being the 1.82 branch. |
|
It is indeed an option, but I am wondering if it is not best to consider the DLL question as a massive change in the architecture of the library, like the 1.82 branch is, and thus addressing both together would avoid problems for users going from 2.0 to 3.0. Moreover, the 1.82 branch makes use of a duplication of the dearimgui cpp in order to propose both the core module and the internal module and I am not sure that this should be like that and the DLL question would solve that issue. And since the DLL question seems mandatory for C++ integration of pyimgui or external modules like pyimplot, it has to be solved quickly in either case which would imply two successive major releases. Maybe I am missing something? |
|
Doing it in two steps would help with regression testing / finding the source of bugs. |
|
I think it mostly depends on your capacity. I'd be fine with having them both in the same release, but it might not be worth it if it means postponing 2.0 for several months. |
|
Would it be a low hanging fruit to integrate imnodes into the upcoming 2.0 release of pyimgui? I suppose that this useful node editor feature would not require an additional external DLL, since it is only implemented as a header and a cpp file in the same style as Dear ImGui itself. |
|
Hello, I am not sure that "addon" for dear imgui such as imnodes or implot should be baked inside pyimgui. The reason for that is that if we decide to include one of them, there is no reason to not include every other one of them. Every user of pyimgui doesn't necessarily need all these possibilities and shouldn't be forced to download them just to access the core imgui functionalities. (Without saying that it would be a nightmare to maintains in the long run). These functionalities are clearly interesting, but it may be preferable to implement them as external modules that depend on pyimgui and are installable separately. And, for this to work, we need to implement the DLL functionality. I think the plan for now is:
As usual, I am open to suggestions. I am currently a bit overbooked and I can't work on the new release as much as I want (We may have troked a busy project manager for another busy project manager ^^). I think the only remaining things are to fix the Linux building pipeline (may need some help with that) and ensuring that all little details are correctly set (version number in files, documentation, etc). |
|
Dear @KinoxKlark, Thank you very much indeed for your explanation and for taking over adminstrative reponsibility for this project. Clearly, as an open source community effort you should not be left alone going forward with implementing this roadmap and deserve our biggest respect and all support possible. In my opinion pyimgui is awesome, since it supports so many backends. For my use case, I am particular happy that pygame is also supported as a backend by it. Nevertheless, my current impression is that pyimgui competes with DearPyGui for market share and DearPyGui is already shipping with implot and imnodes support right out of the box, However, DearPyGui does not support so many backends that are still very important in virtual machine environments and also for embedded hardware like the Raspberry Pi requiring support for OpenGL verions <= 2.1 (when running under X11 or VNC). I understand that DearPyGui rather aims to compete with backends like pygame and not aiming to support them like pyimgui already does. Regarding the current state of the pyimgui project, my impression of the apparently only very limited availble resources and the very ambitious professional engineering roadmap that has been discussed in this thread to this end for going forward with pyimgui might lead to falling into the trap of over-engineering pyimgui with flexible and desirable DLL support while unfortunately losing momentum and market share to competing projects. Therefore, it is my impression (just my two cents) that a second best tomorrow approach to going forward with this project is also worth considering in order to keep pyimgui alive, with a desirable aim to deliver and refactor it frequently and gain momentum by attracting potential competent new contributors from the wider community (by not losing them to other projects and putting to much burden on you as an administrator alone). However, if the sketched 1.4.0 / 2.0.0 relase apppears feasible from your perspective than by all means I would be most grateful if it eventually happend. Best regards and wishes and all the best to you and this awesome project. |
|
Thanks a lot for your valuable insight! I may be a little biased regarding that question but I don't think of DearPyGui as a competitor of pyimgui. As I understand it, DearPyGui has for objective to propose a complete Retained Mode GUI using in backend DearImGui, which is an Immediate Mode GUI. Pyimgui is a more direct binding of DearImGui and is thus an immediate mode GUI tool. Both have radically different philosophies and thus have a different target audience. The proposal of DearPyGui is to gives their users a complete GUI backend on which to build their applications, i.e. construct a user interface. Pyimgui proposes a lightweight library that one can load on top of his application to quickly display pieces of information in an immediate mode. It is the reason why pyimgui can support so many backends, in fact, one could graft it to any backends, even if not officially distributed with the package (distributed backends are only examples of integration that are already delivered as python code in the package). The main difference between DearPyGui and pyimgui is that the first one is an all in one tool to create GUI and the latter one is a small extra that you add on top of your existing application to not reinvent the wheel and help you render GUI. It is because of that difference that I am not so inclined to include many other addons of DearImGui to this binding. In my understanding of the philosophy of pyimgui, the user should have the choice of what he is adding to its application, and bindings of implot or imnodes should only come as extra packages. However, you make very good points concerning the ambitions of the project versus the actual resources that are allowed to it and we should be careful about that. Indeed, it is better to ship something quickly than never ship anything, waiting for the perfect moment. As I see it, both 1.4 and 2.0 are mostly ready to be shipped. I have to solve some issues with the linux build pipeline in order to build the wheels and releases them on pypi. For 2.0 I will have to do a quick "quality" pass, mostly to be sure that the documentation is consistent, that the version number is correct everywhere, and so on, but functionalities are here and some already use the branch in their project for several months. It is in that regard that I think the discussed roadmap is feasible. Concerning the DLL functionalities, it is not really fixed yet. Some tests have been done to studies the possibilities. But all that should wait until 2.0 is out. You are more than welcome to start a binding of imnodes inside pyimgui if you need it. I don't think that it would be included in 2.0 since, as I said, 2.0 is mostly done. But it would be a good start for what is coming next, whether for inclusion inside pyimgui as you suggested or for the separation in an external package using the DLL functionalities. |
|
Somewhat slightly related to the above (but not entirely) is the amount of open issues on this repo. |
|
No indeed, I don't think they should, you are right. Unfortunately, I didn't have time to go over every one of them. Some should be closed, others should wait until releases, and so on. Maybe you could help me with that by pointing which ones should be closed? Or is there a way to designate volunteers as moderator or some similar roles? (I am not used to all functionalities of GitHub) |
The I would be willing to close some tickets or apply labels, but cannot give any guarantee about my availability. |
|
On GitHub repo administration:
|
|
I hope this is the right place to pitch this idea. Something I believe would be very beneficial to pyimgui is a simple way for average users to share their custom widgets made using the library, and I really liked how this is handled in upstream imgui: an issue label called "useful widgets". Creating issues is quick and easy to do, and allows for easier management compared to setting up a separate repo or committing in the examples directory. Also provides a centralized place for newcomers to see what cool things can be created using pyimgui. I myself have a few such widgets (file browser / picker, star rating widget and a few others) that, while being simple and rudimental, might come in handy to someone else. I'm sorry if this has been considered already, but I couldn't find any mention of it in the issues... |
I have created #282 for this purpose, feel free to post there for now. |
Hello everyone!
As you may have seen, changes are coming. First of all, the repo is now an organization one, which will be easier to manage as a team project. Due to work overload, our dear @swistakm is not able to manage the project anymore and has to retire from the development. The change to an organization repo is here to support this and to allow the project to move forward without him. We can't thank him enough for what he started and I hope he will succeed in his numerous projects outside 'pyimgui'!
In his absence, I inherited admin right on this repository and we have carte blanche for the evolution of the project. I say 'we' because I don't expect to stay the lone manager of pyimgui. I wish to gather a small core team of active contributors that is willing to organize at my side the future of pyimgui. Feel free to contact me (or responds to this post) if you are interested.
I am not yet very familiar with every functionality of GitHub, thus I expect your help to discuss the organization of the repository. What is the best way to manage such a project? Any proposal is welcome to be discussed here.
Concerning the direct future, I think it is time to prepare next major release. I will soon go on pending push requests and merge what needs to be merged. After that, I will look for the merging of the big upgrade to the latest dear imgui, pr #192. I do not have the access to PyPi yet, this will have to wait a little bit. In the meantime, there is still stuff to do on the upgrade before releasing it.
We also have to settle on the question of distributing pyimgui as an external dll (which would help with external modules that are wishing to extend pyimgui) or compiled in pyimgui (which facilitate version management and distribution). I don't think this needs to be decided for the next release and can be developed in the future.
For future developpement, we also need to discuss how we will organize futures catch-up with dearimgui upgrades. v1.83 is already here! Should we create an "upgrade" branch which tends to be in sync with dearimgui? Or do we keep working on the master branch?
The question of dearimgui docking branch is back on the table. I was thinking of a branch in pyimgui that is in sync with their dev branch. This rise the question of distributing such a branch. Should we distribute it with PyPi like a normal module? Or do we keep it as a manual installation with documented instructions? Maybe, if we manage to allow easy extension of pyimgui (e.g. with external dll), it would be possible to develop this as an extension (and perhaps another repo of the pyimgui organization)?
I would love to hear about your insights on all that subjects and I hope we will be able to make great things with this project. Feel free to comments and criticize any of my suggestions. As I have said, I am not an expert on the subject and I need your help to manage the project properly. I probably have forgotten many things, please adds them to the discussion.
Best,
KinoxKlark
The text was updated successfully, but these errors were encountered: