future coordination

[RonnyPfannschmidt]

hi, im one of the original authors, and as need arose i wanted to port the lib to gobject-introspection and continue the work

in due diligence i found your fork that was carrying on, and i'd like to coordinate the proceeding instead of just pushing the kind of half-dead old project forward

regards

[cfobel]

Hello,

I would be happy to coordinate on this. I must admit that our most recent development focus has transitioned to developing UIs in electron/javascript. However, I would be happy to cooperate with you in any way I can, e.g., contributing where/when I can, even transferring ownership of the repository if needed. I have recently ported a lot of our code base to support both Python 2.7 and Python 3.5+. I haven't done that for this package, but that is something that I could potentially contribute towards, if there is interest.

Our development on the pygtkhelpers package has been in support of our MicroDrop control software for our digital microfluidics lab automation robot. As such, our contributions have mainly been centered around features that were of interest to us, but we recognize that they may not all be of interest to many others...

Our main contributions since v0.4.3 have been:

Build/packaging:

• Switch to using versioneer for versioning
• Build as Conda package

UI:

• Add GtkCairoView: slave view containing cairo canvas
• Add GtkShapesCanvasView: view to draw a set of cairo shapes to a canvas (optionally loaded from an SVG file), with optional text labels sized to fit in the corresponding shapes.
  • For example, we use the shapes canvas to draw the shapes and text labels in our UI shown here:

• Add schema.SchemaDialog which creates a dialog based on a JSON schema.

  • For example:

    from pygtkhelpers.schema import SchemaDialog
    
    schema = {'properties': {'bar': {'default': 6,
                                  'maximum': 15,
                                  'minimum': 5,
                                  'multipleOf': 3,
                                  'type': 'integer'},
                          'foo': {'default': 'hello',
                                  'pattern': '^hello.*',
                                  'type': 'string'}}}
    dialog = pgh.schema.SchemaDialog(schema)
    dialog.run()

    displays the following dialog:

    

    Note error messages are displayed when entered values do not match validation criteria, e.g.:

    

• Add ui.animation_dialog function
  • For example, we use this to demonstrate loading a test board into our instrument in out MicroDrop software:

Other:

• Add gthreads.gtk_threadsafe decorator function to simplify explicitly running code in a threadsafe way

Known issues:

• Before we started distributing our releases as Conda packages, we renamed the Python package to wheeler.pygtkhelpers (this was done while development was being done out of the Wheeler microfluidics lab). Going forward, the Python package will need to be renamed.

Please let me know how I can help.

Cheers, Christian

[RonnyPfannschmidt]

hi,

thanks for the detailed update, personally i wanted to get started with pygtkhelpers again since i want to avoid all that electron/javascript stuff for my personal things

as part of getting that done i would like to ensure it working on GObject Introspection and on top of python3.6+ as well

the UI additions look fabulous and give me some nice ideas for enhancements/re-compositions that i will address eventually when we figure a way to bring the project forward that everyone is comfortable with

as far as i'm understanding ensuring microdrop will work exactly as expected will/should be a priority

as far as renaming goes, i believe renaming it back is rather simple i consider your fabulous work a friendly fork (although it was not coordinated back then, it could have just gotten the same pypi name) the main question is how to integrate the repos soundly and/or if its perhaps best to start with your history as a base

additionally i'm the author/maintainer of https://github.com/pypa/setuptools-scm and would love to eventually put it to use here as well, but only if you are comfortable with it as well ^^

cheers, Ronny

[cfobel]

Hi Ronny,

Thanks for you response. Please see my response inline below.

On Tue, Jun 26, 2018 at 7:30 AM, Ronny Pfannschmidt < notifications@github.com> wrote:

hi,

thanks for the detailed update, personally i wanted to get started with pygtkhelpers again since i want to avoid all that electron/javascript stuff for my personal things

I think this would be great. For personal projects, I would also like to have Python GTK an easy solution to get up and running quickly. We decided to shift UI development for our company’s product to electron/javascript because 1) it is easier to find HTML/javascript developers; and 2) we are able to support other platforms (e.g., tablets, phones, etc.).

as part of getting that done i would like to ensure it working on GObject Introspection and on top of python3.6+ as well

Sounds great. As many of the users of our legacy software rely on Windows, I am also interested in seeing a GObject introspection release combined with pygtkhelpers that is easy to install on Windows (e.g., as a Wheel and/or Conda package). We have already bundled pygtk2 as a Conda package, but haven’t had the chance to bundle a gio package.

the UI additions look fabulous and give me some nice ideas for enhancements/re-compositions that i will address eventually when we figure a way to bring the project forward that everyone is comfortable with

Thanks, sounds good to me.

as far as i'm understanding ensuring microdrop will work exactly as expected will/should be a priority

Yes, that would be ideal. However, I am certainly not opposed to migrating functionality out of the pygtkhelpers if it is deemed not suitable for the project.

as far as renaming goes, i believe renaming it back is rather simple i consider your fabulous work a friendly fork (although it was not coordinated back then, it could have just gotten the same pypi name) the main question is how to integrate the repos soundly and/or if its perhaps best to start with your history as a base

Thanks, I am happy to proceed in any way here. I have a lot more development experience (both related to Python packages and in general) now than I did when I first started the pygtkhelpers fork, so I suppose I was reluctant to reach out at the time.

additionally i'm the author/maintainer of https://github.com/pypa/ setuptools-scm and would love to eventually put it to use here as well, but only if you are comfortable with it as well ^^

This looks great. I have no problem with using setuptools-scm - I haven’t used it personally, but it looks great!

In general, since it has been such a long time since I started the fork, I think there may be a bit of “cruft” that built up that we never actually put to use.

Therefore, may I propose the following strategy going forward?

• We use the your original pygtkhelpers code as a base for future development
• I will isolate the parts of the library that that microdrop actually depends on and clean up the git history into commits grouped by feature
• We can together decide which features (if any) make sense to merge into the master

What do you think? This is just off the top of my head, so please let me know any ideas you have.

I was also wondering how you were thinking of handling support for GObject Introspection. Are you envisioning a single branch that supports both pygtk2 and gio? Or are you planning to drop support for pygtk2? Or two separate branches? Other ideas?

Cheers, Christian

cheers, Ronny

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sci-bots/pygtkhelpers/issues/1#issuecomment-400274401, or mute the thread https://github.com/notifications/unsubscribe-auth/AAyQO7uVJhsFzLjbgj-MPVd5eJEGiwaLks5uAhs6gaJpZM4U1L_4 .

​

[RonnyPfannschmidt]

wrt gobject-introspection - im currently thorn between different approaches, the last experiment with porting was a bit of a pain and i'm wondering about creating a codebase that supports migration of pygtk to gobject introspection

the last experiment on porting to gobject-introspection failed with a lot of segfaults/detail issues, and i'd like to take it slower this time

as for combining codebases, both approaches work for me (take new, start form old and fetch features), i'd like to deffer the decision for when you have a basic understanding of the actual effort involved in sorting those things

as i'd rather push in a few deprecation's in 1-2 years than throw an unreasonable amount of work on you

i will experiment with GI porting mechanisms in the next 1-2 weeks and would appreciate a estimate of the effort you'd need for the taking appart of things

Cheers