Re: Dropping 'fringe' pixbuf loaders

2015-09-21 Thread Bastien Nocera 
On Mon, 2015-09-21 at 18:38 -0400, Matthias Clasen wrote:
> 
> On Mon, Sep 21, 2015 at 5:10 PM, Cosimo Cecchi 
> wrote:
> > 
> > On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor 
> > wrote:
> > > Do we trust this code or not? If not, we should either a) sandbox
> > > it or b) delete it.
> > > 
> > > Moving less-trusted loaders into a separate repo is a blame-the-
> > > user or blame-the-os-vendor move, depending on who installs them
> > > onto the system.
> > The only way to prevent the blame game you mention in a typical
> > distribution where everything is installed through packages would
> > be to stop supporting out of tree modules entirely, if I interpret
> > your concern correctly.
> > 
> > My point is that as long as that's the case, at least maintaining
> > them in a central location gives people an aggregation point for
> > fixes.
> > 
> But they are not being maintained by anybody, and the fixes have not
> been aggregating... every few years some security researchers decide
> to have a look at image loaders, and then we get a bunch of overflows
> and corruptions reported, and either me of Benjamin grudgingly fix
> them. And both of us are tired of doing that.

I would argue that at least I have taken care of some of that work at
the end of 2014. I didn't get to see coverity scans or cppchecks, but
this isn't the most complicated code to fix up and review.

If removing some of those loaders helps lighten the number of potential
bugs, sure, go for it.

As for removing those loaders, I'd double-check whether GIMP has native
support for those (not through a gdk-pixbuf loader), so that at least
some modicum of support is left for those, making it less likely that
we'll crash when somebody has a duff file in their file manager.

Cheers

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

Re: Auto-resize scrolled window

2015-09-21 Thread Subsentient 
I've already tried this. I'm afraid the scrolled window resizes 
horizontally, but not vertically.
I've even tried putting it into a GtkAlignment with full expansion. It's 
in a vbox btw.


On 09/21/15 17:46, Chris Moller wrote:


 Try gtk_window_set_default_size ()

On 09/21/15 20:33, Subsentient wrote:
When I resize the window, I'm having difficulty finding a way to make 
a scrolled window automatically resize with it. I can't use 
gtk_widget_set_size_request(), because then I won't be able to shrink 
it down again.
Working in C. How can I have a widget automatically resize to fill 
all available space given by a window, and then be willing to shrink 
again if the user tries to resize the window?


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


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

libvte color troubles.

2015-09-21 Thread Subsentient 
Writing a new terminal application with GTK and libvte, and setting 
colors is not working.


I'd like to know what I'm doing wrong.

vte_terminal_set_color_background() is ignored. Nothing changes, no 
warnings appear in stdout or stderr, just, nothing.



Here's some stub code that illustrates my problem.

P.S. It's curiously hard to find a decent guide on libvte. And yes, I 
know vte_terminal_fork_command() is deprecated.


   #include 
   #include 
   int main(int argc, char **argv)
   {
gtk_init(, );


GtkWidget *Win = gtk_window_new(GTK_WINDOW_TOPLEVEL);

GtkWidget *Term = vte_terminal_new();
GdkColor Color = { 0, 22323, 0xff * 255, 0xff * 255 };
vte_terminal_set_color_background((VteTerminal*)Term, );

vte_terminal_set_size((VteTerminal*)Term, 50, 30);




const char *ShellArgv[] = { "/usr/bin/bash", NULL };

gtk_container_add((GtkContainer*)Win, Term);

vte_terminal_fork_command((VteTerminal*)Term,
   (char*)*ShellArgv, (char**)ShellArgv, NULL, NULL, TRUE, TRUE, TRUE );


gtk_widget_show_all(Win);

gtk_main();

return 0;
   }





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

Re: libvte color troubles.

2015-09-21 Thread Ben Iofel 
> GdkColor Color = { 0, 22323, 0xff * 255, 0xff * 255 };
That doesn't look right. Shouldn't colors be in 0..255?

On Mon, Sep 21, 2015, 8:12 AM Subsentient  wrote:

