Hi;
Ah well ... I started a small update to our jpeg
support:https://github.com/pgiffuni/openoffice/tree/libjpeg-turbo
Unfortunately with those patches I now get a complaint that sinc_pi, which we
use from boost requires C++14. Why it doesn't complain now? Who knows, we have
a mess mixing very old language features and Boost doesn't help.
So I am working on a patch that fixes all the deprecated C++ warning issues
reported by clang/libc++; the patch is currently 2.7M and growing. I will
create a new branch as soon as I get something that compiles. After that I will
try to reduce a bit the Boost footprint as well. This is not meant for 5.0.
Concerning future roadmap: we need color
management.https://littlecms.com/tags/lcms2/
Oh and I installed CLion (free for Apache devs) with bazel support but I can't
figure out how to build AOO.
Pedro.
On Wednesday, November 4, 2026 at 10:31:28 PM GMT-5, Petko.apache.org via
dev <[email protected]> wrote:
Hi all,
I would like to put (again) the windows roadmap on the table. I have the
feeling that there is still a disagreement how we move and what to do.
What i would like to propose a 2 step modernization.
The goal is AOO6. I see following features in AOO6
- 4k support and multimonitor or variable dpi support
- windows (native?) theming, allowing at least dark mode, contrast mode.
- accessibility that work with readers. At least support windows reader,
but if we get 3rd party software to work too that would be awesome.
maybe other things i do not know about at the moment.
Why not AOO5. The answer is simple.
- momentum
it would push a release further back. I tried 4k support and variable
DPI, and while it worked it was a rabbit whole. I started to run into
small issues that created small frictions in the code.
I want to prepare for the changes, clean up code that does not support a
modern UI. (that does not mean AOO will look different. It means adding
the features to support the development that is normal today.
- change size.
The chang got really big. I want to split it into smaller chunks and
have it tested and create robust code.
Now where does it end then for AOO5.
I propose
- AOO5 floor is win7
- AOO API does not or minimal change from the win2k / winXP API, because
we know it works.
- Focus on modernizing the code base first.
-- cuting off 4.1.X
-- VLC modernization
-- fix optical bugs for a decent codebase. (examples are, if you have an
arabic or hebrew text the mark tool is really wrong. It marks the right
words but it is an optical glitch. On dxt there are some grafic errors,
which seem to have their root cause in the code which draws on the canvas.)
-- we will bump C++ standards internally pretty quickly once AOO5 has
taken over from 4.1.X
-- probably bumbing java standards too? not sure.
- python is an issue. For python 3.11.15, that we have in trunk i back
ported the compatibility already to win7. the project maintains only
compatibility to 8.1 which does not make sense in my eyes. Since win8 is
irrelevant. So far i think it works.
I think the floor in win7 is a small effort to maintain. It will not
slow development. It is a continuation of our principles.
And if we release AOO6, we still can easy backport fixes to AOO5 if the
communtiy has win7 in use and requests it
Which i think makes a difference in our communication to our users who
value long term support. Plus we do support the spirit of the EU cyber
resilience act without the need to do so.
Imho this would be a strong statement against industrial decay.
I hope this plan is convincing and makes sense. In addition I hope i
could make my point why flooring on win7 is not a step back. and does
not block.
I am looking forward to your comments.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
