and first special thanks to Mike Purvis, as I have learned a lot while
examining his LabeledMarker...
Meanwhile during my first experience of using it in my project I ran
into several visibility issues. The patch to fix them is appended
below.
1) The current release version (1.2) of LabeledMarker does not allow
setting up visibility before .addOverlay()/.initialize(). It produces
an error due to .div_ not having been created yet. Normal overlays
(polylines, etc) do allow this. Solution: move .div_ creation code
from .initialize() to the constructor.
2) Labels are forced to be visible at .addOverlay()/.initialize()
even if they were made hidden before. Solution: add helper
method .applyLabelVisibility_() and call it consistently from .show
(), .hide(), .setLabelVisibility().
3) LabeledMarker inherits from the GMarker the problem that it is
always visible after having been added to a map, regardless of the
visibility status assigned before (unlike other standard overlays).
Solution: add extra private property .ownVisibility_ to store assigned
visibility status and use it along with .applyLabelVisibility_() where
appropriate - in .initialize(), .show(), .hide().
/**
* Constructor for LabeledMarker, which picks up on strings from the
GMarker
- * options array, and then calls the GMarker constructor.
+ * options array, creates the div, and then calls the GMarker
constructor.
*
* @param {GLatLng} latlng
* @param {GMarkerOptions} Named optional arguments:
@@ -45,7 +45,18 @@
this.clickable_ = opt_opts.clickable || true;
this.title_ = opt_opts.title || "";
this.labelVisibility_ = true;
+ // That's a workaround for the problem with GMarker that it unlike
other
+ // GOverlay's is always visible after addOverlay(), regardless if
having
+ // been hidden before it
+ this.ownVisibility_ = true;
+ this.div_ = document.createElement("div");
+ this.div_.className = this.labelClass_;
+ this.div_.innerHTML = this.labelText_;
+ this.div_.style.position = "absolute";
+ this.div_.style.cursor = "pointer";
+ this.div_.title = this.title_;
+
if (opt_opts.draggable) {
// This version of LabeledMarker doesn't support dragging.
opt_opts.draggable = false;
@@ -61,8 +72,8 @@
LabeledMarker.prototype = new GMarker(new GLatLng(0, 0));
/**
- * Is called by GMap2's addOverlay method. Creates the text div and
adds it
- * to the relevant parent div.
+ * Is called by GMap2's addOverlay method. Adds the text div to the
relevant
+ * parent div.
*
* @param {GMap2} map the map that has had this labeledmarker added
to it.
*/
@@ -71,13 +82,12 @@
GMarker.prototype.initialize.apply(this, arguments);
Hey Sergey-
It looks good. I was the one that wrote all the show/hide stuff for
LabeledMarker, and I remember that I wasn't quite sure what developers would
expect the behavior to be. I assume that my current example of show/hide
still works correctly with this change in code?
Would you like to join the project and patch in the code, or have someone
else patch it in for you?
On Thu, Nov 13, 2008 at 9:31 AM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
> Hi,
> and first special thanks to Mike Purvis, as I have learned a lot while
> examining his LabeledMarker...
> Meanwhile during my first experience of using it in my project I ran
> into several visibility issues. The patch to fix them is appended
> below.
> 1) The current release version (1.2) of LabeledMarker does not allow
> setting up visibility before .addOverlay()/.initialize(). It produces
> an error due to .div_ not having been created yet. Normal overlays
> (polylines, etc) do allow this. Solution: move .div_ creation code
> from .initialize() to the constructor.
> 2) Labels are forced to be visible at .addOverlay()/.initialize()
> even if they were made hidden before. Solution: add helper
> method .applyLabelVisibility_() and call it consistently from .show
> (), .hide(), .setLabelVisibility().
> 3) LabeledMarker inherits from the GMarker the problem that it is
> always visible after having been added to a map, regardless of the
> visibility status assigned before (unlike other standard overlays).
> Solution: add extra private property .ownVisibility_ to store assigned
> visibility status and use it along with .applyLabelVisibility_() where
> appropriate - in .initialize(), .show(), .hide().
> /**
> * Constructor for LabeledMarker, which picks up on strings from the
> GMarker
> - * options array, and then calls the GMarker constructor.
> + * options array, creates the div, and then calls the GMarker
> constructor.
> *
> * @param {GLatLng} latlng
> * @param {GMarkerOptions} Named optional arguments:
> @@ -45,7 +45,18 @@
> this.clickable_ = opt_opts.clickable || true;
> this.title_ = opt_opts.title || "";
> this.labelVisibility_ = true;
> + // That's a workaround for the problem with GMarker that it unlike
> other
> + // GOverlay's is always visible after addOverlay(), regardless if
> having
> + // been hidden before it
> + this.ownVisibility_ = true;
> /**
> - * Is called by GMap2's addOverlay method. Creates the text div and
> adds it
> - * to the relevant parent div.
> + * Is called by GMap2's addOverlay method. Adds the text div to the
> relevant
> + * parent div.
> *
> * @param {GMap2} map the map that has had this labeledmarker added
> to it.
> */
> @@ -71,13 +82,12 @@
> GMarker.prototype.initialize.apply(this, arguments);
> Hey Sergey-
> It looks good. I was the one that wrote all the show/hide stuff for
> LabeledMarker, and I remember that I wasn't quite sure what developers would
> expect the behavior to be. I assume that my current example of show/hide
> still works correctly with this change in code?
> Would you like to join the project and patch in the code, or have someone
> else patch it in for you?
> Thanks!
> On Thu, Nov 13, 2008 at 9:31 AM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
> thanks for the invitation. I have no objections against joining the > project.
> I have also checked the new code against all samples including the one > with bars and restaurants. Looks like nothing is ruined :)
> Regards, > Sergey
> On 13 нояб, 01:54, "pamela fox" <pamela....@gmail.com> wrote: > > Hey Sergey- > > It looks good. I was the one that wrote all the show/hide stuff for > > LabeledMarker, and I remember that I wasn't quite sure what developers > would > > expect the behavior to be. I assume that my current example of show/hide > > still works correctly with this change in code? > > Would you like to join the project and patch in the code, or have someone > > else patch it in for you?
> > Thanks!
> > On Thu, Nov 13, 2008 at 9:31 AM, Sergey Ushakov <s-n-usha...@nm.ru> > wrote:
Thanks Sergey. I checked out your signature and it seems you didn't actually type the 'I AGREE". Can you do that, and then let me know what gmail address I should add to the project for you?
> Thanks Sergey. I checked out your signature and it seems you didn't actually
> type the 'I AGREE". Can you do that, and then let me know what gmail address
> I should add to the project for you?
Hey Sergey-
Thanks, I've added you. The CLA form is just a Google Spreadsheet form, it's
not that smart. :)
You can go ahead and submit the patch now. If you can, try to re-run jslint
and packer to generate the new packed file as well.
On Fri, Nov 14, 2008 at 1:54 PM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
> Ok, done. And the gmail address is supplied in the CLA form too. But
> frankly the CLA form did not have any objections the previous time
> also ;)
> Regards,
> Sergey
> On Nov 14, 12:41 am, "pamela fox" <pamela....@gmail.com> wrote:
> > Thanks Sergey. I checked out your signature and it seems you didn't
> actually
> > type the 'I AGREE". Can you do that, and then let me know what gmail
> address
> > I should add to the project for you?
I've encountered two issues with jslint and packer:
1) jslint has found a problem in the old part of the code:
Problem at line 111 character 5: Function statements cannot be placed
in blocks. Use a function expression or move the statement to the top
of the outer function.
function newEventPassthru(obj, event) {
...
This piece of code originates to the very first version by Mike, and
related comments suggest that he has put some effort into appropriate
considerations. Frankly I do not feel that I understand all aspects of
these matters, so maybe you have a look yourself or communicate Mike
so that he could share his ideas about best approach to make jslint
happy?
> Hey Sergey-
> Thanks, I've added you. The CLA form is just a Google Spreadsheet form, it's
> not that smart. :)
> You can go ahead and submit the patch now. If you can, try to re-run jslint
> and packer to generate the new packed file as well.
> - pamela
> On Fri, Nov 14, 2008 at 1:54 PM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
Sergey:
1) The jslint included in the util does not complaint about that
statement. You may used a different jslint that is more restrictive.
That said, if you want get rid of it, you can 1) move it up right
after the line ".initialize = function", or 2) rewrite it as
var newEventPassthru = function (obj, event) {
..}
As the best way to handle this: do not use this function, instead, use
the function in core library:
// delete the whole section of the function newEventPassthru
// then
//replace
// GEvent.addDomListener(this.div_, name, newEventPassthru(this,
name));
// with
GEvent.addDomListener(this.div_, name, GEvent.callback(GEvent,
GEvent.trigger, this, name));
not sure if GEvent.callback was available when the LabelMarker was
written, but there is no need for newEventPassthru function any more.
2) I think you should stick with the packer copy in the util folder
and just run ant with it, not try to check out the packer from other
source, unless you are totally familiar with the packer itself. As far
as I can see, if jslint is happy, then the packer is happy.
On Nov 15, 5:20 am, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
> I've encountered two issues with jslint and packer:
> 1) jslint has found a problem in the old part of the code:
> Problem at line 111 character 5: Function statements cannot be placed
> in blocks. Use a function expression or move the statement to the top
> of the outer function.
> function newEventPassthru(obj, event) {
> ...
> This piece of code originates to the very first version by Mike, and
> related comments suggest that he has put some effort into appropriate
> considerations. Frankly I do not feel that I understand all aspects of
> these matters, so maybe you have a look yourself or communicate Mike
> so that he could share his ideas about best approach to make jslint
> happy?
> On Nov 14, 6:18 am, "pamela fox" <pamela....@gmail.com> wrote:
> > Hey Sergey-
> > Thanks, I've added you. The CLA form is just a Google Spreadsheet form, it's
> > not that smart. :)
> > You can go ahead and submit the patch now. If you can, try to re-run jslint
> > and packer to generate the new packed file as well.
> > - pamela
> > On Fri, Nov 14, 2008 at 1:54 PM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
first thanks to Nianwei for the clues on getting hold of the tools and
for making jslint more happy :) I've finally got jslint and packer
running, and jslint now does not have any complaints, and the examples
do not look broken by the new version :)
Pamela, I have checked in the new version into the trunk svn
repository. What's going to happen next? :)
Regards,
Sergey
On Nov 16, 2:49 pm, Nianwei <nian...@gmail.com> wrote:
> Sergey:
> 1) The jslint included in the util does not complaint about that
> statement. You may used a different jslint that is more restrictive.
> That said, if you want get rid of it, you can 1) move it up right
> after the line ".initialize = function", or 2) rewrite it as
> var newEventPassthru = function (obj, event) {
> ..}
> As the best way to handle this: do not use this function, instead, use
> the function in core library:
> // delete the whole section of the function newEventPassthru
> // then
> //replace
> // GEvent.addDomListener(this.div_, name, newEventPassthru(this,
> name));
> // with
> GEvent.addDomListener(this.div_, name, GEvent.callback(GEvent,
> GEvent.trigger, this, name));
> not sure if GEvent.callback was available when the LabelMarker was
> written, but there is no need for newEventPassthru function any more.
> 2) I think you should stick with the packer copy in the util folder
> and just run ant with it, not try to check out the packer from other
> source, unless you are totally familiar with the packer itself. As far
> as I can see, if jslint is happy, then the packer is happy.
> On Nov 15, 5:20 am, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
On Mon, Nov 24, 2008 at 2:31 AM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
> Hi Nianwei and Pamela,
> first thanks to Nianwei for the clues on getting hold of the tools and
> for making jslint more happy :) I've finally got jslint and packer
> running, and jslint now does not have any complaints, and the examples
> do not look broken by the new version :)
> Pamela, I have checked in the new version into the trunk svn
> repository. What's going to happen next? :)
> Regards,
> Sergey
> On Nov 16, 2:49 pm, Nianwei <nian...@gmail.com> wrote:
> > Sergey:
> > 1) The jslint included in the util does not complaint about that
> > statement. You may used a different jslint that is more restrictive.
> > That said, if you want get rid of it, you can 1) move it up right
> > after the line ".initialize = function", or 2) rewrite it as
> > var newEventPassthru = function (obj, event) {
> > ..}
> > As the best way to handle this: do not use this function, instead, use
> > the function in core library:
> > // delete the whole section of the function newEventPassthru
> > // then
> > //replace
> > // GEvent.addDomListener(this.div_, name, newEventPassthru(this,
> > name));
> > // with
> > GEvent.addDomListener(this.div_, name, GEvent.callback(GEvent,
> > GEvent.trigger, this, name));
> > not sure if GEvent.callback was available when the LabelMarker was
> > written, but there is no need for newEventPassthru function any more.
> > 2) I think you should stick with the packer copy in the util folder
> > and just run ant with it, not try to check out the packer from other
> > source, unless you are totally familiar with the packer itself. As far
> > as I can see, if jslint is happy, then the packer is happy.
> > On Nov 15, 5:20 am, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
> Thanks! Now we just need to decide if the changes are significant enough to
> warrant a new version release of the library.
> I'm just looking through the reported issues now. Would you have interest in
> patching in the diff from either of these issues?http://code.google.com/p/gmaps-utility-library-dev/issues/detail?id=7...
> - pamela
> On Mon, Nov 24, 2008 at 2:31 AM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
the consent on issue 73 is achieved, and appropriate final revision is
available. I have not checked it in yet just to ask one more question
about API.
By the moment we can control label visibility either by hideLabel()/
showLabel() or by setLabelVisibility(). It's clear that these
different functions have appeared historically in the process of
realizing necessary API facilities, but aren't they finally somewhat
excessive? Perhaps we might consider deprecation either of them - just
to avoid confusion of new users? In the current revision the hideLabel
()/showLabel() pair is the right candidate for deprecation as they are
not fully functional, but it would be easy also to make them fully
functional and deprecate setLabelVisibility() instead - just to make
API more uniform...
What's your opinion?
Regards,
Sergey
On Nov 30, 8:17 pm, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
Hmm. So I think I did showLabel/hideLabel to be parallel with
GMarker.show/hide, but now when thinking about it, it seems
programmatically better to have a setLabelVisibility function.
Developers could just pass in whatever booleans into that function
instead of having to do an if/else block.
So I'm fine with deprecating the show/hide. Going forward, I'd like to
deprecate the "release" branches of the libraries and just have the
version folders. That way we can fully deprecate(remove) functions in
new versions without worrying about breaking old versions.
On Wed, Dec 3, 2008 at 9:07 AM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
> Hi Pamela,
> the consent on issue 73 is achieved, and appropriate final revision is
> available. I have not checked it in yet just to ask one more question
> about API.
> By the moment we can control label visibility either by hideLabel()/
> showLabel() or by setLabelVisibility(). It's clear that these
> different functions have appeared historically in the process of
> realizing necessary API facilities, but aren't they finally somewhat
> excessive? Perhaps we might consider deprecation either of them - just
> to avoid confusion of new users? In the current revision the hideLabel
> ()/showLabel() pair is the right candidate for deprecation as they are
> not fully functional, but it would be easy also to make them fully
> functional and deprecate setLabelVisibility() instead - just to make
> API more uniform...
> What's your opinion?
> Regards,
> Sergey
> On Nov 30, 8:17 pm, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
>> Hi Pamela,
> Hmm. So I think I did showLabel/hideLabel to be parallel with
> GMarker.show/hide, but now when thinking about it, it seems
> programmatically better to have a setLabelVisibility function.
> Developers could just pass in whatever booleans into that function
> instead of having to do an if/else block.
> So I'm fine with deprecating the show/hide. Going forward, I'd like to
> deprecate the "release" branches of the libraries and just have the
> version folders. That way we can fully deprecate(remove) functions in
> new versions without worrying about breaking old versions.
> Thanks for your effort on this!
> On Wed, Dec 3, 2008 at 9:07 AM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
On Wed, Dec 3, 2008 at 5:31 PM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
> Ok Pamela, just to make things more clear:
> should I better completely remove the showLabel/hideLabel pair or just
> mark them as deprecated in jsdoc?
> Regards,
> Sergey
> On Dec 3, 3:46 am, "pamela fox" <pamela....@gmail.com> wrote:
>> Hmm. So I think I did showLabel/hideLabel to be parallel with
>> GMarker.show/hide, but now when thinking about it, it seems
>> programmatically better to have a setLabelVisibility function.
>> Developers could just pass in whatever booleans into that function
>> instead of having to do an if/else block.
>> So I'm fine with deprecating the show/hide. Going forward, I'd like to
>> deprecate the "release" branches of the libraries and just have the
>> version folders. That way we can fully deprecate(remove) functions in
>> new versions without worrying about breaking old versions.
>> Thanks for your effort on this!
>> On Wed, Dec 3, 2008 at 9:07 AM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
- mime-type should be set to HTML for the setlabeltext example.
- The various GOverlay methods show up in the docs now that they're
auto-generated (they weren't previously). I'm thinking we shouldn't show
them, as they're not really intended for general use, and they're implied by
the fact that LabeledMarker extends GOverlay. There's apparently an
"@ignore" tag for JSDoc, maybe we can use that?
http://jsdoctoolkit.org/wiki/?page=ignore
I agree with all of them and will fix them at next check in.
My only concern is about revision history. I agree that JS code is not
the best place for it, but if we only rely on Google code repository
facilities, then some potentially important information like
references to discussions, etc may disappear from sight. Will it be a
good idea to introduce something like "release notes" file that might
accompany a new release? Or will it be a good idea to make more
extended comments to new revisions in the svn, so that to include all
references, etc? Or maybe you may have other ideas?
Regards,
Sergey
On Dec 7, 12:17 pm, "pamela fox" <pamela....@gmail.com> wrote:
> - mime-type should be set to HTML for the setlabeltext example.
> - The various GOverlay methods show up in the docs now that they're
> auto-generated (they weren't previously). I'm thinking we shouldn't show
> them, as they're not really intended for general use, and they're implied by
> the fact that LabeledMarker extends GOverlay. There's apparently an
> "@ignore" tag for JSDoc, maybe we can use that?http://jsdoctoolkit.org/wiki/?page=ignore
> That's it, thanks!
> - pamela
> On Thu, Dec 4, 2008 at 6:36 PM, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
> I agree with all of them and will fix them at next check in.
> My only concern is about revision history. I agree that JS code is not
> the best place for it, but if we only rely on Google code repository
> facilities, then some potentially important information like
> references to discussions, etc may disappear from sight. Will it be a
> good idea to introduce something like "release notes" file that might
> accompany a new release? Or will it be a good idea to make more
> extended comments to new revisions in the svn, so that to include all
> references, etc? Or maybe you may have other ideas?
> Regards,
> Sergey
> On Dec 7, 12:17 pm, "pamela fox" <pamela....@gmail.com> wrote:
> May it be a good idea if project notes for Google Maps Utility Library
> will be arranged like this?
> Regards,
> Sergey
> On Dec 7, 5:00 pm, Sergey Ushakov <s-n-usha...@nm.ru> wrote:
> > Hi Pamela, thanks for your hints.
> > I agree with all of them and will fix them at next check in.
> > My only concern is about revision history. I agree that JS code is not
> > the best place for it, but if we only rely on Google code repository
> > facilities, then some potentially important information like
> > references to discussions, etc may disappear from sight. Will it be a
> > good idea to introduce something like "release notes" file that might
> > accompany a new release? Or will it be a good idea to make more
> > extended comments to new revisions in the svn, so that to include all
> > references, etc? Or maybe you may have other ideas?
> > Regards,
> > Sergey
> > On Dec 7, 12:17 pm, "pamela fox" <pamela....@gmail.com> wrote:
Well Pamela, it might be a good idea, but it's up to you.
And I have no ambitions to write into the release wiki if it does not
fit standard procedures/approaches :)
I can equally make a separate text or html file with these release
notes. Just tell me which approach will fit best. And if separate
html, then it would be great if you give me a reference to some sample
of structure/styling.
Regards,
Sergey
On Dec 15, 8:28 am, "pamela fox" <pammyla....@gmail.com> wrote:
> Well Pamela, it might be a good idea, but it's up to you.
> And I have no ambitions to write into the release wiki if it does not
> fit standard procedures/approaches :)
> I can equally make a separate text or html file with these release
> notes. Just tell me which approach will fit best. And if separate
> html, then it would be great if you give me a reference to some sample
> of structure/styling.
> Regards,
> Sergey
> On Dec 15, 8:28 am, "pamela fox" <pammyla....@gmail.com> wrote: