A while ago, it did seem like @paintYourDragon was maintaining the Adafruit_GFX library on Github, but recently, it seems that PRs are not even being looked at.I am working on some things around the GFX library that require some minor PRs (to provide virtual functions for some subclasses) and also trying to extend the library in two ways (one is true RGB24 support, the other is indexed color support) and would hate to do this without some consultation and the hope of it actually ever beeing incorporated.

So: is there anybody who's able to look at the github space with any regularity and hopefully also be a mentor / shepherd for people like me, trying to work on the library?

Keep in mind you can always create a fork and add whatever capabilities your task requires; any important changes in the original repo can usually be tracked and merged as needed. Most of the Adafruit code has a permissive license and can even be used in commercial products, Kickstarter projects and so forth. Custom forks are totally encouraged.

Pull requests and Github issues tend to get "batched" -- several might get looked at when time permits. But there's no specific time interval to these batches. They're competing for attention with a lot of other code repos, along with more deadline-sensitive matters like tech support and new product or tutorial development.

High-priority pull requests tend to be those that solve recognized problems that have been reported by multiple users in the forums. (For example, on Raspberry Pi, sometimes new releases of the Raspbian operating system have broken multiple guides. Those are sudden major priorities.)

Really the goal on most repos is just to demonstrate the product in use. A library to accompany a breakout board, for instance -- examples might show typical calling sequences, library might function as a basic diagnostic or as a minimally-capable tool. They're not necessarily optimal (though not pessimal either) and seldom exhaustive, feature-wise. PRs may or may not get merged depending on what they're trying to do.

Break compatibility with existing code or data. In fact this might be the Prime Directive. While it's an easy matter to fix our own guides and examples if an incompatible change is made, there's an enormous number of derivative projects out there, many of them in print, impossible to change. Quite often this means having to accept that we've "painted ourselves into a corner" and certain outstanding bugs or bad design decisions can't be fixed in a direct manner (such as the Code Page 437 bug/workaround in Adafruit_GFX, or the fact that colors are pretty much inherently 16-bit, though in the case of the NeoMatrix library there something of a workaround, albeit kludgey). Case in point, there's been some PRs regarding font compression, but I'm unlikely to merge them as this either breaks compatibility with existing font header files out there in the wild, or introduces bloat by handling a third font format even more complex than the second one.

Reformat things for the sake of reformatting things. Seriously, I've even had to skip over what are probably good bug fixes because the reformatting causes enormous "diff" changes that can't be visually untangled to see what's actually changed vs. what hasn't. I won't do blind merges.

Adds redundant or nonsensical features for the sake of more features.

"Bumps." There's no surer way to make me ignore a bug than a "bump" post in the forums or Git issues, because I am a cantankerous old man.

Adds support for devices outside our product space. For example, there've been some PRs for monochrome OLEDs we don't carry. That's what forking repos is for...it's cool, we encourage it! But you won't see these merged because we don't have the hardware on-hand to test against, and even if we did it's a time sink away from supporting our own customers or working toward our own product goals.

I'm of the belief that all PRs are well-meaning. Sometimes I might leave a PR stewing for months or longer because I hate to be the bearer of bad news and don't know how to politely tell a well-intentioned person that their contribution didn't make the cut.

Thanks for the exhaustive response @pburgessFirst of all: the bump, as well as the whole post, wasn't meant to annoy anyone but to get attention. Things drown pretty quickly here if they're too far out of the focus of this forum, which is really projects around Adafruit hardware. So: if it annoyed you, please apologize, that was not the intention.

I understand the point that the code is (initially) intended to be able to demonstrate the Adafruit hardware, but especially Adafruit_GFX has become an important part of the Arduino ecosystem, wouldn't you agree (at least most things I do have some sort of a display).

When I did the work to implement fonts, I was very happy to see that included and I think that was to the benefit of many people out there.

And this is the thing: Adafruit-GFX-library is part of what is being installed with Arduino by default, that's what people see and use, that's what the display drivers use and so forking it is really just a way to work on single projects (as I do) but difficult as a way forward for the codebase as such.

I have spent quite a bit of time trying to expand a number of things and come across some limitations. The simplest one is this one, asking for inclusion of two functions that are present in some derived classes but not in the GFX class itself, making it difficult to write code that works with a wide set of displays like my Gauges class. Currently, I am working in two other directions as well, one is a general enhancement of Adafruit_GFX to be able to deal with 24 Bit rgb color and to provide the application with a set of capabilities provided by the display driver. As I'm aware that this might break compatibility, I have submitted it as an issue to hopefully get some discussion. As part of this, I am also working on an indexed color model similar to the Bitplanes model on the Amiga, mainly to be able to have canvasses that are less demanding on memory (this is in the context of the Gauges library that currently uses canvas16 to draw off screen, which is terribly memory ineffective since any gauge uses at max 4 colours)

