tomboy-ng -o file.note -- access violation about tomboy-ng

[davidbannon]

OK, been digging.
Your access violation is because you are opening a txt file (?) and tomboy-ng assumes its getting a Tomboy XML note and DOES NOT CHECK ! Sigh.
The Peeks hae been with us from the early days, annoying but thats all.
The GTK Assertion is more of a problem. I have traced it down into (LCL) gtk2proc.inc, line number 7451,
if gtk_selection_convert(ClipboardWidget, ClipboardTypeAtoms[ClipboardType],
FormatID, TimeID)<>GdkFalse
Its calling a GTK Library after that so my debugger does not follow into there. And I don't seem to be able to rebuild the pp file with extra debugging.

Anyway, the immediate action seems to be -

1. Fix tomboy-ng so it does not get unwell when passed an unexpected file. Ideally, it should test for a Tomboy XML, then RTF, and (superficially) a TXT file. And load if possible. Complain if not.
   Might, sensibly be a new unit.

2. We treat the noise we see on the command line as just that, noise to be ignored for now, ultimatly to be fixed. But, unless indications change, not high priority.

[davidbannon]

This ticket may be a good place to socialise the SingleNoteMode. I think it needs a bit more planning than I have put into it. Should do better...

SingleNoeMode is intended to allow the user to open a solitary note that is not located in their normal note directory. It directly opens and displays that note without any other tomboy-ng infrastructure visible. So, no TrayIcon, no note history, no search facilities etc. It opens independently of an existing instance of tomboy-ng running normally. There is no communication possible between instances.

In SingleNoteMode, tomboy-ng "might" look at its config for font sizes etc. What happens if no config there yet ?

In single note mode, you cannot -

1. Search other notes.
2. Use notebooks
3. Sync
4. Separately start up a normal tomboy-ng instance. Thats unfortunate.

SingleNoteMode saves back to where it found its note. Not to the general note directory. Maybe a option to either copy or move the note to the repo ? Whats the use case ?

tomboy-ng, comes up in single note mode when its started with a "-o Filename" or "--open-note Filename" option. Filename can include a path.
If the path is invalid, generate an error and exit.
If the filename does not exist, open a new Tomboy XML file by that name.
If the file exists, text if its Tomboy XML, if so open.
Else test if its RTF, if so, open.
Else test it it looks a bit like text, if so, open.
Else, print error and exit.

Question
If we allow someone to open a text file, should we then allow them to make markup changes, Bold, highlight etc. That they cannot then save back into a plain text file ? Force it to become a .note file in same location perhaps ?

Hmm, not the trivial task I thought it was.

[davidbannon]

OK, does, pretty much do that now.
To my surprise, same code will load plain text or rtf ('cos rtf is kmemo's underlying dialect I guess).
It always converts incoming content to Tomboy XML and saves it with a .note extension so no overwrite (unless the plain text was already .note ?).
Checks path if one is given and if the filename nominated does not exist, it creates a new note.
Passed rough tests but has not yet been tested on Mac or Windows.
Davo

[benjbrandall]

Unfortunately I've pulled the latest commit and still getting access violations:

benjamin@debian:~/Apps/tomboy-latest/tomboy-ng/tomboy-ng$ ./tomboy-ng -o /home/benjamin/Dev/codeblocks/Fun/347037D3-4D43-435C-8458-BD4C5B1E33BF.note
Peek !!!
Peek !!!
Peek !!!
Peek !!!
Peek !!!

(tomboy-ng:15706): Gtk-CRITICAL **: 10:41:20.709: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed
Decided the file is of type tomboy
TApplication.HandleException Access violation
Stack trace:
$000000000065F6A3
$000000000042E7D6
$000000000042123F
$00000000004BFA2D
$0000000000430872
$00000000004CA8F8
$00000000004BD751
$00000000004BD681
$0000000000433CF9
$00000000004BBB07
$00000000004D41EC
$00000000004D1DDE
$000000000042E22B
$000000000043318C
$0000000000434261
$0000000000445BF9
$000000000042E7D6

And a different stack trace when creating a new note using -o:

benjamin@debian:~/Apps/tomboy-latest/tomboy-ng/tomboy-ng$ ./tomboy-ng -o /home/benjamin/Dev/testnote.note
Peek !!!
Peek !!!
Peek !!!
Peek !!!
Peek !!!

(tomboy-ng:15728): Gtk-CRITICAL **: 10:42:18.798: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed
Decided the file is of type new
TApplication.HandleException Access violation
Stack trace:
$000000000065F6A3
$00000000005D6B69
$00000000005507B3
$00007FA084678B73

...Which is the same if I try to open Tomboy's Notes.txt in the source:

benjamin@debian:~/Apps/tomboy-latest/tomboy-ng/tomboy-ng$ ./tomboy-ng -o Notes.txt
Peek !!!
Peek !!!
Peek !!!
Peek !!!
Peek !!!

(tomboy-ng:15608): Gtk-CRITICAL **: 10:39:30.932: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed
Decided the file is of type text
Peek !!!
TApplication.HandleException Access violation
Stack trace:
$000000000065F6A3
$00000000005D6B69
$00000000005507B3
$00007F28AA508B73

It's worth mentioning that everything works fine after dismissing the Access Violation, but it does seem to mess with the UI:

[davidbannon]

OK, I have this one at last. Its caused by calling the code that marks links to other notes. In single note mode that does not make sense anyway, so I now don't call it at all in single note mode.
(does show up a flaw in my testing, I always run with links turned off and did not think to turn it one in testing phase.)
See this fixed in v0.16 !