Eric G. Miller wrote:
I think this may be a bug in the blackbox window manager, but with the
X driver code in release_april11... I'm unable to change the size of a
monitor ever. Seems blackbox makes the decision the window is not
resizeable, doesn't give it "resize" handles or respond to
Alt-Right_Button (which will also resize typical windows). I ran the
monitor in WindowMaker without such troubles, so I guess it's a bug in
blackbox. Maybe I could get help formulating a bug report for blackbox?
I don't know exactly what it is/is not responding to... I rather like
blackbox for its nice looks with light weight, so I'd like to be able to
point the author(s) in the right direction...
The current behaviour of XDRIVER is this:
1. The initial state of WM_NORMAL_HINTS has flags USSize|USPosition.
2. When a client connects, unless a redraw is in progress, the flags
are set to PSize|PMinSize|PMaxSize, with all three sizes equal to the
window's current size (as returned by XGetWindowAttributes()).
3. When a client disconnects, the flags are set to PSize.
Note that state 1 is transient; the initial mon.select will change the
state to 3.
XDRIVER doesn't specify a _MWM_HINTS property, but then neither do any
of the other applications which I checked.
BTW, I'm open to comments as to whether the existing behaviour is
correct. It's arguable that it shouldn't be using the US* flags unless
the XDRIVER_* environments variables are set. Also, whether to specify
the position when XDRIVER_{LEFT,TOP} are unset is a matter of
preference. Personally I'd rather let the WM place it, but this won't
happen if the program always requests a specific location.
--
Glynn Clements <glynn.clements@virgin.net>
From neteler Wed Jun 13 15:27:35 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id PAA10143; Wed, 13 Jun 2001 15:27:34 +0100
Date: Wed, 13 Jun 2001 15:27:34 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5@geog.uni-hannover.de
Cc: Request Tracker <grass-bugs@intevation.de>
Subject: Re: [GRASS5] [bug #752] (grass) configure: doesn't add -lGL -lGLw -lGLUT entries in head file (Solaris)
Message-ID: <20010613152734.A10125@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5@geog.uni-hannover.de,
Request Tracker <grass-bugs@intevation.de>
References: <20010612173505.465B113A00@mailman.intevation.de> <15142.23525.316240.636978@cerise.nosuchdomain.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15142.23525.316240.636978@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Tue, Jun 12, 2001 at 07:13:57PM +0100
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 1716
Lines: 49
On Tue, Jun 12, 2001 at 07:13:57PM +0100, Glynn Clements wrote:
Request Tracker wrote:
> the "configure" doesn't add -lGL -lGLw -lGLUT in head file on Solaris/SUN
> while this is working on Linux. Similar was reported for MaxOSX recently.
>
> After adding above entries into head file, everything compiles fine.
> The libraries are detected:
>
> [...]
> checking GL/gl.h and GL/GLwMDrawA.h... -I/usr/include -I/usr/local/include and -I/usr/include
> checking for glBegin in -lGL... (cached) no
> checking for gluBeginCurve in -lGLU... (cached) no
> checking for GLwDrawingAreaMakeCurrent in -lGLw... (cached) no
> checking for GLwCreateMDrawingArea in -lGLwM... (cached) no
> [...]
>
> I have no idea how to fix this (as it works for Linux). Probably
> some wrong variable quoting?
What does config.log say?
After the line:
configure:4226: checking for glBegin in -lGL
there should be the compilation command, along with any error messages
and the source of the test program. The error message(s) should
provide some clues as to why it failed.
It seems there is nothing:
configure:4044: checking libpq paths
configure:4059: checking for PQcmdTuples in -lpq
configure:4183: checking GL/gl.h and GL/GLwMDrawA.h
configure:4226: checking for glBegin in -lGL
configure:4270: checking for gluBeginCurve in -lGLU
configure:4314: checking for GLwDrawingAreaMakeCurrent in -lGLw
configure:4354: checking for GLwCreateMDrawingArea in -lGLwM
configure:4460: checking for sql.h
configure:4496: checking for location of odbc lib
configure:4594: checking for jpeglib.h
(above of that the curses compile thing is present in config.log).
Strange...
Markus
From neteler Wed Jun 13 15:52:05 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id PAA10377; Wed, 13 Jun 2001 15:52:05 +0100
Date: Wed, 13 Jun 2001 15:52:05 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5@geog.uni-hannover.de
Subject: Re: [GRASS5] 0 != no data
Message-ID: <20010613155205.D10125@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5@geog.uni-hannover.de
References: <Pine.LNX.4.21.0106121504440.13574-100000@reclus.nhh.no> <3B260843.F963A104@unity.ncsu.edu> <20010612173636.E24187@hgeo02.geog.uni-hannover.de> <3B272A7C.60E8EE68@hpcc.nectec.or.th>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B272A7C.60E8EE68@hpcc.nectec.or.th>; from jhickey@hpcc.nectec.or.th on Wed, Jun 13, 2001 at 03:55:24PM +0700
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 9370
Lines: 199
Hi all,
On Wed, Jun 13, 2001 at 03:55:24PM +0700, Justin Hickey wrote:
Hello all
Markus Neteler wrote:
>
> On Tue, Jun 12, 2001 at 07:17:07AM -0500, Helena wrote:
> > Roger explained the issue correctly - let me just add a little bit
> > more. When NULL was being implemented there were 2 groups of users:
> > 1. Those who worked mostly with classes and had large number of
> > files with 0 set as NULL - that was the standard when I came to
> > CERL.
> > 2. Those who started to use raster maps as representation of
> > continuous fields and 0 was a data value. Both lack of FP
> > support and NULL was a big problem.
> >
> > It was clear that one of those 2 groups will have to update their
> > databases when NULL is introduced and because the first one was
> > overhelming majority, we ended up with what we have now.
> > As I said, I don't like it because I am the user in the no. 2
> > group, but I strongly suggest to send a message to the users group
> > to see what the reaction would be.
Yes, it was my intention to question the users list before doing
anything.
> > There are people who have 10 years of GRASS4.* data accumulated in
> > their databases and my experience is that even those old data are
> > quite often used. The removal of the NULL file may require a lot of
> > work and it would be good to evaluate how does it compare with
> > other priorities.
The actual major changes would be done after 5.0 is released. I only
suggest users switch now when they expect a major change.
> > The issue with LZW compression was different because there weren't
> > very many people who had lots of floating point data because the FP
> > GRASS was never officially released. So it was relatively easy and
> > fair to ask them to update.
> >
> > So Markus, let us know what do you think and if you believe that it
> > is worth considering such a change please write a message to the
> > users list to see what the reaction would be,
>
> If you ask me: I agree with Justin that the additional NULL file is
> somewhat confusing and obviously not necessary any more.
>
> In my opinion major changes should be done for 5.0 and not for 5.1 as
> there are many 4.x users still waiting for the stable release. When
> published, they will switch over to 5.0. To have much extra work
> again in 5.1 to convert raster data will not be very satisfying.
>
> At time I am not clear about the percentage of GRASS users working
> already with 5.x. Can't we implement a sort of autodetection which
> checkes the data at GRASS startup and going to modify the NULL stuff
> if required? A sort of automated raster data upgrade (similar to
> r.lzw2z, but fully automated).
No, we cannot automate the conversion. The deciding factor in whether to
convert a given file or not is user preference (do they want 0 to be
interpreted as NULL). If we automatically convert 4.x files so that 0 is
turned to NULL, then users who want 0 = 0 will have to convert back
again. However, I believe I can write a script that, given a list of
databases, can go through a user's data and perform the conversion. I
haven't tested it, but I have an idea of how to do it. This of course
would depend on whether users have maintained their data properly. That
is, all directories under a database are locations and all directories
under a location are mapsets.
> Even if it delays the 5.0 again (luckily pre1 is out), the raster
> part should be stable for 5.0 as we have a new vector management for
> 5.1. GRASS 5.0 is announced to provide a new raster engine, so it
> should be completed.
>
> Concerning the 4.x existing data: I have already put a 4.x and a 5.x
> version online of SPEARFISH and friends. It was a simple run of
> r.support (-r now). I didn't dig too deeply into the NULL problems
> yet, but it doesn't look unfeasible to me as it should be mostly a
> library issue.
>
> Generally we should minimize the *number* of transitions due to the
> large number of datasets around. I would prefer a transition more
> time consuming for the individual conversion rather than invoking new
> transitions when upgrading to 5.1 (if I come from 4.x). Multiply the
> number of transitions with number of datasets which doesn't equals
> user's happiness...
>
> Shall I start a poll on number of 4.x/5.x users? There are some free
> poll sites around.
Yes, start a poll but not on the number of grass 4 and 5 users. The
question should be related to whether we keep the feature or not. See
below for more on this.
> We should't carry GRASS history around for all versions (backward
> compatibility). I actually don't see any reason to fall back to 4.x,
> hope that most 5.0.0pre1 users agree.
> Think of the Windows/DOS story... 
Since I will be posting this issue to the user list, I would like to
suggest the wording for the post here and have all concerned developers
change, or add to it, to make sure I don't leave anything out. Helena, I
hope you don't mind me borrowing part of your post.
======================== Start of post ===============================
Subject: We need your opinion
Hello all users
Recently on the developers mailing list, there has been a discussion
concerning the current implementation of NULL. When the NULL concept was
first introduced and implemented there were basically 2 groups of users:
1. Those who worked mostly with classes and had a large number of
files with 0 set as NULL
2. Those who started to use raster maps as representation of
continuous fields and 0 was a data value
The majority of the users were in group 1 and thus, the decision was
made to keep the feature that 0 could be interpreted as NULL.
In the discussion on the developers list, some developers have indicated
that since GRASS 5.0 has the concept of NULL (which is represented by
non-zero values), it is confusing to also have the feature that 0 can be
interpreted as NULL, especially to new users of GRASS. This feature has
also caused some problems for some users who had greyscale aerial
photographs stored as raster maps in GRASS 4.x, and then transferred
them to GRASS 5.0. The problem was that the color black (value 0) was
being interpreted as NULL causing them to believe that their data had
been corrupted somehow.
In order to eliminate this confusion, a proposal was put forth on the
list that 0 should never be considered as NULL in GRASS 5.0. Also, in
order to facilitate those users who wish to use their GRASS 4.x files
with the new GRASS 5.0, we would provide a script to assist them in
converting the 0 values of their data to appropriate NULL values in
GRASS 5.0.
This script has not been written yet but the proposed usage would be
that a user would run the script and provide a list of GRASS 4.x
databases which contain raster files in which 0 should be interpreted as
NULL. The script will automatically go through all locations and mapsets
in each database and perform the conversion for all raster files. The
only requirement for this script would be that the GRASS 4.x data would
have to be maintained in proper GRASS databases. That is, all
directories under a database will be locations, and all directories
under a location will be mapsets. If a user has files that he/she does
not want converted then either the files can be moved to a different
database, or the user can provide a specific location, or mapset, or
raster file to the script.
What we would like you to do is provide us with your opinion on whether
we should keep the feature of 0 being interpreted as NULL. To make
things a little easier, we have set up a poll at
<URL>
for you to submit your opinion. We would greatly appreciate it if you
could take a few moments to cast a vote.
Thank you for your time in this matter.
========================= End of post ================================
So, please feel free to edit the above message in any way. For the poll,
perhaps we could say something like.
The feature of 0 being interpreted as NULL should be
a) kept in GRASS 5.0
b) eliminated from GRASS 5.0, but a script will be provided to
convert GRASS 4.x files to GRASS 5.0 format for those who wish
0 to be NULL
Again, please feel free to edit this statement.
thanks for your nice proposal. A few remarks:
- Perhaps (even for the new users), an example may be added to demonstrate
the 0 to be NULL thing
- it should be pointed out, that GRASS 5 will keep the feature to store
NULLs (for those not carefully ready), perhaps in a bottom summary
- it should be pointed out, that GRASS 5 will keep the feature to convert
individual values to NULL and back
- maybe in a bottom summary it should be explained, that, if eliminating the
feature of 0 to be NULL, that both groups (1) and (2) will stay happy,
only that a conversion step is required (or not?).
BTW: Does anyone know a free poll server without adult images or annoying
ads? I don't want that they catch all the users' email adresses and sell
them anywhere.
Regards
Markus
From neteler Wed Jun 13 17:34:57 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id RAA11035; Wed, 13 Jun 2001 17:34:57 +0100
Date: Wed, 13 Jun 2001 17:34:57 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5 developers list <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] grass font
Message-ID: <20010613173457.N10125@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5 developers list <grass5@geog.uni-hannover.de>
References: <3B1A28B4.23A2D723@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B1A28B4.23A2D723@yahoo.com>; from agarwal_somesh@yahoo.com on Sun, Jun 03, 2001 at 05:38:20PM +0530
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 562
Lines: 19
On Sun, Jun 03, 2001 at 05:38:20PM +0530, Somesh Agarwal wrote:
hello all ,
i am developing new font support for grass , but I have not
being able to
understand the format in which font files are produced by the
grass/src/font/for_grass/split_font <fontdir>
what is this format is that a standard format or something ,
someone please help
thanks
Hi Somesh,
unfortunately I have no idea about the font system in GRASS.
Alex Shevlakov, are you listening here? Perhaps you could throw
in some ideas for a local README?
Thanks,
Markus
From neteler Wed Jun 13 17:40:06 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id RAA11081; Wed, 13 Jun 2001 17:40:06 +0100
Date: Wed, 13 Jun 2001 17:40:06 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: grass5@geog.uni-hannover.de
Subject: Re: [GRASS5] Grass Funding
Message-ID: <20010613174006.O10125@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: grass5@geog.uni-hannover.de
References: <200106050534.WAA25079@avocet.mail.pas.earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200106050534.WAA25079@avocet.mail.pas.earthlink.net>; from jeshua@SierraMaps.com on Mon, Jun 04, 2001 at 10:34:25PM -0700
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 796
Lines: 23
On Mon, Jun 04, 2001 at 10:34:25PM -0700, Jeshua Lacock wrote:
Hello all,
I have been selling Grass CD's for Mac OS X (I made a GUI installer),
and I would like to donate a percentage of all future Grass CD sales to
the continued development of Grass.
Who might I contact? Is there are a Grass Fund or something?
I greatly value the efforts of the entire Grass Development Team, and I
would like to help make a contribution.
Hi Jeshua,
a nice idea! As we will face problems to distribute individual
amounts of money to certain programmers, I suggest the money will
be used for a developers meeting. Maybe those could be (partly) funded,
who are far away from the meeting place so that finally everyone
has a similar amount of travel expenses.
Just an idea,
Markus