Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Russell Keith-Magee
    @freakboy3742
    The pack layout builtin to Toga was my quick-and-dirty attempt to get something CSS-like that worked.
    trying to be as CSS like as possible, while not promising all of CSS.
    In the meantime, hacking something that is “CSS-grid-like” into Pack would be amazing
    Russell Keith-Magee
    @freakboy3742
    Ok - I need to go cook dinner… glad we finally got to the bottom of the problem, though!
    Olga Bulat
    @obulat
    Me too :)
    Paul m. p. P.
    @pmp-p
    @paulproteus hi, i actually put all calls in an async queue by default to have batching, explicit await is only when you want to get a primitive type/boxed pointer return value from host
    also gc is called only when enough frametime left to avoid framedrop
    Asheesh Laroia
    @paulproteus
    @pmp-p Very sensible. Is there a link to your code?
    psytron
    @psytron
    Do beeware apps necessarily include the python source code inside? Or can they be compiled apps ?
    Russell Keith-Magee
    @freakboy3742
    @psytron I’m a little confused about the question. BeeWare apps, are by definition, Python apps… so how would you have a “compiled” app?
    psytron
    @psytron
    Like nuitka or pyinstaller
    Russell Keith-Magee
    @freakboy3742
    Still not completely sure I understand the question - if you’re asking “is there a way to produce a .exe from any beeware tool”, the answer is no.
    But you also need to be clear about what you’re asking for.
    psytron
    @psytron
    Is it possible to ship stand alone app that doesn't
    Russell Keith-Magee
    @freakboy3742
    Beeware isn’t a tool. It’s the umbrella project name.
    Toga is a library that is part of the BeeWare toolchain. It’s a Python library. You can use it wherever you can use Python. You could, I guess, use Pyinstaller or Nuitka to compile an app that uses Toga
    psytron
    @psytron
    Ok, briefcase then
    Russell Keith-Magee
    @freakboy3742
    Briefcase is a BeeWare tool
    And it very deliberately doesn’t do “single executable” output.
    psytron
    @psytron
    Deliberately ?
    Russell Keith-Magee
    @freakboy3742
    My experience has been that those approaches just don’t work in the general case.
    Yes, you can get code to run. But Python code is written to be interpreted. Trying to put it into single binaries and pretending that it doesn’t work the way it does when you run python myscript.py is a recipe for disaster.
    Briefcase is very deliberately designed as a “get a working python interpreter to the end user in such a way that they never know they’ve got a python interpreter doing the work."
    This means the Python code is always running they way it was written to be used - as an interpreted program.
    psytron
    @psytron
    Ok, thanks :)
    Russell Keith-Magee
    @freakboy3742
    (As a side note - this is why .egg failed as a distribution format. Python code doesn’t even like being wrapped up as a zip file, even though the Python interpreter theoretically allows importing from zip files.)
    If the problem is “but I don’t want to distribution my source code with my applicaiton because it’s commercially sensitive” - that’s a different issue
    And there are ways you can mitigate against that - for example, only ship the PYC files, and not the .PY files.
    psytron
    @psytron
    What about data communication between toga webview and python ? Any thoughts on roadmap for that ?
    Russell Keith-Magee
    @freakboy3742
    It’s not on my roadmap, no. If you want to contribute something, I’m not morally opposed to it.
    psytron
    @psytron
    "
    Russell Keith-Magee
    @freakboy3742
    Because, as I’ve told you before - Toga is a widget toolkit. It’s a direct response to the idea that “oh, we can build our UI as a webiview” being, IMHO, a bad idea.
    psytron
    @psytron
    Wow cool ! :) pyc only files, I didn't know that, thanks
    Russell Keith-Magee
    @freakboy3742
    That said, there are other potential uses for being able to invoke Python code as a response to a webview, so if someone was to contribute code to do it, I’ll at least consider it (API and implemetnation notwithstanding)
    psytron
    @psytron
    That would be sweet !
    I check back on this project time to time hoping it will be able to be used like electron / react , but with Python. Then anyone could bolt on their favorite pre-built web UI and use Python for system / data aspects, then we wouldn't need electron and there would be a huge number of developers
    This is why I think BeeWare is one of the most exciting instruments
    Russell Keith-Magee
    @freakboy3742
    Ok - so don’t hold your breath on that, because, as I keep telling you - that is explicitly what we’re trying to prevent people doing.
    We don’t want people bolting Web UIs onto an app. We want native apps. Built to run natively.
    psytron
    @psytron
    Yeah I totally agree you're right for most applications I want naive UI too
    I just have some twisty 3D WebGL GUI and game that I wanna package with Python backend
    3D GUI with smooth touch drag and gravity effects
    psytron
    @psytron
    That would be so awesome , since everything else already works great with toga webview
    60 FPS smooth animation, touch events in WebGL renderer , works so well in toga webview
    Russell Keith-Magee
    @freakboy3742
    Well, again - as I keep saying - if you want it, you can build it and submit a PR. The WebView APIs have mechanisms for registering DOM triggers… work out how they work, and come up with an abstracted API for registering a Python callback on a DOM event, and turn that into a PR.
    psytron
    @psytron
    Ok, I will try to replicate the CEF Chrome embedded framework interface
    Also, Thanks for the *pyc tip !
    Russell Keith-Magee
    @freakboy3742
    No problems! As a heads up, it can cause some interesting behavior if you’ve got code doing a introspection (e.g., looking at the __code__ object). It’s also fragile if you have to work across Python versions - but in the context of a briefcase app, you’re shipping the interpreter that will be used, so that risk is virtually zero.
    psytron
    @psytron
    Ok
    Thank you