Blog Post: The End of Carbon Support

One thing everyone can do to aid this is go through old bug reports with the latest releases and see which bugs of your have already been fixed in Cocoa builds.
And if they have not please add a note to the case saying “this still exists in 2014r2” so we know who checked it and what version.

Last night I went through about 20 reports and found only 3 still existed in the latest builds.

This will help us focus on those remaining issues.

Carbon->Cocoa missing functions
As I discussed in another thread, I use a way to detect Web proxy parameters via Declares that will no longer work in Cocoa. I think it would be important to add it to Cocoa in the future. (I know it exist in MBS plug-in)

What I meant is BUGS that make moving from Carbon to Cocoa problematic.

Proxy detection doesn’t exist so it would be a new feature regardless of framework.

Does this also mean Cocoa app will be a little smaller? :slight_smile:

Out with the old, in with the new. Same will happen to Object-C in a few years which will be replaced with
Swift, and say goodbye to 32 bit apps in the future.

I have a crystal ball :slight_smile:

Not sure why you’d elect bug reports would have an effect or why dropping Carbon support would have any effect ?

Completing Cocoa and dropping Carbon as soon as possible makes sense. However, there are still a lot of known problems with Cocoa:-

1 O2D graphics in clip is still unsupported and needs fixing unless you are also depreciating vector graphics.

2 Cocoa text with TABs wraps prematurely (Feedback case 31488)

3 Cocoa TextArea custom cursor flickers because default text cursor appears intermittently (Feedback case 31476)

The two feedback cases have been left as “reviewed” for 6 months so they may not have been on you list of residual bugs.

In my MacDraw-like application I have a palette for creating arrows types that offers a selection of arrow heads, decorations and line types in a floating window. Under Carbon when one close the window it is instantly gone. Under Cocoa it takes 3 seconds. One can see items (canvases) in the palette being slowly erased in turn before the window closes so the problem seems to be in the framework implementation not Cocoa. I asked for advice on the forum about this and other slow-downs in Cocoa and managed to fix some other issues but this one remains. I need to investigate it further before creating a feedback case.

News to me. Is there a case for this?

Take a sample of the process in Activity Monitor and shove it in a Feedback case, ideally with some sort of project or built application I could test against.

Heu… look at the smiley … it was humour . :slight_smile:

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.

I’m sure there is a good reason for this but like the decision to drop support for several versions of Mac OS X and usability issues with the new IDE it sure makes life using Xojo difficult at times.

you can still use two different Xojo versions in parallel and still share code.

For me I have several projects which require a specific version of Real Studio or Xojo to build.

[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]

If your Carbon code is well written so the logic is not tied to controls, you can copy and paste all your methods and functions from older versions of Xojo into the new. If it is anything like today’s Web, that’s transparent. Then all is needed is to create the GUI, which in the case of IOS is quite necessary, because it is quite different from regular Mac OSX. Compared to other iOS development tools, though, Xojo iOS will be a wonderful way to port older RB/Xojo code.

[quote]Kevin Gale Really disappointing to hear that Carbon is being dropped with the iOS release as we are still in the transition to Cocoa
[/quote]
I understand what you say and know what really scares a bit this weekend Carbon, I have projects that are still totally in Carbon and unresolved issues, I even had a case open for some time feedback that was closed as Fixed this week but not yet I could test it only available in 2014 r3 and it really complicates things a bit.

Hi Joe, the framework gives a detailed error message that “Putting vector images on Clipboards or DragItem is currently not supported” so the issue is already documented and hence a bug report did not seem appropriate.

I assumed that the features documented as “currently not supported” would already be on the list to be completed in the transition to Cocoa.

[quote=110769:@Dr Brian R Gaines]Hi Joe, the framework gives a detailed error message that “Putting vector images on Clipboards or DragItem is currently not supported” so the issue is already documented and hence a bug report did not seem appropriate.

[/quote]

These are only in Cocoa?

AFAIK in Carbon the only vector graphic support for the Clipboard (and I assume Dragging pictures) is the PICT format, which few modern apps support and is not really X-platform these days ether. It is a BIG problem IMO, but it is one that is significantly present in Carbon too.

Unfortunately, it won’t be as easy as that. iOS will require the new framework so existing code will need modification before it will compile. Our plan was to convert relevant code to the new framework while still compiling as Carbon so we could start our iOS apps at the same time as our Cocoa transition and still releasing updates. With no Carbon support we either have to finish our upgrade to Cocoa and then transition to the new framework before we start iOS or, maintain two versions of our code so we can start iOS earlier. Market forces will probably push us down the two versions route so the advantages of using Xojo start to diminish and make tools such as Xamarin more enticing.

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=110772:@Karen Atkocius]These are only in Cocoa?

AFAIK in Carbon the only vector graphic support for the Clipboard (and I assume Dragging pictures) is the PICT format, which few modern apps support and is not really X-platform these days ether. It is a BIG problem IMO, but it is one that is significantly present in Carbon too.[/quote]

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=110787:@Dr Brian R Gaines]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]

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.

  • Karen