Re: Changing font of GtkSourceView changes font of GtkSourceMap
Still looking for some help on this. Thank you. On Mon, Feb 11, 2019 at 9:11 AM Mitko Haralanov wrote: > > Any help would be appreciated. > > Thank you. > > On Tue, Feb 5, 2019 at 2:28 PM Mitko Haralanov wrote: > > > > Forwarding to gtk-app-devel since there appears to be much more activity > > related to GtkSourceView. > > > > -- Forwarded message - > > From: Mitko Haralanov > > Date: Tue, Feb 5, 2019, 13:42 > > Subject: Changing font of GtkSourceView changes font of GtkSourceMap > > To: > > > > > > I can't figure out how to change the font of GtkSourceView and > > GtkSourceMap in a reasonable way. > > > > According to the documentation, the View and the Map should be using > > the same font but with the Map using a font size of 1pt. To me this > > implies that when I change the font of the TextBuffer of the View > > using tags, I can copy the PangoFontDescription to a new object, > > change the font size to 1pt and set the new PangoFontDescription as > > the "font-desc" property of the Map. > > > > In practice, however, the Map always has the exact same font size as > > the View. No matter what I do, I can't seem to change the font size of > > the Map to 1pt, unless I change the font size of the View to 1pt, as > > well. > > > > What is the correct processes for changing the font size of both the > > View and the Map? > > > > Thank you, > > - Mitko ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: liststore issue 2 - which 'path' comes from signal
On 02/27/2019 06:51 AM, Mike Martin via gtk-app-devel-list wrote: according to the docs the path reference is edited signal = path editing-started = path These above two look like something a treeview uses changed = path_string And this one I assume to be coming from a CellRendererCombo? So this would actually be describing the combo renderer's model path. Which is not necessarily the same as the TreeView model. which I thought meant that path would be a treepath (ie: an object) and path_string would be a reference to the row (an integer in the case of a simple liststore) no, paths are not objects, they are integers telling which row was affected However in all three cases the value is the same ie: an integer, not an object Can anyone clarify this That is what I found. thanks Mike ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: liststore issue 1 - iter points to wrong row after sort of column with cellrenderercombo
On 02/27/2019 06:46 AM, Mike Martin via gtk-app-devel-list wrote: I have come across an issue where the iter points to the wrong row on edited signal after sorting the column (via clicking header). This only happens with edited signal and not editing-started (which is correct) I don't understand all the nuances, but I learned to get an iter from the path and then change the model according to the iter. It seems after the model changes (with sort enabled), all the paths are wrong but the iters seem to be right. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
liststore issue 2 - which 'path' comes from signal
according to the docs the path reference is edited signal = path editing-started = path changed = path_string which I thought meant that path would be a treepath (ie: an object) and path_string would be a reference to the row (an integer in the case of a simple liststore) However in all three cases the value is the same ie: an integer, not an object Can anyone clarify this thanks Mike ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
liststore issue 1 - iter points to wrong row after sort of column with cellrenderercombo
I have come across an issue where the iter points to the wrong row on edited signal after sorting the column (via clicking header). This only happens with edited signal and not editing-started (which is correct) The edited iter is obtained via treeview->get_model->get_iter_from_string($path_str), which is obtained from the path variable given by signal This is pre sort (and correct) Gtk3::CellRendererCombo=HASH(0x55938bc4f418)0 /mnt/progs/programs/DS9a-- array from edited signal Gtk3::TreeIter=SCALAR(0x55938b3dc050) -- iter from editing-started signal Gtk3::TreeIter=SCALAR(0x55938bc46d50)-- iter from edited signal /mnt/progs/programs/DS9ads9_101_envs.mp41 --result using iter from editing-started signal /mnt/progs/programs/DS9ads9_101_envs.mp41 --result using iter from edited signal This is post sort (and wrong) Gtk3::CellRendererCombo=HASH(0x55938bc4f418)0 /mnt/progs/programs/DS9b-- array from edited signal 2836 Gtk3::TreeIter=SCALAR(0x55938b44c938) -- iter from editing-started signal 2836a Gtk3::TreeIter=SCALAR(0x55938bc46d68) -- iter from edited signal /mnt/progs/programs/DS9bds9_102_envs.mp42--result using iter from editing-started signal and is correct /mnt/progs/programs/DS9ds9_103_envs.mp43 --result using iter from edited signal and is wrong row Any ideas why this is happening? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