> Writing a new terminal application with GTK and libvte, and setting
> colors is not working.
>
> I'd like to know what I'm doing wrong.
>
> vte_terminal_set_color_background() is ignored. Nothing changes, no
> warnings appear in stdout or stderr, just, nothing.
>
>
> Here's some stub code that illustrates my problem.
>
> P.S. It's curiously hard to find a decent guide on libvte. And yes, I
> know vte_terminal_fork_command() is deprecated.
>
> #include 
> #include 
> int main(int argc, char **argv)
> {
>  gtk_init(, );
>
>
>  GtkWidget *Win = gtk_window_new(GTK_WINDOW_TOPLEVEL);
>
>  GtkWidget *Term = vte_terminal_new();
>  GdkColor Color = { 0, 22323, 0xff * 255, 0xff * 255 };
>  vte_terminal_set_color_background((VteTerminal*)Term, );
>
>  vte_terminal_set_size((VteTerminal*)Term, 50, 30);
>
>
>
>
>  const char *ShellArgv[] = { "/usr/bin/bash", NULL };
>
>  gtk_container_add((GtkContainer*)Win, Term);
>
>  vte_terminal_fork_command((VteTerminal*)Term,
> (char*)*ShellArgv, (char**)ShellArgv, NULL, NULL, TRUE, TRUE, TRUE );
>
>
>  gtk_widget_show_all(Win);
>
>  gtk_main();
>
>  return 0;
> }
>
>
>
>
>
> ___
> 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: Dropping 'fringe' pixbuf loaders

2015-09-21 Thread Matthias Clasen 
On Mon, Sep 21, 2015 at 5:10 PM, Cosimo Cecchi  wrote:

>
> On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor  wrote:
>
>> Do we trust this code or not? If not, we should either a) sandbox it or
>> b) delete it.
>>
>> Moving less-trusted loaders into a separate repo is a blame-the-user or
>> blame-the-os-vendor move, depending on who installs them onto the system.
>>
>
> The only way to prevent the blame game you mention in a typical
> distribution where everything is installed through packages would be to
> stop supporting out of tree modules entirely, if I interpret your concern
> correctly.
>
> My point is that as long as that's the case, at least maintaining them in
> a central location gives people an aggregation point for fixes.
>

But they are not being maintained by anybody, and the fixes have not been
aggregating... every few years some security researchers decide to have a
look at image loaders, and then we get a bunch of overflows and corruptions
reported, and either me of Benjamin grudgingly fix them. And both of us are
tired of doing that.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Auto-resize scrolled window

2015-09-21 Thread Subsentient 
When I resize the window, I'm having difficulty finding a way to make a 
scrolled window automatically resize with it. I can't use 
gtk_widget_set_size_request(), because then I won't be able to shrink it 
down again.
Working in C. How can I have a widget automatically resize to fill all 
available space given by a window, and then be willing to shrink again 
if the user tries to resize the window?


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

Re: Auto-resize scrolled window

2015-09-21 Thread Chris Moller 


 Try gtk_window_set_default_size ()

On 09/21/15 20:33, Subsentient wrote:
When I resize the window, I'm having difficulty finding a way to make 
a scrolled window automatically resize with it. I can't use 
gtk_widget_set_size_request(), because then I won't be able to shrink 
it down again.
Working in C. How can I have a widget automatically resize to fill all 
available space given by a window, and then be willing to shrink again 
if the user tries to resize the window?


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: Dropping 'fringe' pixbuf loaders

2015-09-21 Thread Cosimo Cecchi 
On Mon, Sep 21, 2015 at 8:28 AM, Matthias Clasen 
wrote:

> Before doing so, I want to ask if anybody is willing to step up and
> maintain these loaders.  Note that even if we drop these from gdk-pixbuf
> itself, they can be maintained out-of-tree... one of the advantages of
> having loaders as modules.
>

Not stepping up to maintain those, but I really like Emmanuele's idea of
splitting the other modules into a separate repository on git.gnome.org; I
think there is value in keeping them all in a central location.

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

Re: Dropping 'fringe' pixbuf loaders

2015-09-21 Thread Owen Taylor 
Do we trust this code or not? If not, we should either a) sandbox it or b) 
delete it.

Moving less-trusted loaders into a separate repo is a blame-the-user or 
blame-the-os-vendor move, depending on who installs them onto the system.

- Owen

- Original Message -
> On Mon, Sep 21, 2015 at 8:28 AM, Matthias Clasen < matthias.cla...@gmail.com
> > wrote:
> 
> > Before doing so, I want to ask if anybody is willing to step up and maintain
> > these loaders. Note that even if we drop these from gdk-pixbuf itself, they
> > can be maintained out-of-tree... one of the advantages of having loaders as
>  modules.
> 
> Not stepping up to maintain those, but I really like Emmanuele's idea of
> splitting the other modules into a separate repository on git.gnome.org ; I
> think there is value in keeping them all in a central location.
> 
> Cosimo
> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

2015-09-21 Thread Cosimo Cecchi 
On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor  wrote:

> Do we trust this code or not? If not, we should either a) sandbox it or b)
> delete it.
>
> Moving less-trusted loaders into a separate repo is a blame-the-user or
> blame-the-os-vendor move, depending on who installs them onto the system.
>

The only way to prevent the blame game you mention in a typical
distribution where everything is installed through packages would be to
stop supporting out of tree modules entirely, if I interpret your concern
correctly.

My point is that as long as that's the case, at least maintaining them in a
central location gives people an aggregation point for fixes.

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