| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Meson is a meta build system that is:
- fast
- simpler to understand and use
- portable to multiple platforms through different backends
- well integrated with the GNOME platform
- well maintained
Using Meson allows us to build Pango much more quickly, and on all the
platforms we currently target, without any loss of functionality,
compared to Autotools.
Some timing comparisons with hot ccache for both build systems:
* autogen.sh: * meson
real 0m11.149s real 0m2.525s
user 0m8.153s user 0m1.609s
sys 0m2.363s sys 0m1.206s
* make -j$(($(nproc) + 2)) * ninja
real 0m9.186s real 0m3.387s
user 0m16.295s user 0m6.887s
sys 0m5.337s sys 0m1.318s
--------------------------------------------------------------
* autotools * meson + ninja
real 0m27.669s real 0m5.772s
user 0m45.622s user 0m8.465s
sys 0m10.698s sys 0m2.357s
System: Intel Core i7-7500U, SSD, 16GB of RAM
|
|
|
|
|
|
| |
While `.C` is a valid GCC extension for C++ files, it only works for
case sensitive file systems. Let's use `.cpp`, like the rest of the
planet does.
|
|
|
|
|
| |
No other library in the stack ships them any more, and they are of
dubious use.
|
|
|
|
|
| |
The log of each change is in Git, as it should be. For dist tarballs we
only care about the changes since the beginning of the last cycle.
|
|
|
|
| |
Avoid a compiler warning for potentially uninitialized variables.
|
| |
|
|
|
|
|
|
|
|
| |
It's used in pango-markup.c and pango-color.c, so it should have an
internally-available prototype, instead of an `extern` declaration at
the point of use.
This also avoids a compiler warning for a missing prototype.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First of all, we need to define `PANGO_UNAVAILABLE`, as it's missing a
definition, and the only reason why nobody caught this is because we're
building without -Wundef, and clearly nobody attempted using
min-required/max-allowed with Pango.
Additionally, we really need a way to disable deprecation warnings from
the compiler.
The complete implementation of the version macros for GLib-based
libraries includes both items above.
|
|
|
|
|
|
|
|
|
| |
Some files that this script will process might have UTF-8 items in
there, which can cause problems on Python 3.x as it is more strict and
careful on unicode issues. Fix this by:
-Doing what we did before on Python 2.x
-Opening the file with encoding='utf-8' on Python 3.x
|
| |
|
| |
|
|
|
|
|
| |
The compiler complains that rightmost_space may be used
uninitialized. And it may be right.
|
|
|
|
|
|
| |
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778663
|
|
|
|
|
|
|
|
|
| |
To make it a bit more explicit that there’s no need to worry about
introspecting them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778663
|
|
|
|
|
|
|
|
|
| |
This should fix a few scanner warnings, but this is not an attempt to
fix them all.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778663
|
|
|
|
|
|
|
|
|
|
|
|
| |
The handling for \r or \r\n line endings in pango_read_line() was
broken. It should have discarded the \r or \r\n, but was only doing this
for \n or \n\r. The condition (c == EOF) could never have been reached.
Coverity ID: 1391696
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778816
|
|
|
|
|
|
|
| |
Improve the behavior of the cairo renderer to take
alpha into account even if no color specified.
https://bugzilla.gnome.org/show_bug.cgi?id=773767
|
|
|
|
|
|
|
| |
Since win32_render_layout and win32_render_layout_line now support
rendering in color, that word no longer applies.
https://bugzilla.gnome.org/show_bug.cgi?id=768679
|
|
|
|
|
|
|
|
| |
Rectangle() uses x1, y1, x2, y2 coordinates instead of x, y, w, h. Fix
the coordinates passed to the function so it draws the background in the
correct location.
https://bugzilla.gnome.org/show_bug.cgi?id=768679
|
|
|
|
|
|
|
| |
Adding 128 to the component value would overflow in colors with full
brightness and set the component to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=768679
|
|
|
|
|
|
|
|
|
| |
If the DC's background mode is set to OPAQUE, ExtTextOut will draw its
own background boxes around glyph items. Since we don't place any
requirements on the DC, set the background mode to TRANSPARENT before
rendering any glyphs (and reset it to its original value afterwards).
https://bugzilla.gnome.org/show_bug.cgi?id=768679
|
|
|
|
|
|
|
|
|
| |
Underline drawing was using the pen selected into DC before
pango_win32_render_layout_line was called. Since layout allow the user to
select underline colors, we have to create a temporary pen in the correct
color before drawing it.
https://bugzilla.gnome.org/show_bug.cgi?id=768679
|
|
|
|
|
|
|
|
|
| |
Increasing the component values by 128 may overflow and result in that
component being treated as 0. Additionally, using a brush to color text
is wrong; ExtTextOut instead uses the color set by SetTextColor to draw
glyphs.
https://bugzilla.gnome.org/show_bug.cgi?id=768679
|
| |
|
| |
|
|
|
|
|
|
|
| |
This enables the new feature recently added in G-I where we can generate
the full NMake Makefile module to build the .gir files by passing in a list
of C includes, instead of needing to specify them fully one-by-one with
--c-include=...
|
|
|
|
|
| |
This enables one to build the introspection files using Visual Studio
2017.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In pango_layout_index_to_pos(), it looks like layout_line could be
dereferenced while still NULL in the first loop iteration. This is not
the case, as other bits of PangoLayout ensure its start_index is always
0, so this branch is never taken. Add an assertion to clarify that and
guide static analysis.
Coverity ID: 1391700
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These checks are preceded by other checks or code which demonstrates
that the values are definitely always non-NULL.
In the case of pango_attr_list_insert_internal(), the final branch of
the function never needs to update list->attributes_tail, as the middle
branch handles the case of appending to the list. The final case is just
for insertions in the middle of the list.
Coverity IDs: 1391710, 1391711
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778654
|
|
|
|
|
| |
This will ensure that it will be up-to-date when
win32/vs10/pango-install.props is re-generated.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates the autotools scripts to support Visual Studio 2017 builds, by copying
the Visual Studio 2010 projects and updating items in there as necessary.
Note the format of the toolset version changed, so we allow one to specify a
custom toolset version string and hence use it if it is specified, otherwise
the toolset version string is generated as it was before.
Since Visual Studio 2017 aims to be compatible on the CRT level as Visual Studio
2015, the 2017-compiled binaries should be usable without problems with 2015-compiled
binaries.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are a few code paths where pango_utf8_strwidth() is called on
language-specific sample text. The sample text should have been chosen
to never have a zero width, but we should add some assertions to ensure
that’s the case. This guides static analysers into the right analysis.
Coverity IDs: 1391697, 1391698, 1391699
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778602
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If this loop adds the final feature to the features array, the start and
end assignment for the next feature will drop off the end of the array.
I don’t think the assignments are necessary, since num_features stores
the number of elements in the array (so it doesn’t need to be
terminated), and the start and end elements are assigned each time a
feature is parsed.
Coverity ID: 1391709
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=778601
|
|
|
|
|
| |
Some more paths in auxillary scripts and NMake Makefiles need to be
updated as well...
|
|
|
|
|
|
|
| |
This allows one to go down one less level in the directory tree to get to the
Visual Studio project files, and so make things more in line with the rest of
the GTK+ stack. This also cleans up the Visual Studio 201x projects as there
are some items that can be actually combined.
|
|
|
|
| |
The AdditionalIncludePaths setting missed a semicolon, fix that.
|
|
|
|
|
| |
We don't have a separate math library for Visual Studio, so don't try to
link to one in the .pc files.
|
|
|
|
|
|
| |
This is to ensure that any changes that was made to the generated
build/win32/vs10/pango-install.props will also be applied to
build/win32/vs[11|12|14] as well.
|
|
|
|
|
|
|
|
|
|
|
| |
Make the Makefile.am targets for generating the Visual Studio projects re-generate the
project files and the header listings whenever the Makefile.am's that include
build/Makefile.msvcproj changes, so that whenever a source/header is added, they will
be reflected in the projects and in the property sheets that are used to copy the
headers.
Also ensure that these are applied to the vs11, vs12 and vs14 projects when this
happens, as they are copied and processed from the Visual Studio 2010 projects.
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=770729
|
|
|
|
|
|
| |
Introduced with commit 1147da131ad13e583e73fed956e5c944e1497bf4
https://bugzilla.gnome.org/show_bug.cgi?id=771004
|
| |
|
|
|
|
|
| |
Now that we're using new-style deprecations, we have to fight
a little harder to get rid of them inside pango.
|
|
|
|
|
|
|
| |
Update the copyright notice of this file, to reflect things more
accurately and to give more proper acknowledgement.
Please see: https://bugzilla.gnome.org/show_bug.cgi?id=767587#c16
|
|
|
|
|
|
|
|
|
|
| |
Add a configure check to see whether compiler directives are available
for exporting symbols, and use them if so. Likewise, update
the Visual Studio projects and config.h.win32.in to do likewise for
Windows builds.
We can then drop the .def files that were used to export symbols on
Windows builds, which should clean up things a bit.
|
|
|
|
|
| |
This is to ensure that we can override the verion macros to export the symbols
later.
|
|
|
|
|
|
|
| |
From the last commit, decorate all the symbols with the version
macros. Also add the version macros in the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=767587
|
|
|
|
|
|
|
|
|
|
|
| |
This header is used for:
-Indicating what stable versions an API is introduced at and after 1.30.0.
-Indicating what APIs are deprecated, and which stable release series
they are deprecated if the deprecation is done after 1.30.0. This replaces
the use of G_DEPRECATED* in Pango.
-Use in a later commit to be used to export symbols directly via compiler
directives instead of doing so over .def files, for compilers that do not
support exporting via regex expressions.
|