Questions about wxlibrary use

@Correct-Syntax Firstly I'd like to say, you have done a good job working on the wxnodegraph stuff. Just trying it out I was surprised it worked decently out of the box. Tho it does still have crash issues here and there when linking things and clicking around.

I'd like to help, but I'm not sure how far you are in your project as to whether I should continue working on the little bit I've done with my copy of wxnodegraph.

I'd like to see the wxnodegraph actually become part of the standard wxPython lib. This would benefit everyone from having to duplicate a lot of the work when it comes to customizing options and the sort and in the end dealing with bugfixes, etc... but doing that will mean basically ripping out the basic node functionality and turning it into a package that requires just wxpython as a base. A lot of projects in the past I have seen will start out and someone will come along and ask if they can use the widget and get told they can, but it is so ingrained in the program that it would be a nightmare to reverse without ripping the whole program to shreads. Timeline project for example was one that did this but kind of realized they couldnt do it fully because their program was actually a timeline and keeps track of itself... go figure... :/

When I started hacking on mine I had a few other ideas in store, mainly one was similar to how you do custom nodes. This allows users to implement something on the fly which is specific to their needs that for example wouldn't be able to be done with just base wx. In Embroidermodder we achieved this by making every single command in the program basically a plugin(custom node in your case), all the way down to simple cut copy paste stuff lol. I had need of a blender like node system in SourceCoder, but at the time I needed to write a ton of other code in order to be able to make dynamic nodes possible. For example, I could generate my code on the fly and also generate a nodegraph leading to possible problems where an exception occured ect ect. Also I figured it would be useful in my 3dModeler if I wanted to interface with my models I design in whatever program. Of course your biggest problem will be dealing with images also because that is the main reason for out of memory errors and crashes. modeler

Also I'm not sure why you changed the license to apache2 from MIT...? Maybe its because you use other requirement libs in your program? Maybe you are worried about patent trolls. Personally I try to avoid it anytime I can because of the changelog statements. Most anyone isn't going to save 10 years of minimal changes just to please a lawyer(plus they are not going to spend 10 years reading it lol). Especially if you are the author of a code editor. Basically what I'd like to do if you are not too far in the project is to help get the node stuff in a releasable state. On the wxPython end that basically means formatting for sphinx docs, trying to follow code conventions, etc, etc. and then make some demos. I was the one who ported the whole demo to phoenix and boy let me tell you it sure was alot of work for a single person. wxPython/wxWidgets license is basically LGPL with an exception that you can license your binary any way you want. Also I'm sure that the wxWidgets folks would want to port such a widget into the C++ end which would make the widget alot faster... tho im not sure how much work that would entail on their end. probably would take awhile and they would want it to be stable and cross platform on the python end before doing so.

Anyhow, I'd like to hear your thoughts...

Hi @Metallicow,

Hope you are doing well.

Firstly I'd like to say, you have done a good job working on the wxnodegraph stuff. Just trying it out I was surprised it worked decently out of the box.

Thank you and HalleluYAH!

it does still have crash issues here and there when linking things and clicking around.

This is a known issue that has more to do with the threading issues with the image renderer, I believe.

I'd like to help, but I'm not sure how far you are in your project as to whether I should continue working on the little bit I've done with my copy of wxnodegraph.

I would definitely appreciate help with Gimel Studio. :)

I'd like to see the wxnodegraph actually become part of the standard wxPython lib. This would benefit everyone from having to duplicate a lot of the work when it comes to customizing options and the sort and in the end dealing with bugfixes, etc... but doing that will mean basically ripping out the basic node functionality and turning it into a package that requires just wxpython as a base.

Hmmm.... Before I created Gimel Studio and worked with creating the node graph functionality myself, I probably would have agreed with you. However, my personal opinion is that a node graph widget is really something you need to have full control -made to fit the requirements of the application you are creating.

