[quote=110796:@Karen Atkocius]I agree whole heartedly…
But my point was that it is a problem in BOTH Carbon and Cocoa , so I don’t see how dropping Carbon makes it worst.
[/quote]
From another thread not too long ago, it appears Xojo support for Pict depended on system support. So until Mac OS X supports another vector based image format natively, it looks doubtful a Xojo solutions can be found. And this probably explains why Xojo does not support EMF on Mac OS X either.
[quote=110784:@Michel Bujardet]Xojo is not Objective-C. The language does not change when changing framework. Unless you make heavy use of Carbon declares which would not be usable in iOS more than in Cocoa, pure Xojo code remains the same, apart from occasional deprecation such as calls to the UI from a thread.
However, iOS will indeed necessitate a complete redesign of the UI.
Yeah right. Rewriting entirely a program in a different language and Xamarin when you already seem unable to move to Cocoa is the way to go : easy, fast, not conducive to errors … Right on …[/quote]
I didn’t say that the language would change. However, some functions will be different and strings will be indexed from zero amongst other changes so it isn’t a copy and paste job. In our case we would end up with two versions of some very critical code so Xojo has little advantage there.
And yes, right on, we could quite easily re-write our application in another language. We have already created a HTML5 Canvas based version of our RB app using PHP and Javascript in the past 12 months so if we can do it once we can easily do it again. Just because you might not be able to do it doesn’t mean others can’t. The only reason why we haven’t finished our Cocoa transition is purely down to business priorities and not, as you put it, unable to do it.
Cross platform vector support using the SVG standard is a FR raking the top 30: <https://xojo.com/issue/10931>
[quote=110681:@Kevin Gale]Really disappointing to hear that Carbon is being dropped with the iOS release as we are still in the transition to Cocoa. For us, one of the main advantages of using Xojo for iOS development would have been code re-use but since we cannot have Carbon with the new framework this will now be impossible.
[/quote]
There was never any intent to have Carbon with the new framework. In any form. Ever.
At best it would have come along for the ride but still been old framework.
However there are some things we’re forced to update in the old & new frameworks and quite honestly implementing them for Carbon is a ton of more work with no payback since it already was deprecated and would be sea in the not to distant future.
Carbon is getting no fixes or updates anyways - so at most what you’d get with an update is bug fixes in the IDE and not much more if you build for Carbon.
iOS is ONLY new framework so there will still be some revamping of code required where it uses framework classes etc
[quote=110787:@Dr Brian R Gaines]Hi Karen, the need to replace PICT with PDF was a major topic on the NUG mailing list some 5 years ago. It became subsumed into a feature request to be able to create PDFs which is a much bigger task but is shown as “scheduled” under case 10701.
I worked around the PICT problem in the OS X version of my app by putting a jpeg of scaled up O2D graphics in the clip which worked well for pasting into Word etc, and providing export to SVG for those who needed full res vector output. Many graphics apps and web browsers now render SVG correctly and can convert it to vector graphics in PDF. There are also excellent freeware services on the web that do this.
However, if vector graphics in Xojo is not being depreciated it is important that it can be pasted and dragged in a vector format to other apps. EMF under Windows does this well and there needs to some equivalent for OS X.[/quote]
Writing an Object 2D as a PDF for vector is certainly plausible
Going from PDF to O2D isn’t
Thats really the big stumbling block for using PDF for vector images
Tiny SVG however looks promising as it supports what we need and you can read & write
We’re looking into that
[quote=110846:@Norman Palardy]There was never any intent to have Carbon with the new framework. In any form. Ever.
At best it would have come along for the ride but still been old framework.
However there are some things we’re forced to update in the old & new frameworks and quite honestly implementing them for Carbon is a ton of more work with no payback since it already was deprecated and would be sea in the not to distant future.
Carbon is getting no fixes or updates anyways - so at most what you’d get with an update is bug fixes in the IDE and not much more if you build for Carbon.[/quote]
Hi Norman
As far as I can remember it was never highlighted that Carbon wouldn’t get the new framework so it looks like I was under the wrong assumption. Getting no payback for supporting Carbon is probably not 100% correct as I’m sure it would have been of benefit to several customers.
Anyway, no point going on about it any further as the decision has been made so we just have to like it or lump it.
Looking at Wikipedia, SVG Tiny (SVGT) looks like primarily a mobile thing, and it does not support opacity… So not even not all of the already too limited functionality of object2Ds ( which don’t supports gradients or patterned lines).
Is SVGT supported in most desktop apps on the Mac? If not it’s not much use for copying and dragging.
in general graphics support in Xojo is very last century, and really could used to be modernized in terms of capabilities.
i am in the process of changing the framework from Carbon to Cocoa. What do i need to look into in my coding for my application?
My assumption was change the build target to Cocoa and then follow the errors.
i change the target to Cocoa… and didn’t show any error when compile.
I looked into the SVG tiny profile a while back and it does support opacity. See section 3.5 Object opacity.
If everything works and no errors, you’re good to go.
You’re done! (probably should test everything before deploying just in case)
Yes. It does after v1.1.0 (some called v1.1 plus). But due some regressions in some 1.2 libs code some users had the impression it doesn’t. See this: https://bugs.freedesktop.org/show_bug.cgi?id=79078
thanks Tim… i will give the whole application a very good test and see if there is anything weird happening
It looks to me that SVGT is mostly web thing…
On the Mac can you paste SVGT graphics into Word, Excel and Powerpoint? It seems to me to be really useful on the desktop as a vector format, that would be a must!
iOS is another platform and a different UI as well, so I never presumed of a simple copy paste. Yet, the language will remain the same. As between desktop and web, controls may change but the logic remains. Of course classes will change : who heard of a rolling wheel control under Mac OS X, for exemple 
Making Carbon support the new framework IS what motivated this decision since it’s a such big job.
It’s basically a whole new framework for Carbon.
And we already know its a dead, won’t support new technologies won’t be 64 bit and a host of other things.
This is unfortunate as Carbon is a really nice API for what we do.
Its just not what Apple is pursuing / promoting.
[quote=110875:@Karen Atkocius]It looks to me that SVGT is mostly web thing…
On the Mac can you paste SVGT graphics into Word, Excel and Powerpoint? It seems to me to be really useful on the desktop as a vector format, that would be a must!
[/quote]
Theres no really widespread options
PICT’s death left Apple in a weird state where there’s no widespread vector graphics format that you have readers & writers for.
PDF works for some things but not in all apps.
Some can read some can write some can do both.
SVG is not widely supported.
And … then
there’s not much else
SVGT is a subset of a huge standard, designed to be generic, useful and lighter for low processing power. It’s mostly a screen graphics thing. But some implementations accept other color spaces like CMYK for printing with RGB fallback for screen.
Adobe Illustrator saves and reads it. Inkscape uses a extended set.
SVGT probably can do much more than you could do saving a log of object2d creation/attributes in sequence and reloading, and it can be used by external vector editors like Illustrator. It’s a big plus.