UI discussions 2007-02-08

UI discussions 2007-02-08

[Andrew Cagney]

[Note: next meeting 9:30 US East time, 2007-02-14; double clash thursday]

Elena, Kris, Sami, Mike, Phil, Rick, Mark, Scox, Nurdin, Tim?
Moller sent apology.


Session Assistant
-----------------

Mike and Sami's changes were reviewed.  Agreed much better.  The follow 
list the "nits" identified for each page:

-> Session Manager
- Again need to make how to create a new session clearer
- "edit" button should be removed for now (it can come back later when 
it really does edit the session - a more advanced concept)

-> Add Assistant introduction with (go away tickbox)
HIG suggests that an assistant start with an overview window explaining 
what will happen next.  Should include a tick box (and include in 
preference) to not show again - so it doesn't get anoying.

-> Try adding a task picker - debug or monitor chooser here

-> Process Picker
- LHS and RHS lists should be identical
- LHS and RHS lists should be same size
- Start with just PID, and name; and way to add others

-> Observer Picker
- give threads observer defaults - fork, clone, exec, terminate; and 
catch backtrace
- improve help text for each observer
- add a "save" button?


Source Code Window
------------------

- fix "continue" button, wired to "run"
- when no source code, display raw assembly in source window
Means creating a fake "dom" or source code object so that the Source 
Code Window can't tell the difference - polymorp.
- ensure selected frame always highlighted
- drop line numbers (by default?); save real estate
- highlight as much of "current line" as possible: if .debug_line 
indicates entire line, highlight hard left to hard right; if .debug_line 
indicates partial-line, highlight part; if .debug_line indicates 
multiple lines, highlight all.
- needs keyboard short cuts
- step button should not pop-up a process picker; step is for selected 
thread only; add menu for more complex cases
- "thread id", not "tid"; better or bonus marks for finding the name in 
the stack backtrace
- start looking at an integrated source/assembly view


Monitor Window
--------------

[from last week] Brief discussion about what should happen when a user 
clicks on an event:
-> below the timeline, the backtrace and source code for the event is 
displayed


Command Line
------------

[from last week] The following options have been proposed:
-> frysk --debug PID : brings up the debug window directly
-> frysk --terminal : brings up a monitor with the terminal dominating
-> frysk --monitor PID : brings up the monitor window
[also]
-> frysk --session SESS : starts the specified session
-> frysk <core-file> : brings up the debug window on the core file



Next Week
---------

Custom Observers
?

/

UI agenda 2007-02-14 @9:30 US-EST

[Andrew Cagney]

Note different time -> This week only 2007-02-14 by 9:30 US-EST <- note 
different time.

These are the agenda items so far identified; pick two?

Custom Observer - sami
Monitor - sami
HPD - scox, tim

(I'm trying to not schedule too much so that each meeting comes out with 
a few action items that do get actioned and not a long wish list.)

Over comming weeks:

Disassembler Window
Register Window
HPD interface.
utilities
Session Assistant
Source Window

Re: UI agenda 2007-02-14 @9:30 US-EST

[Elena Zannoni]

Thanks for posting this, and also for the notes.
talk to you all tomorrow


Andrew Cagney wrote:
> Note different time -> This week only 2007-02-14 by 9:30 US-EST <- 
> note different time.
>
> These are the agenda items so far identified; pick two?
>
> Custom Observer - sami
> Monitor - sami
> HPD - scox, tim
>
> (I'm trying to not schedule too much so that each meeting comes out 
> with a few action items that do get actioned and not a long wish list.)
>
> Over comming weeks:
>
> Disassembler Window
> Register Window
> HPD interface.
> utilities
> Session Assistant
> Source Window
>

Re: UI agenda 2007-02-14 @9:30 US-EST

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On Tue, 2007-02-13 at 16:34 -0500, Elena Zannoni wrote:
> Andrew Cagney wrote:
> > Note different time -> This week only 2007-02-14 by 9:30 US-EST <- 
> > note different time.
> >
> > These are the agenda items so far identified; pick two?
> >
> > Custom Observer - sami
> > Monitor - sami
> > HPD - scox, tim

My pick would be hpd!

> Thanks for posting this, and also for the notes.
> talk to you all tomorrow

I'll setup a vnc server so we can easily interact together.
Ping me on irc.gimp.org #frysk.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Minutes 2007-02-14 @9:30 US-EST

[Andrew Cagney]

Present: Rick, Phil, Mike, Cagney, Elena, Moller, Kris, Stan, Tim, 
Jonathan, Mark, Sami, Nurdin

(snow in Toronto meant some people arrived late)

HPD command line.
-----------------------
Stan and Tim provided a walk through.

tab-completion:
- per bug(?), for a full completion, should append a space as that is 
the next thing the user will type, vis:
help<tab> -> help_

attach:
- HPD syntax is <<attach program pid ...>>, per bug (?) the <<program>> 
is redundant, and just the list of pids need to be provided
- attach needs to provide direct feed back that the operation is 
completed, for instance by displaying the line of the main thread

print:
Working in some cases.  Need to expose code to more stress testing.

help:
Simple help works, but <<help sub-command>> doesn't display the more 
specific information.

breakpoint:
The syntax needs to review the HPD, in particular how to specify 
file#line or foo(int) or file#foo(int) or #glibc.so#printf or ...; the 
syntax is powerful and follow pattern matching (but may contain 
limitations).  Most important the wart of having to specify 'foo(int)', 
caused by using ':' as the breakpoint separator needs to be avoidable.

additional comments and notes:

threads and thread groups?
The HPD describes how the prompt can change, reflecting which threads an 
operation will apply to.  For instance:
  [1.1,1.2]> break foo
applies the breakpoint to both threads.

transcript mechanism?
is there a command for capturing operations (hpd defines one) so that it 
is possible to capture how people are trying to use the interface.

registers?
Brief discussion about adding a way to print registers; was noted that 
this requires core changes, in particular changing 
frysk.proc.Task.registers so that they are described in terms of 
frysk.value.Value - i.e., the registers have a type.

disassembler?
Brief discussion about adding a disassembler; was noted that 
frysk.rt.StackFrame will need to be modified adding a frysk.rt.Symbol 
object that contains the function address, name, and bound; and then 
disassemble based on that range.


-----

Custom Observer:

Meta-discussion: is the custom observer at the right level.  For 
instance, is it reasonable to be trying to implement all possible 
functionality graphically, or provide a basic edit menu and then have 
more complicated events added as custom event handling code.

Conclusion: custom observer is at the right level, with edits.  In 
particular complicated event trigers should be handled using programming 
interface.

-> default should be to capture information, but not try to log it.  For 
instance, don't write to log window, instead let user examine event 
using monitor view.
-> rename observer to "event"; its an event trigger that is being selected
-> +/- buttons in filter et.al. confused; for instance, why does the 
first action have a "+"; suggest looking at thunderbird and evolution's 
filter windows
-> 'ok' at bottom should make it clear what clicking on it does
-> action arguments should be disabled when they don't apply; for 
instance, catch stack backtrace requires no argument
-> "filter" and what it is doing misleading; should be clear that a 
filter is a customization of the event