Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
The problem is just what it says:- it's too early to use a variable at
this point, sorry my mistake. What is surprising is not that it failed
to compile for some systems, but that it did compile at all on others. I
am uploading changes now.
David
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
I have been using v.digit under with my latest build on Solaris. I am using
v.digit with no digitizer (none) and the new osckets monitor.
Everything starts fine and seems to work. The first problem that I have is the
"Begin digitizing" menu flashes until it receives input from the monitor.
After doing some digititizing and saving some segments I am suddenely unable to
save any work. I will digitize a line, select "Quit" to stop digitizing and I am
not prompted to save the line. Instead I am dumped back to the digitizer menu
without the work saved.
Is this a digitizer problem (v.digit) or is it possibly related to the new
sockets window? I am using beta11 downloaded from CVS late last week.
Any help would be appreciated.
--
Bob Covill
Tekmap Consulting
P.O. Box 2016
Fall River, N.S.
B2T 1K6
Canada
On Wed, Feb 21, 2001 at 08:42:26PM -0400, Bob Covill wrote:
Hello,
I have been using v.digit under with my latest build on Solaris. I am
using v.digit with no digitizer (none) and the new osckets monitor.
Everything starts fine and seems to work. The first problem that I
have is the "Begin digitizing" menu flashes until it receives input
from the monitor.
After doing some digititizing and saving some segments I am suddenely
unable to save any work. I will digitize a line, select "Quit" to stop
digitizing and I am not prompted to save the line. Instead I am dumped
back to the digitizer menu without the work saved.
Is this a digitizer problem (v.digit) or is it possibly related to the
new sockets window? I am using beta11 downloaded from CVS late last
week.
Hmmm. I don't see such things here (but that doesn't mean anything).
I have made some changes to the XDRIVER to try to handle Xevents better,
but it sounds like your having problems with the menu/curses part of
v.digit (maybe I misunderstand?). I wouldn't think the sockets code
would have too much effect on how v.digit itself behaves. If the
problems are in the display monitor, then maybe so...
Perhaps this is related to curses problems others have mentioned. Are
you using libncurses5.x, or some native curses implementation. I
understand there's not alot of consistency between the various
implementations.
I'm also, not sure what changes of the XDRIVER implementation you've
picked up (I've made a few in the last week or so). One way to test,
would be to recompile with FIFOs or IPC and see if that makes a
difference. I suspect it won't.
Have you used v.digit in the past with your current set-up? And did it
work okay then?
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Wed, Feb 21, 2001 at 08:42:26PM -0400, Bob Covill wrote:
>
> Hello,
>
> I have been using v.digit under with my latest build on Solaris. I am
> using v.digit with no digitizer (none) and the new osckets monitor.
>
> Everything starts fine and seems to work. The first problem that I
> have is the "Begin digitizing" menu flashes until it receives input
> from the monitor.
>
> After doing some digititizing and saving some segments I am suddenely
> unable to save any work. I will digitize a line, select "Quit" to stop
> digitizing and I am not prompted to save the line. Instead I am dumped
> back to the digitizer menu without the work saved.
>
> Is this a digitizer problem (v.digit) or is it possibly related to the
> new sockets window? I am using beta11 downloaded from CVS late last
> week.
Hmmm. I don't see such things here (but that doesn't mean anything).
I have made some changes to the XDRIVER to try to handle Xevents better,
but it sounds like your having problems with the menu/curses part of
v.digit (maybe I misunderstand?). I wouldn't think the sockets code
would have too much effect on how v.digit itself behaves. If the
problems are in the display monitor, then maybe so...
Perhaps this is related to curses problems others have mentioned. Are
you using libncurses5.x, or some native curses implementation. I
understand there's not alot of consistency between the various
implementations.
I'm also, not sure what changes of the XDRIVER implementation you've
picked up (I've made a few in the last week or so). One way to test,
would be to recompile with FIFOs or IPC and see if that makes a
difference. I suspect it won't.
Have you used v.digit in the past with your current set-up? And did it
work okay then?
--
Eric G. Miller <egm2@jps.net>
Eric,
I suspect you are right about it being related to the curses and not the monitor.
I have used v.digit alot in the past on the Sun with no problems. This version
seems to have changed a bit from previous versions I have used. The changes seem
to be the mouse menu options changed around. I do not know when these changes
were implemented.
If it is a cursres problem would it show up in other menus? If so which ones?
I know you are probably sick of answering this question, but ... what is easiest
way to re-build the distribution with IPC or the old fifo's (but not have to
rebuild the entire distribution)?
Thanks for your help.
--
Bob Covill
Tekmap Consulting
P.O. Box 2016
Fall River, NS
Canada
B2T 1K6
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Thu, Feb 22, 2001 at 09:20:43AM -0400, Bob Covill wrote:
"Eric G. Miller" wrote:
> On Wed, Feb 21, 2001 at 08:42:26PM -0400, Bob Covill wrote:
> >
> > Hello,
> >
> > I have been using v.digit under with my latest build on Solaris. I am
> > using v.digit with no digitizer (none) and the new osckets monitor.
> >
> > Everything starts fine and seems to work. The first problem that I
> > have is the "Begin digitizing" menu flashes until it receives input
> > from the monitor.
> >
> > After doing some digititizing and saving some segments I am suddenely
> > unable to save any work. I will digitize a line, select "Quit" to stop
> > digitizing and I am not prompted to save the line. Instead I am dumped
> > back to the digitizer menu without the work saved.
> >
> > Is this a digitizer problem (v.digit) or is it possibly related to the
> > new sockets window? I am using beta11 downloaded from CVS late last
> > week.
>
> Hmmm. I don't see such things here (but that doesn't mean anything).
> I have made some changes to the XDRIVER to try to handle Xevents better,
> but it sounds like your having problems with the menu/curses part of
> v.digit (maybe I misunderstand?). I wouldn't think the sockets code
> would have too much effect on how v.digit itself behaves. If the
> problems are in the display monitor, then maybe so...
>
> Perhaps this is related to curses problems others have mentioned. Are
> you using libncurses5.x, or some native curses implementation. I
> understand there's not alot of consistency between the various
> implementations.
>
> I'm also, not sure what changes of the XDRIVER implementation you've
> picked up (I've made a few in the last week or so). One way to test,
> would be to recompile with FIFOs or IPC and see if that makes a
> difference. I suspect it won't.
>
> Have you used v.digit in the past with your current set-up? And did it
> work okay then?
>
> --
> Eric G. Miller <egm2@jps.net>
>
Eric,
I suspect you are right about it being related to the curses and not the
monitor. I have used v.digit alot in the past on the Sun with no problems.
This version seems to have changed a bit from previous versions I have
used. The changes seem to be the mouse menu options changed around. I do
not know when these changes were implemented.
Huidae has implemented them to improve the usage of v.digit (my wish).
It's related to zoom/pan. Now you can zoom/pan while digitizing without
stopping to digitize. At least here it works quite nice.
Probably the GRASS_PAN_THRESHOLD is too high (I think the deafault should
be less) so that the background image moves too quickly away if reaching the
borders of the current map region.
If it is a cursres problem would it show up in other menus? If so which ones?
curses are used in g.help as well.
I know you are probably sick of answering this question, but ... what is
easiest way to re-build the distribution with IPC or the old fifo's (but
not have to rebuild the entire distribution)?
You can use
configure --with-fifos
configure --with-ipc
but I am rather sure that it is not related to sockets.
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Huidae has implemented them to improve the usage of v.digit (my wish).
It's related to zoom/pan. Now you can zoom/pan while digitizing without
stopping to digitize. At least here it works quite nice.
Probably the GRASS_PAN_THRESHOLD is too high (I think the deafault should
be less) so that the background image moves too quickly away if reaching the
borders of the current map region.
> If it is a cursres problem would it show up in other menus? If so which ones?
curses are used in g.help as well.
Markus
Markus,
I have checked g.help and it seems to work fine.
The problems with v.digit seem to only relate to the digitize menu and the pan
menu. Other zoom functions, etc, still seem to work fine.
When I activate digitize (space-bar) the Begin Digitize menu begins flashing. It
is only the menu button options that are flashing, as if the cursor is cycling
throught the menu. The effect is not as dramatic with the pan menu, but cursors
can be seen flashing at the left and right side of the menu.
Any ideas would be appreciated.
--
Bob Covill
Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada
On Thu, Feb 22, 2001 at 12:25:18PM -0400, Bob Covill wrote:
Markus Neteler wrote:
> Bob,
>
>
> Huidae has implemented them to improve the usage of v.digit (my wish).
> It's related to zoom/pan. Now you can zoom/pan while digitizing without
> stopping to digitize. At least here it works quite nice.
> Probably the GRASS_PAN_THRESHOLD is too high (I think the deafault should
> be less) so that the background image moves too quickly away if reaching the
> borders of the current map region.
>
> > If it is a cursres problem would it show up in other menus? If so which ones?
>
> curses are used in g.help as well.
>
>
>
> Markus
Markus,
I have checked g.help and it seems to work fine.
The problems with v.digit seem to only relate to the digitize menu and the pan
menu. Other zoom functions, etc, still seem to work fine.
When I activate digitize (space-bar) the Begin Digitize menu begins flashing. It
is only the menu button options that are flashing, as if the cursor is cycling
throught the menu. The effect is not as dramatic with the pan menu, but cursors
can be seen flashing at the left and right side of the menu.
Any ideas would be appreciated.
Bob,
yes, that's a result due to the new pan method (Huidae will know more).
On fast machines (or accelerated video cards), you are not aware of
this. However, on a slower machine it might become annoying. I guess
it can be switched of with an env variable (flag).
All GRASS variables are listed in
documents/envVars.txt
(thanks to Justin). We should add explanations to the list and eliminate
the unused vars there.
The file with above definition of the menu flicker is here (I think so):
src/mapdev/v.digit/slid_window.c
and/or: window.c
I suggest to make the auto-pan method optional in a v.digit menu and/or
to be set with GRASS_AUTO_PAN=0/1
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
yes, that's a result due to the new pan method (Huidae will know more).
On fast machines (or accelerated video cards), you are not aware of
this. However, on a slower machine it might become annoying. I guess
it can be switched of with an env variable (flag).
All GRASS variables are listed in
documents/envVars.txt
(thanks to Justin). We should add explanations to the list and eliminate
the unused vars there.
The file with above definition of the menu flicker is here (I think so):
src/mapdev/v.digit/slid_window.c
and/or: window.c
I suggest to make the auto-pan method optional in a v.digit menu and/or
to be set with GRASS_AUTO_PAN=0/1
Markus
Markus,
The environment variables seem to have no affect on the "flashing menus". I took a
look in the code and the cuplrit seems to be the "_Clear_base ()" call inside a while
loop. In digitize.c on line 240 ...
"while(yes_no = mouse_yes_no_zoom ( ....)' the mouse_yes_no_zoom function uses the
_Clear_base() routine which I believe clears the screen until mouse input is received.
If I remove the _Clear_base () from the mouse_yes_no_zoom function in mouse_yn.c and
place it outside the while loop in digitize.c the problem is cleared up. It would
appear that the function is continually clearing the window when inside the while
loop. There are a couple of other locations where where this Clearing is an issue.
If you want I forward the modified files with the problem corrected to see if it
functions correctly in other environments.
--
Bob Covill
Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada
On Thu, Feb 22, 2001 at 04:36:48PM -0400, Bob Covill wrote:
Markus Neteler wrote:
> Bob,
>
> yes, that's a result due to the new pan method (Huidae will know more).
> On fast machines (or accelerated video cards), you are not aware of
> this. However, on a slower machine it might become annoying. I guess
> it can be switched of with an env variable (flag).
>
> All GRASS variables are listed in
> documents/envVars.txt
>
> (thanks to Justin). We should add explanations to the list and eliminate
> the unused vars there.
>
> The file with above definition of the menu flicker is here (I think so):
> src/mapdev/v.digit/slid_window.c
> and/or: window.c
>
> I suggest to make the auto-pan method optional in a v.digit menu and/or
> to be set with GRASS_AUTO_PAN=0/1
>
> Markus
>
Markus,
The environment variables seem to have no affect on the "flashing menus".
I took a look in the code and the cuplrit seems to be the "_Clear_base ()"
call inside a while loop. In digitize.c on line 240 ...
"while(yes_no = mouse_yes_no_zoom ( ....)' the mouse_yes_no_zoom function
_uses the Clear_base() routine which I believe clears the screen until
_mouse input is received.
If I remove the _Clear_base () from the mouse_yes_no_zoom function in
mouse_yn.c and place it outside the while loop in digitize.c the problem
is cleared up. It would appear that the function is continually clearing
the window when inside the while loop. There are a couple of other
locations where where this Clearing is an issue.
If you want I forward the modified files with the problem corrected to see
if it functions correctly in other environments.
Yes, please send it over.
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
when using "widen view" in (un)zoom in v.digit, and
having the GRASS monitor *partly* outside the screen,
the monitor isn't refreshed any more. This leads to
various overlayed vector pictures resulting from the
different zoom operation. If you move back the monitor
fully into the screen, refresh is back o.k.
Just to notify you (probably Eric),
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Feb 26, 2001 at 01:17:41PM +0000, Markus Neteler wrote:
Hi all,
when using "widen view" in (un)zoom in v.digit, and
having the GRASS monitor *partly* outside the screen,
the monitor isn't refreshed any more. This leads to
various overlayed vector pictures resulting from the
different zoom operation. If you move back the monitor
fully into the screen, refresh is back o.k.
Just to notify you (probably Eric),
Yep, I can confirm. Undoubtedly the result of a blocked read. I tried
to modify the way SWITCHER handles reads, but there seem to be a dozen
different pathways to read/write on the communications channel, all
making for a god awful mess. Most likely it's blocking in read1().
Unfortunately, handling the blocked read is not straight forward. I'll
try to look at it again, when I can.
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'