Lastly, while working with some of the display libraries recently, it became obvious, that the whole Adafruit_GFX ecosystem is probably in need for some overhaul.Modern driver libraries implement a huge amount of code to drive their respective interface on all sorts of platforms, making them hard to maintain. There should really not be any specific Teensy/ESP8266/whatever platform code in the display library, nor should it be in the GFX library. The ILI9341 is, in my view, a great example of how it should not be.

So, I understand your approach, and it works well for keeping it all in one piece, compatible and simple, but I would also appreciate a wider discussion around those larger topics that will need some decent architecture in order to not be incompatible.

And lastly, the thing about being the bearer of bad news: in this I side with Linus Thorwalds. There is no benefit in making someone think they doing well when they aren't. I am well aware that despite my advanced age (you think you're old? bwaaahaa!), my grasp of c++ is rather light (heck, on another project, I'm currently struggling to understand delegates. Mind.blown)So when you think a PR doesn't make the cut, say it. We're all hobbyists, we're all doing it for the fun, and a big part of the fun is to learn, at least for me, and you learn from your mistakes and the fact that someone points them out. The way I've seen you interact in the past makes me think you don't share the same temper as Linus, so there is not a huge probability that we'll all get into big fights :D

with that: happy holidays to everybody and hopefully, we can find a way to work on a few of the things I've laid out above.

Thanks for understanding. And I should probably have added a disclaimer that much of this is my own approach and doesn't canonically represent Adafruit policy, though I'm pretty confident the "don't break code" and "focus on supported products" elements would be a part of such a thing. It's like...we talk about this stuff sometimes but there's no real rulebook. Perhaps there should be, it might avoid some misunderstandings and hurt feelings.

Something also I've been ruminating is having a brief "roadmap" section either in a repo's README or comments in the code itself that covers the planned direction of the project. Things that were wanted but got cut short...but also, maybe, mention things definitely outside the plan, so it's not as awkward if a PR is passed over. I've been meaning to try the roadmap thing in a couple recent projects but even this part itself got cut short. It's like a firehose of projects sometimes! As an example, the source code for the Raspberry Pi 'retrogame' program asks for no new features, as it's become a super complicated mess and we'd like to use simpler Python scripts for such things in the future...but that request could be made more conspicuous in a roadmap section.

As for GFX...that kind of...grew...into a more pivotal thing than expected. It was a neat way to abstract away the drawing primitives from the hardware, but like I said, has a number of corners that have been painted into. There's some features and performance bottlenecks that I'd really like to fix but it would just break the world at this point...it's one of those Space Shuttle/horse's ass problems. Maybe at some point we'll need to make a clean break with a 'GFX2' library and could address some things, but that's really not in the cards right now and also one needs to be careful of Second System Effect.

from what you say, I would think that a good approach would be to go ahead and define requirements (or in modern terms: a backlog) for what we would want to see in GFX (be itv2 or not).

I can see that this would be a massive undertaking when addressing everything, which ultimately would probably require changes to the interface (spi/wire/whatever), where I believe anything platform specific should go into the platform core and all the classes derived from GFX should be free of platform specifics.

I do belive that there are a number of people who would be willing to contribute code and help build this in order to get a more flexible environment.

Would it be a good idea to open a document to collect a "wishlist"? and some architecture ideas?

I have still a number of wishes/requirements that I would still be happy to contribute:

* beyond 7-Bit ascii characters* selective icon support (font awesome, without having to import the full icon set)* flexible bit depth canvasses* auto updating Gauge objects* support for RGB24 and displays that can support more than 16 Bit (ili9341 with RGB18)* capability reporting for specific implementations

Also, getting all the interface / platform specifics out of the display driver libraries would be really useful in order to make things cleaner and make implementations of new drivers easier

It would also be good to have an idea how to better support alternative displays such as e-papers which don't allow single pixel updates.

I think you're heading in the wrong direction. Think about the customer. Most have a hard time figuring out what an if statement is for an why delay(); is a bad thing. If you roll all these goodies into the base classes, your going to make the lowest rung on the ladder way too high for them. It works fine as it is. Keep it simple and understandable.

The default implementation of the 24 bit interface would just fall back to 16 bit and do the conversion automatically, but a more capable display driver can chose to implement the function locally and, for example, use an RGB18 implementation or better, depending on the capability of the hardware.

So if anything, I think the change would make it easier for the beginner as I think writing "255,0,0" is a more intuitive way of saying "red" than writing ...errrr, what's the RGB16 for red again? 32768+16384+8192+4096+2048 or 0x1f<<11 or even rgb565(255,0,0).

The fact that the display could be asked for capabilities is entirely optional, for most cases, that would be encapsulated by GFX itself, but for an advanced user, it would be useful to know what they can expect the display to do. Say you are writing code that would want to scroll text. Some display classes support that directly, some don't. So you could decide in your code, based on a display capability, which way to go. That would just enhance portability. While we all tend to know firmware is written once and for a specific hardware set, that's not really true, is it? We all share code a lot in the community and this would make example code more available across hardware combinations.

Have you had a look at the gauges library I'm working on? I think this should be most appealing to a novice who just wants to get some data displayed, since it basically takes most of the issues that can make displaying data difficult and wraps them in a class (which is by no means finished or polished yet).

And lastly international character sets and icon fonts: those were specifically asks from novice users. Think about it: they come from their own environment where characters are being used that don't exist in ASCII. Today, if they use the custom fonts, they run into the issue that their accented or other local characters are just not being displayed. Why would this happen? The expectation would be that it just works, right?Same for icons, why can't we have simple icons?Well, the problem here is that the implementation is much more difficult that it would seem, but it would be under the covers, the only thing the user would have to know is how to tell the system, what they mean when they type something like "é", or "ü" or "â" - and for that, they would, in my thinking, select an iso character set by chosing a #define.

Now, does it all have to go into the base class?I'm not sure. The way the GFX system is built, any display driver inherits the base class, so I don't see a simple way to split things up in a base and advanced class without breaking a lot of things (but I might just be wrong). But could we provide a simplified and an extended API set from the same class? Well yes, of course. We could even implement a turtle graphics API if we wanted. My preference would be to make the interface as accessible as possible for the novice while providing enough functionality for the advanced user. After all, this is also a learning environment and when we tell novices to stay away from the more complex stuff by hiding it someplace else, we're actively discouraging them from learning but if we're providing an API that reaches from a simple "display this number" (as in the Gauges library) to a (mildly) complex "create a canvas with five bitplanes and set the following palette", I think that would encourage learning as your capabilities increase.

I'm all for making the lowest rung low enough so that anyone who wants to use it will be able to use it.But I also think even the lowest rung should already reward the user with an "oh, I have just learned something" moment.

but that's just my 0.02ct

pj

ps: when I started out working with the GFX library, I hit the international character set issue and boy have I learned about things when I went and wrote fontconvert and the initial implementation of the rendering routines in GFX. They have since been improved by others but I am certainly a better developer now than I was before.

I think the odd 16 bit color packing is to match .BMP files. But anyway, to deal with colors I just created my own colorObj independent of any of this stuff. It stores colors in 24 bit and can output them in the 16 bit if you want. Objects can be created by either flavor as well. The neat thing is, I can use it for anything. GFX, bitmap files and Neopixles. All my blending routines and things have a nice place to live and no complexity is added to any of Adafruit's base classes.

I've not looked at your gauge stuff. I'm actually pretty skeptical about gauge libraries in general. I tend to find writing my own is typically easier than trying to understand other people's logic. I'm weird.

Anyway, I'm still in the "simple concise base tools" camp. Added features add confusion for the beginner and makes things harder to maintain. The other problem with adding features is that they tend to blur the definition of the library itself. Blurry defined code is always a nightmare to use, maintain or explain.

The font issue? I've run into it myself. I don't know what the correct way to jump would be for this.

An independent gauge library? Even one that uses GFX? Wonderful. Adding it to GFX? I donno'.

jim_lee wrote:I think the odd 16 bit color packing is to match .BMP files. But anyway, to deal with colors I just created my own colorObj independent of any of this stuff. It stores colors in 24 bit and can output them in the 16 bit if you want. Objects can be created by either flavor as well. The neat thing is, I can use it for anything. GFX, bitmap files and Neopixles. All my blending routines and things have a nice place to live and no complexity is added to any of Adafruit's base classes.

But every one has to re-invent the wheel.

jim_lee wrote:I've not looked at your gauge stuff. I'm actually pretty skeptical about gauge libraries in general. I tend to find writing my own is typically easier than trying to understand other people's logic. I'm weird.

we all are

jim_lee wrote:Anyway, I'm still in the "simple concise base tools" camp. Added features add confusion for the beginner and makes things harder to maintain. The other problem with adding features is that they tend to blur the definition of the library itself. Blurry defined code is always a nightmare to use, maintain or explain.

I agree, but then again, there are already things in GFX that are that way, buttons. I personally don't think they belong into GFX but into a UI lib that is more encompassing than just buttons. Perhaps they are actually gauges.

jim_lee wrote:The font issue? I've run into it myself. I don't know what the correct way to jump would be for this.

well, it would have to balance complexity, flexibility, portability and memory useage. The arduino platform (and actually the write function used by print/printf etc) handles utf8 if the input is utf8, so we could use that, but I think that firmware is better off with smaller sets such as are defined by ISO8859 and actually selecting specific sets from -1 to -15 or so. The downside is that the forward mapping, for some encodings, creates either a very sparse table or requires an index search. One is bad for memory usage, the other is bad for performance.The request for icon fonts is even worse, I fear that would be #define hell as font-awesome alone will use tons of memory if completely imported (http://fontawesome.io/cheatsheet/) though, wouldn't it be cool if you could use that coffee cup by just printing 'fa-coffee'?

jim_lee wrote:An independent gauge library? Even one that uses GFX? Wonderful. Adding it to GFX? I donno'.

That's what I built here and I think it should live outside of GFX since the long term goal is to also enable physical things as gauges (such as servos, steppers etc). It just layers on top of GFX, but it was one of the first places where I found I have to do something about GFX itself, too. First, there are functions that only some derived classes implement (such as those pesky oled displays that need a display() call). Those need to be implemented in GFX as virtual so they are at least available when the subclass does not define it. And because I'm using the canvas object (in essence an in-memory pixbuff graphics device) I came to the point where gauges uses just too much memory by allocating a rgb16 canvas - hence the thought of creating flexible bit depth canvasses. I could of course build that into the Gauges library itself, but would that really be the place for it? I'm torn about this one as it certainly breaks many of the existing drawing functions by re-defining the color parameter to not be the actual color but a color index.

jim_lee wrote:-jim lee

btw, I am appreciating the discussion as that was one of the things I wanted to stipulate. I don't want to just fork GFX and do my own thing (for one, that will have a hard time to get momentum). If we understand what we want and where we want to take it, the result will be much better.

there are already things in GFX that are that way, buttons. I personally don't think they belong into GFX

Totally agree. What I see is: GFX is for drawing. Buttons don't just draw, they interact. Now we've just muddied the waters about what GFX is. Is it drawing? Does it control touch?

As for Fonts. The approach I'd planned on taking was to setup a .BMP file with all the letters I wanted in a grid. Easy to do. I already have code to grab a rectangle from a .BMP file and draw it to a GFX rectangle. This gives me any font I could possibly want. Or icon too I guess.

And yes, the github stuff is frustrating. I submitted a fix for the music maker stuff and I have no idea what ever happened to it. I gave up checking after awhile.

I guess in the end its easier to build our own paper castles with allowances for other's ideas as opposed to nudging others to adjust theirs to suite our ideas. No matter how correct our ideas seem to us, they're still just our ideas. They're probably totally wrong from other points of view.

nice!Now, in my model, this would be an object (let's say of class servoGauge) that you would configure with things like max/min value, output pin, max/min angle and maybe something like slow start/slow stop behaviours and after that only call setValue(v) with v being what you want it to show.Apart from the different configuration, it wouldn't make a difference if it's an on-screen gauge, a number display or a servo like yours.

and on each building our own: that so violates the basic idea of open source. Contribution is king! (or Queen, if you want)

A month or so later.. Now I'd love an addition to the GFX Library. Clipping rectangle. Set the clipping rectangle and it would only draw in that area. It would be so nice for things like scrolling a list. Set the clipping rectangle to the visible part of the list and scroll all your list items past it.

@pjakobs I don't think I mentioned how I dealt with wanting more than GFX Lib. I have my own base drawing class that has all the same calls as GFX. So, when I want to use adafruit hardware, I derive a class for that piece of hardware from my library. 90% of the calls are pass throughs to the GFX library. But things I want to add I can at wild abandon. If I want to use someone else's hardware, Its typically not hard to derive a class for it from my base class. All my screen drawing stays consistent and I don't have to wait for adafruit. (Much).