Stephan Houben wrote: > Rick Johnson schreef: > > It seems to me the best solution is for the TCL/Tk folks > > to provide a configuration utility that stores user > > preferences in the registry, or some other OS provided > > mechanism, as to have these settings reset on every > > invocation of the application would be inefficient from an > > enduser perspective. > > You mean, like the existing .Xdefaults mechanism (yes Tk > also supports that on Windows), and the "option" mechanism?
Not "exactly" (see footnotes [1] and [2]). Those features are only available to the programmer. What i'm talking about is an "interface configuration utility" that _bypasses_ the programmer and allows the _enduser_ to reshape or reorder the interface widgets. For instance: (IMO) it is appropriate for a programmer to define the initial interface commands (be they menu commands or keyboard shortcuts, or other..), but it is not appropriate for the programmer to limit the placement of these menu commands (either by purposeful action or outright neglect), nor to prevent the redefining of keyboard shortcuts. Furthermore, many devs refuse to employ the resizable container widgets such as "tk.PanedWindow". I would argue that _all_ containers should be user-resizable, coupled with an application level: "reset all frames to default size" command. Typically, most software developers will provide a configuration dialog so that users can redefine keyboard shortcuts, however, this feature will only be available *IF* the developer decides to make it available. Even more rare, is the ability to re-order the menu commands as the user sees fit. Some large softwares like Eclipse and Open Office offer this feature, but again, the configuration power the end user is given remains at the discretion of the developer, and many times, the decision to omit these important configuration features is not a matter of discretion at all, it's just pure laziness. Realizing the ubiquitous nature of poor GUI interface design, and realizing the impossibility of hardcoding a single interface that will satisfy all users, i have come to the conclusion that an enduser configuration utility must be made available by the GUI library _itself_, thereby bypassing the prejudice and incompetence of developers entirely, and giving the endusers the ultimate power to reshape the interface as the endusers see fit. [1] I had read somewhere once, and my knowledge in this area is admittingly limited as i have not yet migrated to Python3's tkinter module, that the Option Database of legacy Tkinter (python2) was being deprecated in favor of the new ttk.widget styling defined in tkinter (python3). My understanding is that the legacy Option Database (which i have not utilized much myself) was merely a means by which certain widget attributes (typically: styling attributes) could be propagated throughout an interface -- so i doubt (but i could be wrong) that this feature would provide a _persistent_ means by which a user can reconfigure the interface outside of simple stylings. [2] However, if .Xdefaults provides a cross-platform _persistent_ storage mechanism, then all one would need do is wrap it in a friendly dialog that would be made available to every [Tt]kinter enduser (perhaps through a small button added to every tk.Tk window). And although Tk itself does not provide a built-in method for moving around menu commands, one could be implemented fairly easily using the methods of the existing menu components. -- https://mail.python.org/mailman/listinfo/python-list
