Tix Vs Pmw which is better to use?

[Cimarron Taylor]

gregm at iname.com (Greg McFarlane) wrote in message news:<a3a83607.0205132310.773b6466 at posting.google.com>...
> It seems that Cimarron has not read (or did not understand) the Pmw
> documentation, otherwise he would have found that none of his
> frustrations are due to Pmw itself.  Perhaps the documentation
> could be improved? Please let me know.

Thank you for responding to my comment.  I would very much appreciate 
your feedback on the following suggestions and questions related to Pmw:

1. how to improve the documentation
2. how to improve the source code
3. how to improve the interface
4. the (unanswered) question at the end of my previous comment

Item 1 - how to improve the documentation
-----------------------------------------
You are correct: I did not read *and* understand the Pmw documentation.  

I did however read what I believed at the time were the relevent sections
and in retrospect I think I can suggest some improvements which would have
made it easier for me to understand:

With respect to the setentry() method, I now realize I must have missed
the example in doc/howtouse.html.  However this method is not mentioned
in the class-specific documentation (doc/PmwCounter.html) I did read.
Therefore I propose that the name of each public method, inherited 
or otherwise, appear in the html file for the specific widget.  That is,
instead of the following text

  Only methods specific to this megawidget are described below. For a 
  description of its inherited methods, see the manuals for its base classes.
  In addition, methods from the Pmw.EntryField class are forwarded by 
  this megawidget to the entryfield component. 

I would write

  The counter widget, like all Pmw widgets, inherits the following methods 
  from Pmw.MegaArchtype:

    addoptions(), cget(), component(), componentaliases(), 
    componentgroup(), components(), configure(), createcomponent(),
    createlabel(), defineoptions(), destroy(), destroycomponent(),
    hulldestroyed(), initialiseoptions(), interior(), isinitoption(),
    options()

  The counter widget also delegates the following methods to its 
  Pmw.EntryField entryfield component:

    checkentry(), clear(), invoke(), setentry(), valid

Item 2 - how to improve the source code
---------------------------------------
Given that I also went immediately to the source code to find what
I wanted to know, I would also suggest changing the source code in
the following way: each function described in the documentation sould
have a docstring which identifying it as part of Pmw's documented 
interface.  I would also include an explicit reference to the relevent
section of the documentation.  For example, instead of

    def increment(self):
	self._forceCount(1)

I would suggest

    def increment(self):
      """Increment the counter once, as if the up arrow had been pressed.
         See also doc/Counter.html""
	self._forceCount(1)

Item 3 - how to improve the interface
-------------------------------------
Regarding my statement that it is often necessary to violate the
encapsulation to set the value of a widget, I stand corrected.  
However I believe the Pmw interface would be much improved if each
widget would support the following methods:

   def getvalue(self):
      """returns a string representing the visual value of the widget"""
      ...

   def setvalue(self, value):
      """sets the visual representation of the widget to the specified value"""
      ...

This way instead of using settext() for a textbox and setentry() 
for a counter, I could simply use setvalue() in each case and dispense
with my artificial wrapper classes.


Item 4 - the (unanswered) question at the end of my previous comment
--------------------------------------------------------------------
I would like to add to my interface a text area which would contain the 
output of a separate long running make process I need to spawn.  
I can't just call system() as that would block the entire ui 
(unless I setup a separate thread).  I've tried using fork() and exec() 
but that seems to cause an X server error which kills the entire
application.  The best thing I've found so far is to run the separate 
process in an xterm window by creating an instance of the following class:

  class StartMake:
     def __init__(self, target):
        os.popen('xterm -e make %s &' % target)

My question for you is have you ever solved this problem with Tkinter/Pmw?
If so, what did you do?  If not, do you have any suggestions?

Lastly, thank you again for the ongoing attention and support you 
have provided for the Pmw package and to the community of developers 
who are using it.  I have found it very useful.

Cim