[GRASS-dev] WxPython front-end to ps.map

[Moritz Lennert]

On 09/02/07 19:56, Michael Barton wrote:
> Moritz,
> 
> Sorry for the confusion. I'm thinking of how map layers are presented to
> users in the layer control panel. It might be cleaner to have a single
> "vector" layer button instead of "vector", "thematic map", and "thematic
> chart" buttons. In the options panel for the vector layer, you could decide
> whether this would display a single color vector map, thematic display of
> the vector map, or a thematic chart of the vector map. In other words, there
> would be a single control/options panel that would wrap d.vect,
> d.vect.thematic, and d.vect.chart.
> 
> Again, I'm not talking about what we should do with the modules, only how
> they could be presented to a GUI user. However, if we have a different way
> of rendering vectors (i.e., a rewrite of the vector display somehow), I
> think it should include the thematic and chart mapping, rather than just the
> simply vector display.
> 


Sounds like an interesting idea. The only danger I see is that panels 
will be huge. Combining all options of d.vect, d.vect.thematic, and 
d.vect.chart into one single panel might make it quite confusing.

Moritz


> Michael
> 
> 
> On 2/9/07 1:33 AM, "Moritz Lennert" <mlennert at club.worldonline.be> wrote:
> 
>> On 09/02/07 04:46, Michael Barton wrote:
>>
>>> Thematic maps and charts seem like they should be a vector option rather
>>> than separate layers. This could be done with GUI code without needing to
>>> combine the d.* modules. However, if we did true vector rendering for
>>> primitives, we'd want the same quality in thematic maps and charts.
>>>
>>> I'm not sure if this makes any considered recoding any easier or not. But
>>> the upshot is that vector primitives, thematic maps, and charts seem the
>>> best candidates for some reworking of the C code for display. Most of the
>>> other d.* effects can work with current code or be replaced by GUI generated
>>> graphics if we want. As you point out, this is more work at the GUI coding
>>> end. I'm not sure which will take more effort.
>>
>> I'm not sure I completely understand what you mean here, and as we are
>> still (albeit slowly, I admit) working on a C replacement of
>> d.vect.thematic, it would be good to know what we should take into account.
>>
>> I do have to agree with Glynn, though, in that we should try to not code
>> two parallel and different ways of drawing things, one for the command
>> line and one for the GUI. I am afraid that this would almost inevitably
>> lead to inconsistencies and definitely to twice the work load trying to
>> keep everything up to date. IMHO, GRASS's strength is its modularity and
>> the GUI should be on top of that, not replace it.
>>
>> Moritz
> 
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics and Complexity
> Arizona State University
> 
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton 
>