gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2024-03-25T22:47:56Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/6566[RFC] Provide abstraction to popup a menu on a widget on secondary button, me...2024-03-25T22:47:56ZPablo Correa Gomez[RFC] Provide abstraction to popup a menu on a widget on secondary button, menu key and F10+ShiftSo I've bumped into this when looking a bit around https://gitlab.gnome.org/GNOME/Incubator/papers/-/issues/11 This issue comes from the fact that in GTK3 there was this `GtkWidget.popup` virtual function that was used to trigger context...So I've bumped into this when looking a bit around https://gitlab.gnome.org/GNOME/Incubator/papers/-/issues/11 This issue comes from the fact that in GTK3 there was this `GtkWidget.popup` virtual function that was used to trigger context menus on widgets. When we did the port of Papers from GTK3 to GTK4, that thing had been replaced, and we just hooked up a GtkGestureClick with secondary button when appropriate. However, then the Menu key did not work. When trying to look around how to implement it, I bumped into the fact that `gdk_event_triggers_context_menu` which we used to filter events, does not actually consider the Menu key. So then I kept digging I found out that most uses of that key in gtk have the structure:
* Add a shortcut controller with F10+Shift and Menu key, and assign an action to it
* Add a gesture click controller with secondary button, and connect a callback to `pressed`
* The callback and the action basically call the same function with `x, y` or `-1, -1`. There are different variations of this, but all very similar, and with quite some duplicated code around.
I guess I could just copy that same structure to Papers and call it a day :smile: But I was wondering if having some kind of abstraction around it wouldn't make some sense. I guess `GtkWidget.popup` was removed for a reason, and I'm not experienced with API design. But maybe if the maintainers think this is a good idea, we can try to re-introduce something that helps? If we were to do so, something that I feel we're also doing wrong downstream is this thing of parenting the popup, and properly pointing it to where it should, so maybe incorporating that would help.https://gitlab.gnome.org/GNOME/gtk/-/issues/6263No API to unregister a GdkContentSerializer2023-12-20T12:33:21ZPBSNo API to unregister a GdkContentSerializerThe function [`gdk_content_register_serializer()`](https://docs.gtk.org/gdk4/func.content_register_serializer.html) has no counterpart `gdk_content_unregister_serializer()`. This means serializers for a given type stay registered forever...The function [`gdk_content_register_serializer()`](https://docs.gtk.org/gdk4/func.content_register_serializer.html) has no counterpart `gdk_content_unregister_serializer()`. This means serializers for a given type stay registered forever, and there is no way to unregister them.
The ability to unregister serializers would be useful in e.g. Inkscape. The possible formats that Inkscape can serialize to depends on a dynamic list of export extensions, which can be loaded and unloaded at any time by the user. So for example, if the user decides to unload the extension responsible for exporting to `image/webp`, then that format should no longer be advertised on the clipboard.https://gitlab.gnome.org/GNOME/gtk/-/issues/6133Add text commit hooks to GtkTextBuffer2024-02-17T16:36:14ZChristian HergertAdd text commit hooks to GtkTextBufferOne thing that is increasingly complex is dealing with text changes from signal callbacks in GtkTextBuffer. People often do things they very much should not do from these callbacks which makes it practically impossible to track changes f...One thing that is increasingly complex is dealing with text changes from signal callbacks in GtkTextBuffer. People often do things they very much should not do from these callbacks which makes it practically impossible to track changes for external code in a reliable manner.
This was one of the reasons that GtkTextHistory was put in GtkTextBuffer directly.
In Builder, we have something to help with this so our plugins that only need to track changes cannot run into signal connection/disconnection ordering issues. It's called a TextCommitFunc and you can register a set of them for the textbuffer.
https://gitlab.gnome.org/GNOME/gnome-builder/-/blob/937e37b463b51cb743cdb8e70187b5e08e40917b/src/libide/code/ide-buffer.h#L196
We should determine if this is something we want in GtkTextBuffer itself. GtkTextHistory could be made to use it as well as libspelling, GtkSourceView, Builder, etc.GNOME 46Christian HergertChristian Hergerthttps://gitlab.gnome.org/GNOME/gtk/-/issues/6090Add a replacement for `gtk_file_chooser_add_choice()`2023-09-18T13:07:33Zalex-teeAdd a replacement for `gtk_file_chooser_add_choice()``gtk_file_chooser_add_choice()` was deprecated with no replacement.
I have a use case where I want the user to specify the MIDI file format (there are 3 types: Format0/Format1/Format2) when saving MIDI files. This is similar to having a...`gtk_file_chooser_add_choice()` was deprecated with no replacement.
I have a use case where I want the user to specify the MIDI file format (there are 3 types: Format0/Format1/Format2) when saving MIDI files. This is similar to having a choice for "text encoding" or other similar file format options in other apps. According to @ebassi , "a couple of apps (gnome-text-editor and gnome-builder, mainly) have expressed it as a requirement for loading text files with a specific encoding".https://gitlab.gnome.org/GNOME/gtk/-/issues/6028Gtk.Clipboard add set_uri method2023-08-15T13:15:01Zqiuyuan wangGtk.Clipboard add set_uri methodgtk.clipboard have no set_uri
but it have wait_for_uris and wait_is_uris_available
library version is 3.24gtk.clipboard have no set_uri
but it have wait_for_uris and wait_is_uris_available
library version is 3.24https://gitlab.gnome.org/GNOME/gtk/-/issues/5689Add a replacement for GtkEntryCompletion2024-03-12T06:23:18ZEmmanuele BassiAdd a replacement for GtkEntryCompletionNow that `GtkEntryCompletion` has been deprecated, we need to figure out a possible replacement.
The "suggestion entry" widget in gtk4-demo seems to be a good starting point, but there are various use cases covered (badly) by `GtkEntryC...Now that `GtkEntryCompletion` has been deprecated, we need to figure out a possible replacement.
The "suggestion entry" widget in gtk4-demo seems to be a good starting point, but there are various use cases covered (badly) by `GtkEntryCompletion` that may not fit into a single widget. We may even delegate this particular widget to libadwaita, if it gets too niche.
It would be good to gather requirements from the current users of `GtkEntryCompletion`, and loop the design team into the topic.https://gitlab.gnome.org/GNOME/gtk/-/issues/5444inscription: Have something like GtkLabel::single-line-mode2023-02-20T15:47:41ZMarco Melorioinscription: Have something like GtkLabel::single-line-mode`GtkInscription` can't render the text as if it were all in the same line, if just cuts off all the other lines. It would be great to have something similar to `GtkLabel::single-line-mode`, where all the newlines are replaced with a "ret...`GtkInscription` can't render the text as if it were all in the same line, if just cuts off all the other lines. It would be great to have something similar to `GtkLabel::single-line-mode`, where all the newlines are replaced with a "return" symbol.https://gitlab.gnome.org/GNOME/gtk/-/issues/5064GtkAdjustment possible enhancements - storing original value, and respect cla...2022-07-27T11:31:50ZswilmetGtkAdjustment possible enhancements - storing original value, and respect class invariants at all timesCurrently, a GtkAdjustment needs to be used with some care. So the idea is to make it less error-prone to use.
Since it's the user that controls the property values, it can easily break the class invariants.
It also depends on which or...Currently, a GtkAdjustment needs to be used with some care. So the idea is to make it less error-prone to use.
Since it's the user that controls the property values, it can easily break the class invariants.
It also depends on which order the properties are set. For example setting first :value and then :lower can break the class invariants too, since it's the :value setter that clamps the value.
An idea is to keep the original :value, and ask for the clamped one when needing it. Sometimes the original value is useful to keep around, in case the other properties change and the original value _becomes_ in range.
Currently the original value can be stored externally of course.
In all cases, it's the user of the class that better knows whether re-clamping the original value makes sense or not.
But storing the original value would resolve the class invariants problem.
(it's more an API design proposal, feel free to close this issue if it's not a good idea to change GtkAdjustment).https://gitlab.gnome.org/GNOME/gtk/-/issues/5056Problematic commit: signallistitemfactory: Update signal prototype (be1729b316)2023-09-16T10:05:53ZKjell AhlstedtProblematic commit: signallistitemfactory: Update signal prototype (be1729b316)The commit message says:
> I'm not sure this is API safe, but it is necessary if we want to support section items and canvas items.
>
> If it's deemed API-unstable, we have to copy this object and deprecate this one.
If we would ma...The commit message says:
> I'm not sure this is API safe, but it is necessary if we want to support section items and canvas items.
>
> If it's deemed API-unstable, we have to copy this object and deprecate this one.
If we would make a similar change in gtkmm, the C++ binding, it would certainly break API.
The user expects to get a pointer to a GtkListItem in the signal handler, but might get a
pointer to something else. Because of the name mangling in C++, it would probably also break ABI.https://gitlab.gnome.org/GNOME/gtk/-/issues/4991Add shared interfaces for widget containers2023-01-15T10:52:38ZAaron ErhardtAdd shared interfaces for widget containersWith GTK4 the common container interface was removed and there were good reasons for that. Yet, it turned out to be useful for libraries that build upon GTK4 (in particular Relm4) to have a common interface for widgets that act as contai...With GTK4 the common container interface was removed and there were good reasons for that. Yet, it turned out to be useful for libraries that build upon GTK4 (in particular Relm4) to have a common interface for widgets that act as containers for other widgets. As a temporary solution, Relm4 has implemented these interfaces itself but this limits the use of these interfaces to only a fraction of the GTK user. [In an effort to make these features available inside gtk-rs](https://github.com/gtk-rs/gtk4-rs/issues/1038) it was agreed that it makes more sense to upstream them than to implement such interfaces for each language binding individually.
The interfaces that Relm4 implements distinguish between containers that have only one child (SetChildExt, e.g. Window) and those that can have many (ContainerExt, e.g. Box). It also has a category for containers that have simple methods to remove one of their children (RemoveExt, e.g. Grid).
With these three interfaces, all different types of containers should be covered. Of course, this is just a suggestion that can be discussed and adjusted as needed.
| Interface (trait) | Docs | Code | Implementors | Description |
| - | - | - | - | - |
| IterChildrenExt | [Link](https://relm4.org/docs/next/relm4/trait.RelmIterChildrenExt.html) | [Link](https://github.com/Relm4/Relm4/blob/next/relm4/src/extensions/iter_children.rs) | Box, ListBox, FlowBox, Grid, Stack, adw::TabView | Iterate over the children of widgets.
| SetChildExt | [Link](https://relm4.org/docs/next/relm4/trait.RelmSetChildExt.html) | [Link](https://github.com/Relm4/Relm4/blob/next/relm4/src/extensions/set_child.rs) | Button, LinkButton, ToggleButton, FlowBoxChild, Frame, ListBoxRow, Popover, Window, ScrolledWindow, ApplicationWindow, Dialog, Overlay, Revealer, adw::Application, adw::Bin, adw::Clamp, adw::ClampScrollable, adw::SplitButton, adw::StatusPage | Has a `container_set_child` method that sets a widget as the only child of the container or removes it.
| ContainerExt | [Link](https://relm4.org/docs/next/relm4/trait.RelmContainerExt.html) | [Link](https://github.com/Relm4/Relm4/blob/next/relm4/src/extensions/container.rs) | Box, ListBox, InfoBar, Stack, *all SetChild implementors* | Has a `container_add` method to add a child to the container (the new child might replace previously added children).
| RemoveExt | [Link](https://relm4.org/docs/next/relm4/trait.RelmRemoveExt.html) | [Link](https://github.com/Relm4/Relm4/blob/next/relm4/src/extensions/remove.rs) | ListBox, FlowBox, Box, Fixed, Grid, ActionBar, Stack, HeaderBar, InfoBar, *all SetChildExt implementors* | Has a `container_remove` method to remove previously added widgets.https://gitlab.gnome.org/GNOME/gtk/-/issues/4835GtkListBase|list.* actions cannot be activated on GtkColumnView2023-06-14T00:03:35ZAntónio Fernandesantoniof@gnome.orgGtkListBase|list.* actions cannot be activated on GtkColumnViewGtkColumnView is not a subclass of GtkListBase, so this is to be expected.
However, the list widget actions are just as necessary as in other list widgets. For instance, there is no other way to trigger a scroll to a given item other th...GtkColumnView is not a subclass of GtkListBase, so this is to be expected.
However, the list widget actions are just as necessary as in other list widgets. For instance, there is no other way to trigger a scroll to a given item other than activating `list.scroll-to-item`.
The internal GtkColumnListView child is not accessible by public API, so it's impossible to invoke the action on it without poking into its internals (which is what I'm shamefully doing in GNOME Files for the time being https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/817).
Should we install the actions in GtkColumnView itself? Or provide a getter for the internal list view? I can help with a patch if given advice on the correct direction.https://gitlab.gnome.org/GNOME/gtk/-/issues/4833No way to get the current sort column in GtkColumnView2022-10-20T21:20:42ZAntónio Fernandesantoniof@gnome.orgNo way to get the current sort column in GtkColumnViewAs per designer's guidance, Files should have a sort menu regardless of view mode (grid or list).
However, it's not possible to get the current sort column in GtkColumnView.
My best-effort has been to clear the menu when the GtkSorter...As per designer's guidance, Files should have a sort menu regardless of view mode (grid or list).
However, it's not possible to get the current sort column in GtkColumnView.
My best-effort has been to clear the menu when the GtkSorter changes by any other means (such as the user clicking a column header), but is far from ideal.
![sort-menu](/uploads/d8ce4a846805705d41e7fc26c7d761e5/sort-menu.png)
(current implementation in https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/817)
So, I'd like to request something like a `gtk_column_view_get_current_sort_column()`. Or a `::sort-column-changed` signal. In either case, it should not only provide the column but also whether it is reverse-sorted.
I can help provide a patch if you tell me the the preferred API design.https://gitlab.gnome.org/GNOME/gtk/-/issues/3260Provide A Way To Make Custom Popover Menus Matching MenuModel Styling2020-10-27T04:51:01ZChristopher DavisProvide A Way To Make Custom Popover Menus Matching MenuModel StylingCurrently in GTK3, developers can create popovers that match MenuModel-generated popovers with a GtkPopover, margins, and GtkModelButton. In GTK4 ModelButton has been made private. This makes it harder to make menus with similar styling ...Currently in GTK3, developers can create popovers that match MenuModel-generated popovers with a GtkPopover, margins, and GtkModelButton. In GTK4 ModelButton has been made private. This makes it harder to make menus with similar styling to provided ones.
Example use cases are:
* Fractal's primary menu
* My app Social's [account menu](https://gitlab.gnome.org/Teams/Design/app-mockups/-/raw/master/social/social.png)
In both cases a custom widget is at the start of the menu.https://gitlab.gnome.org/GNOME/gtk/-/issues/3249Evaluate GDK Wayland public API2020-10-15T16:55:20ZEmmanuele BassiEvaluate GDK Wayland public APIWe currently have a bunch of private symbols used by GTK declared inside public GDK Wayland headers and even in the documentation:
- [x] `gdk_wayland_toplevel_inhibit_idle()` and `gdk_wayland_toplevel_uninhibit_idle()`
- [x] `gdk_wayl...We currently have a bunch of private symbols used by GTK declared inside public GDK Wayland headers and even in the documentation:
- [x] `gdk_wayland_toplevel_inhibit_idle()` and `gdk_wayland_toplevel_uninhibit_idle()`
- [x] `gdk_wayland_toplevel_announce_csd()`
- [x] `gdk_wayland_display_prefers_ssd()`
A public symbol that's really a private one:
- [x] `gdk_wayland_toplevel_set_dbus_properties_libgtk_only()`
A `GdkSeat` method without public `GdkWaylandSeat` type:
- [x] `gdk_wayland_seat_get_wl_seat()`
An awkwardly named method:
- [x] `gdk_wayland_device_pad_set_feedback()`
We should mop this up before GTK4 is out.
/cc @carlosgEmmanuele BassiEmmanuele Bassihttps://gitlab.gnome.org/GNOME/gtk/-/issues/3167The gtk_widget_insert_* methods are hard to understand from bindings2023-04-03T22:14:29ZArnaud B.arnaud.bonatti@gmail.comThe gtk_widget_insert_* methods are hard to understand from bindingsGtk4 allows to directly add a widget to another one, using the `gtk_widget_insert_after()` and `gtk_widget_insert_before()` methods. But the current way this methods are written makes things hard to understand when reading code in some o...Gtk4 allows to directly add a widget to another one, using the `gtk_widget_insert_after()` and `gtk_widget_insert_before()` methods. But the current way this methods are written makes things hard to understand when reading code in some other languages than C: python, vala, etc.
For example:
```vala
button.insert_before (box, null);
```
is [quite hard to get](https://gitlab.gnome.org/GNOME/gtk/-/issues/3165#note_911636): yes, that’s adding a button at the end of a box <small>(N.B.: GtkBox has a clearer method for doing that, it’s just for the example)</small>.
That’s due to the C API being:
```C
void gtk_widget_insert_after(GtkWidget *widget, GtkWidget *parent, GtkWidget *prev_sibling);
void gtk_widget_insert_before(GtkWidget *widget, GtkWidget *parent, GtkWidget *next_sibling);
```
with the name of the methods referring to their *last* argument, the sibling.
I see two possible solutions to this problem.
---
The first one is to invert the `parent` and `sibling` args. In C, that doesn’t read harder:
```C
void gtk_widget_insert_after(GtkWidget *widget, GtkWidget *prev_sibling, GtkWidget *parent);
void gtk_widget_insert_before(GtkWidget *widget, GtkWidget *next_sibling, GtkWidget *parent);
```
but in bindings it makes things clearer:
```vala
widget.insert_after (sibling, parent);
widget.insert_before (sibling, parent);
```
as that can be read as “insert widget after/before sibling in parent.”
---
The other solution I suggest is to completely remove the `parent` argument: Gtk can grab it from the sibling…
```C
void gtk_widget_insert_after(GtkWidget *widget, GtkWidget *prev_sibling);
void gtk_widget_insert_before(GtkWidget *widget, GtkWidget *next_sibling);
```
But that means that `prev_sibling` and `next_sibling` cannot be null, and so that we need to add two methods to add in first and last positions <small>(or else an easy way to get the current first and last children of a widget, but I dislike this option)</small>.
```C
void gtk_widget_append_to(GtkWidget *widget, GtkWidget *parent);
void gtk_widget_prepend_to(GtkWidget *widget, GtkWidget *parent);
```
All of these methods are quite easily understood when using bindings.
```vala
widget.insert_after (sibling);
widget.insert_before (sibling);
widget.append_to (parent);
widget.prepend_to (parent);
```https://gitlab.gnome.org/GNOME/gtk/-/issues/3053[RFE] API for context menus on custom widgets in GTK42020-10-06T11:49:13Zbob[RFE] API for context menus on custom widgets in GTK4Having a look through the code in the current master (473ed75ed54524677efdbddd05896210565b7be0), it seems `GtkLabel`, `GtkText`, `GtkTextView`, `GtkNotebook` and others all implement a very similar pattern:
- Define a function that han...Having a look through the code in the current master (473ed75ed54524677efdbddd05896210565b7be0), it seems `GtkLabel`, `GtkText`, `GtkTextView`, `GtkNotebook` and others all implement a very similar pattern:
- Define a function that handles creating a `GtkPopoverMenu` from a `GMenuModel` associated with the widget and positioning it per invocation-specific coordinates
- Add a `menu.popup` action handled by calling said function with default coordinates, with action bindings to Shift+F10 and the menu key
- Add a `GtkGestureClick` handler that calls said function if `gdk_event_triggers_context_menu`
Grepping for `GDK_KEY_Menu` in GTK returns matches in more than a dozen files, so this appears to be a fairly common thing.
`GtkLabel`, `GtkText` etc expose convenient `GMenuModel`-based API that hides these details, but this all has to be reproduced by the user if, for example, they want context menus on a `GtkListBoxRow`. Besides being a pain in the neck, it doesn't seem reasonable to expect people to replicate it correctly: I, for one, didn't even know about Shift+F10, and I think about the menu key so infrequently that I've hardly noticed it missing from my keyboard!
Is it possible some API could be introduced to abstract some or all of these details? If it helps, I can think of some (possibly questionable) approaches:
- Add a new event controller subclass, `GtkContextMenuController`(?), that has a `GMenuModel` property and does all the stuff required to make that appear as a context menu on its widget when appropriate. I quite like this sort of solution, since it's applicable to arbitrary widgets and can be done entirely in the GTK Builder interface description, but it seems incongruent with the other event controllers in that it implements some behaviour in response to events instead of just providing an interface for other code to respond to events.
- Give the `menu.popup` action some sort of special status within the toolkit, such that context menus are handled automatically on widgets implementing some interface that exposes a `GMenuModel`; maybe something like `GtkContextMenuable` (hopefully with a better name ;) that requires `GtkActionable` and has a menu model property. Or maybe just adding a `GMenuModel` property directly to `GtkWidget`?
- A less invasive approach might be to move the function(s) creating/placing the popover into `GtkWidget` and expose it (`gtk_widget_create_and_place_menu(GtkWidget*, GMenuModel*, GdkEvent*)`?); that would disentangle the popover placement from the event source. Adding a pre-defined `GtkShortcutTrigger` that knew about context menu shortcuts would then abstract the details of popover placement and exact key combinations away from widgets that needed to manually implement context menu support.
I must admit, I haven't fully digested the changes to event handling in GTK4, so perhaps none of the above are appropriate; nonetheless, hopefully it might serve as a place from which to start.https://gitlab.gnome.org/GNOME/gtk/-/issues/2967GtkGrid maybe shouldn't use "left"2020-08-03T01:41:30ZAdrien PlazasGtkGrid maybe shouldn't use "left"Mentions of "left" and "right" were remplaced by "start" and "end" in many places in the API to work as well on RTL as it does on LTR. I noticed GtkGrid still uses "left" and "top" to refer to positions in GTK 4, maybe they could be repl...Mentions of "left" and "right" were remplaced by "start" and "end" in many places in the API to work as well on RTL as it does on LTR. I noticed GtkGrid still uses "left" and "top" to refer to positions in GTK 4, maybe they could be replaced by "x-attach" and "y-attach", or "h-attach" and "v-attach".https://gitlab.gnome.org/GNOME/gtk/-/issues/2340Remove gtk-application-prefer-dark-theme2020-02-07T16:52:51ZBjörn DaaseRemove gtk-application-prefer-dark-themeDark themes are super hard to read for some people, especially for those with astigmatism. https://www.techradar.com/news/the-dark-mode-craze-may-do-more-harm-than-good-this-is-why gives some more details on that.
As I am probably one o...Dark themes are super hard to read for some people, especially for those with astigmatism. https://www.techradar.com/news/the-dark-mode-craze-may-do-more-harm-than-good-this-is-why gives some more details on that.
As I am probably one of those persons (at least I have serious difficulties to read text in dark themes), I explicitly set a light theme. Unfortunately, applications can override the theme used (e.g. pitivi does that) with `gtk-application-prefer-dark-theme`, making them nearly unusable for some user (e.g. me).
It is not really comfortable to ovveride each desktop file with `GTK_THEME=Adwaita:light <application>` individually, especially for inexperienced users. Having this setting really conflicts with the GNOME inclusion and universal access idea.
Therefore I would suggest for to remove the `gtk-application-prefer-dark-theme` setting. Users who still want a dark theme mostly want that for all their applications, so they can still set a dark them globally which can be respected by each application.https://gitlab.gnome.org/GNOME/gtk/-/issues/2293Enhancement: Add gtk_tree_model_set_value() / gtk_tree_model_set() method2020-04-19T03:15:11ZDarkTrickEnhancement: Add gtk_tree_model_set_value() / gtk_tree_model_set() methodThis enhancement request aims to make it easier for the user to change a value "inside" a GtkTreeModel.
Currently I feel a real challenge to accomplish (especially for novices) "making a cell editable". There is already a lot of "knowled...This enhancement request aims to make it easier for the user to change a value "inside" a GtkTreeModel.
Currently I feel a real challenge to accomplish (especially for novices) "making a cell editable". There is already a lot of "knowledge noise" through Renderer and the function signature of current value set functions.
Currently Situation:
====================
It is very difficult to change the value of a cell through GtkTreeModel:
The user must use GtkTreeStore methods or GtkListStore methods to change values. In case of GtkTreeModelSorted, things get even more difficult. The necessity for differentiation results in the uselessness of the GtkTreeModel interface, as it cannot be used universally.
Suggestion:
===========
Provide the following function:
```
void
gtk_tree_model_set (GtkTreeModel *tree_store,
GtkTreeIter *iter,
...);
```
Implementation:
===============
- GtkListStore already has gtk_list_store_set()
- GtkTreeStore already has gtk_tree_store_set()
- GtkTreeModelSort has no implementation, yet. It might look like the following:
```
GtkTreeModelSort * model_sorted = GTK_TREE_MODEL_SORT(p_model_sorted);
GtkTreeIter iter_sortedModel;
gtk_tree_model_get_iter_from_string((GtkTreeModel*)model_sorted,
&iter_sortedModel, path_string);
GtkListStore * model_raw;
model_raw = GTK_LIST_STORE(gtk_tree_model_sort_get_model(model_sorted));
GtkTreeIter iter_rawModel;
gtk_tree_model_sort_convert_iter_to_child_iter(model_sorted, &iter_rawModel, &iter_sortedModel);
gtk_list_store_set(model_raw, &iter_rawModel,
LIST_COL_NAME, new_text, -1);
```
- Of course, the respective function should be called through gtk_tree_model_set.
Remark:
=======
Changing the signature of the callback on "edited" to include a direct link to the cell content, which could then be changed directly, would of course be a much better solution. I did not suggest that one, as I expect it to be much harder to implement and therefore less likely to be implemented.
https://gitlab.gnome.org/GNOME/gtk/-/issues/2267GtkBuilder removed get_type_from_name vfunc, but gtkmm's Gtk::Builder uses it2019-12-13T19:21:37ZDaniel BolesGtkBuilder removed get_type_from_name vfunc, but gtkmm's Gtk::Builder uses it`gtkmm` counterpart: https://gitlab.gnome.org/GNOME/gtkmm/issues/61
`builder.ccg` stated that
```cpp
// Allow GtkBuilder to instantiate a gtkmm derived GType instead of the regular
// GTK+ GType, so we can, for instance, use our vfunc...`gtkmm` counterpart: https://gitlab.gnome.org/GNOME/gtkmm/issues/61
`builder.ccg` stated that
```cpp
// Allow GtkBuilder to instantiate a gtkmm derived GType instead of the regular
// GTK+ GType, so we can, for instance, use our vfuncs and default signal handlers.
// static
GType Builder_Class::get_type_from_name_vfunc_callback(GtkBuilder* self, const char* type_name)
```
However, `GtkBuilder` in `master` has now removed `get_type_from_name` and made `GtkBuilder` a final class. Thus, we probably need to coordinate what needs done here, with @kjellahl _et al._
From IRC:
![image](/uploads/aa1777dfa90dc38a1e093e99d42208a5/image.png)Benjamin OtteBenjamin Otte