hazel - Okay, no drag-drop.

The main difference between the toolkits is that Cairo cannot draw on a GdkPixbuf. GdkPixbuf was replaced by the Cairo image surface. If a GdkPixbuf is still needed, the program can copy the image in either direction.

The program should create a Cairo image surface and draw on it. The draw handler should copy from the image surface to the device.

I suspect that your program is relying on the GdkPixbuf/Cairo image surface to hold its state because it has no other data structures. You should consider building one. All of my programs have data structures. The GUI is one of many things generated from the data structure.
Ed

Yes, that could be one solution. There are a couple of gdk-cairo interface functions to translate pixbufs into cairo surfaces and vice versa.
Solution number 2! It means essentially going back to the way I did it before, but with a cairo surface replacing the pixbuf. All copying would be in one direction only as before. That would probably be the simplest way to code it. But actually I quite liked the idea of writing directly onto the drawing area. It's conceptually tidier.
Solution number 3! So what's a data structure and how do I build one? More important, how long would it take me to learn how to build and use it? If it's too big a deal, I'll go with solution 2. I'll start afresh with the gtk2 version and I can quickly put in all the modifications that I now know I need for gtk3/cairo while not changing anything that requires data transfer in a different direction from the original.

Programming = Algorithms + Data Structures

Data structures are half of programming. Countless books have been written.

Read about the C struct. Design a struct to hold data for a single note. Represent the musical score as a doubly-linked list of structs.

This will require work, but afterwards you will wonder how the program got by without it.
Ed

Also search youtube for c struct

Such as this one:
https://m.youtube.com/watch?v=dqa0KMSMx2w

Ha ha! That's what I'm doing already. You can't write a program as complex as this without using a few structs. It's just impossible.

I use two in this program actually and I don't know what I'd do without them. The glyph struct contains everything about a note: its type, its position on the stave, the parameters that affect the meaning of this (key, clef, etc), its modifier (if present), which way the stem goes, and so on plus the corresponding pmw code. The globvars singleton is a one-off struct that contains the "global variables", including a pointer to the current glyph and one to the backup surface, but also flags, window title, name of pmw output file and so on. Anything I might need to know inside a function. It's a very useful thing to pass around as an argument.
Hmm. That's more or less what I did in my sudoku_aid program. I have a struct called sudoku_value and I kept a list of them which could be saved in a temporary file, so that I can go down guesswork branches and then double back again. So you are saying I don't need a visual backup at all: I could just keep a list of glyphs and completely reconstruct the stave when required. Yes, that would probably work too. But I think going back to writing on the backup surface and not on the screen is the simplest solution, the one that requires less mucking about with the original logic, so I think I shall do that.

That is good to hear.

Yes. The drawing should be fast enough that a pre-rendered image is not needed.

That will work too, but the pre-rendered image needs to be kept in sync with the doubly-linked list. In my experience, that is worthwhile only if the drawing time is long.
Ed

You misunderstand. I need to do this in stages, because I shall get completely mixed up otherwise. So stage 1 will be a simple conversion from gtk2/gdk2 to gtk3/cairo without changing the logic of the program in any way, like I did with my other programs. When I have got that to work, I shall try creating and maintaining a GList of glyphs. That's a bit more complicated than you might think because the program has an edit function where you can go backwards and modify an earlier note. With a purely visual backup, that doesn't cause problems -- you just queue the modified area for redrawing, the same as you would for a new note -- but a glyph list would need to be retrospectively modified by pulling out the affected glyph (probably by its x-coordinate) and replacing it with the new version.

And if all that works, I can remove the visual backup and use the list instead. The draw handler(in pseudocode) would then be something like:

That sounds good: first get the program working on GTK3/Cairo, and then re-engineer it to use a doubly-linked list.

BTW, I have written a dozen editors. What they edit is completely different, but all are built around doubly-linked lists.
Ed

You'll laugh! We already have the GList of glyphs! I'd completely forgotten about it, which shows you how long ago it is that I wrote this bloody thing. Of course when you use a program habitually, you become fixated on the UI and forget how it works in the background. In fact I needed to store my glyphs in a list and not in a file because of the need to back-edit. When you're writing out music, you often notice a mistake only after you have added the next couple of notes.

The pmw codes get copied to the file only when you press the save button, and that also clears both the GList and the stave. glyphlist and stave are always in sync, which is just what you need for a backup. The pointer to glyphlist btw is one of the things stored in globvars.

Okay, it turns out your program is built like an editor after all.

Drawing from the doubly-linked list should be easy and instantaneous on a modern computer.
Ed

It compiles! Hallelujah! It's still rather buggy: the edit function doesn't work yet, but I'm sure I can fix that. The glyphs (other than actual notes) mostly look awful but they can be improved incrementally as I get more experienced with cairo drawing operations. The important thing is that the drawing model works. Glyphs appear instantly on the stave where I click and, if I minimise the window or drag another window across it, the stave and notes reappear on exposure. So Tekk's draw handler works perfectly.

Thanks a million.

PS: Edit works too now.

Just to tidy up: I've rewritten the drawing of all the glyphs that looked wrong and the new gtk3 version is now installed. As far as I can see, it works perfectly. In fact the stave interface is greatly improved by the switch from gdk to cairo: the glyphs are blacker and more clean-cut than in the old version.

I'm less happy with the UI. The old gtk2 UI had lovely 3D widgets that looked as if they had been cast out of gunmetal. When you clicked on a button, it depressed visibly and then jumped back. The new one reminds me of the schematic X-Athene widgets that the early X applications used. But that apparently is the price of progress.

Cairo's anti-aliased drawing is very nice. gdk_draw's jagged lines were from the dinosaur era.

Themeing changed completely between GTK2 and GTK3. Custom themes need to be rewritten. I coaxed more-or-less the same appearance from GTK3 as GTK2.
Ed