Jeremy Sanders wrote:
On Thu, 12 May 2005, James Graham wrote:
Attached is a simple patch that ought to:
Allow Ctrl+P as a shortcut for Print
Cause "New" to open a new window
Cause "Open" to open a new window
[...]
Okay. I've put in the Ctrl+P patch, and the New patch (slightly
modified). I had to fix a bug in the CommandInterpreter which meant
the same document was shared between each command line in different
windows! I now copy the environment so it's not shared. Also the
environment is made before importing things, so it should be cleaner.
Excellent :) I played with the code a little since then... I'll have to
look at how the new code will play with you bugfixes... in essence I
changed the behavior so that opening a file overwrites the current
window if it's a blank unmodified file. I also have drag and drop of
files from a file manager (apparently) working, and added support for
globbing of command line arguments (so something like veusz *.vsz will
open all veusz files in the current directory). Oh and a reload
button/command... but I'll test these things a bit more I think ;)
It probably also makes sense to make the working directory an
instance variable rather than a class variable (as well as any
others I haven't noticed). So that's one bug already.
I'm not sure it should be a member of the class. Doesn't it make more
sense that if you are opening files, the most likely place to find the
next file is in the same directory?
Right, the correct behavior is probably to initiate the new window so
that the working directory is the same as the window which opened it.
After that, each window should be able to change working directories
independently.
Cause NameError exceptions when loading a file to be dealt with like
IOErrors
Which doesn't work because the console traps and displays the error
first. Is there an easy elegant way to make the error propogate when
calling from a GUI object but not when calling from the command line?
The "New Dataset" dialog is fun but it should probably have a menu
item and be called "Create Dataset" or something that makes it clear
it's not
It has a menu item doesn't it? Probably should change as you suggest
to "Create Dataset".
Yes, I missed that. Sorry :)
An easy way of converting a fit into a function would be good (maybe
the paramaters for the fit should go into some sort of grid with a
column for the name and one for the value? This would make entering
things easier but the results harder to copy)
I'm not sure how to do this cleanly. I might have to break open the
python parser, substitute in the variables and work out how to write it.
Well, if you know what the variables names are, it's not hard to parse
the expression as a string and do string substitution to replace the
variable names with their values. But that's not really clean.
Is keyboard focus in the settings panels going to the labels a result
of the context menus or is it normal? In either case, it seems
suboptimal...
I made it so that it was clear there was a context menu. Otherwise
keyboard users wouldn't be able to get the menu. Try it now with the
new QTable properties code. Any suggestions are welcome...
The problem with the new setup is that the label behaves like
left-clicking will have an effect, but it doesn't (well it focuses the
table cell but that doesn't _do_ anything). I really don't know what the
solution is (short of dropping those functions which I assume you
use...). Maybe if clicking selected the whole table row (rather than
just a single cell) and the context menu was defined on the row?
--
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"
-- Dr. Bunsen Honeydew & Beaker of Muppet Labs
