Ir para o conteúdo

Thin logo

Tela cheia Sugerir um artigo
 Feed RSS

Grupo de Usuários Debian da Bahia - GUD/BA

7 de Dezembro de 2009, 0:00 , por Software Livre Brasil - | Ninguém está seguindo este artigo ainda.

Seja bem vind@, se você é um debiano (um baiano que usa debian) faça parte de nossa comunidade!

New Features in Picasso

23 de Setembro de 2014, 12:52, por Software Livre Brasil - 0sem comentários ainda

I’ve always been a big fan of Picasso, the Android image loading library by the Square folks. It provides some powerful features with a rather simple API.

Recently, I started working on a set of new features for Picasso that will make it even more awesome: request handlers, request management, and request priorities. These features have all been merged to the main repo now. Let me give you a quick overview of what they enable you to do.

Request Handlers

Picasso supports a wide variety of image sources, from simple resources to content providers, network, and more. Sometimes though, you need to load images in unconventional ways that are not supported by default in Picasso.

Wouldn’t it be nice if you could easily integrate your custom image loading logic with Picasso? That’s what the new request handlers are about. All you need to do is subclass RequestHandler and implement a couple of methods. For example:

public class PonyRequestHandler extends RequestHandler {
    private static final String PONY_SCHEME = "pony";

