olikraus:
Let me start to answer your question on the last section: The calculation of a frame around a string is discussed here for U8glib: Google Code Archive - Long-term storage for Google Code Project Hosting.. It should be the same for Ucglib, although function names might differ a little bit.
So how would this be invoked in a uCglib sketch? Can I somehow send a string to a ucg object, after passing it setFont(), and get its size back? Again, I'm not well-versed with object-oriented functions, variable scope, etc., and everything I've tried just gives various errors. I don't see any functions in uCglib exposing font or string metrics except getFontAscent() and getFontDescent().
olikraus:
I agree to your other statements. But i would call it an impossible task to create a generic open source graphics library. As an open source project, there is no budget to buy all the different hardware.
What about an abstraction class, providing a standard graphics primitive and geometry query vocabulary which can then be parsed into calls to hardware-optimized libraries, thereby reusing the hardware driver work you've already done? So, rather than invoking u8glib or uCglib directly, we'd pass the hardware library of choice to a generic Display class, something like this:
Display display(uCglib, ili9341, hwspi, 240, 320, 18, 9, 10, 8);
// Display anyDisplay(hardwareLibrary, hardwareChipset, hardwareInterface, displayHeight, displayWidth, displayBitDepth, cdPin, csPin, rsPin);
void setup(void) {
display.begin();
int lcdWidth = display.getWidth():
int lcdHeight = display.getHeight();
int padding = 8;
display.clearScreen();
drawWindow();
}
void loop (void) {
}
void drawWindow(void) {
display.setColor(0,255,255,255);
display.drawRect(padding, padding, lcdWidth-padding, lcdHeight-padding);
}
For that matter, why not then let the Display class pick which hardware library to use, based on the chipset definition? Can the Arduino IDE handle conditional includes properly yet?
Basic bitmap primitives should be the same across every display other than character LCDs, shouldn't they? I would also think that character devices have less in common at an abstract level than pixel devices, so it makes more sense from a user perspective to group all pixel devices into a single abstract class, excepting character devices. And the Display class could allow unsupported calls to fail gracefully by, for instance, thresholding RGB values for 1-bit displays, etc...
Any reason this wouldn't make sense?
Thank you again, by the way, for the mind-blowing amount of work you've put into all these libraries. I'm so impressed. I just wish I could figure out how to get u8glib to work on my TFT for the moment, until M2Tklib supported full-color devices...!
Quite frustrating. I should qualify all this by saying that I am a database "programmer"