conflict with U8glib from Arduino IDE's Library Manager.

[davidbuzz]

When this library is manually installed into the 'libraries' folder, it works/compiles fine ( tested on IDE version 1.6.7 ) , but it also triggers the 'Library Manager' to report that there is an updateable "legacy" library ( this one and a few others). When I followed the instructions of the IDE, and installed the new versions of each of the available software updates, the replacement U8glib library does not compile the same way this one does.

Using library SdFat in folder: /Users/xxx/Documents/Arduino/libraries/SdFat (legacy)
Using library u8glib in folder: /Users/xxx/Documents/Arduino/libraries/u8glib (legacy)
Using library MCP3424 in folder: /Users/xxx/Documents/Arduino/libraries/MCP3424 (legacy)
Using library MCP980X in folder: /Users/xxx/Documents/Arduino/libraries/MCP980X (legacy)
Using library ds3231 in folder: /Users/xxx/Documents/Arduino/libraries/ds3231 (legacy)

[davidbuzz]

Sketch->Include Library -> Manage Libraries... -> (type u8 into search box ) -> click the line for the u8glib library listed below -> click Install button.

[MLXXXp]

I agree. If you're going to create and require a custom version of a library, it should be renamed so it doesn't conflict with the original. The original may need to be installed in the IDE for use by other Arduino projects.

[charlespax]

Agreed. I'll rename the library and submit a pull request upstream. Ideally, the Pax Instruments LCD would simply be supported upstream.

[charlespax]

I've renamed the library to PaxInstruments-U8glib. The changed are also reflected in the t400-firmware repository. I'm away from the office and I don't have a T400 on hand to test right now, but everything compiles.

Is this implementation satisfactory? If so, I'll implement it for the rest of the libraries.

In case you're curious: I'm using forks hosted on the Pax Instrument Github account to ensure the code is in a known state. I could do the same thing by cloning the upstream repo and checking out a specific commit. The downside is that beginners wouldn't be able to just click the "download ZIP" link. In the installation instructions we could link to the zip file from a specific commit (e.g. "https://github.com/olikraus/u8glib/archive/5539f03b4c7d81b02dab33e07a39f79ed7615950.zip"), but that feels a little messy.

[charlespax]

Pull request: olikraus/u8glib#397

[MLXXXp]

I've renamed the library to PaxInstruments-U8glib.

I would have put the original library name first, extending it with a postfix. This makes it easier to spot when searched for or sorted. You could also probably get away with shortening it a bit without the likelihood of causing a conflict:
U8glib-Pax

If so, I'll implement it for the rest of the libraries

I don't think any of the other libraries conflict currently, but it still should be done.

I'm using forks hosted on the Pax Instrument Github account to ensure the code is in a known state.

Understood. This is the right thing to do since you have a specific target and don't want the possibility of it being adversely affected by changes to the common libraries, which you don't have control of. You should just monitor the original libraries for any bug fixes or enhancements that would be worth porting to versions that you maintain. It's also courteous to create pull requests for any changes you make that may be beneficial to the original library (as you've done).