LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 04-01-2024, 10:17 AM   #16
EdGr
Member
 
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 998

Rep: Reputation: 470Reputation: 470Reputation: 470Reputation: 470Reputation: 470

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
 
Old 04-01-2024, 11:05 AM   #17
hazel
LQ Guru
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 7,569

Original Poster
Blog Entries: 19

Rep: Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451
Quote:
Originally Posted by EdGr View Post
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.
Yes, that could be one solution. There are a couple of gdk-cairo interface functions to translate pixbufs into cairo surfaces and vice versa.
Quote:
The program should create a Cairo image surface and draw on it. The draw handler should copy from the image surface to the device.
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.
Quote:
I suspect that your program is relying on the GdkPixbuf/Cairo image surface to hold its state because it has no other data structures. All of my programs have data structures. The GUI is one of many things generated from the data structure.
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.

Last edited by hazel; 04-01-2024 at 11:33 AM.
 
Old 04-01-2024, 11:52 AM   #18
EdGr
Member
 
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 998

Rep: Reputation: 470Reputation: 470Reputation: 470Reputation: 470Reputation: 470
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
 
Old 04-01-2024, 01:17 PM   #19
teckk
LQ Guru
 
Registered: Oct 2004
Distribution: Arch
Posts: 5,137
Blog Entries: 6

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Also search youtube for c struct

Such as this one:
https://m.youtube.com/watch?v=dqa0KMSMx2w
 
Old 04-02-2024, 12:35 AM   #20
hazel
LQ Guru
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 7,569

Original Poster
Blog Entries: 19

Rep: Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451
Quote:
Originally Posted by EdGr View Post
Read about the C struct. Design a struct to hold data for a single note.
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.
Quote:
Represent the musical score as a doubly-linked list of structs.
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.

Last edited by hazel; 04-02-2024 at 01:21 AM.
 
Old 04-02-2024, 06:44 AM   #21
EdGr
Member
 
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 998

Rep: Reputation: 470Reputation: 470Reputation: 470Reputation: 470Reputation: 470
Quote:
Originally Posted by hazel
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.
That is good to hear.

Quote:
Originally Posted by hazel
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. The drawing should be fast enough that a pre-rendered image is not needed.

Quote:
Originally Posted by hazel
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 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
 
Old 04-02-2024, 07:38 AM   #22
hazel
LQ Guru
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 7,569

Original Poster
Blog Entries: 19

Rep: Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451
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:
Code:
{
   DrawStave()
   ClefWrite(globvars_pointer->clef)
   KeySigWrite(globvars_pointer->key)
   TimeSigWrite(globvars_pointer->time)
   while glyph in glyphlist 
   {
   GlyphWrite(glyph)
   }
}

Last edited by hazel; 04-02-2024 at 09:44 AM.
 
Old 04-02-2024, 10:57 AM   #23
EdGr
Member
 
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 998

Rep: Reputation: 470Reputation: 470Reputation: 470Reputation: 470Reputation: 470
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
 
Old 04-03-2024, 04:39 AM   #24
hazel
LQ Guru
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 7,569

Original Poster
Blog Entries: 19

Rep: Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451
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.

Last edited by hazel; 04-03-2024 at 04:46 AM.
 
Old 04-03-2024, 07:25 AM   #25
EdGr
Member
 
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 998

Rep: Reputation: 470Reputation: 470Reputation: 470Reputation: 470Reputation: 470
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
 
Old 04-05-2024, 03:39 AM   #26
hazel
LQ Guru
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 7,569

Original Poster
Blog Entries: 19

Rep: Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451
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.

Last edited by hazel; 04-05-2024 at 11:04 AM. Reason: PS added
 
Old 04-09-2024, 10:08 AM   #27
hazel
LQ Guru
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 7,569

Original Poster
Blog Entries: 19

Rep: Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451Reputation: 4451
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.
 
Old 04-09-2024, 11:24 AM   #28
EdGr
Member
 
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 998

Rep: Reputation: 470Reputation: 470Reputation: 470Reputation: 470Reputation: 470
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Drawing arcs in cairo hazel Programming 15 03-19-2024 07:39 AM
Cairo build fails at cairo-analysis-surface.lo CME2 Linux - Newbie 2 12-15-2017 08:10 PM
[SOLVED] cairo's image surface backend feature could be enable ... no lee.colbert Linux - Software 3 10-21-2012 10:43 PM
pckage "cairo" required by cairo" not found barunparichha Linux - Software 4 06-25-2008 08:29 AM
GTK Drawing Area gsrikanth Programming 0 10-06-2006 07:42 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 02:07 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration