Significant changes in DBF driver, I have rewritten the code
parsing and evaluating WHERE conditions. Testing of DBF driver
is desirable, especially with complicated WHERE conditions.
I have added db.test but currently only one simple test is available,
run it anyway (db.test test=test1), database must exist and set by db.connect.
Small fix in Postgres driver ( escape backslash ).
Significant changes in DBF driver, I have rewritten the code
parsing and evaluating WHERE conditions. Testing of DBF driver
is desirable, especially with complicated WHERE conditions.
I have added db.test but currently only one simple test is available,
run it anyway (db.test test=test1), database must exist and set by
db.connect.
Significant changes in DBF driver, I have rewritten the code
parsing and evaluating WHERE conditions. Testing of DBF driver
is desirable, especially with complicated WHERE conditions.
I have added db.test but currently only one simple test is available,
run it anyway (db.test test=test1), database must exist and set by
db.connect.
Small fix in Postgres driver ( escape backslash ).
just two questions.
The button d.m - options - launch tcltkgrass sometimes keeps on top of all
windows after I selected options - anyone else encountered this problem using
debian?
In the d.m. I set a raster on top and a vector below it but in the monitor the
vector was above the raster - intuitively I would say the the top layer in
the d.m. is also the top layer in the monitor.
but anyway, GRASS definitely matured! looks great! congratulations. Martin
On Tuesday 15 June 2004 17:49, Radim Blazek wrote:
On Sunday 13 June 2004 18:50, Stephan Holl wrote:
> - | '(' y_sub_condition ')' { $$ = $2 }
> + | '(' y_sub_condition ')' { $$ = $2; }
I fixed this, v.extract dissolve and path to MySQL header files.
problem (5.7 only, goes back >1 month)
'Add new map' only lets you pick maps from the current or PERMANENT
mapsets; NVIZ in 5.3 lists all mapsets in location.... ?
minor (5.3 too):
the "site size" slider is backwards
choose a consistent capitalization scheme
"Line Width" vs "site size"
Many new scripts and changes in tcltkgrass ( Michael Barton ).
minor point:
The d.m & the tcltkgrass menu don't close when you leave grass via
the command line. I realize you lose control of child windows to some
extent when you background them, but to be consistent with the d.mon
windows closing?
Martin wrote:
The button d.m - options - launch tcltkgrass sometimes keeps on top of
all windows after I selected options - anyone else encountered this
problem using debian?
Nope. (TclTk 8.3)
Does a "mouse over" the offending text help?
In the d.m. I set a raster on top and a vector below it but in the
monitor the vector was above the raster - intuitively I would say the
the top layer in the d.m. is also the top layer in the monitor.
You can think of it as a list of commands, the first instruction on the
list is drawn first; you build the display from the bottom up, not
the top down.. It's just a matter of perception really, e.g. are the
silhouettes of Tom Servo & Crow really watching you or the movie?
Anyway, the side that makes sense from a programming standpoint tends to
win, so that's why it's like that. The tree being open ended at the top
provides a tiny hint.
On Thursday 17 June 2004 12:44, Hamish wrote:
[...]
Martin wrote:
> The button d.m - options - launch tcltkgrass sometimes keeps on top of
> all windows after I selected options - anyone else encountered this
> problem using debian?
Nope. (TclTk 8.3)
Does a "mouse over" the offending text help?
well TclTk 8.4 - I tried to reproduce it, but so far no success. But as far as
I can remember nothing except launching tcltkgrass helped.
I will remember it next time it happens and give it a try.
> In the d.m. I set a raster on top and a vector below it but in the
> monitor the vector was above the raster - intuitively I would say the
> the top layer in the d.m. is also the top layer in the monitor.
You can think of it as a list of commands, the first instruction on the
list is drawn first; you build the display from the bottom up, not
the top down.. It's just a matter of perception really, e.g. are the
silhouettes of Tom Servo & Crow really watching you or the movie?
Anyway, the side that makes sense from a programming standpoint tends to
win, so that's why it's like that. The tree being open ended at the top
provides a tiny hint.
well, ok it makes sense from the "list of commands" point of view but
nevertheless it is quit a challenge to swap my intuition - wouldn't there
be an easy way to decide if I want to have the classical way or the command
way displayed?
Otherwise I have to get used to it ... :-), Cheers Martin
On Thu, Jun 17, 2004 at 06:18:26PM +0200, Martin Wegmann wrote:
On Thursday 17 June 2004 12:44, Hamish wrote:
[...]
> > In the d.m. I set a raster on top and a vector below it but in the
> > monitor the vector was above the raster - intuitively I would say the
> > the top layer in the d.m. is also the top layer in the monitor.
>
> You can think of it as a list of commands, the first instruction on the
> list is drawn first; you build the display from the bottom up, not
> the top down.. It's just a matter of perception really, e.g. are the
> silhouettes of Tom Servo & Crow really watching you or the movie?
>
> Anyway, the side that makes sense from a programming standpoint tends to
> win, so that's why it's like that. The tree being open ended at the top
> provides a tiny hint.
Well, but programs are for users
well, ok it makes sense from the "list of commands" point of view but
nevertheless it is quit a challenge to swap my intuition - wouldn't there
be an easy way to decide if I want to have the classical way or the command
way displayed?
I also feel that it's confusing (say, inverted).
So I vote for reversion of the stacking order.
Otherwise I have to get used to it ... :-), Cheers Martin
- wouldn't there