Tip 556: Add oo like widgets to Tk

This page is for discussion of Tip 556

You can find linux, windows and mac tclkits at https://sourceforge.net/projects/kbskit/files/tip556/

https://sourceforge.net/projects/kbskit/files/tip556/kbsvq8.7-gui+graph+path.exe is tip 556 with rbc graph and tkpath widgets from tip 510 included.

With the implementation you can:

  • create oo class like widgets in C (tko::frame, tko::labelframe and tko::toplevel are included)
  • oo class like widget as superclass and extend it (tko initfrom ?tkoclass?)
  • wrap existing widgets in oo class like widgets (tko initwrap ..)
  • create to oo classes with option handling (tko initclass)
  • dynamically add, delete, show and hide options at class (tko option* ..) and object level (my _tko option* ..)

bll 2019-12-18: Is there a proof-of-concept example widget?


RZ - 2019-12-18 15:16:53

::tko::frame ::tko::labelframe and ::tko::toplevel with same functionality like original widgets. See also in the man page tko.n

I have also a rbc graph widget ready. I will tip it after this tip gets accepted. Should I include it in the ready to run tclkits?

oo::class create W {::tko initfrom ::tko::frame}
oo::define W method xy {args} {puts $args}
W .w
.w xy

GWL - 2020-01-23

See the OO implementation, in pure Tcl, of PTk for additional ideas.

RZ will do. thanks

HE 2020-01-30: Why needs this to be integrated into Tk/Ttk? There are a couple of OO widgets and megawidgets out there. So this new base OO widgets are only a parallel solutions as with tcloo and incrtcl in the OO world of Tcl. Wouldn't it be better to provide it as a separate package and to see if people really works with it? It can then be battery included as incrtcl, if successful.

RZ The code uses internal functions. Therefore it needs to be in the core :( HE 2020-02-03: If it is so deeply integrated, why it is not an additional interface for the existing widgets? On the other hand, why other could create object oriented widgets without such deep integration (like mentioned above)?

HE 2020-01-30: Moreover, I don't like to have again another set of widgets for the same purpose with slightly different functionality. And the provided functionality is far away from being an infrastructure for mega widgets.

RZ Which functionalite you are missing?

HE 2020-02-03: For a infrastructure there should be a documented way how the megawidget should be build. How to propagate configuration from the megawidget call to the included widgets. What about ballonhelp, what about cases where we need to communicate with the internal widgets? What about locale changes on the fly. And for sure, we need all existing wigets embeded in this infrastructure. A "infrastructure" will need to take care about all of this. Not only provide three base widgets,

RZ 2020-02-03: The goal of the tip was to provide a dynamic cget/configure functionality and not a whole "infrastructure" in one step. With using oo we get adding new methods and inheritance. And then there is tip558 and 560 which are targeting the same problem. Imho only after it is decided which one is on the core I would be willing to add more features.

HE 2020-01-30: I would prefer to have the same widgets accessible with different interfaces. Like what was one of the origin ideas of Themed Tk Widgets. Poorly that was dropped later with introduction of Ttk.

RZ 2020-02-03: could you give me a pointer to these "Themed Tk Widgets". I do not remember this discussion. Thanks.

RZ You can do this with using the tko initwrap .. function. HE 2020-02-03: Where is this an infrastructure when I, as the user of the package, have to do all the work by myself.

HE 2020-01-30: We should not make everything object orient only because we can do it. That is not the nature of Tcl.

RZ In Tk we have already objects called widgets. HE 2020-02-03: If widgets would be ojects in the object oriented way, we would not need this tip. To have objects (or to call something an object) and object oriented are two different things.

RZ 2020-02-03 With this tip you get widgets as classest. There are 2 kinds of classes. One is C-coded (the provided tko::*). Another one is wrapping existing tk widgets. You can then inherit from these classes and create your own ones. This is the main difference to existing widgets. These widgets are kind of "static".