For example, many node-based programs (Pixaflux, etc) have the "output node" the one that is currently selected/active while other programs (such as Blender) have a separate Output node, etc. (I prefer the latter which is why Gimel Studio's node graph is that way!)

My point is that (to me), it would be difficult to try and make a node graph widget that was flexible enough so users could customize things like that. It would be a huge undertaking to do so, that's for sure. Maybe you're willing to do the work involved -and that would be great, but as of now with my own experience, I am glad that I implemented my own node graph.

I really feel like the end resulting node graph widget would be good (no doubt), but not very practical for many people. I am open to your thoughts on this, I just don't see it as something worthwhile ...to be honest.

Also I'm not sure why you changed the license to apache2 from MIT...? Maybe its because you use other requirement libs in your program? Maybe you are worried about patent trolls. Personally I try to avoid it anytime I can because of the changelog statements. Most anyone isn't going to save 10 years of minimal changes just to please a lawyer(plus they are not going to spend 10 years reading it lol). Especially if you are the author of a code editor.

I assume you are referring to wxnodegraph as MIT licensed. I chose Apache because it was a balance between the OS licenses and yes because of the req libs.

If I am not mistaken, wxPython does keep track of code changes in some of the source files.

Basically what I'd like to do if you are not too far in the project is to help get the node stuff in a releasable state.

I wouldn't be apposed to help with getting the node graph more stable. :)

Anyway, I do appreciate your pull requests and willingness to help. So, thank you.

As far as Jeffs changelog in the files. That stuff occured before we moved to github and had a proper file for changelogs/git revision system, etc. It is relatively old and shouldnt have been in a library file in the first place, but thats how things worked back in the old days sometimes. Really in reality that is considered cruft and could be removed because that was done in Classic which is dead now. Only Phoenix will be worked on in the future. Stuff like that should have gone/been moved into a changelog file. Occasionally you will see TODO's/Ideas lists in the files, but you have to realize that that simply means if you want to continue work and implement it then at some point those lines would be removed and a changelog entry would be made stating that XX feature has been added.

As far as my copy of wxnodegraph, I have a bit more to do but basically the drawing/looks part is similarly finished like yours. I haven't implemented detaching yet tho... Instead of having a dc drawn image window like you are doing, I had more of an idea of using an actual window class/wxControl to do stuff in. For example a wxTextCtrl or wxSlider, STC, etc... Also I intend in the end to implement the majority into a matrix class so that scaling/zooming will act proper with the window. Sadly there is no PsuedoDC for Graphics Context on the C side yet, but that would make things a bit nicer than dealing with the alpha issues completely from the python side of things(which is way slower if calculating the alpha yourself) Eventually when I get around to adding it to my MCOW package basically the user or programmer would just subclass a base node and customize it from there, kind similar to how you are dealing with imports and then make their program from there depending on what area they may be focusing on(Ex: NonDestructive Image Generation in your case).

As far as my copy of wxnodegraph....

This sounds interesting...

Sadly there is no PsuedoDC for Graphics Context on the C side yet...

It would be nice if there was.

I had more of an idea of using an actual window class/wxControl to do stuff in.

How has this worked out for you?

Eventually when I get around to adding it to my MCOW package basically the user or programmer would just subclass a base node and customize it from there, kind similar to how you are dealing with imports and then make their program from there depending on what area they may be focusing on(Ex: NonDestructive Image Generation in your case).

Yeah. That is probably the right way to do it.

As far as the window drawing part... It is still very much a WIPz. For example everytime I work on something new in SourceCoder or try to start a new concept for a widget or improve one it often involves me writing more code in another module in SourceCoder in order to ease the development so I don't have to duplicate code a lot library-wise. One example is the pure python widget stuff. I recently finally got the CustomCheckBox from the wxPy wiki ported and updated and is now merged into what will become wx.lib.checkbox.GenCheckBox in wxPython4.1.1 . I added some helper functions/mixins to snag graphics for example. The native renderer stuff helps with the drawing of for example the checkbox graphics and whatnot. Other widgets sometimes need to be refactored so I can rip just the drawing methods out of them to make things easier.

As far as the matrix class goes. That is a can of worms in itself if you don't understand how matrix math(it often confuses folks) works, because besides just basic matrix operations you could send/pass a random/arbitrary matrix to be multiplied and it could cause unpredictible results. Also besides scaling the graphics, you have to deal with whether or not to rasterise fonts as they are finiky because wx.Font first arg doesn't accept a float.

As far as using actual native os c widgets, I'm still playing around with streaming and alpha code to try and get some stuff to work(it half works on MSW atm thanks to help from other wxPythoneers) Ex: TaskBarButton I've played with for like 5 years until recently we figured out the alpha issues. Now I can recreate what most folks would call a desktop shell in python with proper alpha(at least on windows atm) It would be awesome to support custom widgets also. wink wink tho I don't know if I'll ever get that far with the nodes.

But overall in the end my version will likely import a lot of other stuff already in the pure python lib from wxPy to help glue all the components together. I'll at least need to get my MCOW package into the library with the matrix as it will use some stuff from it also beforehand. And as far as wxPy4.1 there has been event based changes/fixes on the wxWidgets side that messed up a lot of things on the python side(actually the problem/pyfix has been known for like 10 years, they just finally got around to doing it on the wxWidgets end lol). I also have to go ahead and write me a replacement for the agw aui notebook. That will be a chore in itself making a better one from scratch that wont rely on agw aui and will work with wxPy4.0 and wxPy4.1+ and support vector. It will definitely take a while to get the notebook done so that SourceCoder doesn't have to hack around focus issues because of the new fixes. Then at that point I'll update my MCOW lib widgets to support vector. ... and in the mean time, I just chug along here and there working on whatever in my spare time. Ex: wxnodegraph is one of my many widgets on the WIPz/TODO list to get to a releasable state.

I am closing this because It doesn't really have much to do with Gimel Studio itself. Though, I have enjoyed the conversation and am curious to see how your wxnodegraph works out. 👍

What exactly is "SourceCoder". It must be an application you're working on?

Probably the most promising custom widget set I've seen made with wxPython is DynaUI. Unfortunately, it isn't maintained (that I can see) and the license is GPL (pretty-restrictive for doing much with it).

Well, I guess you could call it an application. It is a dynamic code editor basically, so if that gives you any idea, then it basically does everything(tho it isn't the fastest since it is written in python). I use it for many things including developing widgets, watching movies, making meshes, painting, etc,etc... But it is a book at heart. I used to work in a printshop and with the internet and everybody always wanting to sell you a home use junk printer that you might as well throw away after it runs out of ink, basically the industry is hurting bad. It is a dying trade, but will never be dead. And there isn't a whole lot of open source tools, so that is an added expense for small businesses. Overall, when it gets released, it will help be the glue or binding with any program that has a api users can use to script/etc. But it is also a self documenting book. Long story... it has been in development for over 10 years, just to be short and sweet.

GimelStudio / Gimel-Studio

Questions about wxlibrary use #7