Generic widget/frame placement

[slightlynybbled]

Would like to have an app.addFrame() or something similar in which I could add a generic widget that I have created in tkinter. I usually like to subclass frames, so doing that at the frame level would be quite handy:

class MyCustomFrame(tk.Frame):
    def __init__(self, parent):
        tk.Frame.__init__(parent)
        # .... stuff within the frame ....

app = appJar.gui()
app.addFrame('my_custom_frame', MyCustomFrame(), row=2, column=1)
app.go()

I don't know how difficult this is to integrate, but it would help me out a ton and would make the tool that you are building more generic and flexible.

[jarvisteach]

Interesting request. This is (somewhat) outside the original remit of appJar - appJar was always intended as a self contained set of widgets, all managed by appJar, hiding the complexity of OO and tkinter from the user (middle/high school kids).

However, I can see how this would be useful to everyone else! And, it's already (kind of) possible...

You can access the internal functions used by most add functions:

widg = MyCustomFrame("name", app._gui__getContainer())
app._gui__positionWidget(widg, 2, 1)

It would be easy enough to wrap these up and expose them as a function.

It would be a bit more work to allow the user to manage the widget through appJar, but as they made it themselves, they could also manage it themselves?

[slightlynybbled]

This is a plausible path, thank you for the guidance! Perhaps it would be more appropriate to describe the expected functionality of the custom frame that is required in order for it to be fully supported by appJar within the documentation.

Perhaps this is related to issue #147. If you create some global appJarWidget class that simply contains the minimum functionality required in order to be an "appJar compatible" widget, then an informed user could simply subclass that widget and implement the minimum functionality for themselves. This might also be a very good introduction to your students to OO since the majority of an application would be linear and the creation of a custom widget would only be one part.

An additional benefit to coding up a class intended to be subclassed would be easier contributions. Right now, I read the appJar.py and don't really know how to extend it directly. If I had a single appJarWidget class that showed me the functions to add, then I could rely on that API for guidance without having to understand the internal workings of the framework to a high degree.

I freely admit that I have the capability to write a full tkinter program - and have in the past - but I always have something of a learning curve on implementing the non-native elements (i.e. links, tooltips, etc) that you have fully integrated into your framework. In essence, I want to use appJar to manage 90% of a typical GUI and then to add a custom widget for the other 10%. I suspect that I'm not alone here.

[jarvisteach]

Thanks for all the feedback. And you're right, this is exactly where appJar should be going!

I never really envisaged it being more than a quick hack, to allow my pupils to build simple GUIs. But, when I changed schools, I renamed it, stuck the code on GitHub, and moved the documentation to the cloud so that it was still available to my ex-colleagues - and now it's got 50 stars, and people from around the world requesting features and reporting bugs!

I'd love for it to become a useful tool, hence issue #147, and be a lot easier for people to use/contribute to/extend, as well as actually internally be much cleaner.

One issue I have right now though is time, I only really get to make changes during the holidays - I'm aiming for a feature/bug fix release (0.7) at the end of May, with another at the beginning of July, before the big overhaul 1.0 release at the end of August.

Anyway, I like the idea of providing a generic frame as an abstract class, that people can use. It can then force them to implement certain getters & setters, as well as ensuring it supports the various features of appJar. And I think this falls in quite nicely to the overhaul mentioned in #147. If I re-engineer the existing widgets to all conform to this, then it would make it quite obvious how everything works, and allow people to implement their own easily enough...