Sami: Process picker
====================
Width of location column, too wide, there is an open bug.
finish button: you can start the session right away if you don't want
to set up observers.
forward button: set up observers: there is the new concept of which observers
are active.
frysk monitor: clicking on a process timeline [X] box to make it go
away: doesn't go away. --> bug
The "close" [x] boxes for threads timelines are greyed out unless the
process is terminated. Possibly one should be allowed to clear the list
of timelines if there are too many threads. So the close box should be
active at all times.
scrollbar on right (vertical) in the timeline pane showing up when
there is no need.--> bug
setting up custom observers or editing existing observers hasn't
changed.
How does the user know that a standard observer has been
edited/changed? Once you close the edit window there is no visual
clue that it's not the default anymore.
Position of the buttons in the session druid window should be changed:
"quick debug" should stand out on its own, move away from other buttons.
Should there be a help button to tell the user what's going to happen
when he presses finish or forward? Hig says no help on an assistant,
but it seems that here the assistant is quite complicated.
clicking on an event in the timeline will show the backtrace in the
summary window.
double cliking on an event should bring up the source window -->
currently broken.
Lot of white space in the timelines, reason is that the [x] button can
be displayed for each. Is there a way to compress the windows?
Lots of NullPointerException' s coming up when the frysk monitor is
running.
Adding/Removing processes is still missing. This will be in the
monitor window, allowing the user to go back to the process picker
window.
General problem of limiting bad actions to happen, like make sure that
the user really intends to stop a process or slow it down by adding
observers to it.
Need to refresh the workflows pictures on the website.
Mike: source/assembly
======================
Sourcewindows on multiple processes: bug: there are currently 2 processes in
a source window instead of 2 source windows.
When sourcewindow is first opened: doesn't position it at the
executing line, just the line 0. Gnome bug.
source/assembly
grey column in the assembly pane is not needed ATM
Should this be split in the horizontal or vertical space?
This may be an option left to the user to choose.
Problem with vertical is that if lines are very long and function
names are also very long, it needs a lot of real estate.
correspondence btw source and disassembly: how to make that more
immediate/intuitive. It's hard right now to see what function the
assembly belongs to. also: "<foo pc+22>:" could be compressed into
"foo+22" --> saves some real estate.
Phil suggests that there is a column for each component of the
assembly window so you can hide maybe the "<foo pc+22>:" area. If we
use columns it may become a problem to hoghlight a row to follow the
PC os a selection in the source view.
When clicking on a source line, it should highlight the corresponding
assembly line (or group of assemby lines). I.e. no need for the PC to
be there in order to see the correspondence src<->assembly.
Things that are still mising from the workflows:
- core files
- click on breakpoints
- creat a new process
- restarting existing processes
Phil: what about a register watch? As opposed to a register window.
You can keep the reg window open and it will update.