Cello - a port from MFC to OSX

Using your own Undo Stack in Cocoa

2010-04-11T17:00:00.003+01:00

Having finished the Insert Frame UI have been connecting the first command Cello. This was something that proved surprisingly easy. The trick seems to be to subclass NSUndoManager and then yo use this as an adaptor for the existing undo system. I have installed my custom undo manager in my NSDocument makeWindowControllers method. Do this and magically it "just works".The methods I have

iCal-like popup window Part II - MAAttachedWindow and CoreAnimation

2010-04-07T20:42:00.005+01:00

Looking closely at the iCal dialog it behaves quite differently from my first cut - what it does is to scale an image of the dialog from a single starting point to something slightly bigger than the final size and then back down to final size. There is a movie of this on my previous post. This gives an appearance like it over-scales and snaps back. To me this is really good because that sort of "

iCal-like popup window Part I - MAAttachedWindow and CoreAnimation

2010-03-31T21:29:00.009+01:00

I have been working on animating the insert frames window in the same way that the iCal window animates. The iCal window does not just appear but instead sort of grows out of the point that you double clicked in. It is a really nice effect - however rather than the 10 minuets (or so) I thought it would take to deploy it - in actual fact it has taken me a little while to get to the bottom of

Non Modal Dialogs

2010-03-17T08:04:00.007Z

I am at the point where I need to add a dialog that appears when he user wants to insert frames. the dialog is quite simple - a popup and a field. The normal way of presenting this to the user is with a modal dialog - or its close cousin the sheet. For me as a user modal dialogs are just not that nice. Suddenly "bang" there is a dialog. It is rarely where you want it and it interrupts your flow.

Inline editing - NSTextView and the mysterious 5px margin

2010-03-07T22:04:00.005Z

The PC version of cello has a dialog box to edit labels. You can, using a contextual menu, add a label or edit a label. Deleting a label is a matter of editing the label and removing it's text.A more OSX way of handling the editing of a label is to be able to edit inline. The idea is that if you double click on a label then you get a text cursor in the label - and you edit the name inline.To

performClickWithFrame, small menus and Señor Calviño

2010-03-07T15:30:00.007Z

An advantage that MacApp had over Cocoa was that you got the source code. My experience of MacApp was that it was far more buggy but having the code meant that you could see how things work and (of course) fix bugs. Cocoa seems rather bug free - but when you find a bug you have no option but to work around it. I am not pining for the days of MacApp, things move on, Cocoa is very, very good - but

Workaround - Crash in NSPopUpCell performClickWithFrame:inView:

2010-03-06T22:21:00.006Z

I have been working on contextual menus for the time line. Contextual menus appear to be quite straight forward. If you don't want your contextual menus customized with whatever can add to contextual menus you create a NSPopUpCell - this is described in Apple's developer documentation. What you need to is nicely covered and well explained in Jesper's blog. Jesper kindly even gives you a category

Poof - Drag Deleting Items in Cocoa

2010-03-03T08:06:00.002Z

OSX has an idea of drag-deleting items in the UI. You can see this in the dock amoungst other places - drag an item out the dock - and the cursor changes to a pointer adorned witha cloud. Release and "Poof" the item disappears with a small animation and a sound. It is cool and intuative. It works well when moving items does not cause a scroll. I have got used to the same way of deleteing

TimeLine view - Labels

2010-03-01T21:48:00.007Z

I am continuing to work on the header of the timeline. In addition to showing the current time frame and a selection the timeline can show labels and actions. I have been working on the visualization of labels. In the PC version of Cello the labels are shown as flags.The flags are named points in the timeline. I have taken this in the OSX Cello and changed it very slightly. Keeping the flags I

TimeLine view - header

2010-02-25T22:01:00.005Z

I have been working on the timeline header view. In Cello this is called the FrameView as it contains details of fime frames. I have just got the selection working. The selection normally shows a single frame - the current frame, but it is possible to select a contiguous strip of frames as well.Before starting work on the selection I once again had a look at CocoaTron NSTableView to see how the

Drag resizable columns in a headerless NSTableView

2010-02-19T18:53:00.003Z

Currently table headers are responsible for handling the dynamic resizing of table columns. I have needed to make it possible to resize table columns from within the table - so the idea is that you will be able to:move your mouse to the divider between two columns the cursor will change to indicate that you can resize the columnclick and drag and your column will resize.I already have a

Synchronizing the selection in two NSTableViews

2010-02-17T19:11:00.003Z

I have been looking at a problem of synchronizing the selection across two NSTableViews. It took a few attempts to come to a solution that worked as I wanted it to. The idea is to have two table views with the same number of elements - as soon as you make a selection in one the other one updates to show the same items selected.My first port of call was to hook into the tableViewSelectionDidChange

Interface Builder

