<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Leandro A. F. Pereira &#187; glib</title>
	<atom:link href="http://labs.hardinfo.org/mindcrisis/category/glib/feed/" rel="self" type="application/rss+xml" />
	<link>http://labs.hardinfo.org/mindcrisis</link>
	<description>geek em treinamento</description>
	<lastBuildDate>Fri, 18 Jun 2010 21:46:47 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Usando o main loop da GLib para liberar memória temporária</title>
		<link>http://labs.hardinfo.org/mindcrisis/2007/01/02/usando-o-main-loop-da-glib-para-liberar-memoria-temporaria/</link>
		<comments>http://labs.hardinfo.org/mindcrisis/2007/01/02/usando-o-main-loop-da-glib-para-liberar-memoria-temporaria/#comments</comments>
		<pubDate>Tue, 02 Jan 2007 17:46:51 +0000</pubDate>
		<dc:creator>acidx</dc:creator>
				<category><![CDATA[c]]></category>
		<category><![CDATA[glib]]></category>
		<category><![CDATA[gtk]]></category>
		<category><![CDATA[hack]]></category>
		<category><![CDATA[idle_free]]></category>
		<category><![CDATA[programming]]></category>

		<guid isPermaLink="false">http://labs.hardinfo.org/mindcrisis/?p=240</guid>
		<description><![CDATA[(English version below.) Quando se programa com GTK+ (ou GLib) em C, muitas vezes faz-se necessário o uso de variáveis temporárias alocadas dinamicamente. O problema é ter que lembrar de liberá-las na hora correta &#8212; ou pior &#8212; ter que usar mais variávies auxiliares, como no exemplo abaixo: gchar *funcao(void) { gchar *temp = g_strdup("sou [...]]]></description>
			<content:encoded><![CDATA[<p><em>(English version below.)</em></p>
<p>Quando se programa com GTK+ (ou GLib) em C, muitas vezes faz-se necessário o uso de variáveis temporárias alocadas dinamicamente. O problema é ter que lembrar de liberá-las na hora correta &#8212; ou pior &#8212; ter que usar mais variávies auxiliares, como no exemplo abaixo:</p>
<pre><code>gchar *funcao(void) {
gchar *temp = g_strdup("sou uma string temporaria");
return g_strdup_printf("%s -> %f", temp, G_PI);
}</code></pre>
<p>Nesse exemplo, a variável temp irá vazar memória, pois ela não foi liberada após a execução do g_strdup_printf e do retorno da função. Uma maneira de resolver isso seria reescrevendo funcao como:</p>
<pre><code>gchar *funcao(void) {
gchar *temp = g_strdup("sou uma string temporaria");
gchar *temp2 = g_strdup_printf("%s -> %f", temp, G_PI);
g_free(temp);
return temp2;
}</code></pre>
<p>Agora está melhor: a variável temp não irá vazar, mas fomos obrigados a usar mais uma variável. A solução que proponho é bem simples, mas requer que seu programa rode na main loop da GLib. É para ser usado apenas em funções de callback. Não é threadsafe. Inclua essas duas pequenas funções em seu programa:</p>
<pre><code>static gboolean __idle_free_do(gpointer ptr) {
g_free(ptr);
return FALSE;
}

void gpointer idle_free(gpointer ptr) {
g_idle_add(__idle_free_do, ptr);
return ptr;
}</code></pre>
<p>Agora podemos reescrever a função teste como:</p>
<pre><code>gchar *funcao(void) {
gchar *temp = idle_free(g_strdup("sou uma string temporaria"));
return g_strdup_printf("%s -> %f", temp, G_PI);
}</code></pre>
<p>Assim a variável temp será liberada logo que o loop da GLib estiver livre para processar eventos. É uma idéia simples e prática&#8230; acho que deveria ser inclusa na GLib por padrão.</p>
<p>(façam o uso que quiser desse código, está em domínio público)</p>
<p><span id="more-240"></span><br />
<a name="english_382"></a><a href="#english_382">Using GLib main loop to free up temporary memory</a></p>
<p>When you program with GTK+ (or GLib) with C, sometimes there&#8217;s a need for temporary dynamically-allocated variables. The problem is to free them in the right time &#8212; or worse &#8212; having to use even more auxiliary variables, like in the example below:</p>
<pre><code>gchar *func(void) {
gchar *temp = g_strdup("i am a temporary string");
return g_strdup_printf("%s -> %f", temp, G_PI);
}</code></pre>
<p>In this example, the temp variable will leak memory, since it was not freed after g_strdup_printf. A way to fix this would be rewriting func as:</p>
<pre><code>gchar *func(void) {
gchar *temp = g_strdup("i am a temporary string");
gchar *temp2 = g_strdup_printf("%s -> %f", temp, G_PI);
g_free(temp);
return temp2;
}</code></pre>
<p>Much better: temp won&#8217;t leak anymore, but we had to use another variable. I propose a simpler solution, but it requires that your program runs in the GLib main loop. It should be used only on callback functions and is not threadsafe. Include these two tiny functions in your program:</p>
<pre><code>static gboolean __idle_free_do(gpointer ptr) {
g_free(ptr);
return FALSE;
}

void gpointer idle_free(gpointer ptr) {
g_idle_add(__idle_free_do, ptr);
return ptr;
}</code></pre>
<p>Now we can rewrite func as:</p>
<pre><code>gchar *func(void) {
gchar *temp = idle_free(g_strdup("i am a temporary variable"));
return g_strdup_printf("%s -> %f", temp, G_PI);
}</code></pre>
<p>This way the memory will be freed as soon as GLib gains control and the main loop is ready to process events.</p>
]]></content:encoded>
			<wfw:commentRss>http://labs.hardinfo.org/mindcrisis/2007/01/02/usando-o-main-loop-da-glib-para-liberar-memoria-temporaria/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Abrindo o browser padrão&#8230;</title>
		<link>http://labs.hardinfo.org/mindcrisis/2006/10/27/abrindo-o-browser-padrao/</link>
		<comments>http://labs.hardinfo.org/mindcrisis/2006/10/27/abrindo-o-browser-padrao/#comments</comments>
		<pubDate>Fri, 27 Oct 2006 16:00:20 +0000</pubDate>
		<dc:creator>acidx</dc:creator>
				<category><![CDATA[c]]></category>
		<category><![CDATA[geek]]></category>
		<category><![CDATA[glib]]></category>
		<category><![CDATA[programming]]></category>

		<guid isPermaLink="false">http://labs.hardinfo.org/mindcrisis/?p=225</guid>
		<description><![CDATA[Essa tarefa é um pouco chata em ambientes Unix: não há uma maneira padrão (salvo o Portland, que ainda não deve estar disponível na base já instalada), e perguntar para o usuário qual o browser dele não é uma opção. A rotina abaixo deve ser suficiente e funcionar bem em qualquer programa que use a [...]]]></description>
			<content:encoded><![CDATA[<p>Essa tarefa é um pouco chata em ambientes Unix: não há uma maneira padrão (salvo o Portland, que ainda não deve estar disponível na base já instalada), e perguntar para o usuário qual o browser dele não é uma opção. A rotina abaixo deve ser suficiente e funcionar bem em qualquer programa que use a GLib. Em suma, ela vai tentando abrir a URL fornecida com browsers conhecidos, tentando com o já citado Portland (xdg-open), gnome-open, kfmclient (konqueror), dentre outras opções. Se tudo for esgotado, uma mensagem é mostrada ao usuário dizendo que não foi possível encontrar um browser.</p>
<p><code /></p>
<pre>void
open_url(gchar *url)
{
const gchar *browsers[] = { "xdg-open", "gnome-open",
"kfmclient openURL", "sensible-browser",
"firefox", "epiphany", "galeon", "mozilla",
"opera", "konqueror", "links -g", NULL};
gint i;

for (i = 0; browsers[i]; i++) {
gchar *cmdline = g_strdup_printf("%s '%s'", browsers[i], url);

if (g_spawn_command_line_async(cmdline, NULL)) {
g_free(cmdline);
return;
}

g_free(cmdline);
}

g_warning("Couldn't find a Web browser to open URL %s.", url);
}</pre>
]]></content:encoded>
			<wfw:commentRss>http://labs.hardinfo.org/mindcrisis/2006/10/27/abrindo-o-browser-padrao/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Delay em aplicações GTK+</title>
		<link>http://labs.hardinfo.org/mindcrisis/2006/10/15/delay-em-aplicacoes-gtk/</link>
		<comments>http://labs.hardinfo.org/mindcrisis/2006/10/15/delay-em-aplicacoes-gtk/#comments</comments>
		<pubDate>Sun, 15 Oct 2006 16:14:15 +0000</pubDate>
		<dc:creator>acidx</dc:creator>
				<category><![CDATA[c]]></category>
		<category><![CDATA[glib]]></category>
		<category><![CDATA[gtk]]></category>
		<category><![CDATA[hack]]></category>
		<category><![CDATA[programming]]></category>

		<guid isPermaLink="false">http://labs.hardinfo.org/mindcrisis/?p=221</guid>
		<description><![CDATA[Se desenvolve aplicações em GTK+, certamente já sentiu necessidade de colocar um pequeno delay dentro de um callback. O problema é que se o delay demorar mais que 10ms, o usuário pode perceber e a interface vai travar, o que não é nada agradável. A solução abaixo é bem simples e permite que seu código [...]]]></description>
			<content:encoded><![CDATA[<p>Se desenvolve aplicações em GTK+, certamente já sentiu necessidade de colocar um pequeno delay dentro de um callback. O problema é que se o delay demorar mais que 10ms, o usuário pode perceber e a interface vai travar, o que não é nada agradável.</p>
<p>A solução abaixo é bem simples e permite que seu código fique parado por (pelo menos) dados milisegundos, sem parar o loop principal do GTK+. Está em C, mas usar a mesma técnica em outra linguagem é trivial:</p>
<blockquote>
<pre>static gboolean __nonblock_cb(gpointer data)
{
gtk_main_quit();
return FALSE;
}

void nonblock_sleep(guint msec)
{
g_timeout_add(msec, (GSourceFunc)__nonblock_cb, NULL);
gtk_main();
}</pre>
</blockquote>
]]></content:encoded>
			<wfw:commentRss>http://labs.hardinfo.org/mindcrisis/2006/10/15/delay-em-aplicacoes-gtk/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.280 seconds -->
