On Sep 23, 2015, at 1:04 AM, Nirbheek Chauhan wrote:
> Just to add to this, GStreamer 1.x currently supports OS X 10.8, so it
> would be great if GLib continued to support at least that. Support for
> older versions should, I suppose, be welcome as well since Ryan says
> he's willing to maintain it. :)
To clarify what I mean when I say I am the maintainer of glib2 in MacPorts:
that title means that I have declared myself responsible for keeping glib2 in
MacPorts updated and working, and will try to report issues to the developers
for them to resolve. It doesn't mean that I know anything about the glib
codebase, nor that I am even a competent C programmer.
On Sep 23, 2015, at 5:14 AM, Bastien Nocera wrote:
> I don't think that making new APIs do nothing, or ABI changing between
> OSX versions is a good idea.
I'm not familiar with what constitutes API or ABI in the context of glib, but
the fact is that prior to 2.46.0, GNotification support did not exist in glib
on OS X, therefore all the existing software that successfully used glib on OS
X didn't care about that missing support.
> You might want to work on adding support
> for another notification sub-system (I don't think that OSX had one
> builtin before 10.9, or without the needed feature), such as Growl.
> Then make GNotification choose which one to use at run-time.
As I understand it, that would mean that the build system would have to be
modified to detect if Notification Center support exists at build time (i.e. if
the OS X 10.9 SDK or later is being used), and would weak-link to it if found.
The code would check at runtime if the symbol exists (i.e. if we are running on
OS X 10.9 or later), and if so it would use Notification Center. I would be in
favor of such changes.
I also have no objection to Growl support being added as an alternative. But
since Growl is a third-party product, I predict that most users do not have it
installed. So glib would need to accommodate the case of neither Growl nor
Notification Center existing.
On Sep 23, 2015, at 5:47 AM, Emmanuele Bassi wrote:
> For instance, supporting MacOS 10.8 would give us about 80% of the
> installed users base for MacOS; going back to 10.7 we'd reach about
> 90% — and after that we enter the land of diminishing returns. Those
> figures are not going to get better in the future, either. Strict
> support cut offs and free updates push OS upgrades forward. Also, I'd
> like to point out that the oldest Apple-supported OS version is 10.8
> (at least for security updates).
Citing percentages ignores the fact that there are real actual users on OS X
10.8 and earlier currently using software that requires glib, and that these
real actual users will not be able to use the current version of glib anymore.
This leaves the distributors of that software (which might be a package
management system like MacPorts, or it might be the developers of the software
themselves, in case they distribute their own binary packages) to decide
between staying with an older version of glib (which may contain bugs that have
already been fixed in newer versions of glib), or else upgrading glib, thus
alienating the users of older systems who then have to use older versions of
the software which may itself have bugs already fixed in newer versions.
> The API for sending notifications via GApplication cannot
> programmatically fail — but the documentation helpfully says:
>
> There is no guarantee that the notification is displayed
> immediately, or even at all.
>
> Which at least gives us some leeway in not supporting platforms that
> do not have system notification API.
Sounds great: if Notification Center support is not available at runtime, then
simply do nothing.
On Sep 23, 2015, at 9:53 AM, Nicolas Dufresne wrote:
> That I agree. If the supporting companies for these proprietary OS drop
> support for stuff removing and remove it devkits while making older
> devkit no longer available, it will be hard for us to keep up (and a
> waste of our time most likely).
I'm not certain what you mean. Certainly, Apple stops releasing new versions of
Xcode for old OS X versions at some point. But there is nothing preventing a
developer from setting up an older Mac with an old version of OS X and
downloading the corresponding old version of Xcode from the Apple developer web
site.
You don't even necessarily need an old Mac: you can use Parallels or VMware
Fusion or Virtual Box on a new Mac to run a virtual machine of an older version
of OS X.
You don't even need to go that far to test the build side of things: on a
current Mac with the latest version of OS X (10.10.5), I can download an older
version of Xcode (5.1.1) which contains the older 10.8 SDK. I can build glib
2.46.0 with the 10.8 SDK in that older Xcode (thus somewhat simulating what
would happen if you were to build on a 10.8 machine) to cause this error to
appear:
CC libgio_2_0_la-gcocoanotificationbackend.lo
gcocoanotificationbackend.c:225:20: error: property 'identifier' not found on
object of type 'NSUserNotification *'
userNotification.identifier = str_id;
^
gcocoanotificationbackend.c:226:20: error: property 'contentImage' not found on
object of type 'NSUserNotification *'
userNotification.contentImage = content;
^
gcocoanotificationbackend.c:254:25: error: property 'identifier' not found on
object of type 'NSUserNotification *'
if ([notification.identifier compare:str_id] == NSOrderedSame)
^
3 errors generated.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