    @Override public boolean canHandleRequest(Request data) {
        return PONY_SCHEME.equals(data.uri.getScheme());

    @Override public Result load(Request data) {
         return new Result(somePonyBitmap, MEMORY);

Then you register your request handler when instantiating Picasso:

Picasso picasso = new Picasso.Builder(context)
    .addRequestHandler(new PonyHandler())

Voilà! Now Picasso can handle pony URIs:


This pull request also involved rewriting all built-in bitmap loaders on top of the new API. This means you can also override the built-in request handlers if you need to.

Request Management

Even though Picasso handles view recycling, it does so in an inefficient way. For instance, if you do a fling gesture on a ListView, Picasso will keep triggering and canceling requests blindly because there was no way to make it pause/resume requests according to the user interaction. Not anymore!

The new request management APIs allow you to tag associated requests that should be managed together. You can then pause, resume, or cancel requests associated with specific tags. The first thing you have to do is tag your requests as follows:


Then you can pause and resume requests with this tag based on, say, the scroll state of a ListView. For example, Picasso’s sample app now has the following scroll listener:

public class SampleScrollListener implements AbsListView.OnScrollListener {
    public void onScrollStateChanged(AbsListView view, int scrollState) {
        Picasso picasso = Picasso.with(context);
        if (scrollState == SCROLL_STATE_IDLE ||
            scrollState == SCROLL_STATE_TOUCH_SCROLL) {
        } else {

These APIs give you a much finer control over your image requests. The scroll listener is just the canonical use case.

Request Priorities

It’s very common for images in your Android UI to have different priorities. For instance, you may want to give higher priority to the big hero image in your activity in relation to other secondary images in the same screen.

Up until now, there was no way to hint Picasso about the relative priorities between images. The new priority API allows you to tell Picasso about the intended order of your image requests. You can just do:


These priorities don’t guarantee a specific order, they just tilt the balance in favour of higher-priority requests.

That’s all for now. Big thanks to Jake Wharton and Dimitris Koutsogiorgas for the prompt code and API reviews!

You can try these new APIs now by fetching the latest Picasso code on Github. These features will probably be available in the 2.4 release. Enjoy!

Introducing Probe

16 de Setembro de 2014, 7:32, por Software Livre Brasil - 0sem comentários ainda

We’ve all heard of the best practices regarding layouts on Android: keep your view tree as simple as possible, avoid multi-pass layouts high up in the hierarchy, etc. But the truth is, it’s pretty hard to see what’s actually going on in your view tree in each UI traversal (measure → layout → draw).

We’re well served with developer options for tracking graphics performance—debug GPU overdraw, show hardware layers updates, profile GPU rendering, and others. However, there is a big gap in terms of development tools for tracking layout traversals and figuring out how your layouts actually behave. This is why I created Probe.

Probe is a small library that allows you to intercept view method calls during Android’s layout traversals e.g. onMeasure(), onLayout(), onDraw(), etc. Once a method call is intercepted, you can either do extra things on top of the view’s original implementation or completely override the method on-the-fly.

Using Probe is super simple. All you have to do is implement an Interceptor. Here’s an interceptor that completely overrides a view’s onDraw(). Calling super.onDraw() would call the view’s original implementation.

public class DrawGreen extends Interceptor {
    private final Paint mPaint;

    public DrawGreen() {
        mPaint = new Paint();

    public void onDraw(View view, Canvas canvas) {

Then deploy your Interceptor by inflating your layout with a Probe:

Probe probe = new Probe(this, new DrawGreen(), new Filter.ViewId(;
View root = probe.inflate(R.layout.main_activity, null);

Just to give you an idea of the kind of things you can do with Probe, I’ve already implemented a couple of built-in interceptors. OvermeasureInterceptor tints views according to the number of times they got measured in a single traversal i.e. equivalent to overdraw but for measurement.

LayoutBoundsInterceptor is equivalent to Android’s “Show layout bounds” developer option. The main difference is that you can show bounds only for specific views.

Under the hood, Probe uses Google’s DexMaker to generate dynamic View proxies during layout inflation. The stock ProxyBuilder implementation was not good enough for Probe because I wanted to avoid using reflection entirely after the proxy classes were generated. So I created a specialized View proxy builder that generates proxy classes tailored for Probe’s use case.

This means Probe takes longer than your usual LayoutInflater to inflate layout resources. There’s no use of reflection after layout inflation though. Your views should perform the same. For now, Probe is meant to be a developer tool only and I don’t recommend using it in production.

The code is available on Github. As usual, contributions are very welcome.

Introducing dspec

8 de Setembro de 2014, 10:52, por Software Livre Brasil - 0sem comentários ainda

With all the recent focus on baseline grids, keylines, and spacing markers from Android’s material design, I found myself wondering how I could make it easier to check the correctness of my Android UI implementation against the intended spec.

Wouldn’t it be nice if you could easily provide the spec values as input and get it rendered on top of your UI for comparison? Enter dspec, a super simple way to define UI specs that can be rendered on top of Android UIs.

Design specs can be defined either programmatically through a simple API or via JSON files. Specs can define various aspects of the baseline grid, keylines, and spacing markers such as visibility, offset, size, color, etc.

Baseline grid, keylines, and spacing markers in action.

Baseline grid, keylines, and spacing markers in action.

Given the responsive nature of Android UIs, the keylines and spacing markers are positioned in relation to predefined reference points (e.g. left, right, vertical center, etc) instead of absolute offsets.

The JSON files are Android resources which means you can easily adapt the spec according to different form factors e.g. different specs for phones and tablets. The JSON specs provide a simple way for designers to communicate their intent in a computer-readable way.

You can integrate a DesignSpec with your custom views by drawing it in your View‘s onDraw(Canvas) method. But the simplest way to draw a spec on top of a view is to enclose it in a DesignSpecFrameLayout—which can take an designSpec XML attribute pointing to the spec resource. For example:


I can’t wait to start using dspec in some of the new UI work we’re doing Firefox for Android now. I hope you find it useful too. The code is available on Github. As usual, testing and fixes are very welcome. Enjoy!

DebConf 14: Community, Debian CI, Ruby, Redmine, and Noosfero

1 de Setembro de 2014, 22:46, por Software Livre Brasil - 0sem comentários ainda

This time, for personal reasons I wasn’t able to attend the full DebConf, which started on the Saturday August 22nd. I arrived at Portland on the Tuesday the 26th by noon, at the 4th of the conference. Even though I would like to arrive earlier, the loss was alleviated by the work of the amazing DebConf video team. I was able to follow remotely most of the sessions I would like to attend if I were there already.

As I will say to everyone, DebConf is for sure the best conference I have ever attended. The technical and philosophical discussions that take place in talks, BoF sessions or even unplanned ad-hoc gathering are deep. The hacking moments where you have a chance to pair with fellow developers, with whom you usually only have contact remotely via IRC or email, are precious.

That is all great. But definitively, catching up with old friends, and making new ones, is what makes DebConf so special. Your old friends are your old friends, and meeting them again after so much time is always a pleasure. New friendships will already start with a powerful bond, which is being part of the Debian community.

Being only 4 hours behind my home time zone, jetlag wasn’t a big problem during the day. However, I was waking up too early in the morning and consequently getting tired very early at night, so I mostly didn’t go out after hacklabs were closed at 10PM.

Despite all of the discussion, being in the audience for several talks, other social interactions and whatnot, during this DebConf I have managed to do quite some useful work.

debci and the Debian Continuous Integration project

I gave a talk where I discussed past, present, and future of debci and the Debian Continuous Integration project. The slides are available, as well as the video recording. One thing I want you to take away is that there is a difference between debci and the Debian Continuous Integration project:

  • debci is a platform for Continuous Integration specifically tailored for the Debian repository and similar ones. If you work on a Debian derivative, or otherwise provides Debian packages in a repository, you can use debci to run tests for your stuff.
    • a (very) few thinks in debci, though, are currently hardcoded for Debian. Other projects using it would be a nice and needed peer pressure to get rid of those.
  • Debian Continuous Integration is Debian’s instance of debci, which currently runs tests for all packages in the unstable distribution that provide autopkgtest support. It will be expanded in the future to run tests on other suites and architectures.

A few days before DebConf, Cédric Boutillier managed to extract gem2deb-test-runner from gem2deb, so that autopkgtest tests can be run against any Ruby package that has tests by running gem2deb-test-runner --autopkgtest. gem2deb-test-runner will do the right thing, make sure that the tests don’t use code from the source package, but instead run them against the installed package.

Then, right after my talk I was glad to discover that the Perl team is also working on a similar tool that will automate running tests for their packages against the installed package. We agreed that they will send me a whitelist of packages in which we could just call that tool and have it do The Right Thing.

We might be talking here about getting autopkgtest support (and consequentially continuous integration) for free for almost 2000 packages. The missing bits for this to happen are:

  • making debci use a whitelist of packages that, while not having the appropriate Testsuite: autopkgtest field in the Sources file, could be assumed to have autopkgtest support by calling the right tool (gem2deb-test-runner for Ruby, or the Perl team’s new tool for Perl packages).
  • make the autopkgtest test runner assume a corresponding, implicit, debian/tests/control when it not exists in those packages

During a few days I have mentored Lucas Kanashiro, who also attended DebConf, on writing a patch to add support for email notifications in debci so maintainers can be pro-actively notified of status changes (pass/fail, fail/pass) in their packages.

I have also started hacking on the support for distributed workers, based on the initial work by Martin Pitt:

  • updated the amqp branch against the code in the master branch.
  • added a debci enqueue command that can be used to force test runs for packages given on the command line.
  • I sent a patch for librabbitmq that adds support for limiting the number of messages the server will send to a connected client. With this patch applied, the debci workers were modified to request being sent only 1 message at a time, so late workers will start to receive packages to process as soon as they are up. Without this, a single connected worker would receive all messages right away, while a second worker that comes up 1 second later would sit idle until new packages are queued for testing.


I had some discusion with Christian about making Rubygems install to $HOME by default when the user is not root. We discussed a few implementation options, and while I don’t have a solution yet, we have a better understanding of the potential pitfalls.

The Ruby BoF session on Friday produced a few interesting discussions. Some take away point include, but are not limited to:

  • Since the last DebConf, we were able to remove all obsolete Ruby interpreters, and now only have Ruby 2.1 in unstable. Ruby 2.1 will be the default version in Debian 8 (jessie).
  • There is user interest is being able to run the interpreter from Debian, but install everything else from Rubygems.
  • We are lacking in all the documentation-related goals for jessie that were proposed at the previous DebConf.


I was able to make Redmine work with the Rails 4 stack we currently have in unstable/testing. This required using a snapshot of the still unreleased version 3.0 based on the rails-4.1 branch in the upstream Subversion repository as source.

I am a little nervous about using a upstream snapshot, though. According to the "roadmap of the project ": the only purpose of the 3.0 release will be to upgrade to Rails 4, but before that happens there should be a 2.6.0 release that is also not released yet. 3.0 should be equivalent to that 2.6.0 version both feature-wise and, specially, bug-wise. The only problem is that we don’t know what that 2.6.0 looks like yet. According to the roadmap it seems there is not much left in term of features for 2.6.0, though.

The updated package is not in unstable yet, but will be soon. It needs more testing, and a good update to the documentation. Those interested in helping to test Redmine on jessie before the freeze please get in touch with me.


I gave a lighting talk on Noosfero, a platform for social networking websites I am upstream for. It is a Rails appplication licensed under the AGPLv3, and there are packages for wheezy. You can checkout the slides I used. Video recording is not available yet, but should be soon.

That’s it. I am looking forward to DebConf 15 at Heidelberg. :-)

KDE Connect, usando seu celular como controle remoto do PC

1 de Setembro de 2014, 10:15, por Software Livre Brasil - 0sem comentários ainda

KDE Connect é um projeto que tem objetivo comunicar o KDE com seu celular.

Com o KDE Connect hoje é possível fazer várias coisas interessantes:

  • Enviar e receber arquivos do seu celular
  • Notifica no seu KDE quando recebe ligação e mensagem SMS no celular
  • Informa no seu KDE a carga atual da sua bateria do celular
  • Navega nos arquivos do seu celular via KDE
  • Pausa o som do seu KDE quando recebe ligação
  • Controle multimídia do KDE a partir do celular
  • Controle do ponteiro do mouse no KDE a partir do KDE

Para usar é muito fácil, basta instalar um aplicativo em seu KDE e outro no celular.

No seu KDE, caso utilize debian, pode instalar com o seguinte comando:

# aptitude install kdeconnect

Obs: Infelizmente o debian, mesmo a versão unstable, não tem a versão mais nova do kdeconnect.

Caso queira instalar a versão mais nova do KDE Connect, siga os passos abaixo:

# aptitude install kde-workspace-dev libqca2-dev libqjson-dev libxtst-dev libfakekey-dev git
# git clone git://
# cd kdeconnect-kde
# mkdir build
# cd build
# cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4

# make
# sudo make install

Depois de instalado, ele aparecerá em seu gerenciador do KDE


Para instalar a versão android do KDE Connect no seu celular basta procurar no seu google play o KDE Connect e instalar, da mesma forma como faz para todos outros aplicativos do android.

O KDE Connect se conecta de forma bem simples, basta que os dois dispositivos estejam na mesma rede WiFi.

Obs: Infelizmente ele ainda não tem suporte a conexão via bluetooth.

Quando um celular que tem o aplicativo KDE Connect acessar uma rede, ele envia um broadcast para buscar dispositivos com KDE Connect instalado no KDE. Uma vez encontrado, o KDE interage automaticamente com o dispositivo apenas para coletar informações de acesso, ou seja, os dispositivos não se conectam automaticamente.


Lista de dispositivos com KDE Connect na mesma rede

Uma vez encontrado o aparelho desejado para conexão, é necessário efetuar uma liberação em ambos dispositivos.


O celular pode solicitar pareamento com o KDE

Uma vez recebido a solicitação de pareamento, o KDE pode ou não autorizar a conexão.


Aparecerá uma notificação em seu KDE

O inicio dessa conexão pode ser em sentido contrário, ou seja, o KDE lista os celulares com KDE Connect instalado e solicitar pareamento, sendo assim você precisará confirmar em seu telefone.

Como foi dito em seu blog (Inglês), o criador da ferramenta utiliza criptografia para assegurar a segurança da comunicação. Eu ainda não fui a fundo na analise dessa questão, mas como as funções são simples e bem reguladas, não vejo problema do seu uso com cautela até então.

Pronto! Agora poderá otimizar a comunicação entre seu celular e estação com KDE.

plasmoid desktop_send_file mobile_touchpad

Obs: Todas as fotos foram retiradas do site do Ronny, que é um dos desenvolvedores do KDE Connect.

Fontes :