Hi,
Em qua, 21 de nov de 2018 às 15:15, Frank Heckenbach
<f.heckenb...@fh-soft.de> escreveu:
>
> > I think that we should revert this change for the time being, though,
> > because if it was working in this way for about a decade and the
> > programs using FTGL worked "fine" despite having some bug there,
>
> Sorry, they did *NOT* all work fine, see my bug report.
I agree with that, that's why I said "fine" with quotes included. I
thought about adding "(for some value of 'fine')", but stopped short
:-)
However, from how I understand it, having completely blank rectangles
in the position of letters (which happens with critterding and
darkradiant for example) is worse than what happened before in your
original report -- it would perhaps be the worst case scenario of what
could happen before.
So in short, critterding is completely unusable now in Debian
unstable, probably megaglest can be considered unusable too, and
darkradiant is at least affected (there's a window rendering stuff
that contains what I assume are blank rectangles that are supposed to
be letters).
Others like zaz seem unaffected.
> > there's no need to change this now and break applications with only a
> > few weeks to fix this in 15+ other packages before the freeze.
>
> For me, there was very much a need to change. This was one of the
> reasons I started working on ftgl at all if you remember. Without
> either fix (sammy's or mine), ftgl is useless to me, so I'm not
> gonna do this in my repo.
Yes, I was talking exclusively in Debian, carrying some extra patch or so.
> So what can we actually do now?
>
> - If you view it as an ABI breaking change, I can bump the version
> to 3.0.0, just let me know. (This would mean that programs using
> the library would need to be rechecked anyway, right? So if we
> document this prominently, they'll know what to look for, both in
> source code and in program behaviour.)
Theoretically an ABI change gets solved with a simple recompilation,
and from what I understand it this is more like an API change (it
doesn't break when compiling but the results are not good so as to
make some programs unusable). So more than an ABI change this is
worse because it needs fixes in the code.
Since in Debian we cannot fix this in one sweep, and we need other
maintainers to help to bring their packages to compliance, this is
tricky.
The worst case is if there are popular applications that are installed
by 3rd parties and that we don't even have in Debian, in which case we
break those too. Not sure if this is the case, but it can
theoretically happen.
> - If you insist on a version without either of those bugfixes, do
> this in your code, but then I'm out, sorry. For me this will mean
> at least 2 more years working with an out-of-distro version (and I
> fear it would get neglected again, so maybe more like 10 more
> years or forever), so I'd have no reason to care about the distro
> version.
Let's try to avoid that, it's not good neither for FTGL nor Debian nor
the people involved :)
> - Otherwise just let the other packages find and fix the resulting
> bugs, like the saying goes "better ask for forgiveness than for
> permission".
The problem with this solution is that those packages that are broken
and which maybe cannot be fixed, will be unusable in Debian for a full
cycle.
Is there a way to easily determine when the applications are buggy by
searching the code? Maybe we can find an upper limit to the
problematic applications, or provide patches, if feasible.
> - A slightly more complex solution would be a flag to select the
> behaviour. Of course, it would need to be a runtime flag. It may
> default to the old behaviour, but that should be deprecated (and
> print a strong depreciation message -- unfortunately that would
> have to be at runtime too AFAICS, or is there a way to warn at
> compile time when a program, say, does *not* reference a
> particular function?).
I am not familiar with OpenGL stuff. Is there a way to detect if a
"Blending Mode" is provided at runtime, when the function is called,
and if not, provide a default one like the one before, and possibly
emitting errors for it to raise attention (both compile time and
runtime)?
Another option would be to have an extra argument in the function, say:
inline FTPoint FTBitmapFontImpl::RenderI(const T* string,
const int len,
FTPoint position,
FTPoint spacing,
int renderMode,
bool disableBlend = false);
Or perhaps a new function to enable/disable globally if the library is
initialised, or an env flag, or similar.
And I think that the default would have to be the old behaviour, yes,
because after many years behaving in that way the applications must
have learned to adapt or cope, and no one knows that they have to use
a different flag or invoke the method with an extra parameter.
I realise that maybe this is not what you like because applications
will ever remain buggy, but reallistically, some might even be
abandoned upstream, so they could remain unusable forever.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
