GNOME Bugzilla – Bug 682840
Deprecate much of pango-utils.h
Last modified: 2015-05-16 21:08:46 UTC
Pretty much all of it can go.
*** Bug 682841 has been marked as a duplicate of this bug. ***
I was going to open a new bug for deprecating pango_get_sysconf_subdirectory() and pango_get_lib_subdirectory() as they are of no use now after bug 733882 (to help with bug 733137), but since this one is already open I’ll use it. I’m just not sure what the function should return now, an empty string or NULL? or even some dummy path?
Maybe there's a glib function we can just call and return? I don't have any preference. NULL sounds safer.
Glib does not seem to have a direct equivalent for those, and may worry about returning NULL is that clients might not be prepared to handle it (though I have hard time finding any third party code using them). But if we just want to get rid of the DllMain thing, we can just pass NULL to g_win32_get_package_installation_directory_of_module() which makes it look up for the directory of the executable rather than process, but it hardly matters anyway.
I'm fine either way. Matthias?
if you want to deprecate the functions, just leave them as they are - returning something other than what they are documented as returning is going to break potential users out there. The alternative is to just break them outright, but then you might as well remove the functions.
But what those functions refer too just gone, pango no longer have a conf or lib dirs to return.
So far we haven't been removing functions for ABI reasons. We are breaking any users that rely on modules and engines, but we don't know any users that would be affected. We might want to do a removal at some point, but there's no rush in doing that. Khaled: just make them return something that 1. wouldn't crash any client, and 2. is not a clear security issue. Can't think of anything for 2. Just return whatever is convenient.
Created attachment 301492 [details] [review] Deprecate noop utility functions After the removal of modules and configuration files, both pango_get_lib_subdirectory and pango_get_sysconf_subdirectory are meaningless now. This patch deprecates them and removes the Windows specific behaviour as it prevents statically compiling Pango under Windows.
Thanks Khaled. Please push it out!
Comment on attachment 301492 [details] [review] Deprecate noop utility functions Attachment 301492 [details] pushed as d2dda8d - Deprecate noop utility functions
Created attachment 301493 [details] [review] Deprecate unused utility functions
The last patch deprecates most of what remains in pango-utils, except the version functions (should remain I think), pango_skip_space and pango_scan_string (used in pangowin32-fontmap.c), pango_scan_int (used in pango-markup.c).
Behdad, what do you think about the last patch?
Looks good. pango_skip_space, pango_scan_string, and pango_scan_int can be deprecated as well, even if they are used internally. The point was that these are minor utilities that should have remained internal functions, not public API. Another approach is to not leave them all intact and leave them as is. I don't have a strong preference one way or another.
Make the call yourself and push out. I'd rather we deprecate all or deprecate none. The pango_parse_* ones are useful, so they should stay.
OK, I deprecated all but the ones I think really belong to Pango, namely pango_version*, pango_is_zero_width, pango_quantize_line_geometry, pango_units_[to|from]_double and pango_extents_to_pixels. No code was removed, but if we decided to do it at some point, I think the useful ones that we need internally should be just made private.
From https://git.gnome.org/browse/pango/commit/?id=f79b50df9d6116759cca5b043692e8d67e3c0984 + * + * Deprecated: 1.37 Should it be 1.38 (the next stable version) instead?
(In reply to Kalev Lember from comment #18) > From > https://git.gnome.org/browse/pango/commit/ > ?id=f79b50df9d6116759cca5b043692e8d67e3c0984 > > + * > + * Deprecated: 1.37 > > Should it be 1.38 (the next stable version) instead? Correct. That's what we've been doing so far. Though, I have started doubting the usefulness of that practice. But lets stick to it for now. Thanks
Pushed the version fix