On Fri, 2002-12-06 at 04:00, Jason R. Mastaler wrote:
> Some things I think would be useful in tmda-gui.
>
> - General:
>
> * The initial frame is a bit confusing IMO. The address
> generation/checking interface comes up right away, and the `Pending'
> button is sort of lost in the middle there.
>
> It might be better to launch an overview frame initially , with
> buttons to go to the address or pending interface from there (or
> exit).
I agree with you, this is a bit confusing, although I did it this way
because I think the main purpose for a user would be to quickly
calculate (or do they say compute ?) a tagged address.
My priority was (and still is) to make it work. However, I'll make the
main window tabbed, so that the different tools are just one click away
in the same frame.
> - The pending interface:
>
> * I'm testing the pending interface with a 12MB pending queue with
> 1900 messages. Not small, but I suspect many users will have one at
> least this large. On a fast workstation, it takes upwards of 25
> seconds after I press the `Pending' button before the pending frame
> appears. I'm not sure why it's taking so long. Hopefully tmda-gui is
> not reading the contents of each message as it loads?
No, it should not. what gives:
$ time tmda-pending -bT
Just to make sure this doesn't come from the new Pending.py module.
> * It's not clear that the app is doing anything during this time. If
> the speed can't be improved, it might be better to give the user
> some indication that it's processing messages---I initially thought
> the app was hung. Same comments for `Refresh'. If not this, at least
> launch the pending frame first before processing, otherwise it looks
> like the button got stuck.
OK, I note it. I'll do a progress-meter (I'll most probably need one for
the networked mode anyway).
> * It would be nice to be able to sort the messages in the pending
> queue in a variety of ways. Time of message (chronological and
> reverse chronological), and perhaps alphabetical and reverse alpha
> from either of the other two columns.
Yes, this is on my todo list.
> * It would be nice to toggle the left column between displaying the
> message id (e.g, 1038203674.1428.msg) and the calendar date.
Nice one, I add it on my todo list.
> * Perhaps Defaults.TERSE_SUMMARY_HEADERS should be used instead of
> hardcoding the contents of the right two columns?
Yes, it used to work like this before I implemented the SplitterFrame's.
I need to do a multi-frames splitter class before taking this one into
account.
But it's on the todo list.
> * The top button bar showing the message actions (Rfsh, Show, W, Rel,
> etc.) is a bit ambiguous (i.e, what does `B' mean?). There seems to
> be enough room there to spell out the actions in their entirety. For
> extra credit, you could dynamically resize the buttons if the frame
> width is resized smaller than the button bar.
ok, I'll put the full sized labels, until I can come up with nice icons.
> * I'd be nice if the arrow keys worked in addition to the mouse, and
> also if certain keys were bound to the various message actions (e.g,
> `b' for blacklist, `r' for release, etc.). PageUp and PageDown would
> be helpful to scroll through the message list as well.
ok, I'll add this to the todo list.
> * I think by default, the user should have to confirm his message
> action before it's executed. Perhaps with a pop-up box prompting
> ``Are you sure you want to Delete foo?'' for example. Configuration
> variables can inhibit the confirmations for ``power users''.
ok, added to the todo.
> * When a particular message is highlighted, it would be cool to be
> able to bring up the `Message' menu through a right mouse click
> rather than having to return to the top of the frame to dispose of
> the message.
I don't know how to do this yet, but I'll think about it.
In the meantime, you can also pin down the Message menu and make it
'always on top'.
> * `Show' doesn't work for me. The display buffer shows the message
> contents in a single loooooonnnnng column instead of line by line.
I don't have this problem.
Was it before or after my last commit (the one with the networking code
added) ?
> * `Release' doesn't work for me:
>
> Exception in Tkinter callback
> Traceback (most recent call last):
> File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", line 1285, in __call__
> return apply(self.func, args)
> File "bin/tmda-gui", line 632, in MessageRelease
> self.listbox.ReleaseSelectedMessage()
> File "bin/tmda-gui", line 433, in ReleaseSelectedMessage
> processMessage(self.msgs[int(self.curselection()[0])], command='release')
> File "bin/tmda-gui", line 115, in lib_processMessage
> return '\n'.join(data)
> TypeError: sequence expected, None found
Fixed. I'll probably commit tonight (France/Paris timezone).
> * `Delete' unlinks the message, but doesn't refresh the display, so
> trying to re-display the message results in:
>
> Exception in Tkinter callback
> Traceback (most recent call last):
> File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", line 1285, in __call__
> return apply(self.func, args)
> File "bin/tmda-gui", line 615, in MessageShow
> (hdr, bdy) = self.listbox.GetSelectedMsgContent()
> File "bin/tmda-gui", line 458, in GetSelectedMsgContent
> command='show').split('\n\n', 1)
> File "bin/tmda-gui", line 105, in lib_processMessage
> msg = Pending.Message(msgid)
> File "/usr/home/jasonrm/cvs/tmda/dist/TMDA/Pending.py", line 390, in __init__
> raise MessageError, MessageError('%s not found!' % self.msgid)
> MessageError: TMDA.Pending.MessageError:
> 1036426240.24133.msg not found!
I bet this one was the same as the previous, so it should be fixed.
Wew, this was a pretty long list ;)
Thanx, Jason, for all these suggestions.
David
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers
