Re: Questions about OSX compatibility

[Sebastian Reitenbach]

 
On Thursday, June 15, 2017 21:28 CEST, Ivan Vučica  wrote: 
 
> On Thu, Jun 15, 2017 at 5:13 PM, Daniel Ferreira (theiostream)
>  wrote:
> > On Thu, Jun 15, 2017 at 9:09 AM, Ivan Vučica  wrote:
> >> My view is a new 'project' (repository) per framework would be good enough.
> >> It would certainly be clear what you need to clone in order to get
> >> 'ApplicationServices/ApplicationServices.h' if the repository was called
> >> 'libs-applicationservices'. Using git submodules, we can also ensure
> >> dependencies are installed at the same time.
> >
> > Hm, why not keep ApplicationServices, for instance, as a
> > submodule-only repository with the global header pointing to all of
> > them and some script/makefile which installs everything inside it?
> >
> > If properly versioned (and *this* is an overhead, unfortunately), it
> > wouldn't conflict with the submodules themselves being installed
> > separately.
> >
> > But this seems to reflect how things are in fact, with
> > ApplicationServices doing nothing really and just grouping other
> > frameworks.
> 
> That sounds like what I meant above? Use submodules to deploy other
> dependencies in subdirs, and then use SUBDIR variable in GNUmakefiles
> to get make to build the other frameworks, too?
> 
> Note that I keep forgetting that .gitsubmodules always refer to a
> specific commit, not to a branch. So we don't really want submodules,
> I think.
> 
> >> This one, I'd keep it in the Opal repo.
> >>
> >> """Originally part of the Core Graphics framework, Image I/O resides in its
> >> own framework to allow developers to use it independently of Core
> >> Graphics."""
> >>
> >> OpalImage sounds like a nice name.
> >
> > There's an issue with compatibility though. If existing binaries link
> > dynamically to OpalGraphics expecting the ImageIO symbols in there, we
> > cause them to break, for instance. How would you suggest we make this
> > change to OpalImage without these consequences?
> 
> True, that's indeed a concern for distros.
> 
> I was going to suggest that we don't care and simply have people
> rebuild their software, but we would be breaking binary compatibility,
> which would make distros demand blood from us.
> 
> How about OpalGraphics's implementations of the functions
> 1) print out a warning
> 2) dlopen() ImageIO and execute the symbols there?

at least as an OpenBSD packager, I'd say "no issue", 
but more seriously: Why not just do a major bump of the
library and done. Everyone knows such major bumps
may break existing things. Release notes should provide
a clear way forward for people/packagers/distris.

just my 2 cents.
Sebastian

> 
> >
> >> (Which reminds me... I should really rename 'quartzcore' project into
> >> 'opalanimation' or something like that.)
> >
> > Why is 'quartzcore' not part of Opal, by the way?
> 
> Original committer who deployed the stub headers (see history of the
> repo) presumably chose how to approach it.
> 
> That said, there isn't really much need to.
> 
> Core Animation /is/ a very distinct thing from Core Graphics, and if
> you could adjust the API, you could comfortably substitute uses of
> CGContextRef with something else (SDLSurface, e.g.) /without/ the API
> becoming /very/ different. There isn't much that Core Graphics
> (quartz2d, opalgraphics) and Core Animation (which happens to ship in
> QuartzCore on OS X) have in common besides CALayers being fed
> graphical content from CGContextRefs (or supplying CGContextRefs for
> someone else to draw into).
> 
> Core Animation deals with rendering (potentially) 3D layers of content
> and properties, animated using certain animation functions, and being
> spit on the screen through OpenGL (or similar 3D graphics API).
> 
> Core Graphics deals with rasterizing 2D content into 2D bitmaps.
> 
> ¯\_(ツ)_/¯
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
 
 
 
 



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Questions about OSX compatibility

[Ivan Vučica]

On Thu, Jun 15, 2017 at 5:13 PM, Daniel Ferreira (theiostream)
 wrote:
> On Thu, Jun 15, 2017 at 9:09 AM, Ivan Vučica  wrote:
>> My view is a new 'project' (repository) per framework would be good enough.
>> It would certainly be clear what you need to clone in order to get
>> 'ApplicationServices/ApplicationServices.h' if the repository was called
>> 'libs-applicationservices'. Using git submodules, we can also ensure
>> dependencies are installed at the same time.
>
> Hm, why not keep ApplicationServices, for instance, as a
> submodule-only repository with the global header pointing to all of
> them and some script/makefile which installs everything inside it?
>
> If properly versioned (and *this* is an overhead, unfortunately), it
> wouldn't conflict with the submodules themselves being installed
> separately.
>
> But this seems to reflect how things are in fact, with
> ApplicationServices doing nothing really and just grouping other
> frameworks.

