Re: Using different signals depending on which row of of a treeview
On 04/29/2019 10:36 AM, Mike Martin via gtk-app-devel-list wrote: Has anyone done anything like this? I haven't, but you are welcome to my simple Glade mockup: 1 one 2 two 3 three text True False False combo False True False toggle False False True False True True tree_model column True 1 0 True combo_model 1 2 0 3 3 Basically the idea is that I push multiple renderers into a treeview column , then depending on the row hide/show the appropriate renderer (text, combo, toggle) So go ahead and add three different renderers, and use row values to set them visible or invisible. In this case we have three different column/row cells to set each widget visible. Then call the appropriate signal_connect (edited, changed, toggled) You can't really generate a signal on an invisible renderer, can you? ___ 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: Setting the scroll position of a GtkTextView in GtkScrolledWindow after render
On 04/08/2019 09:07 AM, Andri Möll via gtk-app-devel-list wrote: Hey, I can't figure out if it's me or something's amiss. I'm trying to set the scroll position after rendering a GtkTextView in a GtkScrolledWindow, but it's reset to a different value, if it works at all. I've so far tried to set the vertical adjustment value both after GtkScrolledWindow is mapped or its child (GtkTextView) size-allocated. When using a GtkListBox instead of a GtkTextView and setting the adjustment's value on "size-allocate", it works. No such luck with a GtkTextView, however. The peculiar thing with the GtkTextView is, while the adjustment reports its upper bound to be, for example, 588 and its value 0, immediately after setting it to 493, it reports its value as 11. I figure "size-allocate" is still the wrong event to use here given the adjustment is in flux. What would the right path be to consistently set the scroll position after the first render, and later, after resetting the GtkTextView's buffer? You probably are affected by the same problem as https://stackoverflow.com/questions/48934458/gtk-sourceview-scroll-to-mark-not-working. Basically, you need to add a timeout (glib_idle_add or so) to allow all render calculations to be done. Reuben ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Problem with grids and items spanning more than one column
On 04/02/2019 05:09 AM, Mike Martin via gtk-app-devel-list wrote: I am using an embedded Gtk grid within a grid , which contains numerous widgets However if I have a widget that spans more than one column it messes up the layout of all other widgets , which seem to position themseleves randomly along the width of this widget, causing horribly jagged widget placement Has anyone had this and come up with a solution Could you post an example? Post the example inline, because attachments are scrubbed. Row 1 Liststore spanning multiple columns Row 2 liststore spanning 1 column and 2 rows , textview , then two buttons the textview should line up on the right with the liststore in row 1 ___ 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: ANNOUNCE: Phasing out GTK mailing lists and move to Discord
RIP gtk-app-devel. :'( I hope this discourse thing succeeds. Personally I find it just another awkward, cumbersome run of the mill QA site. The mailing list should be preserved. But what do I know? I've only seen about 90% of these migrations to forum like sites lose users and community involvement over the past 20 years. Here's to hoping that gtk-app-devel-list will be one of the 10%. I will probably not participate in Discourse. I posted on the 'hello' page just to get the feel of how Discourse works, but found nothing to make me a Discourse type of person. I check StackOverflow on a regular basis, but I get rewarded there. Discourse has no reward feature and I find it rather impersonal compared to email. The mailing list felt like a community, not a QA site. Exactly what Discourse does that bug reports on Gitlab and/or StackOverflow haven't covered, I am not sure. Fragmentation, maybe? What is the technological hold-up to doing both? Listserves are no cost simple implementations that should be able to mirror posts from discourse to the existing list and vice-versa. That would seem to be the way to go until you have some assurance that discourse will preserve community involvement instead of just doing it on hope. I originally thought I would participate on Discourse via email, then email got discouraged in favor of the web UI. I don't have that much answers, and neither do I have a lot of questions. Therefore I will just quietly fade away... Reuben ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Changing font of GtkSourceView changes font of GtkSourceMap
I filed the following bug: https://gitlab.gnome.org/GNOME/gtksourceview/issues/41, which promptly got close as "expected behavior". Apparently, you'd either have to use CSS or install a new font map for the GtkSourceMap. Sure is disappointingly helpful. I can't figure out the connection code between the FontMap and the SourceMap. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Fwd: Re: Changing font of GtkSourceView changes font of GtkSourceMap
I forgot to cc the list.
On 03/01/2019 03:23 PM, Mitko Haralanov wrote:
Thanks for the example.
I modified it to illustrate the behavior:
It verily looks like a bug to me. I can't figure out a way to work
around this either.
import gi
gi.require_version('GtkSource', '3.0')
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, GtkSource, GObject, Pango
def set_font(button, view, map, tag):
font_name = button.get_font_name()
font = Pango.font_description_from_string(font_name)
map_font = font.copy()
map_font.set_size(1*Pango.SCALE)
tag.set_property("font-desc", font)
buffer = view.get_buffer()
buffer.apply_tag(tag, buffer.get_start_iter(), buffer.get_end_iter())
map.set_property("font-desc", map_font)
class GUI:
def __init__(self):
GObject.type_register(GtkSource.View)
window = Gtk.Window()
window.connect('destroy', self.on_window_destroy)
box = Gtk.VBox()
window.add(box)
fontchooser = Gtk.FontButton()
box.pack_start(fontchooser, False, True, 0)
pane = Gtk.Paned(orientation=Gtk.Orientation.HORIZONTAL)
box.pack_start(pane, True, True, 0)
s_view = GtkSource.View()
buffer = s_view.get_buffer()
with open("/usr/share/doc/glade/README", 'r') as fd:
buffer.set_text(fd.read())
tag = buffer.create_tag("buffer-font")
pane.pack1(s_view, True, False)
s_map = GtkSource.Map()
s_map.set_view(s_view)
pane.pack2(s_map, True, False)
fontchooser.connect("font-set", set_font, s_view, s_map, tag)
window.show_all()
def on_window_destroy(self, window):
Gtk.main_quit()
if __name__ == "__main__":
app = GUI()
Gtk.main()
Give it try and change the font of the view. You'll see that the font
of the map changes to the same font as the view, including *the same
size*.
Thank you.
On Thu, Feb 28, 2019 at 8:47 AM Reuben Rissler wrote:
I am not sure if this helps any:
#!/usr/bin/env python
import gi
gi.require_version('GtkSource', '3.0')
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, GtkSource, GObject, Pango
class GUI:
def __init__(self):
GObject.type_register(GtkSource.View)
window = Gtk.Window()
window.connect('destroy', self.on_window_destroy)
pane = Gtk.Paned(orientation = Gtk.Orientation.HORIZONTAL)
window.add(pane)
s_view = GtkSource.View()
pane.pack1(s_view)
s_map = GtkSource.Map()
s_map.set_view(s_view)
pane.pack2(s_map)
s_map.set_property('font-desc',
Pango.font_description_from_string("Sans 3"))
window.show_all()
def on_window_destroy(self, window):
Gtk.main_quit()
if __name__ == "__main__":
app = GUI()
Gtk.main()
On 02/27/2019 12:36 PM, Mitko Haralanov via gtk-app-devel-list wrote:
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
___
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: Changing font of GtkSourceView changes font of GtkSourceMap
I am not sure if this helps any:
#!/usr/bin/env python
import gi
gi.require_version('GtkSource', '3.0')
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, GtkSource, GObject, Pango
class GUI:
def __init__(self):
GObject.type_register(GtkSource.View)
window = Gtk.Window()
window.connect('destroy', self.on_window_destroy)
pane = Gtk.Paned(orientation = Gtk.Orientation.HORIZONTAL)
window.add(pane)
s_view = GtkSource.View()
pane.pack1(s_view)
s_map = GtkSource.Map()
s_map.set_view(s_view)
pane.pack2(s_map)
s_map.set_property('font-desc',
Pango.font_description_from_string("Sans 3"))
window.show_all()
def on_window_destroy(self, window):
Gtk.main_quit()
if __name__ == "__main__":
app = GUI()
Gtk.main()
On 02/27/2019 12:36 PM, Mitko Haralanov via gtk-app-devel-list wrote:
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
___
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
Re: Force liststore to update when leaving treeview
On 02/12/2019 11:32 AM, Mike Martin via gtk-app-devel-list wrote: Is this possible? Yes. I did this a while back, but would need to find an archive to provide you with exact code. I have a (for example) a grid which contains Various action widgets And a Treeview based on a liststore Is there any way to make sure that the changes made to a cell in the liststore are "committed" if I click on one of the other widgets I cant find anything to do this and if I leave the cell without pressing enter or clicking on another cell, all changes are lost Connect to the GtkCellRenderer "editing-started" signal. In that callback, you will have an GtkEntry (GtkCellEditable) object. Connect to the Entry's "changed" signal and keep a permanent string around with the text the user is typing. Also preserve the path and column being edited (obtained with "editing-started"). Also connect to GtkCellRenderer "editing-canceled" signal. In this callback, use the path, column, and text you retained from "editing-started", and update the ListStore. 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: Scrolling to a line in GtkTextView
On 02/12/2019 12:47 PM, Mitko Haralanov via gtk-app-devel-list wrote:
Hi,
In my application, I would like to have a GtkTextView be scrolled to a
particular line after the GtkTextBuffer is loaded.
This was already discussed
https://stackoverflow.com/questions/48934458/gtk-sourceview-scroll-to-mark-not-working.
Basically, the GUI calculations are not done and the lines aren't
calculated, therefore you need to scroll after the GUI rendering is
finished. Use idle_add or timeout_add.
According to the documentation, I can use gtk_text_view_scroll_to_mark() in
order to reliably scroll to the desired line after the line height
computation has been completed. In practice that doesn't work reliably.
Below is the code snippet that I am using:
while (delay++ < 100)
g_main_context_iteration(NULL, FALSE);
debug("Scrolling to line: %lu", lineno);
gtk_text_buffer_get_iter_at_line(GTK_TEXT_BUFFER(priv->sourceBuf),
, (gint)(lineno - 1));
debug("Line: %d, offset: %d", gtk_text_iter_get_line(),
gtk_text_iter_get_offset());
gtk_text_buffer_place_cursor(GTK_TEXT_BUFFER(priv->sourceBuf), );
mark = gtk_text_buffer_get_mark(GTK_TEXT_BUFFER(priv->sourceBuf),
"result-view-search");
gtk_text_buffer_move_mark(GTK_TEXT_BUFFER(priv->sourceBuf), mark,
);
gtk_text_view_scroll_to_mark(GTK_TEXT_VIEW(priv->sourceView), mark, 0.0,
TRUE, 0.0, 0.5);
What I am noticing is that the reliability of this highly depends on the
line number to which I want to scroll and the length of the busy loop in
the beginning - the higher the line number, the longer the busy loop needs
to be in order to reliably scroll to that line.
If the busy loop is not long enough, the text view does scroll but not the
correct line.
What is the proper way to correctly and reliably scroll a GtkTextView to a
certain line?
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
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Force liststore to update when leaving treeview
On 02/12/2019 12:25 PM, Mitko Haralanov via gtk-app-devel-list wrote: One idea is to hook the widget to the "leave-notify-event", which will be triggered when the mouse leaves the widget. Have you used this with a GtkTreeView? I mean, actually implemented what Mike Martin is requesting? On Tue, Feb 12, 2019 at 8:32 AM Mike Martin via gtk-app-devel-list wrote: Is this possible? I have a (for example) a grid which contains Various action widgets And a Treeview based on a liststore Is there any way to make sure that the changes made to a cell in the liststore are "committed" if I click on one of the other widgets I cant find anything to do this and if I leave the cell without pressing enter or clicking on another cell, all changes are lost 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 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Python3, GObject objects & models
So I am assuming that you are looking for a discussion and not for a
specific problem to be solved. If this is not the case, please post the
code that is not working for you, delete my email and forgive me.
On 12/18/2018 01:01 PM, Adam Tauno Williams wrote:
I have created, and registered, a custom GObject type [an object]. I
can place that type into a ListModel: aka model =
Gtk.ListModel(MyClass).
One of the advantages of creating a GObject is the whole property
system - - - and most notably change signals.
And how exactly does that improve on the /model.connect("row-changed")/,
and the signal family already in place?
What I have not been able to find is how to connect/map something like
a Gtk.CellRendererText to a property, such that having a type in a
model has some advantage [vs. a model like (int, str, str)]. ???
For myself, I use Glade for all the Treeviews I can as I would rather
see the Treeview I build than try to memorize the construction of code.
My few attempts in trying to subclass Treeview components got more messy
than just hooking into their signal system and tweaking the data as it
goes from point A to point B.
In the case I have in mind, I was trying to add a autocomplete feature
to a Gtk.CellRendererCombo. I finally discovered that Gtk already has a
provision for that by providing a /editing-started/ signal to add the
autocomplete object to the entry inside the combo.
With that said, I have tens of Treeviews in my accounting system, and am
always on the lookout for more fluent/better ways of showing data.
One other case worth mentioning was trying to get a Decimal column to
play nicely in a Treeview (floats are not acceptable in accounting). I
could use a PyObject type and display it using cell renderer display
functions. However, when filtering and sorting, all manner of extra code
had to be added to work with the Decimals. In the end it was faster and
easier to use a two column approach, a /str/ for display and an /float/
for sorting. Then all the calculations are done in SQL, server side.
Yours,
Reuben
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK window winthout main iterator
Forgive me for second guessing you, but are you definite that that your loop is better/easier to maintain than a Gtk main loop? So far, if I was tempted to implement my own main loop, it wasn't because the Gtk main loop was inferior, but because I was looking at it the wrong way. Definitely check out glib_idle_add(), glib_timeout_add() and family. I would love to be proved wrong, though. Yours, Reuben On 09/04/2018 06:09 PM, Juan Ignacio Donoso via gtk-app-devel-list wrote: I'm trying to create a GUI using gtk I already have a loop that runs my logic. I was using cairo to draw to a png and flush to /dev/fb0 but now I want to instantiate a Gtk::Window to draw on it. I don't want to run Gtk::Main because just want to trigger new drawings when my logic trigger it.. The app is real only there aren't going to be any interactions from the app ui, only from the internal logic I want to draw. Any idea where to look to implement that approach. I was thinking on using Gtk::main_iteration_do with Gtk::Queue_draw. But I'm not getting it work. Do I need to ask for a cairo context on every on_draw signal call? Do I need to "draw" on the "draw" signal? thanks ___ 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: How to scroll to a specific line
Thanks for the suggestion. Believe it or not, I had just arrived at that same solution! I first tried to use GLib.timeout_add(), and that worked too, if the time was larger than 300 - 400 ms, which is on the verge of annoying. I then tried idle_add(), and I guess that makes the 300-400ms 'built-in'. How many lines of text do you have? With 500 - 700 lines of text, my scrolling is instantaneous. The scroll feature itself has a 'soft' stop, but that is quite acceptable for me, as it is easier to adjust my eyes to the change. Reuben ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [PyGObject] Drag & Drop in a TreeView
If it's only for reordering the elements in the tree view, you can use the built-in Gtk.TreeView.set_reorderable() method [1], and you're all set. You get inserted/deleted signals for moved rows so you can know when and how things changed if needed, and the underlying model is also changing accordingly. Of course. Thank you very much, Colomban. It is unbelievable how complicated I can make simple things. Cheers, Reuben ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to scroll to a specific line
On 07/26/2018 02:17 PM, John Coppens wrote:
get_iter_at_line, place_cursor, place_cursor_onscreen, and others. Even tried to
more or less calculate the scroll position and manipulate the vadjustments.
An example:
itr = self.tbff.get_iter_at_line(linenr)
self.tbff.place_cursor(itr)
self.tview.place_cursor_onscreen()
I suspect that the problem may come from the fact that the widget has not
been rendered yet. I also tried to defer the actual scroll to GLib.idle_add,
but that didn't work out either.
This has worked for me:
text_iter = self.source_buffer.get_iter_at_line (linenr)
self.source_buffer.place_cursor(text_iter)
self.source_view.scroll_to_iter(text_iter, 0.1, True, 0.0, 0.5)
I have also seen place_cursor_onscreen() work well. Now the thing is,
none of this will work until the Gtk.SourceView has properly been
rendered. This means doing something like:
self.source_buffer.set_text("my text")
GLib.idle_add(self.scroll_function)
def scroll_function (self):
# your scroll code here, like you use already
So you see, the scroll part is not the problem, but rather the
calculations of iters fails, because these iters are not yet, or are
invalidated when the buffer/view changes.
Cheers, Reuben
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [PyGObject] Drag & Drop in a TreeView
On 07/22/2018 04:26 PM, c.buhtz--- via gtk-app-devel-list wrote:
I am totally confused about this topic. I think I miss some fundamental
understanding on how PyGObject works here.
I want to drag & drop items of one TreeView inside itself. Not other
widgets or applications. I just want to drag item 2 and drop it between
item 4 and 5.
This is how I have done it in the past. Note, I do not proclaim
spectacular or Pythonic code, and would humbly accept any corrections
and/or better ways to accomplish this. It seems to me there should be a
way to let the TreeView do this work itself, but alas, I have not found
it yet.
#!/usr/bin/env python3
import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
from gi.repository import Gdk
class MainWindow(Gtk.Window):
def __init__(self):
Gtk.Window.__init__(self, title="TreeView Drag and Drop")
self.connect("delete-event", Gtk.main_quit)
self.set_default_size(400, 300)
# "model" with dummy data
self.store = Gtk.TreeStore(str, str)
for i in range(5):
self.store.append(None, ['Item {}'.format(i),
'{}'.format(i*100)]) # treeview
self.view = Gtk.TreeView(model=self.store)
self.add(self.view)
# build columsn
colA = Gtk.TreeViewColumn('Col A', Gtk.CellRendererText(), text=0)
self.view.append_column(colA)
colB = Gtk.TreeViewColumn('Col B', Gtk.CellRendererText(), text=1)
self.view.append_column(colB)
# DnD events
self.view.connect("drag-data-received", self.drag_data_received)
self.view.connect("drag-data-get", self.drag_data_get)
target_entry = Gtk.TargetEntry.new('text/plain', 2, 0)
self.view.enable_model_drag_source(Gdk.ModifierType.BUTTON1_MASK,[target_entry],
Gdk.DragAction.DEFAULT|Gdk.DragAction.MOVE)
self.view.enable_model_drag_dest([target_entry],Gdk.DragAction.DEFAULT|Gdk.DragAction.MOVE)
def drag_data_get (self, treeview, drag_context, data, info, time):
model, path = treeview.get_selection().get_selected_rows()
data.set_text(str(path[0]), -1)
def drag_data_received (self, treeview, drag_context, x,y,
data,info, time):
store = treeview.get_model()
source_path = data.get_text()
source_iter = store.get_iter(source_path)
dest_path = self.view.get_dest_row_at_pos(x, y)
if dest_path != None:
dest_iter = store.get_iter(dest_path[0])
if dest_path[1] == Gtk.TreeViewDropPosition.BEFORE:
store.move_before(source_iter, dest_iter)
else:
store.move_after(source_iter, dest_iter)
treeview.emit_stop_by_name("drag-data-received")
win = MainWindow()
win.show_all()
Gtk.main()
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkTreeView: how to get the cell with current focus?
I do this all the time in Python with: def key_tree_tab(self, treeview, event): keyname = Gdk.keyval_name(event.keyval) path, col = treeview.get_cursor() # only visible columns!! columns = [c for c in treeview.get_columns() if c.get_visible()] colnum = columns.index(col) if keyname=="Tab" : if colnum + 1 < len(columns): next_column = columns[colnum + 1] else: tmodel = treeview.get_model() titer = tmodel.iter_next(tmodel.get_iter(path)) if titer is None: titer = tmodel.get_iter_first() path = tmodel.get_path(titer) next_column = columns[0] GLib.timeout_add(10, treeview.set_cursor, path, next_column, True) Hope it helps! On 07/12/2018 01:36 PM, Lars Paulsen wrote: Hi All, I did some further tests and the addresses returned in focus_column are the same as the columns I created with "gtk_tree_view_column_new();". Well, it's quite obvious but somehow I expected that there is some API function which returns an index for a column. Anyway, I will continue by comparing the addresses to find out which column I am in. I need this to find out which column "is next". I want to set the focus to the next cell/column if the user presses tab. If anyone knows a better solution to determine the column/next column please let me know. Cheers, Lars Am 12.07.2018 um 18:11 schrieb Lars Paulsen: Hello All, I got a little problem with a GtkTreeView and with getting the cell which actually has got the focus: From the API documentation it seems like gtk_tree_view_get_cursor(GTK_TREE_VIEW(tree), , _column); is doing the job. I can handle the path, it gives me the row which has the focus. But how do I get the index of the cell from focus_column (alias GtkTreeViewColumn)? A web search revealed some old forum entries which seem to state that it is not supported. Do I have to check the column name or compare the addresses of my columns? Thanks for any help in advance. Best Regards, Lars ___ 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: clear() on TreeView causes select-events
I have had very similar experiences with liststore.clear() in
Python3.5 and Mint 18. To work around this I do:
store = treeview.get_model() #may not be necessary in your code
treeview.set_model(None)
store.clear()
store.append('my string or etc')
treeview.set_model(store)
This works. Disconnecting the "model" from the "view" before doing
clear is the key. But very uncomfortable.
What not worked was to unselect before doing clear. I don't understand
why.
This all sounds to me like a mystic behaviour what could be a bug. But
I am not deep enough into Gtk so I won't open an official report about
this. It is on the core devs and experts in that list to decide if this
is an serious issue or not.
I agree with you. However, since I found this code on a Gtk website,
specifically for common problems with using Gtk, I assume it is the
recommended way. I don't remember where I found it or I would post a link.
And after you study the MVC pattern, you will see why the whole Treeview
stack works the way it does. Google MVC and Gtk MVC. It is worthwhile
reading if you plan on constructing treeviews. It may not make sense
immediately, but eventually you may see the light like I did.
Reuben
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: clear() on TreeView causes select-events
On 07/03/2018 05:30 PM, c.buhtz--- via gtk-app-devel-list wrote:
Hello
I observer an interesting behavior (PyGObject, Gtk3.0, Python3.6,
Debian unstable with XFCE desktop):
An item (row) in a TreeView is selected (highlighted).
Then calling .clear() on the TreeView causes an select-event for each
item (row) below that selected item (row).
I have had very similar experiences with liststore.clear() in Python3.5
and Mint 18. To work around this I do:
store = treeview.get_model() #may not be necessary in your code
treeview.set_model(None)
store.clear()
store.append('my string or etc')
treeview.set_model(store)
Disclaimer > I have no original code. I glean ideas from other people,
and pass them on. Please keep the circle going :)
Am I right here?
___
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: PyGObject Maybe bug with alternate row colors in a Gt.TreeView
On 05/16/2018 01:51 PM, Eric Cashon via gtk-app-devel-list wrote: The following gives an error if I use "cell-background" which is stated in the documentation. Maybe just a typo someplace but "cell_background" seems to work fine for binding the color column to the cell-background property. You can pass some common color names or a rgb hex value for a color string. Eric Python would interpret cell-background as subtracting variable 'background' from variable 'cell'. Hence, all Gtk options with *-* in them get replaced with *_ *Reuben ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