2010-02-15T21:33:00.002Z

Working with an application framework has a few parts - there is the first staggering steps of familiarity and the kind of awkwardness you have because of the difference between what you knew before and what you are looking at. Then there is the familiarity when you know more-or-less how to do what you did before and then there is that time a while later when you sort of "get it". This part is

BWToolKit

2010-02-04T22:18:00.001Z

I have downloaded and built BWToolKit by Brandon Walkin. This is a framework that extends the existing components that are available in Inerface Builder. It is of particular interest to me at the moment as it contains an improved splitter. The BWSplitView is a subclass of the NSSplitView that handles improvements like the splitter collapsing, max min sizes etc. BWToolKit comes with interface

Moving MFC icons to Cocoa

2010-01-17T18:39:00.004Z

Working my way through the timeline MFC to Cocoa conversion I have once again bumped up against graphic resources. Various components in the UI have graphic resources (icons). Back when I was getting the basic engine to work I compiled out all things of this ilk with a huge amount of other things with a #define _NO_UI. A part of my approach is that the structure of the new UI follows the PC

Mutating MFC to Cocoa

2010-01-11T21:16:00.003Z

I am making progress converting the view hierarchy of the timeline to cocoa. In the about face I am working through the classes and interfaces that are defined in MFC and attempting a mechanical conversion where possible. In my first cut I do the following:Mutate the all 'interface' definitions to protocols.Mutate all pure virtual base classes into protocols.Mutate all other classes as objective

C++ Observers in Objective C

2010-01-03T00:28:00.005Z

Cello has various notifications that are posted to observers. This is a good and fine thing - the observers are generally UI components and in the PC version of Cello are C++ classes. The form is that through multiple inheritance of a mix-in class a class becomes an observer. It overrides the observation methods and handles the notifications. The rub comes with Objective-C. Under OSX all the UI

TimeLine - an about-face

2010-01-02T14:46:00.002Z

Sometimes programming is about heading down a blind alley. I guess that thing to do in these situations is to know when to call it a day and head back. So this is what I am doing with my current work on the timeline. So why the about face? What I was doing with the Timeline was to develop a slot in replacement for something a bit like a NSTableView but with all the capabilities rewired for a

TimeLine view - rollovers

2009-12-26T18:19:00.005Z

Each row of the TimeLine header view has two areas that are active. One is the drawMode and has a popup - the other represents the locked status of an item. These appear as graphics in the TimeLine header. I have decided to make these active areas distinct by making them behave as rollovers. The effect that I am looking for is quite simple - as the mouse goes over the active area I want to draw a

TimeLine view - making the header active

2009-12-18T21:05:00.008Z

In the TimeLine view the header is not a passive information-only structure it is active.The text is editable.The "Lock" icon works as a checkbox.The "Draw Mode" icon is a popup menu with four states.This is what one of the popup menus looks in the windows version if Cello.The way that I plan to accomplish these active areas are by using subclasses of NSCell and friends. There is, for example, a

TimeLine view - header with icons

2009-12-13T16:46:00.006Z

I have added the drawing of icons to the header row. I have taken the existing graphics from the PC version and quite quickly converted them to individual tiff images in photoshop. I am for the moment just reusing the PC images. When Cello is finished they will need reworking as they don't have that OSX feel. My thought is to hand this part of the project over to someone else - it really is

Cocoa and Drawing truncated text

2009-12-12T17:10:00.004Z

To properly allow for long names of objects in the time-line I need to draw truncated text.Untruncated TextWhat I mean is that I want to truncate the text if the area is to small for the text and then to have some ellipses that show where the truncation occurs. This was second nature to me in my days as a ToolBox (Carbon) programmer but fathoming it out under Cocoa tool a while. Whatever I tried

TimeLine view - header regions

2009-12-12T16:32:00.004Z

