- offer keyboard short cuts for zooming '-' and '_' for zooming out and '=' and '+' for zooming in. Zooming can now only be done by scroll wheel. - also pan when M1 (first mouse button) is pressed. M3 emulation is not so handy, especially whenM1 has no function anyway. - allow panning with arrow keys, use CTRL for smaller steps and SHIFT for bigger steps. Panning now can only be done by mouse. - offer CTRL-Q for exit/quit
Implementing these propositions will allow users to zoom and pan with more easy with device (mouse or keyboard) of their choice.
> - offer keyboard short cuts for zooming '-' and '_' for zooming out and '=' and '+' for zooming in. Zooming can now only be done by scroll wheel. > Agreed. Just a SMOP > - also pan when M1 (first mouse button) is pressed. M3 emulation is not so handy, especially whenM1 has no function anyway. > M1 is currently used for selection (if a graph object has a URL), and planned for use for node/edge insertion in drawing mode - in the same way that dot.tcl does now. > - allow panning with arrow keys, use CTRL for smaller steps and SHIFT for bigger steps. Panning now can only be done by mouse. > OK > - offer CTRL-Q for exit/quit >
OK Its on the ToDo list - just no time myself right now. If anyone wants to take a shot at coding this, the generic key-binding table is in: lib/gvc/gvevent.c:718 These event definitions are common to both xlib and gtk windows.
[pander] Extended requirement are:
- CTRL-R and F5 for reload - monitor timestamp and reload automatically like evince is doing. An interval of two seconds would suffice
Can these be added to the bug ticket? [ellson] Yes, but what platform is this for? On Linux, the X11 renderer monitors the source graph with inotify() so that it automatically updates when the source changes (try the "vimdot" demo")
I don't understand why a polling mechanism would be needed if inotify() is working?
Are these only required on non-inotify() platforms?
[pander] I use Ubuntu and was under the impression that it was not working. I have verified it and it seems that for large graphs, x1 is already reading the file without it is completely written. This results in an error. Would it be possible to have a setting that adds a delay to inotify?
[ellson] I wasn't aware of this. Possibly I'm using the wrong inotify() events.... I'll investigate.
Related to this bug, I was also trying to get an event for a new graph on stdin, but ran into a problem that the graph parser sees an empty graph on the pipe after every good graph (trailing newlines perhaps). This is related because perhaps the right solution is to buffer input until a valid, non-empty graph can be parsed from it.
John Ellson wrote: > On 06/08/2010 04:56 PM, Pander wrote: >> Hi all, >> >> Can anyone tell me if it is possible to start -Tx11 directly in full screen? > > Not currently. Sounds like another wish list item?
Jes, can you add that to that particular bug issue?
What would be a good default? I think full screen.
Can you also add F11 for 'real full screen' that removes the window decoration? Pressing F11 again will restore window decoration.
> What would be a good default? I think full screen.
Maybe for cell-phone screens, but please not for my dual monitor desktop.
For "vimdot" two windows are opened, so full-screen would only obscure the vim window.
For small screens I do see that an option to open in full-screen mode could be useful.
A side note: command-line option processing in graphviz is currently a mess. If somebody wants to add options, please be prepared to look at the bigger job of cleaning up option processing in general.
> Can you also add F11 for 'real full screen' that removes the window decoration? Pressing F11 again will restore window decoration.
Could be ok. Are there other apps that provide this behavior this way?
On my Fedora desktop, double-clicking the window title-bar "maximizes" the window (not quite full-screen). Isn't it sufficient to leave this kind of behavior to the window manager?