GNOME Bugzilla – Bug 608311
Auto-selection of newly created note's contents is broken in multi-byte language
Last modified: 2010-03-22 15:06:24 UTC
Created attachment 152466 [details] Auto selecting content behaviors in different languages. When the system language is not English, Chinese for instance, GNote does not select the exact "content" when creaing a new note. The screenshot in the attachment shows the problem. I looked into the problem and found that there is a bug in src/notemanager.cpp in function Note::Ptr NoteManager::create_new_note (std::string title, const std::string & guid). The length of the header is calculated by header.length(). This has no problem in English since each English letter takes up exactly one byte. However, each Chinese character is 3 bytes in utf8. The resulting offset will run into the content where there are exactly as many characters before the selection region as the number of bytes in the header. My solution is to change the method call to get_iter_at_line_offset since the header is identified by the line number. I set the line number of the selection region to be the 3rd line so that it behaves like it did in English. If change the number to 3 (select from the 4th line), it will select the exact content (instead of one line before the content) in all languages. The following is my patch and I hope it solves the problem. --- notemanager.cpp.old 2010-01-28 14:46:35.946560064 +0800 +++ notemanager.cpp 2010-01-28 14:45:02.383561588 +0800 @@ -605,7 +605,7 @@ // "Describe..." text so typing will overwrite the body text, //NoteBuffer Glib::RefPtr<Gtk::TextBuffer> buffer = new_note->get_buffer(); - Gtk::TextIter iter = buffer->get_iter_at_offset(header.size()); + Gtk::TextIter iter = buffer->get_iter_at_line_offset(2,0); buffer->move_mark (buffer->get_selection_bound(), iter); buffer->move_mark (buffer->get_insert(), buffer->end());
Declare "header" as a Glib::ustring instead of a std::string. In that case .size() will return the # of char not the # of bytes. It is far better than using get_iter_at_line_offset() with a hardcoded value.
Created attachment 156742 [details] [review] Proposed fix
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.