Working on the TimeLine view I have started getting the row headers to draw. I am stepwise refining the row header drawing until I have the row headers drawing correctly. The PC version of cello draws row headers like this:So my start is to take the single rectangle for a row and to divide it into four parts. The text part will grow and shrink horizontally - the other parts are fixed (they will

NSScrollView - problems

2009-12-04T19:50:00.006Z

I have been having a strange problem scrolling in the TimeLine view. The issue is down to my understanding of coordinate spaces under "normal" (not flipped) circumstances in cocoa. The coordinate space is much as I expect - the bottom left corner is (0, 0). However when you come to NSScrollView things are a little strange. If the position of the content view also starts from the bottom left

TimeLine - sketching out more

2009-12-03T21:29:00.006Z

I am slowly shapping up the timeline. I am working with a scratch target in the main project and doing occasional Git commits. The commits are little more than line in the sand that I can undo to. My approach is to start simple and to refine slowly.Basic Topology (header areas)Starting with the basic ytopology I refined it by adding NSScrollViews. Basic topology (with scrolling)The final shot of

TimeLine view - first brush strokes

2009-11-23T21:28:00.006Z

I have started implementing the TimeLine view - and implementing it from the ground up. My approach is to start with the basic topology and then to add flesh to the bones. The PC view has row labels of user determined width. I can kick this off in a small sample project - I should be able to get the basic structure of what I need working outside of Cello. So I started by adding a new (temporary)

NSTableView vs MBTableGrid - the verdict

2009-11-22T15:49:00.003Z

I have spent some time looking at NSTableView and also the open source MBTableGrid. What I have been doing is playing around with them in test applications to try and get a measure of the two approaches. In the end I have decided to write my own view from the ground up. Looking at the MBTableGrid example has given em a really good idea of what it will take to do it - and the work will not be

NSTableView vs MBTableGrid - the trial

2009-11-19T22:11:00.005Z

The main cello UI is comprised of three views, FrameView TimeLine and ActionView. Together these views comprise the majority of the editing functionality. My intention was to start with the FrameView. The FrameView is used to draw the the items at a given point in time. So when you sketch, say, a box you do this in the FrameView. It seemed like the most important view to start with. There is,

NSDocumentController - Reusing a single window across multiple documents

2009-11-16T21:11:00.003Z

A further twist to having a single document visible at any one time is that I would like to keep a single window and reuse it. The way I have done this is as followsWhen I get the NSApplicationWillFinishLaunchingNotification I create the window controller and window. I do this by reading in a nib file that has my subclass of a window controller and a window. In the makeWindowControllers method

NSDocumentController - Maintaining a single document

2009-11-15T20:52:00.005Z

I have been trying to figure out the best way to structure things to support the concept of the "main frame". Under Windows applications generally seem to have a main frame. This is the single key window that is central to the application. The OSX world is different - you generally have multiple windows one for each document. As a Mac user, now working windows much of the time. I find the

Kon and Bal - NSWindowController won't show my window

2009-11-11T21:45:00.007Z

I am trying to rationalized the Windows idea of a MainFrame with the Cocoa document model, and in that deal with the meshing of C++ and Cocoa. Out the box Cocoa will give you a window per document - but infinitely configurable cocoa gives you the tools to skin the cat as you want it.What I have been trying to do is get my C++ MainFrame to create a NSWindowController (subclass) and to create and

Meshing Cocoa with C++

2009-11-02T22:22:00.000Z

One of the key issues I am looking at is the problem of having a code base that is written as C++ classes and meshing that with an application framework that is written in Objective C. My rough plan at the moment is to have a parallel Objective C object for each C++ object that appears directly in the UI. So, for example, there is an C++ object in Cello that is what is called the FrameView. This

Your document contents here

2009-11-01T19:50:00.002Z

This is a screen shot of the first file that has been opened by the cello application. The application will open a cello document that has been created in the PC version of cello. It openes the document much as the test application did but it is wired to the beginnings of a "propper" application.

Debugging Individual CPlusTestRig Test Cases

2009-10-18T19:04:00.007+01:00

Having got the unit tests working in the debugger I don't really want all the tests to be executed each time I run the debugger. I just want to work with the problem test. The easiest method I know of is just linking in the tests that you want. It is what I have used in the past when fixing unit tests (prior to getting the debugger to work I used NSLog calls and just looked at the output - my

Debugging CPlusTestRig UnitTests

2009-10-14T22:07:00.012+01:00

Having started work on the user interface I am doing a fair bit of reorganizing. In this reorganization I have been changing the way that UI related components are being registered. What has happened is that in the early stages of development I had roughed-out stubs installed as the needed UI components - but these no longer load. The upshot of this is that I have made the first progress am ready

Fun and games with owner counts

2009-07-25T17:37:00.000+01:00

Working on the UI my current short-term target is to open a file. The results of this will not be ostensibly much different from the test bed application which could open, save and publish a file except that it involves putting in the beginnings of a skeleton for the UI of the final app. The skeleton is a mix of Cocoa C++. There are C++ subclasses of existing Cello objects and Cocoa wrappers. I

UI - Initial Approach

2009-06-29T22:12:00.002+01:00

After a bit of a break I have started picking up on Cello again, once again I have some free evenings.Having got to the stage where I can open and publish test files I now have start the serious work of the user interface. My current thoughts are to start with the existing view hierarchy and to use it to wrap cocoa views. For example there is a time-line view. This view manages a time-line and

XCode - Development Version Numbers

2009-03-25T20:22:00.003Z

In the Cello development I have numbered each checkin. This checkin number is recorded in a tag-line in each file that is checked in, and in the checkin comment (or message). Once I have reached the stage of building the test applications I have been careful to build a version of the test application with the build number and archive it. The idea behind this is that when I find a regression or

The Joy of GIT

2009-03-22T11:54:00.004Z

Once you start getting accustomed to GIT it becomes quite addictive. I have started using GIT on another project. Despite using use only a fraction of it I have found it so fast and flexible that I have decided to move the Cello project over to GIT.To install Git on your machine the easiest way to go is to use MacPorts. MacPorts is a cunning system that will install a package and all it's

UI - BabySteps

2009-03-03T20:36:00.003Z

In building the UI I am planning to take baby-steps. There are two reasons for thisSmall steps are easierI have a tiny amount of spare timeAs things currently pan out I can only spare, at most, a couple of hours a week to work on Cello. A philosophy that I take when clearing the kitchen at home, a task that I find perpetually bewildering, is to do something productive with every action and not to

UI - Preparing for Power

2009-01-25T18:29:00.003Z

I had a friend who was in a member of the Revolutionary Communist Party and was planning to attend a meeting optimistically entitled "Preparing for Power". At the time it really tickled me. and has become one of those wonderfull phrases that has stuck with me.So for my part I am "Preparing for UI". These are the small baby steps that are required to start doing something. I have split the

Re-factoring

2009-01-07T20:10:00.004Z

Prior to starting on the UI I have been doing some re-factoring. I have read that the important thing when re-factoring is that the code still works. My experience supports this. The ideal situation is that you re-factor in small steps and intersperse these steps with running unit tests that will ensure that you haven't broken anything. In the case of Cello as most of the work I have done is for

The end of sound

2008-11-20T22:50:00.001Z

[build 0114] I have reached the end of sound - so the files with sound (WAV and MP3) generated on the PC open and publish correctly.The next step is the user interface. However before that I will go back over the new code I have added and do a little cleaning and re-factoring. I am not planning anything big - just making sure that things like names are consistent, that the code is commented and

Sound - nearing the end

2008-11-19T22:59:00.002Z

I think I am nearing the end of sound. I have created a new class that is heavy based on Apple's SCAudioCompress sample code and the existing MFC WAV to PCM converter class. So what I have got is more-or-less a drop in replacement for the old class.The approach I took was to take Apple's SCAudioCompress sample code and transformed it bit-by-bit, into the form I wanted, taking fairly small steps.

Sound - Debugging

2008-11-12T07:54:00.003Z

The biggest drawback for me when working with sound is that I don't know that much what I am doing. What I mean is that I have spent many years, for example, working with graphics, transformations etc. and I know the language, terminology and have encountered many problems. The upshot of this is that when working with graphics I have a context to put things into and looking through the code it "

QTKit and boost

2008-11-07T21:56:00.004Z

I have started working on sound. Somewhere close to he start of the project I focused on getting the project to compile. The support for WAV files butted straight on to MFC so I compiled it out with a #define _NO_WAV. What it means is to work through this code I can remove the #define and work through the compile errors.The support for WAV files in Cello is quite simple. WAV is converted to PCM

Canned Effects - complete

2008-11-02T18:41:00.003Z

[build 0096] I have completed working through all of the "Canned Effects", including the text effects, and they now work under OSX. Once I had completed the various problems with the handling of text it all fell out reasonably quickly. Getting the effects to work was little more than a handle turning exercise - get the files to compile, generate test files and test.The next step is to support

Understanding Fixes - Debugging

2008-10-30T19:21:00.009Z

As I work trough the text effects I make test files on the PC version so I can test on the OSX version. The test files are reasonably straight forward - I test the range of settings, use different styling and a mixture of paragraph and character styling. In this I came across a problem. The issue was a word based effect with a change of style within the word resulted in some characters being

Text Effects - Debugging rounding errors

2008-10-25T19:30:00.006+01:00

The first of the text effects is an effect where glyphs are swapped our randomly. Having fixed the more obvious (large scale) problem in the positioning (as described here) there was an outstanding more subtle bug in the positioning of the effect glyphs.One of my test files is based on some effect text that is precisely positioned on top of some normal text. When the effect ends the text come to

Text Effects - Debugging bounds problems

2008-10-23T22:15:00.006+01:00

I have been looking at a strange problem where glyphs, when revealed by an animation, fail to redraw properly. What happens is when a part of an animation moves over a character shape the shape that is revealed sometimes fails to redraw. You can see this in the snapshot below - most obviously there is a bit missing from the A.When I first saw the problem I presumed that it was down to a bug in

Text Effects - Debugging

2008-10-21T18:13:00.004+01:00

Having implemented the Accessor class getting the base class and the first text effect to compile was reasonably easy. The first text effect is a glyph substitution effect where glyphs in text are replaced with random glyphs in a simple animation.After fixing a couple of crashes the output appeared to more or less work. To test the effect more thoroughly I overlaid the text with the effect

Less is More

2008-10-16T22:53:00.005+01:00

The observation Less is More is an observation of Cello project that comes home time and time again. A considered path of least resistance seems generally to be the best course.For the past week or so I have been working on the text effects and I had sort of stalled. Cello is an after hours project so it is hard to get a stretch of more than a few hours together. The text effects stalled because

Managing TextBreakLocatorRef using Boost

2008-10-05T14:15:00.006+01:00

Since the birth of OSX new data types are based on Core Foundation. Core Foundation provides an owner-counted management of objects which allows for quite a natural, as well as simple, memory management. In C++ these are easily managed by boost intrusive_ptr (more details of which were posted here)My initial take on TextBreakLocatorRef was that it predated Core Foundation and as I wanted to be

Unicode Word Breaks - UCFindTextBreak

2008-10-05T11:24:00.003+01:00

Working through the various effects I have come quite quickly to text - so the holiday (the appearance of rapid progress) is over and it is back to text. I like text so all is right with the world.The text effects work on either lines of text, words within lines or letters. In the PC version of Cello there is no distinction between a letter and a glyph - however gunning everything through

Core Text - CTFontGetUnderlineThickness

2008-10-01T20:52:00.004+01:00

[build 0066] I have got the first five effects to work - that is I can open files that have the effect and publish them. My thought of a chance to make some rapid progress by avoiding text was short-lived. Having added text to the test files there were problems to work through.The effects deal with text as path shapes. That is internally they make a single shape out of the glyphs and then do

Canned Effects

2008-09-30T07:12:00.008+01:00

[build 0062] Having got to the end of Text I found that Sprites, Gradients, Buttons and TimeLines fell out in a few hours. In some ways this is strange because progress has been pretty hard fought for with text. In getting the text to work I had to replace a font scalar, plumb in CoreText - none of this is small beer. The Sprites, Gradients etc are little more than getting the files to compile -

CoreText - Setting styles on empty AttributedStrings

2008-09-29T16:29:00.001+01:00

[build 0058] Text in Cello appears to be completed - for the moment at least.The last problem with text was something of a classic. Within Cello the text and style runs are stored as CFAttributedStrings. This works out really well as this is what CoreText consumes. The problem comes with empty strings. If you have an empty string then it is impossible to set any attributes on it. Also if you try

CoreText Typography - Ligatures

2008-09-25T07:10:00.002+01:00

[build 0051] The great fight with text is slowly coming to a close. I have a few outstanding bugs before I move on to editable text but I can see the end.Ligatures appear correctly in the output.Having spent some time looking into glyphs and glyph codes ligatures are the easiest test case for non-standard glyphs because it is possible to type in normal letters like "f" and "i" in the PC version

CoreText - Accesing the CMAP CTFontGetGlyphsForCharacters

2008-09-24T07:49:00.006+01:00

CoreText provides the function CTFontGetGlyphsForCharacters that will give you a conversion from a letter to a glyph through the unicode CMAP.

Glyphs to Character Codes - revisited

2008-09-21T23:24:00.005+01:00

My original plan to map glyphs to character codes appears doomed. There main flaw in this plan is that it looks like the glyph names are not reliable - what I mean by this is that some glyphs do not have names that can be mapped to a character code. For example the font "Li Song Pro" has glyph names names that apper to be based on glyph codes rather than character codes.At this point I took

CoreText - Getting Glyph Names

2008-09-19T18:01:00.006+01:00

Looking at the published file and its log I can see that there is a problem with the character codes that Cello is publishing. The published file format expects character codes that are then mapped to glyph indexes. Cello is feeding the code glyph indexes, it works but it is not right and will cause problems in other places where text is used. If you are not too familiar with the difference -

CoreText - Bold, Italic and CTFontCreateCopyWithSymbolicTraits

2008-09-17T21:25:00.008+01:00

[build 0047] The text publishing is slowly falling into place. I have managed to get to the bottom of most of the positioning problems. The side-by-side comparison shows publishing under OSX text is quite similar. The vertical positioning is a little different. Also under OSX the text is kerned - something that fell out from using Core Text.More complex example (an unpleasent combination of

CoreText - flipped coordinates and glyph curves.

2008-09-12T23:23:00.011+01:00

Text output is requires partial fonts to be included in the file format. This is done by having the glyph outlines embedded in the file. As described earlier I am using Core Text to get the glyph outlines (see). Unfortunately (looking at the output) the outlines are flipped.This particular problem is caused by CoreGraphics (Quartz) having a flipped y-axis, so zero is at the bottom rather that the

CoreText and Typographic Bounds

2008-09-11T22:20:00.010+01:00

[build 44] Having got the simple file with text to open the next stage was to get the brute to publish. The first attempt at publishing yielded nothing - white space. Looking at the debug log that dumps the published movie it was because the text object that was published was empty i.e. had no text.The primary cause of this was due the conversion of floating point to integer values. Within Cello

CoreText & Cocoa Text - what is RTF?

2008-09-10T09:09:00.004+01:00

[build 42] Cello will open some simple files with text, The question "what is RTF" seems suddenly quite poignant. The reading of a file with text fails because the reading of the RTF (within the file) fails. Cocoa believes the RTF to be bad and throws up it's hands in horror. Cross checking my results with TextEdit (I added some code to squirt out the RTF on its own in a file) yields the same

Text - the first test and the first crash

2008-09-09T07:50:00.004+01:00

[build 41] I have got as far as linking in the text related files for reading, writing and publishing. This means that all the code that is required to read a text object, write it, and publish it has been added to Cello. As my first test I have created a text file in the PC version of Cello with the single word "Text".Attempting to open this crashes - this, of course, is progress. I have

Core Text - CFStringGetParagraphBounds and Setting Paragraph Styles

2008-08-28T07:08:00.006+01:00

I am working through the text classes writing unit tests. As Cello had no unit tests before I took on the OSX port I have been writing unit tests primarily for the delta, that is the changes I have made, rather than attempting to add unit tests for the all of the historic code. Sure I would love to but that is a project in it's self. I would hope that as I find bugs in the code (sure as are eggs

CoreText, RTF, Unit Testing

2008-08-20T22:26:00.006+01:00

I have added the reading and writing of RTF, using the initWithRTF and RTFFromRange cocoa methods. These deal with NS/CFAttriibutedStrings, and back onto NS/CFData. The wrinkle is that NSColor has to be converted to CFColor as I covered before here.The accompanying Unit Tests were quite simple, Create a CFAttributedstring, add attributes, write as a CFData, read back and compare. They should be

CoreText and CTMutableParagraphStyle

2008-08-13T18:52:00.005+01:00

I have implemented Cello's paragraph and character styles as thin wrappers for CTParagraphStyle and CFDictionary. This corresponds to the way that text styling is handled in core text.The API for CTParagraphStyle is rather thin. There is, for example, no CTMutableParagraphStyle - which means that API supports the creation of a CTParagraphStyle in one hit - but you can not set properties one by

CoreText - the approach

2008-08-10T22:31:00.008+01:00

I have been looking at the text in Cello in some detail. The approach that have decided to take is to change the fundamental text object so that it is a thin wrapper on a NS/CFAttributedString. Doing this gives me RTF import and Unicode support at a basic level. On top of this the CTFrame fits quite naturally into one of the Cello classes.The fact that the PC version of cello is fundamentally

CoreText and RTF

2008-08-06T07:59:00.010+01:00

Sample Unicode: 魚もたばませんCello has text so it has support for line layout and line breaking. It has classes that represent Paragraphs, Styles, Style Runs and Layout blocks etc. Down at the metal the text is serialized (written and read) as RTF. Cello has its own RTF reader and writer. All this has to mesh with CoreText - that is where the glyph curves ultimately come from. Also in the back of my

Converting Quartz Paths - MoveTo, LineTo, CurveTo

2008-08-03T11:26:00.007+01:00

Cello has it's own support for curves - internally it has support for cubic and quadratic splines, as well as lines - the equivalent to what exists in CoreGraphics (Quartz) and generally in vector graphics systems. Within Cello there are classes that represent multi contoured splines and the attendant trickery to draw and manipulate them. They are of significance to me now as the existing Cello

CoreText and Unit Testing

2008-07-30T21:39:00.006+01:00

Working through the text the font handling in Cello I find that it meshes well with Core Text. The extent of what I am currently doing requires me to create CTFonts and get glyph curves. This is very similar to some early work I was doing in Cello and as I progress a few modest functions into my Core Text support there is an opportunity to share code.If you have not used Core Text before it is a

Starting Text

2008-07-27T11:24:00.004+01:00

One of the real pleasures of working on Cello is the quality of the code and commenting. I have started working on text. The two big things left on the file format are text and sounds. Text is, I think, the bigger - but is more familiar to me.The first step is to compile in the registration object and then to work through files that need to be built and included, to add and then build them. The

Reading Bitmap Objects III

2008-07-26T21:25:00.008+01:00

[build 0034] It looks like I have come to the end of DIBs and CGImages - well that is as far as the file format and file generation goes. The final part was, much as I suspected, mainly leg-work.Below is one of the final parts of my testing - showing transparency working correctly in the output file. The GIF transparency has the characteristic halo as it only supports 0% or 100%

Saving JPEGs with Image IO

2008-07-20T19:21:00.005+01:00

[build 0031] JPEGs now work again.Fixing the problems in the JPEG images fell out in the wash. It looked like a byte ordering problem combined with a pixel size problem (which would explain the vertical striping) - but I did not look into it. Instead I used Image IO to generate the JPEG. The save, using Image IO, fell out in four or five lines of code. Using Image IO means that the OS will handle

DIBS and CGImage - The price of progress

2008-07-20T00:18:00.006+01:00

[build 0030] Sometimes the price of progress is that things stop working. Not much works in Cello but the JPEG based part of the export now no longer works.For the past couple of weeks I have been working out the underlying problems with bitmaps, DIBs and CGImages. I abandoned my approach of getting the melding the CGImage implementation to be more like the MFC Dibs and instead more-or-less

More Bitmaps - DIBS and CGImage

2008-07-13T09:14:00.006+01:00

[build 0029] I have been working on bitmaps and bit images and the whole thing is slowly coming more into shape. The issue that I have been having with bitmaps is that fundamentally the bitmaps that are imported into Cello using Image IO as a CGImage are richer and more complex than those represented by DIBS. A CGImage has notions of byte order (big and little endian) and different data packing.

Reading Bitmap Objects II

2008-07-04T23:21:00.006+01:00

[build 0027] Looking at the problem with the images it initially seemed like it might be a problem with bounds calculations. Initially I suspected my implementation of CRect intersection operation, that I had added to get the image import code to link, might be at fault. This was a hunch despite the fact that I had written Unit Tests for this essentially trivial function. Like many hunches it

Reading Bitmap Objects I

2008-07-04T08:00:00.003+01:00

Cello's file format is broken up into a number of distinct objects. The simplest the shape works and publishes correctly. All the object types are registered through a GUID and the read calls a factory to make objects that correspond to that GUID. This makes for an easy incremental development. All the registration *except* for the shape object is commented out. It is possible to uncomment them

Cello - publishing the first file

2008-07-02T05:28:00.003+01:00

[build 0025] Cello now publishes the simple test file (just a red square) under OSX.The publish revealed a single bug - code that was designed to ensure that all the folders in a file path existed, and created them if any were missing, failed. Cello has a class that does this and calls through to one of a small number of utility functions built on top of the cocoa NSFileManager. When writing the

Cello - opening the first file

2008-07-01T05:43:00.010+01:00

[build 0024] Cello will now open a very simple file (just a red square) and save an identical one under OSX.Getting Cello to open a file brought in a fair number of new files. Objects within the Cello file format are referenced by a unique identifier (actually a GUID) which are constructed from a factory. So adding the code to register the simplest object (a basic shape) with the factory had the

Mounting the board - Cello's first crash.

2008-06-27T14:56:00.004+01:00

Cello now crashes. This represents progress as it means that I have come to an end of rounding-up in the great ranch of link errors.Cello won't do any more than allow you to choose a file - it crashes way before any part of the file reading code is called. So now to work through the crashes - I fully expect this process to pull in more and more files.I expect that I will have to largely pause my

CGImage & ImageIO - converting premultiplied alpha

2008-06-26T14:55:00.007+01:00

The final part of the DIB (bitmap) equation is reading images. Cello has classes for reading and writing PNG, JPEG and a few formats including PaintShop Pro that are prevalent on windows. The change that I have made here is to use Image IO. Image IO will let you read all the most common formats - and also has support for RAW images (as spat by many digital cameras) amongst other things.ImageIO is

XCode unit testing and Bundle Resources

2008-06-25T17:41:00.007+01:00

In order to test the code that reads images I needed to set up tests that read images. In order to do this repeatably the best thing seemed to be to add them to the bundle of test application. In XCode this is quite simple - I just dragged in a folder of test images into the right place in my source files and XCode magically knows that these are to be copied - updating the copy files phase of

DIB to CGImage - the washing up

2008-06-24T15:28:00.004+01:00

I changed the plans and in the end kept the class that manage the DIBs almost unchanged. The DIB class, within Cello, represents a bitmap with a physical bit-image. Give or take the fact that it can handle native compressed bit-images it handles the concept that an image is a bunch of bits and possibly a color table. A CGImage is very similar except that you can't get to the bit-image. You can

Moving DIBs (device-independent bitmaps) to CGImage

2008-06-21T00:07:00.004+01:00

The biggest remaining clot of link errors (probably about 30 or so) relate to Cello's handing of Bitmaps. There are a handful of classes, many parts of which of which are commented out or omitted from compilation, that deal with bitmaps. Hanging on to this are classes and libraries that deal with reading and writing images to and from physical files. Central to all of this is the class that

Getting the ZLib dylib to link in XCode

2008-06-19T22:27:00.009+01:00

With the link errors dropping into the 50s the home straight of something that links, though not close, seems possible. My latest teaser was some problems linking Zlib. The Cello sources include Zlib but as it exists as standard under OSX there seemed little point in compiling it into the application - also I dimly remember that there was some issue with it compiling - not that large but using

Implementing MFC CTime using CFDate

2008-06-17T23:31:00.005+01:00

In the early stages of Cello I stubbed out the MFC CTime class with little more than a constructor in order to get it to compile. Working my way through the link errors this is something that I needed to flesh out.My basic plan with implementing these MFC classes is to keep the API but to build them on top of Core Foundation objects. Core Foundation can quite ubiquitously be expressed as NS (

Implementing SetFileTime and GetFileTime under OSX

2008-06-15T17:08:00.009+01:00

Working through the link errors makes for some catching up on some things that I sketched out and did not complete. I have been looking at the file handling class, file streams and writing unit tests to make sure that the they are working properly as I flesh them out.I have backed Cello file handling class more or less straight onto STL file streams. In this class there are a couple of methods

CString and Unit Tests

2008-06-10T22:40:00.012+01:00

Right at the head of the link errors was the CString class and most of it's methods. Early on in the port I copied the class declaration from MFC, commented out almost all of the methods and then uncommented the ones that as I got compile errors. It is surprising just how few of the class methods are used. At the time I knew that I wanted to implement it as a CFString so I added constructors and

Link errors - Waxing the board

2008-06-09T19:05:00.003+01:00

If XCode is to be believed I have 460 files compiling including the key file that is responsible for opening and reading the the Cello document. The next step is to wrap the "open" call in minimal snippet of cocoa and some make-shift UI. Pictured bellow is the Nib for the full FileTest UI.The idea from here is then to surf through the link errors and, for a while, to let them drive the

QuickTime - converting Audio Formats

2008-06-03T19:52:00.007+01:00

As I near the end of working through the output generation files I have come across the the issue of audio content. The Cello output file has sound embedded in it either as ADPCM or MP3. As Cello is a port from windows it has code that will covert from WAV (ubiquitous on Windows) to ADPCM. There is a converter class in Cello that backs onto some MFC APIs that takes care of this.I have not done

Cubics & Quadratics - Approximation results

2008-06-02T18:56:00.008+01:00

I spent a few hours going through the Font Forge files to get a grip on how much work it would be to use it in Cello. My suspicion is that the code in Font Forge will produce better results in converting Cubics to Quadratics for fonts, simply because Fount Forge is dedicated to this kind of work and George Williams (the author) has obviously put a lot of work and consideration into the

Glyphs to Paths - Cubics & Quadratics in CoreText

2008-05-30T19:55:00.007+01:00

Sometimes the world is a bit more upside down than you might initially perceive - Cello's output file format requires its curves to be described as Quadratics rather than Cubics. So I need to convert any Cubic paths that I get from CoreText to Quadratics.Converting from Quadratics to Cubics is far less straight forward than the other way around. Cubics can only be approximated by Quadratics they

Glyphs to Paths - Quadratics & Cubics in CoreText

2008-05-29T18:13:00.007+01:00

Pressing on with the conversion of the file that deals with glyphs I need to obtain the path that represents a glyph. CoreText provides the function CTFontCreatePathForGlyph that returns a CGPath of an individual glyph. The final thing to do then is to convert the path to the output format.Core Graphics provides a function CGPathApply that will apply a user defined function to each element a part

Kerning Tables and CoreText

2008-05-23T07:43:00.004+01:00

I don't think I have ever worked on something type related without having, at some stage, to grub around in font tables. Cello, it turns out, is no different. The output file requires a subset of kerning pairs of the fonts used in the documents - to do this I need to get a set of all the kerning pairs that are defined a given font. Core Text won't give me the kerning pars but it has a function

Fonts and Font Scalars - from D-Type to CoreText

2008-05-21T22:43:00.008+01:00

I have come to the part of Cello where I need to start dealing with text and fonts. Detailed information about glyphs, metrics, kerning pairs, glyph outlines etc. all need to be known in order to generate the final output file.The Windows (MFC) version of Cello uses the D-Type font engine (scalar). Looking at D-Type it looks pretty good, and it is available for OSX. I do not, however, plan to use

typename in templates - gcc errors

2008-05-20T19:23:00.006+01:00

Pressing on I am working through the generator files. These are a set of files that generate the output. The biggest problem I found so far in these is some template definitions that tripped up gcc which requires a typename to be specified in some circumstances where visual c++ was quite happy. The following class - when complied on XCodetemplate class Foo{public: Foo(const T&); std::

Pargen for YACC and LEX

2008-05-19T21:47:00.004+01:00

The YACC and LEX libraries that Cello links against come from Pargen. Pargen is a YACC and LEX distribution for use on Windows. Cello was supplied with the Pargen libraries without source. Fortunately Bumble Bee Software have the sources to their previous release of their Pargen library available for download. Checking the source headers against the headers that were included with the Cello code