To everybody. PDF <= #5, SVG <= #30 now. So priorities seems set.
But all the vector system needs a study of all it’s interrelation. O2D, SVG, PDF. Or you will create something fat, slow, and using internal redundant functions, and later will need to deprecate functionalities sooner than expected needing redesign for clean up and expansion of the functionalities.
But the current priorities #1 and #2 (iOS and new compiler) are very intense.
I have 2 of my 10 apps I still build in Carbon because they use graphics and go 30% faster in Carbon than in Cocoa (but they work on Cocoa).
But we spoke about that in another subject (or thread or discussion, or ??? I never now how to call that).
I still develop with RealStudio, then I build with previous version of Xojo for <10.7 and with the last one for ? 10.7 .
It’s boring, I think I will all drop and only use the last Xojo.
[quote=110987:@Norman Palardy]Carbon as a UI toolkit is pretty much 100% deprecated by Apple.
If you need to support OS X < 10.7 you can’t use the latest version of Xojo anyway.[/quote]
When I said supported I really meant not pulled (yet) and still getting critical fixes to keep it running. OS X version support is one of the reasons why we currently don’t use the latest version of Xojo for this app.
Even with Apple “supported” is probably not quite the right term
They really are doing minimal maintenance on it.
Well cared for Mac can last a long time. It would be sawing the branch you are sitting on not to support the systems used by your customers. But one would think that applications dating back to PPC have become extremely stable and need very little new development ?
Our main designer app was first released around 2007 so it has been around a long time. However, it is constantly evolving as we try to release 1 major update and a few minor updates each year. Dropping support for older operating systems is something we only do if we have no choice or if our stats show that supporting them is no longer required. This is why we have not finished our transition to Cocoa as it would end support for quite a few users and reduce our revenue stream.
You app may need a high level of customization kind of “custom fit”. For shelf (or should I say web site) software it is different. I wrote the first Barcode Wizard for Mac back in 2002 for PPC, and went through all the motions of change of font formats, framework and processors with minor issues up to today’s Cocoa and the MAS sandboxed version. I could still support PPC today with the same version I was selling then using the RB from that time. And as it was very stable, I did not actually need to drop it ; it simply stopped selling.
What I don’t quite get is why you should drop support for executables that are probably very stable and do not need maintenance anymore. Is it not possible to keep PPC and 10.4 while issuing Cocoa and >10.7 ?
[quote=111098:@Michel Bujardet]You app may need a high level of customization kind of “custom fit”. For shelf (or should I say web site) software it is different. I wrote the first Barcode Wizard for Mac back in 2002 for PPC, and went through all the motions of change of font formats, framework and processors with minor issues up to today’s Cocoa and the MAS sandboxed version. I could still support PPC today with the same version I was selling then using the RB from that time. And as it was very stable, I did not actually need to drop it ; it simply stopped selling.
What I don’t quite get is why you should drop support for executables that are probably very stable and do not need maintenance anymore. Is it not possible to keep PPC and 10.4 while issuing Cocoa and >10.7 ?[/quote]
We dropped PPC when we upgraded our comms infrastructure. This meant moving from FTPSuite & HTTPSocket to CURLSMBS. Unfortunately, We had reliability issues with SSL under PPC so the decision was made to drop PPC as it had become a barrier.
In theory, we might be able to keep Carbon support after we have transitioned but our current philosophy is that we release 1 Mac binary and 1 Windows binary which covers all of the operating systems we support (ie: no separate Carbon & Cocoa versions). This of course if something that we could decide to change when we are ready to release. Our designer app (which is complex in itself) is only one part of a much larger system so we try not to support too many previous versions due to the overhead this involves.
I encounter problem with the combo box in the process of moving to Cocoa.
When i click on the down arrow the first time, i can see the drop down value is the same as the text area.
When i click on the down arrow the second time, i can see the drop down value is not selected at all.
[quote=111162:@Richard Duke]I encounter problem with the combo box in the process of moving to Cocoa.
When i click on the down arrow the first time, i can see the drop down value is the same as the text area.
When i click on the down arrow the second time, i can see the drop down value is not selected at all.
[/quote]
I tried to reproduce that and actually, never see case 1, where the drop down option is already selected. Somehow it seems more logical, as a menu used with the keyboard rarely starts from anywhere but the top …
in my application, i open the window and read in the record with data and need those field that use combo box to preselect the value as show in the first screen shot.
is the an event or something when user click on the down arrow??
The discussion of O2D graphics exchange formats has clarified the different requirements for vector graphics interchange:-
Req 1: Export for display in apps such as document processors e.g. MS Word and Pages;
Req 2: Export for editing in apps such as drawing packages e.g. Illustrator and EazyDraw;
Req 3: Export for re-use in the originating app or closely associated ones using same data format.
Req 3 is normally satisfied by proprietary formats that include app-specific data, not just raw graphics. Its only relevance is that formats such as SVG and PDF make provision for including such data making it possible to have a single data structure for both export of graphic data and app-specific data saving and interchange.
Req 1 and Req 2 were satisfied by the PICT data format on the Mac and EMF under Windows. PICT has become obsolete – in particular does not support Unicode – and needs replacing.
The only suitable replacement for req 1 is PDF since neither Word or Pages imports SVG but both import vector graphics in PDF.
Req 2 is more complex. Vector PDF works well in Illustrator – all the objects in it may be edited (showing that PDF can be an O2D interchange format). However, in other apps such as EazyDraw vector PDF is imported as a unitary, uneditable vector graphics object, suggesting that that the effort to fully decode it as objects is significant.
SVG works very well as a graphics interchange format with both Illustrator, EazyDraw and an increasing number of graphic editing apps on the Mac. However, in all cases the learning curve to achieve full SVG import has been several years – SVG export from an app using vector graphics is very easy but full SVG import is extremely diffucult because the spec is so comprehensive and there are so many different ways of creating the same visual effect.
I don’t think anyone has suggested that Xojo provide full SVG or PDF import. We have been discussing the interchange of O2D graphics which requires a highly limited subset of both SVG and PDF.
If only one format is provided, then only PDF fully satisfies req 1 and reasonably satisfies req 2.
However, providing SVG as a second export format is not a major task. The O2D primitives translate quite simply to SVG. A DTD within a Xojo namespace for O2D would provide a nice packaging of O2D for graphics interchange and incorporation into proprietary XML DTDs for graphics structures in Xojo apps.
Notes
It is useful to be able to experiment with vector graphics interchange with apps that are important to your users. Dave Mattson’s EazyDraw is helpful because it provides full control over what data formats are copied to the clip. Apple’s Clipboard Viewer is helpful to see what is actually in the clip, particularly as OS X does some automatic conversions of bitmap formats to TIFF.
Keynote exports vector graphics to Pages in a proprietary format but makes only bitmap formats available to other apps in the clip. However, it can export a vector PDF file that, for example. Illustrator can open and edit.
Word 2008 and 2011 import vector graphics in PDF and these print much more clearly than equivalent bitmap graphics (including bitmaps created from upscaled vector graphics that look great on the screen but muddy when printed).
[quote=111177:@Richard Duke]in my application, i open the window and read in the record with data and need those field that use combo box to preselect the value as show in the first screen shot.
is the an event or something when user click on the down arrow??[/quote]
There is : mouseDown. You need to make sure the click was done on the arrow by selecting the area with X and Y.
But I see no way to select a row in the drop down menu.
Maybe you want to create your own control with a listbox, where you have full control of selected rows, where it is clicked, and so on. But I am afraid we are getting quite out of topic.
Sorry, but this is getting completely out of topic in a discussion about the end of Carbon support. Why don’t you start a new thread with it ? I am sure lots of people will be interested.
Micheal, you can certainly can select a row in the drop down menu by simply setting the listIndex of the combo box.
SUB DoSetComboValue(cboRec AS comboBox, vField AS STRING)
DIM i AS Integer
cboRec.text=vField
If Len(vField )<>0 Then
For i = 0 To cboRec.listCount-1
If cboRec.rowtag( i ) = vField Then
cboRec.listIndex=i
Exit
END IF
Next
Else
cboRec.text=""
cborec.ListIndex=-1
END IF
END SUB
[quote=111180:@Dr Brian R Gaines]Req 1: Export for display in apps such as document processors e.g. MS Word and Pages;
Req 2: Export for editing in apps such as drawing packages e.g. Illustrator and EazyDraw;
Req 3: Export for re-use in the originating app or closely associated ones using same data format.
[/quote]
From your summary it seems what we should hope for is:
XPlaform PDF output both for the clipboard and maybe dragging to EXTERNAL apps, as well as for creating external PDF document files, for points 1 and 2.
And SVGT as files as well as on the clipboard (and maybe draggable) for point 2 for external editors, and as external files for 3 reload able vector storage.
Sounds good… But it would be nice to enhance O2Ds little bit first! (thinking patterned lines and gradient fills)
[quote=111162:@Richard Duke]I encounter problem with the combo box in the process of moving to Cocoa.
When i click on the down arrow the first time, i can see the drop down value is the same as the text area.
When i click on the down arrow the second time, i can see the drop down value is not selected at all.
[/quote]
Reply posted in https://forum.xojo.com/13859-how-to-pre-select-a-combobox-row
[quote]Thomas ROBISSON
I still develop with RealStudio, then I build with previous version of Xojo for <10.7 and with the last one for ? 10.7 .
It’s boring, I think I will all drop and only use the last Xojo.[/quote]
Yes I am having the same problem but I will have to update you all soon, just hope 2014 R3 to buy XOJO and initiate changes.
I just tried this with Word 2013 and it does not work on Windows. Like the Windows version, the Mac version of Word is using the system graphics filters so PDF is not a cross-platform solution.
The reality is there are precious few x-platform vector formats that will work in much software like Word/Excel/Powerpoint/Pages
WMF/EMF is only useful on Windows.
PDF is ok for output but is horrid to try & reopen and get O2D’s from it (it mostly loses the information we’d need to reconstitute them)
SVG is not well supported outside of browsers - Pages/Word/Excel on the Mac don’t import them at all via drag & drop
Maybe DWG or DXF or CGM 
[quote=111541:@Norman Palardy]The reality is there are precious few x-platform vector formats that will work in much software like Word/Excel/Powerpoint/Pages
WMF/EMF is only useful on Windows.
PDF is ok for output but is horrid to try & reopen and get O2D’s from it (it mostly loses the information we’d need to reconstitute them)
SVG is not well supported outside of browsers - Pages/Word/Excel on the Mac don’t import them at all via drag & drop
Maybe DWG or DXF or CGM :)[/quote]
My conclusion was that both PDF and SVG were necessary.
PDF is essential for export to the apps such as Pages/Word/Excel to which many users will expect to be able to paste and drag, but not suitable for re-import – probably only Adobe supports importing it for editing as vector graphics.
SVG is the elegant XML DTD that provides everything else (EXCEPT export to the very significant apps that do not support SVG).
So O2D needs to go in the clip and drag as both PDF and SVG. Maybe one day the PDF will be unnecessary but that day is likely at least a decade away – or more given the need to support export to legacy apps
The export of O2D structures in SVG is simple because SVG provides the same graphics primitives as O2D. The re-import of Xojo-produced SVG (NOT SVG in general) is also simple using the XML decoder already provided.
Export to PDF is substantially more effort. However general PDF export from Xojo is shown as “scheduled.” Focusing on O2D to PDF short-term would make sense.