That sounds like what I meant above? Use submodules to deploy other
dependencies in subdirs, and then use SUBDIR variable in GNUmakefiles
to get make to build the other frameworks, too?

Note that I keep forgetting that .gitsubmodules always refer to a
specific commit, not to a branch. So we don't really want submodules,
I think.

>> This one, I'd keep it in the Opal repo.
>>
>> """Originally part of the Core Graphics framework, Image I/O resides in its
>> own framework to allow developers to use it independently of Core
>> Graphics."""
>>
>> OpalImage sounds like a nice name.
>
> There's an issue with compatibility though. If existing binaries link
> dynamically to OpalGraphics expecting the ImageIO symbols in there, we
> cause them to break, for instance. How would you suggest we make this
> change to OpalImage without these consequences?

True, that's indeed a concern for distros.

I was going to suggest that we don't care and simply have people
rebuild their software, but we would be breaking binary compatibility,
which would make distros demand blood from us.

How about OpalGraphics's implementations of the functions
1) print out a warning
2) dlopen() ImageIO and execute the symbols there?

>
>> (Which reminds me... I should really rename 'quartzcore' project into
>> 'opalanimation' or something like that.)
>
> Why is 'quartzcore' not part of Opal, by the way?

Original committer who deployed the stub headers (see history of the
repo) presumably chose how to approach it.

That said, there isn't really much need to.

Core Animation /is/ a very distinct thing from Core Graphics, and if
you could adjust the API, you could comfortably substitute uses of
CGContextRef with something else (SDLSurface, e.g.) /without/ the API
becoming /very/ different. There isn't much that Core Graphics
(quartz2d, opalgraphics) and Core Animation (which happens to ship in
QuartzCore on OS X) have in common besides CALayers being fed
graphical content from CGContextRefs (or supplying CGContextRefs for
someone else to draw into).

Core Animation deals with rendering (potentially) 3D layers of content
and properties, animated using certain animation functions, and being
spit on the screen through OpenGL (or similar 3D graphics API).

Core Graphics deals with rasterizing 2D content into 2D bitmaps.

¯\_(ツ)_/¯

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Questions about OSX compatibility

[Daniel Ferreira (theiostream)]

On Thu, Jun 15, 2017 at 9:09 AM, Ivan Vučica  wrote:
> My view is a new 'project' (repository) per framework would be good enough.
> It would certainly be clear what you need to clone in order to get
> 'ApplicationServices/ApplicationServices.h' if the repository was called
> 'libs-applicationservices'. Using git submodules, we can also ensure
> dependencies are installed at the same time.

Hm, why not keep ApplicationServices, for instance, as a
submodule-only repository with the global header pointing to all of
them and some script/makefile which installs everything inside it?

If properly versioned (and *this* is an overhead, unfortunately), it
wouldn't conflict with the submodules themselves being installed
separately.

But this seems to reflect how things are in fact, with
ApplicationServices doing nothing really and just grouping other
frameworks.

>> The third matter comes to Opal's CGImageSource/CGImageDestination
>> APIs. In Opal, it is part of OpalGraphics (thus under CoreGraphics'
>> headers). However, in OSX, these interfaces are part of a separate
>> framework called ImageIO. That said, I think it does not make sense to
>> keep them inside OpalGraphics, but aside from that I don't know how
>> you see the issue. Is it the case of moving them to another module; to
>> another "subproject" inside Opal (e.g. OpalImage or something); or not
>> move it from OpalGraphics at all and just change where we are
>> installing the headers?
>
>
> This one, I'd keep it in the Opal repo.
>
> """Originally part of the Core Graphics framework, Image I/O resides in its
> own framework to allow developers to use it independently of Core
> Graphics."""
>
> OpalImage sounds like a nice name.

There's an issue with compatibility though. If existing binaries link
dynamically to OpalGraphics expecting the ImageIO symbols in there, we
cause them to break, for instance. How would you suggest we make this
change to OpalImage without these consequences?

> (Which reminds me... I should really rename 'quartzcore' project into
> 'opalanimation' or something like that.)

Why is 'quartzcore' not part of Opal, by the way?

-- Daniel.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev