GoldenDict, a definição e tradução de verbetes em uma tecla de atalho

Quem nunca precisou de um programa pra agilizar pesquisas de significados das palavras, definição no Wikipédia, tradução e afins, tudo com teclas de atalho, sem precisar acessar outros aplicativos ou sites web?

A primeira vista, pode parecer algo bobo e desnecessário, mas quando está lendo um texto longo, parar tudo para acessar um dicionário externo geralmente é uma perda de tempo, que pode atrapalhar seu entendimento sobre o assunto.

Para resolver esse problema, temos o GoldenDict, que é um aplicativo feito em QT. Bem simples, direto e extensível, pois aceita adição de diversos dicionários.

Usando o GoldenDict

Pra usar o GoldenDict é bastante simples, basta selecionar a palavra e digitar o atalho “Ctrl+c” duas vezes seguidas. Com isso aparecerá uma tela com informação disponível em todos dicionários configurados.

Para instalar no Debian ou Ubuntu, é muito simples, basta digitar o comando abaixo:

# apt-get install goldendict -y

No debian ele acompanha por padrão apenas o Wikipédia, sendo assim vamos facilitar seu trabalho com instalação de novos dicionários. Baixe esse arquivo e descompacte em uma pasta.

Obs: Alguns dos arquivos dessa base de dados são proprietários, infelizmente.

Acesse o aplicativo goldendict via ícone, acesse o menu “Editar” e escolha a opção “Dicionários”.

Escolha as abas “Fontes” e “Arquivos”. Em seguida clique no ícone “Adicionar…” escolha sua pasta que acabou de descompactar.

Por fim marque a opção “Buscar em subpastas” e clique no botão “Ok”.

Se você deseja colaborar, basta comprar a versão para android desse software, que é paga. Essa versão android serve como método de financiamento para o projeto GoldenDict. Custa menos de R$ 12,00.

New blog, new life

After so many time with my blog stopped, I decided to reboot the system, so I will keep all my content here and start from scratch even.

Here you will be in touch with my knowledge about IT infrastructure, security and my attempts on software development.

This blog will also talk about other subjects, more subjective, such as poetry, prose and thoughts about political organization.

If you want to avoid some articles, use the categories that are left and access the link directly. For the free software you can use http://techfree.com.br/category/softwarelivre/ for example.

I hope to share the best way all my knowledge. Do not be shy to interact, it is the idea of ​​this blog.

The new TwoWayView

What if writing custom view recycling layouts was a lot simpler? This question stuck in my mind since I started writing Android apps a few years ago.

The lack of proper extension hooks in the AbsListView API has been one of my biggest pain points on Android. The community has come up with different layout implementations that were largely based on AbsListView‘s code but none of them really solved the framework problem.

So a few months ago, I finally set to work on a new API for TwoWayView that would provide a framework for custom view recycling layouts. I had made some good progress but then Google announced RecyclerView at I/O and everything changed.

At first sight, RecyclerView seemed to be an exact overlap with the new TwoWayView API. After some digging though, it became clear that RecyclerView was a superset of what I was working on. So I decided to embrace RecyclerView and rebuild TwoWayView on top of it.

The new TwoWayView is functional enough now. Time to get some early feedback. This post covers the upcoming API and the general-purpose layout managers that will ship with it.

Creating your own layouts

RecyclerView itself doesn’t actually do much. It implements the fundamental state handling around child views, touch events and adapter changes, then delegates the actual behaviour to separate components—LayoutManager, ItemDecoration, ItemAnimator, etc. This means that you still have to write some non-trivial code to create your own layouts.

LayoutManager is a low-level API. It simply gives you extension points to handle scrolling and layout. For most layouts, the general structure of a LayoutManager implementation is going to be very similar—recycle views out of parent bounds, add new views as the user scrolls, layout scrap list items, etc.

Wouldn’t it be nice if you could implement LayoutManagers with a higher-level API that was more focused on the layout itself? Enter the new TwoWayView API.

TwoWayLayoutManager^code is a simple API on top of LayoutManager that does all the laborious work for you so that you can focus on how the child views are measured, placed, and detached from the RecyclerView.

To get a better idea of what the API looks like, have a look at these sample layouts: SimpleListLayout is a list layout and GridAndListLayout is a more complex example where the first N items are laid out as a grid and the remaining ones behave like a list. As you can see you only need to override a couple of simple methods to create your own layouts.

Built-in layouts

The new API is pretty nice but I also wanted to create a space for collaboration around general-purpose layout managers. So far, Google has only provided LinearLayoutManager. They might end up releasing a few more layouts later this year but, for now, that is all we got.

The new TwoWayView ships with a collection of four built-in layouts: List, Grid, Staggered Grid, and Spannable Grid.

These layouts support all RecyclerView features: item animations, decorations, scroll to position, smooth scroll to position, view state saving, etc. They can all be scrolled vertically and horizontally—this is the TwoWayView project after all ;-)

You probably know how the List and Grid layouts work. Staggered Grid arranges items with variable heights or widths into different columns or rows according to its orientation.

Spannable Grid is a grid layout with fixed-size cells that allows items to span multiple columns and rows. You can define the column and row spans as attributes in the child views as shown below.

<FrameLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:colSpan="2"
    app:rowSpan="3">
    ...
</FrameLayout>

Utilities

The new TwoWayView API will ship with a convenience view (TwoWayView) that can take a layoutManager XML attribute that points to a layout manager class.

<org.lucasr.twowayview.widget.TwoWayView
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:layoutManager="ListLayoutManager"/>

This way you can leverage the resource system to set layout manager depending on device features and configuration via styles.

You can also use ItemClickSupport to use ListView-style item (long) click listeners. You can easily plug-in support for those in any RecyclerView (see sample).

I’m also planning to create pluggable item decorations for dividers, item spacing, list selectors, and more.

That’s all for now! The API is still in flux and will probably go through a few more iterations. The built-in layouts definitely need more testing.

You can help by filing (and fixing) bugs and giving feedback on the API. Maybe try using the built-in layouts in your apps and see what happens?

I hope TwoWayView becomes a productive collaboration space for RecyclerView extensions and layouts. Contributions are very welcome!

HOPE X ical for schedule

An introduction to the Debian Continuous Integration project

Debian is a big system. At the time of writing, looking at my local package list caches tells me that the unstable suite contains 21306 source packages, and 42867 binary packages on amd64. Between these 42867 binary packages, there is an unthinkable number of inter-package dependencies. For example the dependency graph of the ruby packages contains other 20-something packages.

A new version of any of these packages can potentially break some functionality in the ruby package.

And that dependency graph is very small. Looking at the dependency graph for, say, the rails package will make your eyes bleed. I tried it here, and GraphViz needed a PNG image with 7653×10003 pixels to draw it. It ain’t pretty. Installing rails on a clean Debian system will pull in another 109 packages as part of the dependency chain. Again, as new versions of those packages are uploaded the archive, there is a probability that a backwards-incompatible change, or even a bug fix which was being worked around, might make some funcionality in rails stop working. Even if that probability is low for each package in the dependency chain, with enough packages the probability of any of them causing problems for rails is quite high.

And still the rails dependency chain is not that big. libreoffice will pull in another 264 packages. gnome will pull in 1311 dependencies, and kde-full 1320 (!).

With a system this big, problems will arrive, and that’s a fact of life. As developers, what we can do is try to spot these problems as early as possible, and fixing them in time to make a solid release with the high quality Debian is known for.

While automated testing is not the proverbial Silver Bullet of Software Engineering, it is an effective way of finding regressions.

Back in 2006, Ian Jackson started the development of autopkgtest as a tool to test Debian packages in their installed form (as opposed to testing packages using their source tree).

In 2011, the autopkgtest test suite format was proposed as a standard for the Debian project, in what we now know as the DEP-8 specification.

Since then, some maintainers such as myself started experimenting with DEP-8 tests in their packages. There was an expectation in the air that someday, someone would run those tests for the entire archive, and that would be a precious source of QA information.

Durign the holiday break last year, I decided to give it a shot. I initially called the codebase dep8. Later I renamed it to debci, since it could potentially also run other other types of test suites in the future. Since early January, ci.debian.net run an instance of debci for the Debian Project.

The Debian continuous Integration will trigger tests at most 4 times a day, 3 hours after each dinstall run. It will update a local APT cache and look for packages that declare a DEP-8 test suite. Each package with a test suite will then have its test suite executed if there was any change in its dependency chain since the last test run. Existing test results are published at ci.debian.net every hour, and at the end of each batch a “global status” is updated.

Maintainers can subscribe to a per package Atom feed to keep up with their package test results. People interested in the overall status can subscribe to a global Atom feed of events.

Since the introduction of Debian CI in mid-January 2014, we have seen an amazing increase in the number of packages with test suites. We had little less than 200 packages with test suites back then, against around 350 now (early June 2014). The ratio of packages passing passing their test suite has also improved a lot, going from less than 50% to more than 75%.

There is documentation available, including a FAQ for package maintainers with further information about how the system works, how to declare test suites in their packages and how to reproduce test runs locally. Also available is development information about debci itself, to those inclined to help improve the system.

This is just the beginning. debci is under a good rate of development, and you can expect to see a constant flux of improvements. In special, I would like to mention a few people who are giving amazing contributions to the project:

• Martin Pitt has been working on improving debci to support parallel and distributed workers. Being the current autopkgtest maintainer, Martin also already got some bug fixes and fixes into autopkgtest motivated by debci use cases.
• Brandon Fairchild is a GSOC student working on improving the debci web interface to provide more useful information, display information for multiple suites and architectures, plus making the UI work even without Javascript enabled.
• Lucas Kanashiro is another GSOC student, who is working on investigating patterns among packages that fail their test suites, so that we can figure out how we can fix them, or if there are classes of failures that are actually caused by problems in the debci infrastructure.

Custom Layouts on Android

If you ever built an Android app, you have definitely used some of the built-in layouts available in the platform—RelativeLayout, LinearLayout, FrameLayout, etc. They are our bread and butter for building Android UIs.

The built-in layouts combined provide a powerful toolbox for implementing complex UIs. But there will still be cases where the design of your app will require you to implement custom layouts.

There are two main reasons to go custom. First, to make your UI more efficient—by reducing the number of views and/or making faster layout traversals. Second, when you are building UIs that are not naturally possible to implement with stock widgets.

In this post, I will demonstrate four different ways of implementing custom layouts and discuss their respective pros and cons: composite view, custom composite view, flat custom view, and async custom views.

The code samples are available in my android-layout-samples repo. This app implements the same UI with each technique discussed here and uses Picasso for image loading. The UI is a simplified version of Twitter app’s stream—no interactions, just the layouts.

Ok, let’s start with the most common type of custom layout: composite view.

Composite View

This is usually your starting point. Composite views (also known as compound views) are the easiest way of combining multiple views into a reusable UI component. They are very simple to implement:

1. Subclass one of the built-in layouts.
2. Inflate a merge layout in the constructor.
3. Initialize members to point to inner views with findViewById().
4. Add your own APIs to query and update the view state.

TweetCompositeView^code is a composite view. It subclasses RelativeLayout, inflates tweet_composite_layout.xml^code into it, and exposes an update() method to refresh its state in the adapter^code. Simple stuff.

Custom Composite View

TweetCompositeView will likely perform fairly well in most situations. But, for sake of argument, suppose you want to reduce the number of child views and make layout traversals a bit more efficient.

Although composite views are simple to implement, using general-purpose layouts has a cost—especially with complex containers like LinearLayout and RelativeLayout. As platform building blocks, they have to handle tons of layout combinations and might have to measure child views multiple times in a single traversal—LinearLayout‘s layout_weight being a common example.

You can greatly optimize your UI by implementing a custom logic for measuring and positioning child views that is specially tailored for your app. This is what I like to call a custom composite view.

A custom composite view is simply a composite view that overrides onMeasure() and onLayout(). So, instead of subclassing an existing container like RelativeLayout, you will be subclassing the more general ViewGroup.

TweetLayoutView^code implements this technique. Note how it gets rid of the LinearLayout from TweetComposiveView and avoids the use of layout_weight altogether^code.

The laborious work of figuring out what MeasureSpec to use on each child view is done by the ViewGroup’s handy measureChildWithMargins() method—and getChildMeasureSpec() under the hood.

TweetLayoutView probably doesn’t handle all possible layout combinations correctly but it doesn’t have to. It is absolutely fine to optimize custom layouts for your specific needs. This allows you to write both simpler and more efficient layout code for your app.

Flat Custom View

As you can see, custom composite views are fairly simple to write using ViewGroup APIs. Most of the time, they will give you the performance your app needs.

However, you might want to go further and optimize your layouts even more on critical parts of your UI that are very dynamic e.g. ListViews, ViewPager, etc. What about merging all TweetLayoutView child views into a single custom view to rule them all? That is what flat custom views are about—see image below.

Custom Composite View (left) and Flat Custom View (right)

A flat custom view is a fully custom view that measures, arranges, and draws its inner elements. So you will be subclassing View instead of ViewGroup.

If you are looking for real-world examples, enable the “show layout bounds” developer option in your device and have a look at apps like Twitter, GMail, and Pocket. They all use flat custom views in their listing UIs.

The main benefit from using flat custom views is the great potential for flattening your view hierarchy, resulting in faster traversals and, potentially, a reduced memory footprint.

Flat custom views give you maximum freedom as they are literally a blank canvas. But this comes at a price: you won’t be able to use the feature-packed stock widgets such as TextView and ImageView. Yes, it is simple to draw text on a Canvas but what about ellipsizing? Yes, you can easily draw a bitmap but what about scaling modes? Same applies to touch events, accessibility, keyboard navigation, etc.

The bottom line is: with flat custom views,you will likely have to re-implement features that you would get for free from the platform. So you should only consider using them on core parts of your UI. For all other cases, just lean on the platform with composite views, custom or not.

TweetElementView^code is a flat custom view. To make it easier to implement it, I created a little custom view framework called UIElement. You will find it in the canvas^code package.

The UIElement framework provides a measure/layout API which is analogous to Android’s. It contains headless versions of TextView and ImageView with only the necessary features for this demo—see TextElement^code and ImageElement^code respectively. It also has its own inflater^code to instantiate UIElements from layout resource files^code.

Probably worth noting: the UIElement framework is in a very early development stage. Consider it a very rough sketch of something that might actually become useful in the future.

You have probably noticed how simple TweetElementView looks. This is because the real code is all in TweetElement^code—with TweetElementView just acting as a host^code.

The layout code in TweetElement is pretty much analogous to TweetLayoutView‘s. It handles Picasso requests differently^code because it doesn’t use ImageViews.

Async Custom View

As we all know, the Android UI framework is single-threaded. And this is for a good reason: UI toolkits are not your simplest piece of code. Making them thread-safe and asynchronous would be an unworthy herculean effort.

This single-threaded nature leads to some fundamental limitations. It means, for example, that you can’t do layout traversals off main thread at all—something that would be useful in very complex and dynamic UIs.

For example, if your app has complex items in a ListView (like most social apps do), you will probably end up skipping frames while scrolling because ListView has to measure^code and layout^code each child view to account for their new content as they become visible. The same issue applies to GridViews, ViewPagers, and the like.

Wouldn’t it be nice if we could do a layout traversal on the child views that are not visible yet without blocking the main thread? This way, the measure() and layout() calls on child views would take no time when needed in the UI thread.

Enter async custom view, an experiment to allow layout passes to happen off main thread. This is inspired by the async node framework developed by the Paper team at Facebook.

Given that we can never ever touch the UI toolkit off main thread, we need an API that is able to measure/layout the contents of a view without being directly coupled to it. This is exactly what the UIElement framework provides us.

AsyncTweetView^code is an async custom view. It uses a thread-safe AsyncTweetElement^code factory^code to define its contents. Off-screen AsyncTweetElement instances are created, pre-measured, and cached in memory from a background thread using a Smoothie item loader^code.

I had to compromise the async behaviour a bit because there’s no sane way of showing layout placeholders on list items with arbitrary heights i.e. you end up resizing them once the layout gets delivered asynchronously. So whenever an AsyncTweetView is about to be displayed and it doesn’t find a matching AsyncTweetElement in memory, it will force its creation in the UI thread^code.

Furthermore, both the preloading logic and the memory cache expiration would need to be a lot smarter to ensure more layout cache hits in the UI thread. For instance, using a LRU cache^code here doesn’t seem ideal.

Despite these limitations, the preliminary results from async custom views look very promising. I’ll continue the explorations in this area by refining the UIElement framework and using it in other kinds of UIs. Let’s see where it goes.

Wrapping up

When it comes to layouts, the more custom you go, the less you’ll be able to lean on the platform’s proven components. So avoid premature optimization and only go fully custom on areas that will actually affect the perceived quality and performance of your app.

This is not a black-and-white decision though. Between stock widgets and fully custom views there’s a wide spectrum of solutions—from simple composite views to the more complex async views. In practice, you’ll usually end up combining more than one of the techniques demonstrated here.

Mon petit Jean marchant

I got this cute little walker by following these instructions. It's a simple 3 servo robot controled by a light sensor, mapping light intensity with speed. To avoid beating his face against the wall Jean uses an ultrasonic sensor which also gives him a fancy big-eye look. So smart uh? :) The code doesn't differ much from that one mentioned above. I've just taken these pictures before he gets disassembled, after all I can't afford a microcontroller for each fun I have on this arduino-world thing.

‹ ›