Hi, yes you should file a bug
Of course, the sizing of the column is also marked as
"AUTOMATIC", which may be the reason why. I am assuming that it works
for you because you are overriding the "AUTOMATIC" sizing by calling
gtk_tree_view_column_set_resizable() after the UI has been processed.
Yes the problem is with AUTOMATIC sizing mode while with other sizing modes it works correctly.
Il giorno ven 8 mar 2019 alle ore 02:20 Mitko Haralanov <voidtrance@xxxxxxxxx> ha scritto:
I just tried this and it doesn't work. I set the first column as
resizable in the main.ui (through Glade) and the bad behavior is still
present. Of course, the sizing of the column is also marked as
"AUTOMATIC", which may be the reason why. I am assuming that it works
for you because you are overriding the "AUTOMATIC" sizing by calling
gtk_tree_view_column_set_resizable() after the UI has been processed.
On Thu, Mar 7, 2019 at 10:47 AM Luca Bacci <luca.bacci982@xxxxxxxxx> wrote:
>
> try adding the line
> gtk_tree_view_column_set_resizable (gtk_tree_view_get_column(view, 0), TRUE);
>
> Il giorno gio 7 mar 2019 alle ore 19:43 Luca Bacci <luca.bacci982@xxxxxxxxx> ha scritto:
>>
>> just setting column1 as resizable fixes the issue
>>
>> Il giorno gio 7 mar 2019 alle ore 18:35 Luca Bacci <luca.bacci982@xxxxxxxxx> ha scritto:
>>>
>>> Yes, go ahead.
>>>
>>> I don't know if that can be useful to you, but if you increase the time spent in usleep() to something greater it works correctly.
>>> With usleep(10000) I get mixed results:
>>>
>>> Third column activated
>>> Third column activated
>>> Activated an other column
>>> Activated an other column
>>> Third column activated
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Third column activated
>>> Activated an other column
>>> Third column activated
>>> Third column activated
>>> Third column activated
>>> Activated an other column
>>>
>>> with usleep(100000) I always get correct results:
>>>
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>>
>>>
>>> Il giorno mer 6 mar 2019 alle ore 20:26 Mitko Haralanov <voidtrance@xxxxxxxxx> ha scritto:
>>>>
>>>> OK, thank you.
>>>>
>>>> Please, let me know if you'd like me to file a bug for this?
>>>> Thanks
>>>>
>>>> On Wed, Mar 6, 2019 at 10:27 AM Luca Bacci <luca.bacci982@xxxxxxxxx> wrote:
>>>> >
>>>> > I'm working on it. But yes, this really seems a bug in Gtk.
>>>> >
>>>> > Il mer 6 mar 2019, 18:40 Mitko Haralanov <voidtrance@xxxxxxxxx> ha scritto:
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> Any update? Does anyone think this is a bug that should be filed against Gtk?
>>>> >>
>>>> >> Thanks
>>>> >>
>>>> >> On Thu, Feb 28, 2019 at 2:05 AM Luca Bacci <luca.bacci982@xxxxxxxxx> wrote:
>>>> >> >
>>>> >> > Hi, I can't promise I will find a solution but I'll certainly take a look at this
>>>> >> >
>>>> >> > Il gio 28 feb 2019, 02:13 Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> ha scritto:
>>>> >> >>
>>>> >> >> You are right, and I withdraw my remarks. As noted, I didn't read it carefully enough.
>>>> >> >>
>>>> >> >> But yes, g_idle_add_full() runs in the worker thread, however that's one thing that is always OK.
>>>> >> >>
>>>> >> >> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov <voidtrance@xxxxxxxxx> wrote:
>>>> >> >>>
>>>> >> >>> But that's not how the code is written:
>>>> >> >>>
>>>> >> >>> g_task_run_in_thread(obj->task, custom_object_work) ->
>>>> >> >>> custom_object_worker() ->
>>>> >> >>> signal_emit() ->
>>>> >> >>> g_idle_add_full(..., signal_emitter, ...);
>>>> >> >>>
>>>> >> >>> signal_emitter() is the function that *actually* emits the signal.
>>>> >> >>> signal_emitter() is supposed to be running in the main context thread
>>>> >> >>> by the virtue of being the g_idle_add_full() callback.
>>>> >> >>>
>>>> >> >>> Are you saying that the g_idle_add_full() callback also runs in the
>>>> >> >>> worker thread?
>>>> >> >>>
>>>> >> >>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>>> >> >>> >
>>>> >> >>> >
>>>> >> >>> >
>>>> >> >>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov <voidtrance@xxxxxxxxx> wrote:
>>>> >> >>> >>
>>>> >> >>> >> How is that? The update is happening from a callback executed by the
>>>> >> >>> >> main context thread?
>>>> >> >>> >
>>>> >> >>> >
>>>> >> >>> > g_task_run_in_thread(obj->task, custom_object_worker);
>>>> >> >>> >
>>>> >> >>> > custom_object_worker() emits the "updated" signal. the handler modifies the model.
>>>> >> >>> >
>>>> >> >>
>>>> >> >> _______________________________________________
>>>> >> >> gtk-list mailing list
>>>> >> >> gtk-list@xxxxxxxxx
>>>> >> >> https://mail.gnome.org/mailman/listinfo/gtk-list
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
