Born Geek
Posts Tagged "googlebar-lite"

The Future of CoLT & Googlebar Lite

August 24, 2015

It has been quite some time since the last releases of either CoLT or Googlebar Lite, and a lot has changed in the land of Firefox extension development. In a few weeks, Firefox will require all extensions to be signed. At the moment, neither of my extensions (as available from this website, at least) meet this requirement.

The Firefox extension world is increasingly becoming a walled garden, much like every other browser today. As such, I’ve made the frustrating decision to release my extensions through the official add-ons site only. This policy will begin with the next release of each extension, which I hope to make available in the next month or so.

In addition, the next releases of both Googlebar Lite and CoLT are likely to be my last. I’m not as interested in Firefox development as I once was, especially given some of the frustrating plans they have announced for the ecosystem. This unfortunately means that support for the multi-process version of Firefox that is coming down the pipeline will not be implemented (at least by me).

If you’re a developer and want to contribute either bug fixes or new features for my extensions, you are more than welcome to do so (merge requests are always appreciated). The source code for both is available via GitHub:

Dropping Outdated Locales

February 18, 2015

I’m currently working on an update to Googlebar Lite, and I’m debating whether or not to drop some of the more outdated locales. I wrote a Perl script to gather some data about the locales, and this is what it reports as of my current development snapshot:

Locale   Matches   % Match   Missing   % Missing
 en-US       172   {Master Locale}

 ca-AD        24     14.0%         6        3.5%
 cs-CZ        12      7.0%         0        0.0%
    da         7      4.1%         0        0.0%
    de         8      4.7%         0        0.0%
 el-GR        32     18.6%         6        3.5%
 es-ES         4      2.3%         0        0.0%
 et-EE        14      8.1%         6        3.5%
    fr        13      7.6%         6        3.5%
 hr-HR        31     18.0%         6        3.5%
    it        23     13.4%         6        3.5%
 ja-JP         9      5.2%         6        3.5%
    nl         8      4.7%         0        0.0%
    pl         6      3.5%         6        3.5%
 pt-BR        31     18.0%         6        3.5%
 ru-RU        22     12.8%         6        3.5%
 sk-SK        32     18.6%         6        3.5%
    tr        30     17.4%         6        3.5%
 uk-UA         5      2.9%         0        0.0%
 zh-CN        30     17.4%         6        3.5%
 zh-TW        11      6.4%         6        3.5%

The 4 locales most out of date are el-GR, hr-HR, pt-BR, and sk-SK. Those are currently the ones I’m considering tossing out, but I also could make a case for tr and zh-CN. My non-scientific rule of thumb has been that I toss out locales that get to be more than 20% out of date (meaning that a sum total of 20% of strings either match or are missing). I’ll give this a few more days to think about it. Do you have any ideas as to what I should do? If so, feel free to leave a comment below.

Upcoming Change to Googlebar Lite

January 14, 2015

The “search words” feature of Googlebar Lite is a popular feature. But when Googlebar Lite lives on the same toolbar as the URL bar (the “nav-bar”), it doesn’t play nicely with everyone else. As you type words into the search box, everything to the left of the Googlebar Lite toolbar shrinks horizontally. This is a direct result of the search word buttons that appear as you type.

Starting in the next release, I plan on introducing a fix to this problem. When the Googlebar Lite toolbar is placed on the “nav-bar” toolbar, the search words overflow button will appear. As you type search words into the search box, they will appear as items in this button’s associated menu. Here’s a screenshot to illustrate this change in action:

Search Words in Googlebar Lite

This tweak should fix the associated problems that today’s design contains, while maintaining access to the search words for those who use that feature. Note that this mode will only activate in the aforementioned scenario (i.e. Googlebar Lite living in the nav-bar). When on its own toolbar, Googlebar Lite’s search words will appear today as they always have.

I’m interested to hear what everyone’s thoughts are on this change. I think it will be helpful, but I want to make sure I’m not breaking any scenarios that I may have overlooked. Leave a comment below to let me know what you think.

Comments Off on Upcoming Change to Googlebar Lite Tags:

Googlebar Lite 5.0.6

December 4, 2014

A small bug fix has just been pushed out for Googlebar Lite. Here’s the change:

  • Bug Fix: Performing an empty Maps search with the force classic Google Maps search option checked no longer results in a 404

Googlebar Lite 5.0.5

November 30, 2014

Version 5.0.5 of Googlebar Lite is now available. Here’s the change log:

  • Added an option to hide all toolbar separators
  • Added an option to force the classic Google Maps interface when performing a Maps search
  • Added a Ukranian (uk-UA) translation
  • Bug Fix: External toolbar buttons placed on the Googlebar Lite toolbar should no longer display their label

Googlebar Lite 5.0.4

September 20, 2014

I’ve just released a new version of Googlebar Lite, fixing an issue that was introduced in 5.0.3. The up menu wasn’t working properly thanks to an over-zealous edit I made. A big thanks to Richard Johnson for pointing out this error to me.

Googlebar Lite 5.0.3

September 16, 2014

I’ve just posted a new version of Googlebar Lite, which fixes a few outstanding bugs:

  • Bug Fix: Simplified logic in the ProgressListener routines that caused search terms to occasionally be removed in some circumstances
  • Bug Fix: The Googlebar Lite toolbar should no longer permanently overflow if it’s placed on the navigation toolbar and search words are enabled
  • Bug Fix: Overflowed search terms should now properly display an icon, indicating their highlighted color
  • Bug Fix: Search word buttons are no longer created when the search word area is hidden

Search Suggestions Broken in Firefox 31

July 26, 2014

It looks like Firefox 31 has broken the search suggest feature in Googlebar Lite. Specifically, it looks like mouse events are no longer being registered properly (for reasons I have yet to understand). If you use the keyboard to select suggestions, things work as expected.

I’ve opened issue #17 to track this bug, and will investigate how to fix this. Stay tuned for updates, and my apologies for the problem.

Comments Off on Search Suggestions Broken in Firefox 31 Tags:

Search Words and the Nav-bar

June 17, 2014

The search word buttons in Googlebar Lite are occasionally a source of frustration for me. With the user interface changes made in Firefox 28+, I’ve heard of an increasing number of users who place Googlebar Lite in the nav-bar (the toolbar that houses the URL field, forward / back buttons, etc.). When search word buttons are enabled, they cause the toolbar to shift around wildly as they appear or disappear. The toolbar can even get into a mode where it completely overflows into a breakout panel, with the only way to restore it being to close Firefox and reopen it!

I’ve been trying to think of ways to improve the way search words are handled when Googlebar Lite appears in the nav-bar. One option I thought of is to use a fixed width search word area. Some words would fit, while all the other overflow into the overflow menu, as they do today. This comes with its own set of problems, however (a bunch of blank space in the toolbar, being one of them). The other solution I’ve thought of, and which I’m currently leaning towards, is to have a dedicated search words menu button that appears in this nav-bar case. Search words would then become children of this menu button. This would make things compact, the size wouldn’t jump around, and the words would still be easily accessible (though it would require one more click).

What do you think of this idea? Are there other ways that search words might be handled in this case? I’m leaning towards implementing the second option above for the next release, but I’m open for other suggestions.