Re: First deprecate APIs and then remove them in the next major version

2017-12-17 Thread Daniel Kasak 
Yeah, I poked originally. See:
 https://bugzilla.gnome.org/show_bug.cgi?id=156017#c3
 https://bugzilla.gnome.org/show_bug.cgi?id=156017#c5
 https://bugzilla.gnome.org/show_bug.cgi?id=156017#c6

Other people commented and submitted further patches after that. After
that, I just gave up. If you're looking for more volunteers, have a good
think about this.

Just recently another bug has been marked as a duplicate of this one. I get
the feeling if I just continue to ping the bug, or the list, people would
tell me to pull my head in because it's not scratching their itch or
whatever. I only brought it up in the context of someone else saying there
are issues getting patches reviewed and applied.

Regarding IRC - I've never used it because it doesn't save history, so I
have to keep an IRC client open 24/7 just to see people's responses - and
the people I'm waiting on are invariably in a different timezone. If you
have a viable product, submitting a bug to their bug tracking systems and
pinging a couple of times should be sufficient - and I note what's been
said above regarding there only being 1 full-time developer on the product.
Redirecting people to IRC doesn't make less work for anyone - it makes
more. Anyway, I did email the gtk-devel-list - from memory - though
admittedly it was 13 years ago, as you mentioned.

> Otherwise, you get exactly what you paid for.

Oh, I had that one coming. Thankyou.

Dan

On Mon, Dec 18, 2017 at 11:16 AM, Emmanuele Bassi  wrote:

> On 17 December 2017 at 23:14, Daniel Kasak  wrote:
>
> >> Just one example, gtk3 (yes 3, not even 4) is currently completely
> >> unusable on
> >> Mac, so I sent a patch to fix this:
> >>
> >> https://bugzilla.gnome.org/show_bug.cgi?id=791174
> >>
> >> I know my patch is suboptimal, but to make this clear: it does not
> address
> >> a
> >> minor bug, this bug is a real show stopper on Mac, and this change is
> >> purely
> >> gtk internal. Of course it is not a clean solution, but there is no
> reason
> >> to
> >> simply apply this patch (at a bare minimum at least to the gtk3/stable
> >> branch)
> >> with a FIXME comment for now so that people on Mac can finally start
> using
> >> gtk3
> >> at all.
> >
> >
> > I really have to agree. One of my bugs I raised in 2004 - which involves
> > data loss - is still open. I submitted a patch ( which was difficult at
> the
> > time - I only dabble in C when I absolutely have to ) which received very
> > little feedback, and the bug has rotted since.
>
> Yes, everyone has their own pet bug where they submitted a patch and
> waited for feedback, as if GTK doesn't have ~3000 issues open at any
> given time, and a constant stream of bugmail.
>
> It would be *great* if we could review all incoming patches; sadly, we
> either do that, or we spend time actually developing the toolkit.
>
> Plus, if you have a patch lying in bugzilla for *13* years and you
> never bothered to actually poke people about it, then I don't think
> it'll ever get bumped up in terms of priority on the list of things to
> do.
>
> > "Send a patch" only goes so far. If patches don't get reviewed, or don't
> get
> > sufficient feedback, and never get accepted, what's the point in sending
> > patches?
>
> Your role doesn't terminate at sending a patch.
>
> It's your bug, your patch, and your responsibility for bringing it up
> to the people *volunteering* to work on GTK. If you have a patch that
> is languishing in Bugzilla, join the #gtk+ IRC channel on
> irc.gnome.org, or send an email to gtk-devel-list.
>
> Otherwise, you get exactly what you paid for.
>
> Ciao,
>  Emmanuele.
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: First deprecate APIs and then remove them in the next major version

2017-12-17 Thread Emmanuele Bassi 
On 17 December 2017 at 23:14, Daniel Kasak  wrote:

>> Just one example, gtk3 (yes 3, not even 4) is currently completely
>> unusable on
>> Mac, so I sent a patch to fix this:
>>
>> https://bugzilla.gnome.org/show_bug.cgi?id=791174
>>
>> I know my patch is suboptimal, but to make this clear: it does not address
>> a
>> minor bug, this bug is a real show stopper on Mac, and this change is
>> purely
>> gtk internal. Of course it is not a clean solution, but there is no reason
>> to
>> simply apply this patch (at a bare minimum at least to the gtk3/stable
>> branch)
>> with a FIXME comment for now so that people on Mac can finally start using
>> gtk3
>> at all.
>
>
> I really have to agree. One of my bugs I raised in 2004 - which involves
> data loss - is still open. I submitted a patch ( which was difficult at the
> time - I only dabble in C when I absolutely have to ) which received very
> little feedback, and the bug has rotted since.

