Hi!
Den 22 maj 2014 17:45 skrev "Damián Nohales" <damiannohales gmail com>:
>
> Hello guys!
>
>
> Yeah, haha, I'm very messy while crafting UMLs, mainly because I
> usually use it as a draft to get an idea. But basically, the private
> methods should be protected and _ prefixed, I'll change it in a
> moment.
No problem, I just wasn't sure of your intents. :)
> > Yeah, I have the same question. We should always have access to the lat and lon
> > right? So positioning should just be a matter of getting the x and y through
> > the ChamplainView and creating a rect?
>
> The thing is, mostly all markers are positioned using the
> ChamplainMarker::set_location method, then I saw the Rishi POIRenderer
> class and he use raw positions (using ClutterActor::set_position
> method), relative to tile position.
>
> See https://github.com/rishirajsinghjhelumi/GNOME-Maps/blob/poi-testing/src/poiRenderer.js
>
> Maybe this case, POIRenderer should set position by hand or using a
> callback to set the marker position (by default this callback calls
> set_location), I called this callback positioningAlgorithm, an
> optional construction parameter. How to deal with this?
I think the way to do this is to just make those markers be these new MapMarkers, Rishi seemed to agree here. Will this work?
> >
> >> 5) I'm not sure entirely how the overlay should come to the popover,
> >> maybe add it back to the mapView and have it there as a property? Really
> >> not sure.
> >>
> >
> > We could also go with making mapView inherit from GtkOverlay.
> >
> >> Nitpicks:
> >> 1) I think you can drop the Generic in front of Poi{Marker, Popover}
> >> 2) MapMarkerPopover → MapPopover
> >> 3) Maybe replace all Popover-instances with Bubble instead, since then
> >> we know that we're talking about the bubbles in the map and not the
> >> popovers in the headerbar etc.
>
> Ok, I'm going to fix that.
Cool!
> >
> > 4)
> > What is the point of the createUI function of the MarkerPopover?
>
> _init set the place property and calls to createUi, this avoid to
> forgot the parent _init method and you should only implements
> createUi. It's just the same thing, we can create the UI components in
> _init, after call this.parent(params) and do it without createUi.
> Hmmm... now that I think of it, implements _init in the child classes
> allows to customize the parent constructor parameters. So, I'm going
> to remove createUi.
Ah understood. Yeah that seems better.
> Isn't related to Poi markers? a user usually do the check-in to a bar,
> restaurant, hotel, etc. Anyway, the "dialogs" part of the check-in
> (account selection, place selection, bla bla), can be developed
> separated from markers and bubbles stuff.
I think it only make sense to do a check in from your current location actually. I know the designs doesn't reflect this (bit that's what I remember me and Andreas agreeing on, Andreas?) and I know Zeeshan has some other idea here.
We should decide here pretty soon I think. Will bring it up in London.
Great work again and thanks for bringing this all up!