>
>
> On 3/19/07 5:59 AM, "Jachym Cepicky" <
[hidden email]> wrote:
>
> >
> > AFAIK, this is supposed to be the output PNG - the file, which at the
> > end contains all the layers renderd to one single file
>
> Jáchym,
>
> I misunderstood your reply. This is incorrect. The composited output file
> will be a PPM, not a PNG. So maybe the PNG is an unnecessary leftover from
> an earlier iteration?
>
> Michael
>
>
> >
> > line 562:
> >
> > # compose command
> > compcmd = "g.pnmcomp in=" + mapstr + \
> > " mask=" + maskstr + \
> > " opacity=" + opacstr + \
> > " background=255:255:255" + \
> > " width=" + str(self.width) + \
> > " height=" + str(self.height) + \
> > " output=" + self.mapfile
> >
> > and in mapdisp.py, line 269, GetImage method:
> >
> > if Map.mapfile and os.path.isfile(Map.mapfile):
> > self.Img = wx.Image(Map.mapfile, wx.BITMAP_TYPE_ANY)
> >
> >>
> >> 2. The second has to do with the structure of the layer manager. I've used a
> >> tree widget, like we did with TclTk--the main reason being so that we can
> >> implement hierarchically nested map groups. This seems like a useful feature
> >> to carry over from the old GUI. I've used a ComboCtrl for map selection, but
> >> think I'll switch to a similar-appearing ComboTreeBox because it offers
> >> additional flexibility.
> >>
> >> The question is does it seem best to have map selection directly accessible
> >> on the control, as it is now in the wxPython prototype, and have the other
> >> properties visually hidden and with access via some kind of popup (note that
> >> PopupControl does not work on the Mac, though alternatives can be done)? Or
> >> is it better to have all properties directly accessible on the GIS
> >> Manager--sort of like we do now in the TclTk GUI. There is an interesting
> >> new control called a TreeBook that might work very well for the latter
> >> (check it out in demo). In brief, it has a left pane with a tree (hierarchy,
> >> image, and text string). When you click a tree item, it selects a page in
> >> the right pane. You can have anything on the page--i.e., all properties. I'm
> >> not sure, but it might make it much easier to keep track of all layer
> >> options together in this way.
> >>
> >> Check it out and see what you think. I may try to see if can be implemented
> >> easily. If so, I'll give you a demo.
> >>
> >> Michael
> >>
> >>
> >>
> >>
> >> On 3/17/07 12:01 PM, "Martin Landa" <
[hidden email]> wrote:
> >>
> >>> Michael, [cc Jachym]
> >>>
> >>> sorry that I didn't cooperate. I hope that the problems with Internet
> >>> connection here in Italy during weekend's will be solved very soon.
> >>> And I will be on-line all the time;-) [as I used to be in the Czech
> >>> Republic]
> >>>
> >>> Best regards, Martin
> >>>
> >>> 2007/3/17, Michael Barton <
[hidden email]>:
> >>>> I got it! There is yet hope for me as a wxPython programmer.
> >>>>
> >>>> The GUI will now display maps in the layer tree. No options yet and there
> >>>> needs to be a new method in render for command layers. But it will display
> >>>> raster and vector layers. We have a functional prototype GUI in wxPython
> >>>> again.
> >>>>
> >>>> YEA!
> >>>>
> >>>> Michael
> >>>>
> >>>>
> >>>> On 3/16/07 8:21 PM, "Michael Barton" <
[hidden email]> wrote:
> >>>>
> >>>> Jáchym and Martin,
> >>>>
> >>>> I've been trying to follow the logic of the new rendering scheme in
> >>>> render.py and I think I understand how it is supposed to work now. As best
> >>>> I
> >>>> can tell, a call to AddRaster must come from mapdisp.py for anything to
> >>>> actually show up in the display. The reason is that each display creates
> >>>> its
> >>>> own instance of render.Map that does the rendering for that display.
> >>>>
> >>>> However, the layer management is being done in gismutilities.py‹which must
> >>>> create its own instance of render.Map. So when you add a new layer to the
> >>>> layer tree, it is added to self.layers in the gismutilities instance of
> >>>> render.Map.
> >>>>
> >>>> This means that there are no maps added to self.layers in the instance of
> >>>> render.Map created by the display. Hence, when you go to render the
> >>>> display,
> >>>> there is nothing to render.
> >>>>
> >>>> For reasons you've already pointed out, gism.py and mapdisp.py need to
> >>>> remain independent, so we can't put layer tree management into mapdisp.py.
> >>>>
> >>>> The way I got around a similar issue related to maintaining a common set of
> >>>> variables that could be used both by gism and mapdisp was to store them in
> >>>> track.py. Perhaps this is the way to go with the problem here. I'll
> >>>> continue
> >>>> pondering it tonight. See if you come up with something tomorrow.
> >>>>
> >>>> Michael
> >>>> __________________________________________
> >>>> Michael Barton, Professor of Anthropology
> >>>> School of Human Evolution & Social Change
> >>>> Center for Social Dynamics & Complexity
> >>>> Arizona State University
> >>>>
> >>>> phone: 480-965-6213
> >>>> fax: 480-965-7671
> >>>> www:
http://www.public.asu.edu/~cmbarton> >>>>
> >>>>
> >>>>
> >>>> __________________________________________
> >>>> Michael Barton, Professor of Anthropology
> >>>> School of Human Evolution & Social Change
> >>>> Center for Social Dynamics & Complexity
> >>>> Arizona State University
> >>>>
> >>>> phone: 480-965-6213
> >>>> fax: 480-965-7671
> >>>> www:
http://www.public.asu.edu/~cmbarton> >>>>
> >>>>
> >>>
> >>
> >> __________________________________________
> >> Michael Barton, Professor of Anthropology
> >> School of Human Evolution & Social Change
> >> Center for Social Dynamics & Complexity
> >> Arizona State University
> >>
> >> phone: 480-965-6213
> >> fax: 480-965-7671
> >> www:
http://www.public.asu.edu/~cmbarton> >>
> >>
> >>
> >
>
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
>
> phone: 480-965-6213
> fax: 480-965-7671
> www:
http://www.public.asu.edu/~cmbarton>
>
>