Yes, everyone has their own pet bug where they submitted a patch and
waited for feedback, as if GTK doesn't have ~3000 issues open at any
given time, and a constant stream of bugmail.

It would be *great* if we could review all incoming patches; sadly, we
either do that, or we spend time actually developing the toolkit.

Plus, if you have a patch lying in bugzilla for *13* years and you
never bothered to actually poke people about it, then I don't think
it'll ever get bumped up in terms of priority on the list of things to
do.

> "Send a patch" only goes so far. If patches don't get reviewed, or don't get
> sufficient feedback, and never get accepted, what's the point in sending
> patches?

Your role doesn't terminate at sending a patch.

It's your bug, your patch, and your responsibility for bringing it up
to the people *volunteering* to work on GTK. If you have a patch that
is languishing in Bugzilla, join the #gtk+ IRC channel on
irc.gnome.org, or send an email to gtk-devel-list.

Otherwise, you get exactly what you paid for.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Build GTK3 without ATK

2017-12-17 Thread Emmanuele Bassi 
On 17 December 2017 at 23:28, Tomasz Gąsior  wrote:

> It is possible to build GTK3 without Accessibility Toolkit dependency? How
> can I do it?

You can't: ATK types are exposed in the GTK API.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Build GTK3 without ATK

2017-12-17 Thread Tomasz Gąsior 

Hi.

It is possible to build GTK3 without Accessibility Toolkit dependency? 
How can I do it?


--
Tomasz Gąsior
https://tomaszgasior.pl
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: First deprecate APIs and then remove them in the next major version

2017-12-17 Thread Daniel Kasak 
On Sun, Dec 17, 2017 at 1:12 AM, Christian Schoenebeck <
schoeneb...@linuxsampler.org> wrote:

> On Samstag, 16. Dezember 2017 12:05:03 CET Sébastien Wilmet wrote:
> > On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote:
> > > I know this may sound harsh, but: If you want things to work
> differently,
> > > send patches.
>
> In theory. In practice you send patches and then you get a response like
> "hmm,
> not sure about that, I would like to have it differently", and that
> without an
> actual suggestion how to do that "differently".
>
> Like you said, if you want things differently, send your patches. But then
> as
> a patch sender you have the same expectation: you don't like the patch,
> make a
> better suggestion! You don't have a better suggestion or at least an
> adequate
> feedback? Ok, then apply the patch and simply add FIXME comment(s) at your
> own
> discretion and maybe one day somebody replaces it with a better solution.
>
> Just one example, gtk3 (yes 3, not even 4) is currently completely
> unusable on
> Mac, so I sent a patch to fix this:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=791174
>
> I know my patch is suboptimal, but to make this clear: it does not address
> a
> minor bug, this bug is a real show stopper on Mac, and this change is
> purely
> gtk internal. Of course it is not a clean solution, but there is no reason
> to
> simply apply this patch (at a bare minimum at least to the gtk3/stable
> branch)
> with a FIXME comment for now so that people on Mac can finally start using
> gtk3
> at all.
>

I really have to agree. One of my bugs I raised in 2004 - which involves
data loss - is still open. I submitted a patch ( which was difficult at the
time - I only dabble in C when I absolutely have to ) which received very
little feedback, and the bug has rotted since. I believe it exists in gtk+
versions 2 and 3, but I removed support for GtkComboBoxEntry widgets from
all my code when porting to version 3 to avoid the issue entirely.

"Send a patch" only goes so far. If patches don't get reviewed, or don't
get sufficient feedback, and never get accepted, what's the point in
sending patches?

Dan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_log_set_fatal_mask() not working for me.

2017-12-17 Thread Eric Cashon via gtk-app-devel-list 

 
Hi Richard,

This sounds similar to the problem Dino Aljević had in "Scrolled TreeView and 
size allocation warnings" in this list in September?

I can get the warning

"(treeview4:3830): Gtk-WARNING **: Allocating size to GtkWindow 0x843e188 
without calling gtk_widget_get_preferred_width/height(). How does the code know 
the size to allocate?"

