Version 9 of Tip 556: Add oo like widgets to Tk

Updated 2020-02-03 07:03:06 by HE

This page is for discussion of Tip 556

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

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,

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 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.