creating snap package about notekit

[blackhole89]

Is snap supposed to bundle all the libraries it depends on? Can you check if there is any libgtkmm-3.0 in the archive it generates? (Maybe it's not named libgtkmm-3.0.so.1 for some reason?) Alternatively, could it be that you do not have libgtkmm-3.0-1v5 installed in your parent system, and if you run the executable directly, it does not try to load libraries from the unpacked folders? (In that case you probably want to also export LD_LIBRARY_PATH=/snap/notekit/x1/usr/lib/something.)

(I can try to check for myself in a bit, but currently I don't have access to any machine that even has the free disk space to install snap...)

[noah1510]

Is snap supposed to bundle all the libraries it depends on? Can you check if there is any libgtkmm-3.0 in the archive it generates? (Maybe it's not named libgtkmm-3.0.so.1 for some reason?) Alternatively, could it be that you do not have libgtkmm-3.0-1v5 installed in your parent system

Snap uses the system package manager to install its dependencies that's why I am confused about the error. I think it really is a problem caused by some older library, but I don't know which one.
What version of gcc and libc do you havefor your local builds?

and if you run the executable directly, it does not try to load libraries from the unpacked folders? (In that case you probably want to also export LD_LIBRARY_PATH=/snap/notekit/x1/usr/lib/something.)

The snap package only contains the executable and the data and sourceview folder, no library because they are installed seperately. Its contents are essentially the linux package you provide for download just compiled on ubuntu 18.04.

[blackhole89]

Snap uses the system package manager to install its dependencies that's why I am confused about the error.

The snap package only contains the executable and the data and sourceview folder, no library because they are installed seperately.

Then what's even the point of using a snap package, as opposed to creating a .deb? I thought that the reason for using these container-based distribution systems was precisely that you could sidestep system package management and bundle any required libraries at the right version...

Can you tell me the output of tree /snap/notekit/x1? (Might have to pipe it into a file.) Also, when you run notekit, it should print some data on the directories it decided to use to stdout. Could you tell me what these are when running it directly?

What version of gcc and libc do you havefor your local builds?

I'm on gcc 8.3.0-7 and libc 2.29-2, but I can't imagine it mattering since I've successfully built it on a different machine running gcc 7.3 and an Ubuntu 18.04 based Mint before.

[noah1510]

I'm on gcc 8.3.0-7 and libc 2.29-2, but I can't imagine it mattering since I've successfully built it on a different machine running gcc 7.3 and an Ubuntu 18.04 based Mint before.

Well the build succeeded but the created program is a bit funky, and does not work like intended at all.

Can you tell me the output of tree /snap/notekit/x1?

/snap/notekit/x1
├── data-dir
│   ├── icons
│   ├── sounds
│   └── themes
├── gnome-platform
├── lib
│   └── bindtextdomain.so
├── meta
│   └── snap.yaml
├── snap
│   └── command-chain
│       ├── desktop-launch
│       └── snapcraft-runner
└── usr
    └── share
        └── notekit
            ├── data
            │   ├── default_config.json
            │   ├── fonts
            │   │   ├── bchb8a.pfb
            │   │   ├── bchbi8a.pfb
            │   │   ├── bchr8a.pfb
            │   │   ├── bchri8a.pfb
            │   │   └── readme.charter
            │   ├── icons
            │   │   └── hicolor
            │   │       ├── index.theme
            │   │       └── scalable
            │   │           └── emblems
            │   │               ├── eraser-tool-symbolic.svg
            │   │               ├── large-pen-symbolic.svg
            │   │               ├── medium-pen-symbolic.svg
            │   │               ├── pen-tool-symbolic.svg
            │   │               ├── pick-color-symbolic.svg
            │   │               ├── small-pen-symbolic.svg
            │   │               └── text-symbolic.svg
            │   ├── stylesheet.css
            │   └── toolbar.glade
            ├── notekit
            └── sourceview
                ├── classic.xml
                ├── def.lang
                ├── language2.rng
                ├── language.dtd
                ├── language.rng
                ├── markdown.lang
                ├── markdown.lang.in
                └── styles.rng

19 directories, 29 files

Also, when you run notekit, it should print some data on the directories it decided to use to stdout. Could you tell me what these are when running it directly?

Simply calling notekit results in /snap/notekit/x1/usr/share/notekit/notekit: error while loading shared libraries: libgtkmm-3.0.so.1: cannot open shared object file: No such file or directory

Calling /snap/notekit/x1/usr/share/notekit/notekit gives the following

noa@noa-ZenBook-UX462DA:~/Desktop/temp/notekit$ /snap/notekit/x1/usr/share/notekit/notekit 
== This is notekit, built at Wed May 20 07:38:10 2020. ==
Detected paths:
Config: /home/noa/.config/notekit
Active notes path: /home/noa/.local/share/notekit
Default notes path: /home/noa/.local/share/notekit
Resource path: /snap/notekit/current/usr/share/notekit

color1
old: 125, new: 93
old: 132, new: 95
old: 202, new: 143
old: 108, new: 85

While the output says that something is being draw, the lines all soon disappear and I cannot write text.

Then what's even the point of using a snap package, as opposed to creating a .deb? I thought that the reason for using these container-based distribution systems was precisely that you could sidestep system package management and bundle any required libraries at the right version...

Snaps work on more distributions, and use the package manager of that specific distro to install the packages your program depends on.
You can also choose to depend on other snaps which would allow bypassing the distro, but very few libraries are actually provided by snap, since it is intended for application (at least as far as I know)
It seems to be a design choice made by canonical and results in smaller packages and less overhead and helps not to become the mess libraries are on windows (where each program has to always bundle all the required dlls making security updates of broken libraries impossible).
If you want bundled libraries you have to use appimage or flatpack, but I has really bad experience with both (appimages take forever to start and flatpacks take forever to install because they tend to get quite large)
And they are less of a hassle to create that debian packages (at least if you want to create them properly).
Also snap actually isolates the package and allows you to install more than one version at a time (which a deb cannot do).

[noah1510]

I just noticed that you can bundle libraries with snap, but even if I bundle the required libraries, it still wouldn't work properly because snap has the same build environment as my laptop.
If it does not work with the libraries I have installed on my laptop, it wouldn't work wit the same version form the snap environment.

[blackhole89]

Snaps work on more distributions, and use the package manager of that specific distro to install the packages your program depends on.

...but how do they figure out what the right packages in a given distro are? I remember seeing that even between Debian and Ubuntu, some Qt components were split up differently between packages for a while (so you wouldn't know if, I don't know, SVG support was already provided as part of the qt webkit package or you needed to install some libqt*svg*), and, for instance, zlib1g-dev is apparently called zlib-devel on Fedora. I doubt you'd get around having to write a separate dependency list for every distro you want to support, but at that point you might as well package it for that distro; this would also have the effect that if the distro update process were to break or remove one of your dependencies, it would actually let you know, rather than making the application start failing with no explanation. Meanwhile, between Provides: and |-disjunctions in your dependency list, you could probably at least cook up a deb package that works on every debianesque distribution including those that do not usually come with snap (such as, elephant in the room, Debian itself), and I imagine similar things are possible with rpm and pacman.

I'm not a big fan of AppImage or Flatpak either, but what I'm hearing about Snap really makes it sound like it's inferior to a proper package in every respect except for two that seem fairly insignificant in my eyes (install more than one version at a time; weaker standards for what constitutes a "proper" package). Maybe I should just bite the bullet and put .deb metadata in the repository at some point so that you can get one automatically as part of the build process...

Simply calling notekit results in /snap/notekit/x1/usr/share/notekit/notekit: error while loading shared libraries: libgtkmm-3.0.so.1: cannot open shared object file: No such file or directory

Since libgtkmm-3.0.so.1 does manifestly seem to be on your system, the only possible problem I can see is that whatever mechanism snap uses to actually let a "contained" application use libraries installed via the system package manager did not wind up exposing that library to notekit when it's run via snap. Could it be that you need to declare the system package manager provided libraries a snap uses explicitly in some place where you didn't include this particular one?

Calling /snap/notekit/x1/usr/share/notekit/notekit gives the following (...)

This output, on the other hand, looks like nothing is wrong...

While the output says that something is being draw, the lines all soon disappear and I cannot write text.

This may be a silly question, but did you create and open a note after starting it? When there are no .md files in its notesbase folder (/home/noa/.local/share/notekit, for you?), it defaults to showing a dummy document that is not editable and contains text to the effect that no document is currently opened. You can create one by double-clicking the "+" in the tree view on the left and entering a name followed by <RETURN>.

[noah1510]

This may be a silly question, but did you create and open a note after starting it? When there are no .md files in its notesbase folder (/home/noa/.local/share/notekit, for you?), it defaults to showing a dummy document that is not editable and contains text to the effect that no document is currently opened. You can create one by double-clicking the "+" in the tree view on the left and entering a name followed by .

I have created documents even more than one but this did not improve anything, it seems to be a runtime dependency problem or an incompatible library version. But I don't know what is missing at all...

Since libgtkmm-3.0.so.1 does manifestly seem to be on your system, the only possible problem I can see is that whatever mechanism snap uses to actually let a "contained" application use libraries installed via the system package manager did not wind up exposing that library to notekit when it's run via snap. Could it be that you need to declare the system package manager provided libraries a snap uses explicitly in some place where you didn't include this particular one?

I found the problem, snap has a few problems when you set the stage and stage-package but now I get the following error message:
FATAL: config.json not found in note tree, and default_config.json not found in data tree!
It seems notekit cannot find the config.json, where is it supposed to be with a different $XDG_DATA_DIRS variable set?

I also noticed that snap actually seems to include all the libraries specified, but downloads them from the ubuntu repository during the build process, so you only have to now which ubuntu packages your program depends on.

Maybe I should just bite the bullet and put .deb metadata in the repository at some point so that you can get one automatically as part of the build process...

I have some experience with debian packages but creating them properly is a pain and it really is annoying to add a new software source for every package that is not inside of the default repositories.
In addition to that it will not change the problems I have during the runtime since it will be compiled like every other program.

[blackhole89]

I have created documents even more than one but this did not improve anything, it seems to be a runtime dependency problem or an incompatible library version. But I don't know what is missing at all...

I just find it really weird that either of those things would result in it starting up and running without crashing, but failing in that peculiar way... can you post a screenshot of a state in which you expect to be able to enter text but can't? What if you put an .md file with some text in /home/noa/.local/share/notekit by hand (via the command line or otherwise)? Can you load and display that in notekit?

FATAL: config.json not found in note tree, and default_config.json not found in data tree!

That would happen if it can't actually read from the path that it otherwise would output as the "Resource path", which should contain a /data/default_config.json. It's a bit unfortunate that the way I set it up, in that scenario you do not actually get the initial blurb printing the paths it calculated. If you are feeling adventurous, you could edit mainwindow.cpp to move the block that says

	printf("== This is notekit, built at " __TIMESTAMP__ ". ==\n");
	printf("Detected paths:\n");
	printf("Config: %s\n",config_path.c_str());
	printf("Active notes path: %s\n",config["base_path"].asString().c_str());
	printf("Default notes path: %s\n",default_base_path.c_str());
	printf("Resource path: %s\n",data_path.c_str());
	printf("\n");

before the LoadConfig() that precedes it, and comment out the line with the "Active notes path" (because at that point that variable has not been loaded yet), but the logic should be something like:

• If $HOME is not set, it assumes that it's been compiled portably for a weird system and looks for everything relative to the current working directory. In that case, the data/ subfolder needs to exist wherever you are running it in.
• Otherwise, it goes through each entry in $XDG_DATA_DIRS and appends /notekit/, and returns the first that exists, so something like /usr/local/share/notekit/data or /usr/share/notekit/data has to be populated.

I also noticed that snap actually seems to include all the libraries specified, but downloads them from the ubuntu repository during the build process, so you only have to now which ubuntu packages your program depends on.

That's after the stage etc. changes you made, right? The tree before contained no libraries.

Have you tried running the prebuilt binary package that I link to in README.md? Does that work for you?

[noah1510]

Have you tried running the prebuilt binary package that I link to in README.md? Does that work for you?

I have but my libc is too old so I cannot run it.

That's after the stage etc. changes you made, right? The tree before contained no libraries.

Yes it is after I made the changes.

That would happen if it can't actually read from the path that it otherwise would output as the "Resource path", which should contain a /data/default_config.json...

I will look into it tomorrow and see if I can do something about it.

What if you put an .md file with some text in /home/noa/.local/share/notekit by hand (via the command line or otherwise)? Can you load and display that in notekit?

They actually contain some text but notekit simply does not display it.
I will share a screenshot tomorrow since it is quite late at the moment.

[noah1510]

I made some progress with the snap package by correcting the environment variable and changing to base20 (pacakges from ubuntu 20.04) causing the following error appear:

(process:22917): Gtk-WARNING **: 20:52:14.987: Locale not supported by C library.
	Using the fallback 'C' locale.
== This is notekit, built at Sun May 24 17:30:08 2020. ==
Detected paths:
Config: /home/noa/snap/notekit/x1/notekit
Active notes path: /home/noa/snap/notekit/x1/notekit
Default notes path: /home/noa/snap/notekit/x1/notekit
Resource path: /snap/notekit/current/usr/share/notekit

Fontconfig warning: "/etc/fonts/conf.avail/53-monospace-lcd-filter.conf", line 10: Having multiple values in <test> isn't supported and may not work as expected
color1

(notekit:22917): Gtk-WARNING **: 20:52:15.261: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/bullet-symbolic.svg.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Bail out! Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Aborted (core dumped)

Any idea what is missing or how to get it to work? Is a dependency missing?

[blackhole89]

I remember having to bundle, among others, a ridiculous number of default GTK icons in order for the Windows build to work (normally, those icons seem to be part of a default GTK installation, but of course none of that would be present on a Windows system). Maybe you are encountering a similar problem because the snap (which now bundles its own copy of GTK and may even be prevented from accessing the resources installed for the system one?) doesn't contain those.

What happens if you unpack it and try to run the binary directly now?

[noah1510]

What happens if you unpack it and try to run the binary directly now?

Well the same as usual, nothing is displayed and the whole program is really buggy and looks like this:

The content of dw.md is

test

rer3test2

When I draw lines they disappear as soon as I release my mouse button and those that stay don't stay for long and disappear when I draw a new line or switch the window.

Maybe you are encountering a similar problem because the snap (which now bundles its own copy of GTK and may even be prevented from accessing the resources installed for the system one?)

Any idea which packages contain the missing icons?

[blackhole89]

missing icons

Might be adwaita-icon-theme.

screenshot

That really looks quite curious... I can't help but notice that the colours in the sidebar also exhibit that black x5, red, black pattern instead of the default colour set which I've also seen in some screenshots people posted of Fedora builds; I still have no idea what gives rise to that, either.

The thing you said about drawing lines is not particularly unexpected considering everything else - for performance and layout reasons, when you draw on the note, the line you are drawing first gets rendered to a temporary layer on top of everything and only is inserted into an appropriate place in the document when you release the mouse/pen. So it seems like for some reason, the text editor widget is refusing to draw its contents (it still has contents, as the unrealize/destroy events in stdout evidence! These only get printed when a subwidget representing a block of drawings in the document is destroyed, e.g. because you opened a different document.)

Two things to check:

• What's your version of the libgtksourceviewmm-3.0-dev package? (Of gtkmm itself?)
• When you create a note and blindly type into it (click the area where it would appear, press some keys) and then close notekit, does the file on disk wind up containing anything? i.e. is it just a display problem or is abstract behaviour also broken?

[noah1510]

What's your version of the libgtksourceviewmm-3.0-dev package? (Of gtkmm itself?)

libgtksourceviewmm-3.0-dev is version 3.18.0-3, libgtkmm-3.0-dev is version 3.22.2-2 and libgtkmm-3.0-1v5 is also 3.22.2-2.

When you create a note and blindly type into it (click the area where it would appear, press some keys) and then close notekit, does the file on disk wind up containing anything? i.e. is it just a display problem or is abstract behaviour also broken?

Yes the file actually contains something the content is in dw.md because I blindly typed it.

Might be adwaita-icon-theme.

I tried adding the package to the build and stage dependencies but I does not change anything to help.
There might be some info hidden in the long list of warnings produced by the build process.

[blackhole89]

long list of warnings

Most of those are gtksourceviewmm internals and the rest seems fairly inconsequential...

versions

The only difference seems to be that I'm on 3.24 for gtkmm, but I thought I tested it on 3.22 systems before as well... it might be worth asking: are these also the versions of the packages that the binary is built against, if you use a snap-associated building process?

I'm fairly sure that the snap issues (icon files etc.) are orthogonal to the ones that you experience when you run the binary directly, and probably can be resolved by looking at how other Gtk+3 applications were packaged up as snaps (there might be more data you need to include for it to actually be able to find the icons you bundled). (From a quick search, could the "gnome-3-28" extension from their documentation be relevant? I see you commented it out in your copy. Alternatively, maybe this thing?)

I just pushed a commit that should remove all valgrind memcheck errors that notekit throws, if the build is correct. Could you merge that into your repository and see if running valgrind [path to notekit binary] outputs anything?

(edit: ...and, finally, another thing that might be worth trying: if you send me your binary, I can try and see what happens if I run it locally. It might tell us more if this is a problem with libraries, the system config or the build process, and if I get the same problem, I might be better equipped to debug it.)

[noah1510]

(edit: ...and, finally, another thing that might be worth trying: if you send me your binary, I can try and see what happens if I run it locally. It might tell us more if this is a problem with libraries, the system config or the build process, and if I get the same problem, I might be better equipped to debug it.)

Just use the binary produced by the latest build, the builds by github actions are basically identical to my local builds.

[noah1510]

The only difference seems to be that I'm on 3.24 for gtkmm, but I thought I tested it on 3.22 systems before as well... it might be worth asking: are these also the versions of the packages that the binary is built against, if you use a snap-associated building process?

Since I use the snap core20, snap builds against version 3.24 and also uses and bundles the latest libc.

and probably can be resolved by looking at how other Gtk+3 applications were packaged up as snaps (there might be more data you need to include for it to actually be able to find the icons you bundled)

I tried looking into how xournal++ creates their snaps but it still produces the same error.

(From a quick search, could the "gnome-3-28" extension from their documentation be relevant? I see you commented it out in your copy.

The problem is that the core20 is still in beta and extentions are not added at the moment so I had to comment it out to get the build going.

Alternatively, maybe this thing?

I thought that might be it but I could not add it as a dependency or use it...

[noah1510]

I just pushed a commit that should remove all valgrind memcheck errors that notekit throws, if the build is correct. Could you merge that into your repository and see if running valgrind [path to notekit binary] outputs anything?

running valgrind --leak-check=full [path to notekit binary] on the local build produced this as output

[blackhole89]

Just use the binary produced by the latest build, the builds by github actions are basically identical to my local builds.

Unpacked that into a fresh folder and ran it, it worked just fine for me...

valgrind output

The only problems there seem to be internal to Gtk, so unfortunately that's not pointing out any obvious problems.

Since I use the snap core20, snap builds against version 3.24 and also uses and bundles the latest libc.

You said earlier that in your containing system,

libgtkmm-3.0-dev is version 3.22.2-2 and libgtkmm-3.0-1v5 is also 3.22.2-2.

Could the problems when running the binary directly be caused by the version mismatch? After all, if I understand correctly, we haven't managed to run the snap itself with its bundled libraries yet, due to problems which are more likely than not unrelated (bundled icons and what-not).

What happens if you run it directly, but with LD_LIBRARY_PATH pointed at whatever directory the snap's bundled libraries wound up in? (/snap/notekit/x1/usr/lib/ or /snap/notekit/x1/usr/x86_64*/ or something?)

As another thing to try, people have reported many font-related issues. Those ought to have been fixed when I went to bundle the requisite fonts recently, but you never know... You could try and see if changing the font in data/stylesheet.css from "Bitstream Charter" to "serif" does something.

[noah1510]

Could the problems when running the binary directly be caused by the version mismatch? After all, if I understand correctly, we haven't managed to run the snap itself with its bundled libraries yet, due to problems which are more likely than not unrelated (bundled icons and what-not).

The local build running with my system dependencies is the one with the strange behavior, while the snap build won't even start due to missing icons, etc.
I have to separate builds, one I build in the repo folder and one produced by snap install in /snap/notekit/current with all the required libraries.

As another thing to try, people have reported many font-related issues. Those ought to have been fixed when I went to bundle the requisite fonts recently, but you never know... You could try and see if changing the font in data/stylesheet.css from "Bitstream Charter" to "serif" does something.

Doing this does not change the local build at all and the snap package still wont run properly.

Could the problems when running the binary directly be caused by the version mismatch?

I just tried using core18 to build notekit and added the gnome-3-28 extention but now I get the following error:

+ cd /snap/notekit/current/usr/share/notekit
+ ./notekit
== This is notekit, built at Tue May 26 07:31:02 2020. ==
Detected paths:
Config: /home/noa/snap/notekit/x5/.config/notekit
Active notes path: /home/noa/snap/current/.local/share/notekit
Default notes path: /home/noa/snap/notekit/x5/.local/share/notekit
Resource path: /home/noa/snap/notekit/x5/.local/share/notekit

terminate called after throwing an instance of 'Gtk::CssProviderError'
/snap/notekit/x5/usr/share/notekit/snap_launch_notekit.sh: line 6:  7383 Aborted                 (core dumped) ./notekit

The error is appears even if the working directory contains the data and sourceview files.
I don't know what causes this error. Any ideas?

[blackhole89]

This time it said Resource path: /home/noa/snap/notekit/x5/.local/share/notekit, which means that the data and sourceview directory need to exist in that folder, rather than the current working directory... (though it's odd that it would wind up using the same path as both the default notes path and the resource path; I might need to revisit the logic for computing those paths)

The local build running with my system dependencies is the one with the strange behavior, while the snap build won't even start due to missing icons, etc.

Oh, you mean you built it directly with cmake . and make against the containing system's libraries? I assumed from one of your earlier posts that you just unpacked the snap package and ran the binary in that directly from your containing system: you said

Running the executable directly using /snap/notekit/x1/usr/share/notekit/notekit (...) gets the program to launch but parts of the ui are missing and I cannot write stuff.

[noah1510]

Oh, you mean you built it directly with cmake . and make against the containing system's libraries? I assumed from one of your earlier posts that you just unpacked the snap package and ran the binary in that directly from your containing system: you said

I did both. Or rather installing a snap package means that it will be extracted into a folder.

This time it said Resource path: /home/noa/snap/notekit/x5/.local/share/notekit, which means that the data and sourceview directory need to exist in that folder, rather than the current working directory... (though it's odd that it would wind up using the same path as both the default notes path and the resource path; I might need to revisit the logic for computing those paths)

After copying the data and sourceview folder into that folder the programs runs 🥳.
Edit:
i am dumb, I had the wrong base_path in the config..
It runs but there are the same issues as my local build has 😢 ...
The UI looks more promising though:

long list of warnings
Most of those are gtksourceviewmm internals and the rest seems fairly inconsequential...

I also fixed most of the warning caused by your code, making it easier to actually spot something in case there is a problem.
Should I push those changes in a separate pull request or make it part of the snap package?

[noah1510]

(though it's odd that it would wind up using the same path as both the default notes path and the resource path; I might need to revisit the logic for computing those paths)

Could you consider making environment variables specific to notekit to add custom paths for data,notes and config?
I think this would also help I case someone wants to add flatpak or appimage support.

[blackhole89]

Well, the path used as a base path for notes is determined by config.js... I guess I could add support for explicit environment variables overriding the others, but this wouldn't solve the greater problem of no text showing up. I'm really at a loss as to what to do about the issue with text not being displayed, though, since I can't reproduce it on any system I have access to (Debian, some older Ubuntu, a variety of Linux Mints which seem to basically be Ubuntu). Can you confirm that if you download and run the continuous builds from Github that you pointed me at, you experience the same problem? At this point, I'm almost wondering if I can ask you to arrange for me to VNC in and try to debug it on your machine; there are probably a few more things I can test for if I can add some debug output in key places and actually poke at it in gdb or the like. Otherwise, a few other things:

• You aren't on a Wayland-based system, are you? I've never tested it on Wayland, so there are some potential sources of issues there (e.g. the transparent overlay I use to render the strokes currently being drawn might somehow wind up being rendered opaquely?). The overlay can probably be disabled safely by finding, in notebook.cpp, the line that says add_child_in_window(overlay,Gtk::TEXT_WINDOW_WIDGET,0,0); and commenting it out. This might be worth a try either way.
• I do make some text in the view invisible, namely markdown tokens like underscores. If this mechanism went haywire, it could probably make everything invisible (though you ought to at least still see a text input cursor). You can disable it by commenting out the line that says tag_hidden->property_invisible().set_value(true); in notebook.cpp.

I also fixed most of the warning caused by your code, making it easier to actually spot something in case there is a problem.
Should I push those changes in a separate pull request or make it part of the snap package?

Do please make a PR if it's not too much work (I might hand-sift through them a bit though; e.g. I would not remove the structured bindings just because some compilers still complain about them).

[noah1510]

I'm really at a loss as to what to do about the issue with text not being displayed, though, since I can't reproduce it on any system I have access to (Debian, some older Ubuntu, a variety of Linux Mints which seem to basically be Ubuntu).

If you want to reproduce the issue, building the snap package, installing it and then running notekit should start the program with the same issues I have.
The latest commit should basically build the package correctly, you might have to include some packages if they are missing.

Can you confirm that if you download and run the continuous builds from Github that you pointed me at, you experience the same problem?

Yes it the continuous build have the same problem, it really seems to be a runtime problem although I have no idea what is missing.
The output in the terminal when I run the continuous build is the following:

(notekit:387): dbind-WARNING **: 11:21:15.366: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
== This is notekit, built at Tue May 26 22:24:39 2020. ==
Detected paths:
Config: /home/noa/.config/notekit
Active notes path: /home/noa/.local/share/notekit
Default notes path: /home/noa/.local/share/notekit
Resource path: .

color1
unrealize event on 56385F32F2E0
destroy event on 56385F32F2E0

You aren't on a Wayland-based system, are you?

My DE is Mate so I am on X11.

[noah1510]

. The overlay can probably be disabled safely by finding, in notebook.cpp, the line that says add_child_in_window(overlay,Gtk::TEXT_WINDOW_WIDGET,0,0); and commenting it out. This might be worth a try either way.

This actually did it.
Now all the lines and text are displayed correctly 🎉

[noah1510]

The current snap build has one problem.
Every time a new document is opened or created, the whole program crashes with a segmentation fault.

Edit:
Despite this I published the snap to the snap store allowing others to download and test the package.
Like mentioned in the description the problem above still exists.

Edit2:
It seems like notekit uses the wrong resource path again, is it because the base_path inside of the config.json is empty?

[blackhole89]

This actually did it.
Now all the lines and text are displayed correctly

Well, this helps us pin down the issue, but I wouldn't say that leaving the overlay disabled is sustainable; for instance, I imagine that this means that you can't actually see strokes as you are drawing them. We need to find a different solution.

What happens if you reintroduce the add_child_in_window line, but right below it, you introduce a
overlay.override_background_color(Gdk::RGBA("rgba(0,0,0,0)"));? (I realise that this fn is deprecated, and they now want you to do this via CSS, but it's faster to test this way.)

If this doesn't work, then the next things to test for would be:

• is it the background of the overlay window that we see? i.e. does overlay.override_background_color(Gdk::RGBA("rgba(0,255,0,1)")); make it green?
• If not, does CNotebook::on_allocate get called? Does the overlay.get_window() check in it succeed? Does the surface created in it actually have an alpha channel, and is it initialised all transparent?)
• When does CNotebook::on_redraw_overlay get called? What's the state of vars such as overlay_image when it does?)

Every time a new document is opened or created, the whole program crashes with a segmentation fault.

Sorry, but this one's actually sort of on you :) One of the unsigneds introduced in CNotebook::on_deserialize meant that when str::find returned -1, this would wrap around to some positive value, eventually resulting in memory corruption instead of falling through to the "no more drawings to deserialize" behaviour. I probably should've spotted this when merging (and generally written the deserialization in a more safe manner; the same bug could be set off if one were to load a document in which a ![](nk:...) block were garbled for any reason).

Committed a quick fix, anyway.

It seems like notekit uses the wrong resource path again, is it because the base_path inside of the config.json is empty?

No, base_path is the path that the notes (not the resources) go in. The resource path should come from $XDG_DATA_DIRS+/notekit or else /usr/local/share/notekit:/usr/share/notekit, unless $HOME is not set, in which case it always is the current working directory.

I'm glad it looks like we're making progress, anyway. Thanks for putting in all the effort to get this to work!

[noah1510]

I probably should've spotted this when merging

Glad you found the issue and fixed it again.
However the program now crashes with a segmentation fault when I try to draw, although typing seems to work just fine.

The snap build crashes just after creating a new file but after opening the program again I can type text into that file without a problem.
However this does not happen on my local build...

Edit:
It seems like the snap build does not crash because of the creating the new file but while saving the current file.

the same bug could be set off if one were to load a document in which a block were garbled for any reason)

Yeah I also had that for a while, after deleting the files it worked again.

No, base_path is the path that the notes (not the resources) go in. The resource path should come from $XDG_DATA_DIRS+/notekit or else /usr/local/share/notekit:/usr/share/notekit, unless $HOME is not set, in which case it always is the current working directory.

I found the cause for this.
The desktop-runner seems to also use the XDG_DATA_DIRS and add new paths to it.
But it gets called after snap sets up the environment, causing the wrong folder to be in the first place.
Setting the environment variables in the script seems to fix this problem.

then the next things to test for would be

I will look into them, it is just annoying that a clean build of the snap package take ~10 min because of the long list of dependencies so testing if the snap works correctly is a slow process but it really looks like there is some serious progress.
The newest version I just uploaded should run just fine with the problems mentioned above.
In other words:

• You have to restart the program after creating a new file
• You cannot draw

[noah1510]

overlay.override_background_color(Gdk::RGBA("rgba(0,0,0,0)"));
overlay.override_background_color(Gdk::RGBA("rgba(0,255,0,1)"));

Does not do anything and nothing is green but the lines and text are gone..

If not, does CNotebook::on_allocate get called?

Yes it gets called

Does the overlay.get_window() check in it succeed?

No it doesn't. This might be the problem or should it fail?

[blackhole89]

No it doesn't. This might be the problem or should it fail?

If get_window() never succeeds, that would do it; we would wind up never creating a surface to draw to. It can however fail the first time on_allocate is called, if something causes it being called before the whole chain of widgets leading up to it has been realised. (That's why the check is there.)

The add_child_in_window(overlay,Gtk::TEXT_WINDOW_WIDGET,0,0); is _un_commented, right? If it's commented out, it would be natural for get_window to always fail, and

However the program now crashes with a segmentation fault when I try to draw, although typing seems to work just fine.

...for this crash to occur, because on_motion_notify assumes that the widget chain is ready and it is okay to draw to overlay_image.

It seems like the snap build does not crash because of the creating the new file but while saving the current file.

That's curious. Is there any indication of where exactly it crashes? (Can you compile with -g and get a stack trace?) Does the file on disk wind up getting updated, or does it crash without modifying it? I'm thinking it could be due to the snap not having write permissions (this certainly at least seems to happen with AppImages a lot), or maybe another unsigned-related issue.

(I just realised that saving a document requires write permissions to the current working directory, which almost certainly is a bad idea. I will push some better logic for this soon edit: done.)

[noah1510]

(I just realised that saving a document requires write permissions to the current working directory, which almost certainly is a bad idea. I will push some better logic for this soon.)

This should be the cause of the crash, the program has the correct write permissions to the location where the files are stored (it should have them since this is the virtual home folder for that specify snap package it would be weird if id could not write into it).
I will merge and test your change tomorrow.
Edit:
It was the problem, saving files now works without a problem.

The add_child_in_window(overlay,Gtk::TEXT_WINDOW_WIDGET,0,0); is _un_commented, right? If it's commented out, it would be natural for get_window to always fail, and

No it is not commented out any more.
add_child_in_window(overlay,Gtk::TEXT_WINDOW_WIDGET,0,0); is being called but this jusst causes the program to not display anything anymore.

[noah1510]

When does CNotebook::on_redraw_overlay get called? What's the state of vars such as overlay_image when it does?)

It gets called and overlay_image seems to be a valid pointer.
It seems like i and end are almost identical, the only differences are dummy 3,4 and 9, all other dummys are identical (dummy 0-14).
Since I have no idea what the values they have actually mean, here are the screenshots:

Content of iterators:

Content of this / overlay_image:

Content of rect and ctx:

I hope this helps you figure out what is going wrong.

I think we need to open a separate issue for this, since it is not snap related but seems to be an issue with ubuntu 18.04.
I will create the pull request for the snap build config since it looks like there are no problems specific to the snap build any more.

[blackhole89]

I really don't think it's as simple as being an Ubuntu 18.04 problem; I just tested the linux-latest.zip build on a fairly fresh Linux Mint 19 Xfce4 setup (which appears to be based on Ubuntu xenial, and the Gtk packages seem to be coming out straight of Ubuntu's repositories) and it worked just fine. (Tested both xfwm4 and xmonad for WMs, to make sure it couldn't be a compositing-related issue.)

I'll try to see if I can gleam something from the screenshots you posted; my best guess is still that it must be a theming issue of sorts forcing an opaque background onto (some element of) the Gtk::DrawingArea holding the strokes currently being drawn, which really should be transparent.

If you have Gtk Inspector, can you see if there is anything interesting in the properties of this object?

In particular, I'm interested in these:

[noah1510]

I really don't think it's as simple as being an Ubuntu 18.04 problem; I just tested the linux-latest.zip and it worked just fine. (Tested both xfwm4 and xmonad for WMs, to make sure it couldn't be a compositing-related issue.)

Did you try to run the snap package?
The package in beta channel is the one where the overly is not added and the one on the edge channel should have the overlay added again.
I would really appreciate it if you could also test that version because it bundles everything including the gnome desktop so it should allow you to actually reproduce the issue.

Could it be a problem caused by the newer linux kernel versions at the moment I am using kernel 5.6.14 (I just downloaded 5.6.15 and will try again after a reboot) (I use mainline to install the latest kernel from the ubuntu mainline kernels) or the graphics driver (I use the oibaf ppa to get my mesa and drm packages which is a daily build of the mesa git repository version 20.2~git2005281930.f0c102~oibaf~b).
My DE is Mate but that should not be the cause of the problem.

build on a fairly fresh Linux Mint 19 Xfce4 setup (which appears to be based on Ubuntu xenial, and the Gtk packages seem to be coming out straight of Ubuntu's repositories)

All linux mint 19.x variants are based on ubuntu 18.04 (bionic) and the only difference is that they have a different DE.

If you have Gtk Inspector, can you see if there is anything interesting in the properties of this object?

I did but it looks the same.
The only difference was the border-bottom-color which is probably because I use a dark theme so it was a darker color.

[blackhole89]

MATE

I'm also using MATE (on Debian). Can you try seeing if changing your Gtk theme (either for the whole desktop or just for Notekit, using Gtk Inspector's "Visual" tab) does anything about the opaque overlay problem for you?

Did you try to run the snap package?
The package in beta channel is the one where the overly is not added and the one on the edge channel should have the overlay added again.
I would really appreciate it if you could also test that version because it bundles everything including the gnome desktop so it should allow you to actually reproduce the issue.

I just ran it (the one on the edge channel you linked before) on my own, that is, Debian testing, machine. Result:

That is, rendering works, but I'm getting the font problem that some other people have reported (!?). Some search revealed that this may have to do with type1 support being dropped in Pango 1.44. (cf. #30) I have replaced the bundled fonts with OpenType versions, so it would be good if you could rebuild it with those (I don't see an easy way to edit the VFSes of installed snaps...) to see if it helps. (edit: confirmed it does, with latest commit)

Also, there is a really weird issue in that the stroke simplification heuristic I am using is going haywire and stripping way too many control points, resulting in a jagged appearance. This does not happen in my local build, and is completely bizarre because CStroke::Simplify is a very straightforward and self-contained function that makes no API calls. I'm also getting repeated instances of
(notekit:26722): Gdk-CRITICAL **: 16:34:08.483: gdk_device_get_axis_use: assertion 'index_ < device->axes->len' failed
in the output. I'm wondering if something about the event handling model changed between my current Gtk version and 3.28... maybe it's no longer safe to have gdk_window_set_event_compression true for mouse events at all...?

[noah1510]

---

I'm also using MATE (on Debian). Can you try seeing if changing your Gtk theme (either for the whole desktop or just for Notekit, using Gtk Inspector's "Visual" tab) does anything about the opaque overlay problem for you?

It changes nothing, the theme changed but the issue is still there.

---

I have replaced the bundled fonts with OpenType versions, so it would be good if you could rebuild it with those

I merged and recompiled the snap package with your changes.
Edit:
It compiles that is all I can say for now

---

maybe it's no longer safe to have gdk_window_set_event_compression true for mouse events at all...?

From the GDK3 Reference

Some types of applications, e.g. paint programs, need to see all motion events and will benefit from turning off event compression.
By default, event compression is enabled.

Looks like it is better to turn it off, doesn't it?

---

(notekit:26722): Gdk-CRITICAL **: 16:34:08.483: gdk_device_get_axis_use: assertion 'index_ < device->axes->len' failed

This looks like for some reason the index that would be returned is larger than the axis of the device.
Could it be that the device has a problem during initilization causing the axis to be too small?

---

This does not happen in my local build, and is completely bizarre because CStroke::Simplify is a very straightforward and self-contained function that makes no API calls.

This could actually be part of the problem.
Because when I draw a line I can see it until I release the mouse button.
Or it stays visible for a short while but after drawing a few extra lines all lines vanish and do not reappeare after reloading the document.
Edit:
Every line I draw vanishes when I draw over another line even it is not visible, causing all drawn lines to vanish too.

[blackhole89]

Looks like it is better to turn it off, doesn't it?

At least on my system, leaving it off actually causes event delivery to be a little laggy, so you get more of a perceivable delay between moving your pen and actually seeing the strokes appear. I always find this to be fairly unpleasant in tablet applications, so instead I have some code that only switches it on temporarily when it is inferred to be necessary (because the user is moving the pen fast with high curvature, e.g. drawing loops).

This looks like for some reason the index that would be returned is larger than the axis of the device.

Well yeah, that's what it says. In general, for tablet devices, pressure is treated as an additional "axis"; what this seems to suggest is that Notekit somehow winds up querying pressure on a device that does not support it. (...so maybe Gdk for some reason switches to reporting a mouse motion that was attributed to a device with pressure data at first as if it came from a different device mid-stroke?) I'll have to look into this more closely.

This could actually be part of the problem.
Because when I draw a line I can see it until I release the mouse button.

No, that's exactly what we would expect to see if the overlay is for some reason made opaque.

When you start drawing a line/stroke in Notekit, the stroke you are currently drawing is rendered on the overlay only. This is because until we know what parts of the document the stroke covers, we can't actually infer where in the document the resulting drawing should be inserted, or if it should be merged with some existing drawing because they overlap. Tentatively trying to figure out and reflowing the whole contents of the text area every time you move the pen would be very slow, so this computation ("committing the stroke") only happens when you release the mouse button, thus finishing drawing the stroke. At that point, Notekit determines where in the document the stroke should go, either generates a new CBoundDrawing at the location or identifies an appropriate existing one, adds the stroke into it and erases it from the overlay. Since the overlay in your case is opaque rather than transparent, this means that to you the stroke appears to "disappear" - all you see is the overlay in front of everything, which is now empty again.

It compiles that is all I can say for now

Thanks. I updated ("refreshed"?) the snap and it seems to work now.

By the way, currently it seems that every snap update results in old notes being "lost" (because they go into $HOME/snap/notekit/$VERSION/..., and $VERSION got incremented). Is there any way to prevent this? (Can the default notes path be made to be somewhere other than $HOME/snap/...? The direct build should default to $HOME/.local/share/notekit, so it would be good if the snap used the same folder.)

At this point it would even help if we could find someone else reporting the same problem, just so we can get an idea of what the preconditions for it to occur are.

Some more things to test:

• What happens if you always return immediately from CNotebook::on_redraw_overlay? (add a return true at the top) This would help us rule out that the bug pertains to the drawing code per se. If you then still see no text, it does mean there is a difference between your system and mine in how a freshly created Gtk DrawingArea is rendered.
• Complete shot in the dark: add an overlay.set_app_paintable()after add_child_in_window. This shouldn't be necessary for DrawingAreas...

[noah1510]

By the way, currently it seems that every snap update results in old notes being "lost" (because they go into $HOME/snap/notekit/$VERSION/..., and $VERSION got incremented). Is there any way to prevent this? (Can the default notes path be made to be somewhere other than $HOME/snap/...? The direct build should default to $HOME/.local/share/notekit, so it would be good if the snap used the same folder.)

I used the SNAP_USER environment variable, which is a subfolder of the home specific for each installed version of the snap which caused some problems.
However I switched to SNAP_USER_COMMON which is a folder which is used by all versions of the snap, so no matter which version is installed it will read and write the data form/in the same folder.

Some more things to test...

Both ideas do not change anything so is really seems to be a problem with the rendering.
Calling overlay.set_visible(false); or overlay.set_child_visible(false); inside the on_redraw_overlay function makes the drawings visible but (obviously) you cannot see what you draw.

I noticed that inside the GDK_DEBUG the overlay has an opacity property but it only handles the opacity of the "pen" so setting it to 0 only makes the lines I draw invisible.

This is a video where you can observe what it really looks like and a lot of details from GDK_DEBUG

[blackhole89]

All these properties look the same for me, except that the drawingArea for you has name "drawing", which it doesn't for me (and I never set it). Did you set that yourself or does that point at some difference in the libraries?

setting overlay opacity only affects opacity of lines you draw

That's curious. This suggests that the solid background we are seeing might not in fact come from the DrawingArea widget.

In the Gtk Inspector CSS tab, can you try adding the following code?

text { background-color: #ff0000 }

(Also worth trying: #mainView {...}, #mainViewScroll {...})

If you actually see the background turning red with any of those, something like the following might be the case: the sourceview widget's text rendering code assumes that because of the overlay in front of it, it is actually covered, and hence its signal_draw receives a Cairo context whose clipping mask does not include any of the area that should be visible, and all text rendering gets optimised away.

[noah1510]

#mainView {...}

This actually made the whole area red, the other two don't change the look of the UI at all.

All these properties look the same for me, except that the drawingArea for you has name "drawing", which it doesn't for me (and I never set it). Did you set that yourself or does that point at some difference in the libraries?

I set it myself to change the css properties of that object but that did not change anything.

[blackhole89]

Okay, that does sound like it might well be the clipping thing I hypothesised above. I'll have to look into how Gtk determines a widget's clip area and if there have been any changes to it recently; it might also be worth trying to attach a handler to the sourceview's signal_draw and seeing when it gets called and what you get from calling cairo_copy_clip_rectangle_list...

[noah1510]

The problem seems to be a problem with linux mint mate.
When I use plasma (also installed on the same machine) there are no problems at all and the lines I draw are very smooth.
On mate I still have the same problem which is really weird.

So it really seems to be a problem with the specific DE but some more testing is needed to confirm this issue.

[blackhole89]

Yeah, it's made more weird by the circumstance that it doesn't happen on the Linux Mint Mate instances that I have access to. I can only assume that it's some recent change to the Gtk event and/or drawing model.

I'm currently fairly swamped with some real-life commitments, but I'm intending to give you some more things to test after I'm done with those. I'm thinking that based on our previous finding, it's quite likely that at least the problem with the text not being drawn at all is a consequence of some problem with the visibility computation - specifically, that on your system the text display of the GtkSourceView believes that it is completely covered by the drawing overlay and therefore never needs to redraw itself at all (whereas in reality, it does because the overlay is translucent).