with the following code with GTK3.22.26 but I don't see the warning in 
GTK3.18.9. To get the warning expand the treeview until the list extends past 
the window boundry. I looked on Bugzilla but I didn't see it listed there. I am 
not great at finding things on Bugzilla so that doesn't mean it isn't there.

Do you have some test code to produce the GtkScrollbar warning you are seeing?

For the g_log_set_fatal_mask() and a runtime stop, try starting your code with 

G_DEBUG=fatal-warnings

It is a warning though. Something needs to be fixed but your program should run 
fine.

Eric



/*
gcc -Wall treeview4.c -o treeview4 `pkg-config --cflags --libs gtk+-3.0`
Tested on Ubuntu16.04 with GTK3.18.9 and GTK3.22.26

run with

G_DEBUG=fatal-warnings GTK_THEME=Adwaita:dark ./treeview4

this theme doesn't produce any css warnings with GTK3.22.26.

*/
#include

static GtkTreeStore* get_tree_store();

int main(int argc, char *argv[])
  {
gtk_init(, );

g_print("%i.%i.%i\n", GTK_MAJOR_VERSION, GTK_MINOR_VERSION, 
GTK_MICRO_VERSION);

g_log_set_fatal_mask("Gtk", G_LOG_LEVEL_WARNING);

GtkWidget *window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_title(GTK_WINDOW(window), "Tree View");
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
gtk_window_set_default_size(GTK_WINDOW(window), 300, 300);
g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);

GtkTreeStore *store=get_tree_store();

GtkWidget *tree=gtk_tree_view_new_with_model(GTK_TREE_MODEL(store));
gtk_tree_view_set_enable_search(GTK_TREE_VIEW(tree), TRUE);
g_object_unref(G_OBJECT(store));

GtkCellRenderer *renderer1=gtk_cell_renderer_text_new();
g_object_set(renderer1, "editable", TRUE, NULL);
   
GtkTreeViewColumn *column1 = 
gtk_tree_view_column_new_with_attributes("Shape Coordinates", renderer1, 
"text", 0, NULL);
gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column1); 

GtkWidget *scroll=gtk_scrolled_window_new(NULL, NULL);
gtk_container_set_border_width(GTK_CONTAINER(scroll), 5);
gtk_widget_set_vexpand(scroll, TRUE);
gtk_widget_set_hexpand(scroll, TRUE);
gtk_container_add(GTK_CONTAINER(scroll), tree);   

GtkWidget *grid=gtk_grid_new();
gtk_container_set_border_width(GTK_CONTAINER(grid), 20);
gtk_grid_attach(GTK_GRID(grid), scroll, 0, 0, 1, 1);
gtk_container_add(GTK_CONTAINER(window), grid);
   
gtk_widget_show_all(window);
gtk_main();
return 0;   
  }
static GtkTreeStore* get_tree_store()
  {
gint i=0;
gint j=0;
GtkTreeStore *store=gtk_tree_store_new(1, G_TYPE_STRING);

GtkTreeIter iter1;
GtkTreeIter iter2;
gtk_tree_store_append(store, , NULL);
for(i=0;i<3;i++)
  {
gchar *string1=g_strdup_printf("S%i", i);
gtk_tree_store_set(store, , 0, string1, -1);
g_free(string1);
for(j=0;j<5;j++)
  {
gtk_tree_store_append(store, , );   
gchar *string2=g_strdup_printf("C%i", j);
gtk_tree_store_set(store, , 0, string2, -1);
g_free(string2);
  }
gtk_tree_store_append(store, , NULL);
  }
  
return store;
  }

 


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

g_log_set_fatal_mask() not working for me.

2017-12-17 Thread Richard Shann 
I am getting a warning message:

 Gtk-WARNING **: Allocating size to GtkScrollbar 0x5647efd0 without
calling gtk_widget_get_preferred_width/height(). How does the code know
the size to allocate?

however when I call 

call g_log_set_fatal_mask ("Gtk", 1<<4)

at the start of main the warning is not converted into a fatal error.
I've tried

call g_log_set_fatal_mask ("Gtk", 0x)

as well, to no avail.

This is with Gtk version runtime: 3.22.11, compiled against: 3.22.11

Any suggestions to track down the source of the trouble gratefully
received...

Richard Shann
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list