Hi,
I have fresh devel and stable grass50 here with following problem:
d.mon in stable branch:
d.mon start=x0
using default visual which is PseudoColor
ERROR: Unable to get sufficient colors
No socket to connect to for monitor <x0>.
Problem selecting x0. Will try once more
No socket to connect to for monitor <x0>.
I have 256 colors only here on KDE2.1/RH7.1. It starts OK in devel branch.
How is that with stable contra devel branch? I thought, that all fixes from
stable are merged to devel and if now new features were added to devel
for xdriver, both devel and stable should be identical. Which doesn't seems
to be true.
--------------------
BTW:
d.zoom in development branch (in stable the same probably, but I cannot test)
requires at least one raster, vector or site:
if(!rast && !vect && !site)
{
rmap->required = YES;
just->answer = 1;
}
If d.area is displayed only, d.zoom asks for raster file. But I want zoom in
areas only.
Thanks.
Radim
Radim Blazek wrote:
I have fresh devel and stable grass50 here with following problem:
d.mon in stable branch:
d.mon start=x0
using default visual which is PseudoColor
ERROR: Unable to get sufficient colors
No socket to connect to for monitor <x0>.
Problem selecting x0. Will try once more
No socket to connect to for monitor <x0>.
I have 256 colors only here on KDE2.1/RH7.1. It starts OK in devel branch.
Has the colourmap been consumed by existing clients? Does the problem
occur if the monitor is the only program running using the display?
The above error should only occur if InitColorTableFixed() is unable
to obtain the 8 corners of the RGB colour cube (black, red, green,
blue, yellow, cyan, magenta, white).
How is that with stable contra devel branch? I thought, that all fixes from
stable are merged to devel and if now new features were added to devel
for xdriver, both devel and stable should be identical. Which doesn't seems
to be true.
Either someone is committing changes to the devel branch, or the
merging isn't occurring. The CVS server is currently unavailable, so I
can't determine which is the case.
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
Radim Blazek wrote:
> I have fresh devel and stable grass50 here with following problem:
>
> d.mon in stable branch:
>
> d.mon start=x0
> using default visual which is PseudoColor
> ERROR: Unable to get sufficient colors
> No socket to connect to for monitor <x0>.
> Problem selecting x0. Will try once more
> No socket to connect to for monitor <x0>.
>
> I have 256 colors only here on KDE2.1/RH7.1. It starts OK in devel branch.
Has the colourmap been consumed by existing clients? Does the problem
occur if the monitor is the only program running using the display?
Thanks. It works after X restart. No other program was running (except console), I know that
problem. It seems that if konqueror (other apps?) is started and closed, its colors are still in use.
Radim
Radim Blazek wrote:
Glynn Clements wrote:
>
> Radim Blazek wrote:
>
> > I have fresh devel and stable grass50 here with following problem:
> >
> > d.mon in stable branch:
> >
> > d.mon start=x0
> > using default visual which is PseudoColor
> > ERROR: Unable to get sufficient colors
> > No socket to connect to for monitor <x0>.
> > Problem selecting x0. Will try once more
> > No socket to connect to for monitor <x0>.
> >
> > I have 256 colors only here on KDE2.1/RH7.1. It starts OK in devel branch.
>
> Has the colourmap been consumed by existing clients? Does the problem
> occur if the monitor is the only program running using the display?
Thanks. It works after X restart. No other program was running (except console), I know that
problem. It seems that if konqueror (other apps?) is started and closed, its colors are still in use.
Radim
_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5
-
Can we avoid the color problem using a private color map as it is possible in
Netscape (using the command nestcape -install) ? Doing that, GRASS can use any
color with only a drawback, the other appliactions get bizare colors when not
focus.
--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca
Robert Lagacé wrote:
> > > I have fresh devel and stable grass50 here with following problem:
> > >
> > > d.mon in stable branch:
> > >
> > > d.mon start=x0
> > > using default visual which is PseudoColor
> > > ERROR: Unable to get sufficient colors
> > > No socket to connect to for monitor <x0>.
> > > Problem selecting x0. Will try once more
> > > No socket to connect to for monitor <x0>.
> > >
> > > I have 256 colors only here on KDE2.1/RH7.1. It starts OK in devel branch.
> >
> > Has the colourmap been consumed by existing clients? Does the problem
> > occur if the monitor is the only program running using the display?
>
> Thanks. It works after X restart. No other program was running (except console), I know that
> problem. It seems that if konqueror (other apps?) is started and closed, its colors are still in use.
Can we avoid the color problem using a private color map as it is possible in
Netscape (using the command nestcape -install) ? Doing that, GRASS can use any
color with only a drawback, the other appliactions get bizare colors when not
focus.
That would be simple enough. It already uses a private colourmap if
it's using a visual other than the default, or when using a
DirectColor visual.
I'll add this today (assuming that the CVS stays up).
--
Glynn Clements <glynn.clements@virgin.net>
On Wed, Jun 27, 2001 at 07:15:00AM +0200, Radim Blazek wrote:
BTW:
d.zoom in development branch (in stable the same probably, but I cannot test)
requires at least one raster, vector or site:
if(!rast && !vect && !site)
{
rmap->required = YES;
just->answer = 1;
}
If d.area is displayed only, d.zoom asks for raster file. But I want zoom in
areas only.
The problem is with d.area. It does a
if (stat)
D_add_to_list (G_recreate_command());
near the end, but that apparently isn't sufficient. I had a look a
while back, and modified an unreleasable version of d.area (copyright
problem) to have:
if(stat == 0)
D_add_to_list(G_recreate_command()) ;
D_set_dig_name(G_fully_qualified_name(map_name, mapset));
D_add_to_dig_list(G_fully_qualified_name(map_name, mapset));
That seems to work. I didn't update CVS, 'cause the algorithm used for handling
polygon holes isn't quite right, and writing the code to make it right is
non-trivial (anybody know how to implement the Weiler-Atherton clipping
algorithm?). I suppose that little part of d.area could be updated, even if the
program doesn't quite behave correctly.
--
Eric G. Miller <egm2@jps.net>
"Eric G. Miller" wrote:
That seems to work. I didn't update CVS, 'cause the algorithm used for handling
polygon holes isn't quite right, and writing the code to make it right is
non-trivial (anybody know how to implement the Weiler-Atherton clipping
algorithm?). I suppose that little part of d.area could be updated, even if the
program doesn't quite behave correctly.
--
Eric G. Miller <egm2@jps.net>
It is not problem in Xwindow, islands may be attached to area without additional
processing. If I remember your tests (~6 monts ago), problem is in CELL, PNG driver.
Isn't it possible to modify plot function used in this driver?. I think that it draws
horizontal lines from left to right between boundaries. Check if this line is zero length
before drawing should help, I think.
Radim
On Wed, Jun 27, 2001 at 05:34:33PM +0200, Radim Blazek wrote:
"Eric G. Miller" wrote:
> That seems to work. I didn't update CVS, 'cause the algorithm used for handling
> polygon holes isn't quite right, and writing the code to make it right is
> non-trivial (anybody know how to implement the Weiler-Atherton clipping
> algorithm?). I suppose that little part of d.area could be updated, even if the
> program doesn't quite behave correctly.
>
> --
> Eric G. Miller <egm2@jps.net>
It is not problem in Xwindow, islands may be attached to area without additional
processing. If I remember your tests (~6 monts ago), problem is in CELL, PNG driver.
Isn't it possible to modify plot function used in this driver?. I think that it draws
horizontal lines from left to right between boundaries. Check if this line is zero length
before drawing should help, I think.
I had modified d.area subsequently so the "infinitely thin colinear
lines" connecting the outer polygon with the inner holes are always made
between the nearest vertices of the outer polygon and the inner hole.
Therefore, the line should always lie inside the outer polygon (not
guaranteed). For most cases this should work okay, unless a polygon has
multiple holes and the line that would be formed from the outer ring to
one of the inner rings crosses one of the other inner rings. It
probably wouldn't happen too often, but it could happen and the program
doesn't check for this possibility. When it does occur, you'll see some
pretty funky output, and maybe the program will just crash altogether.
I don't know.
Also, d.area does not properly clip to the window extents, and it
disagrees with d.vect slightly on line placement. I wish I could commit
the version I have using the "gpc library" since it fixes all of these
problems. Unfortunately, gpc has an onerous restriction against
"commercial use" or as part of a "commercial product" -- not GPL
compatible ;(. I've tried to contact the author for an exception, be he
is apparently out of the country or just not responding. So, I guess
academics are the only type that can use his code ;( What a shame.
I've slightly back-burnered the issue, since I'm a little stuck on
implementing the polygon clipping.
--
Eric G. Miller <egm2@jps.net>