Navegando por el sitio de extensiones de Mozilla, me he topado con esta extensión que permite recuperar un poco de espacio en la ventana de Firefox.

Al instalar Bookmark Autohider, la barra de marcadores se ocultará mientras el cursor del ratón no se encuentre cerca de la barra de direcciones.

Pero si colocamos el cursor cerca de la barra de direcciones, ocurre esto:

La extensión tiene varias opciones para configurar los tiempos en que se oculta o muestra la barra. Lo pueden encontrar en el apartado de Complementos de Firefox.

Espero que les sea de utilidad la extensión.

Quake 3 Arena code.

I pushed out the Quake 3 Arena code used for demoing limare and for benchmarking.

You can build it on your linux-sunxi with

    make ARCH=arm

or, for the limare version (which will not build without the matching limare driver, which i haven't pushed out yet :))

    make ARCH=arm USE_LIMARE=1

for the GLESv2 version (with the broken lamps due to missing alphatest):

    make ARCH=arm USE_GLES2=1

Get a full Quake 3 Arena version first though, and stick all the paks in ~/ioquake3/baseq3. Add this to demofour.cfg in the same directory:

    cg_drawfps 1
    timedemo 1
    set demodone  "quit"
    set demoloop1 "demo four; set nextdemo vstr demodone"
    vstr demoloop1

To run the timedemo then run the quake binary with +exec demofour.cfg

For your own reverse engineering purposes, to build the GLESv1 version with logging included, edit code/egl/egl_glimp.c, and remove the // before:

    //#define QGL_LOG_GL_CALLS 1

But be aware, you are not free to spread that dumped data. That is ID Software data, albeit in a raw form.

I'd be much obliged if anyone hacks up input support, or re-adds sound. Or even adds the missing GLES2 shaders (color as a uniform for instance). That would make this code playable from the console, and should make it easier for me to provide playable limare code.

As you all can see, we have nothing to hide. The relevant differences between GLES1 and limare is in the GL implementation layer. I did shortcut vertex counting, this to ease logging, but this only has limited effect on CPU usage. The lesser CPU usage of limare is not significant or interesting as we do less checking than a full driver anyway. In simpler tests (rotating cubes), our scheduling results in a much higher CPU usage though (like 50% more, from 10% to 15% :)), even if we are not significantly faster. As said in my previous, i am not sure yet whether to keep this, or to find some improvements. Further tests, on much more powerful hardware, will tell.

Connors Compiler Work.

Connor had a massive motivation boost from FOSDEM (and did not suffer from the bug that was going round which so many of us in the last week). Earl from zaReason is sending him an A13 tablet, which should spur him on even further.

He has been coding like a madman, and he is now close to being able to compile the relatively simple shaders used in the Quake 3 Arena demo. He still has to manually convert the ESSL of the vertex shader to his own GP_IR first though, but that's already massive progress which gets us very close to our goals.

I am going to add MBS loading (Mali Binary Shader format) to limare to be able to forgo the binary compiler and load pre-compiled shaders into our programs. Since MBS is also spit out by the open-gpu-tools, we can then distribute our own compiled MBS files directly, and provide a fully open source Q3A implementation on mali.

How cool is that!

The very near future.

With my post purely about Q3A and its numbers, the reactions were rather strange. Seems like a lot of people were hung up exclusively on us being only 2% faster or because we were using this "ancient" game. The blog entry itself explained fully why this ancient game was actually a very good choice, yet only very few read it. Very few realized what a massive milestone an almost pixel-perfect Quake 3 Arena is for a reverse engineered driver.

As for performance... When i started investigating the mali, i had postulated that we would be happy to have only 75% of the performance of the binary driver. I assumed that, even with performance per watt being mighty important in the mobile space, 75% was the threshold at which the advantages of an open source driver would outweight the loss of performance. This would then lead to only ARMs big partners would end up shipping ARMs own binaries. And for projects like CyanogenMod and proper linux distributions there would be no question about what to ship.

With Q3A, and with the various rotating cubes, we now have proven that we can have a 100% match in performance. Sometimes we can even beat performance. All of this is general, no Q3A specific tricks here!

This is absolutely unique, and is beyond even the wildest dreams of a developer of any reverse engineered driver.

Absolutely nothing stops us now from delivering an open source driver that broadly matches the binary driver in performance! And this is exactly what we will be doing next!

Hey ARM!

We are not going away, we are here to stay. We cannot be silenced or stopped anymore, and we are becoming harder and harder to ignore.

It is only a matter of time before we produce an open source graphics driver stack which rivals your binary in performance. And that time is measured in weeks and months now. The requests from your own customers, for support for this open source stack, will only grow louder and louder.

So please, stop fighting us. Embrace us. Work with us. Your customers and shareholders will love you for it.

-- libv.

(c) S. Delcroix 2013

I'm quite pleased to announce the availability of Chipmunk bindings for monotouch. I started that last year, and bound just enough of it to get a sample working, added some constraints lately in order to place labels, and completed it since for the beauty of the task. The image next to this is a screenshot from a system using a motor, a gear joint, pivot joints and some more.

At this point in time, the ~2000 lines of manually crafted lines of code can be found in this pull request, but you probably won't have to wait long before it's merged in the monotouch-bindings repository.

What's missing ?

Mainly queries, plus a few function calls here and there.

Integrate with cocos2d

Memory management

I’m testing PulseAudio 3.0 on openSUSE 12.3 RC1 and it might be helpful to hang this information out here where Google can find it:

To use Skype with openSUSE 12.3, you need to download the Skype package for openSUSE.  If you’re using a 64 bit machine/install, like most of us nowadays, you also need some 32 bit compatibility packages, included with openSUSE.

1. Download Skype from http://www.skype.com/en/download-skype/skype-for-linux/
2. Select openSUSE 12.1 32 bit (the most recent openSUSE version for which they offer Skype at time of writing) and save the package
3. As root,
   

   zypper in skype-4.1.0.20-suse.i586.rpm alsa-plugins-pulse-32bit

   to install the package, its 32 bit requirements, and the 32 bit ALSA plugin for PulseAudio it also needs, but doesn’t/can’t specify automatically.

Happy calling.

 

Nach Umzug und Vertragswechsel bei meinem Provider gab es ein neues Modem. In meinem Fall ein AVM Fritz!Box 6360 Cable. Das schöne dabei ist die Möglichkeit, die Anrufliste aus der Fritz!Box auszulesen. Besonders auf KDE angepasst gibt es das Programm KFritz zu finden unter http://www.joachim-wilke.de/kfritz.htm. Der Vorteil an diesem Programm liegt noch dabei, dass es Benachrichtigungen (KNotify) beherrscht.

So bekommt man beim Anruf direkt zu sehen wer anruft. Ist die Nummer nicht im Telefonbuch der Fritz!Box hinterlegt so sucht das Programm automatisch in Telefonnummerdatenbanken nach dem Namen des Besitzers. Das Systemabschnittssymbol passt sich auch gut in die Standardsymbole ein.

Das einzige was man Einstellen muss ist eventuell die IP der Fritz!Box (wenn nicht unter fritz.box erreichbar) sowie das Passwort für jene.

Leider hat es bei mir nicht funktioniert neue Kontakte zu den Fritz!Box Kontakten hinzuzufügen. Zwar werden die Kontakte in der Liste angezeigt, sind aber nach einem Refresh nicht mehr vorhanden. Auf der Fritz!Box tauchen sie garnicht auf. Stört mich allerdings weniger. Die Hauptsache der Meldung für ein- und ausgehende Telefonverbindungen reicht mir hier völlig.

Installation

Das Programm gibt es für alle großen Linuxdistribution.
openSUSE User laden sich das Programm von http://download.opensuse.org/repositories/home:/rbos/openSUSE_12.1/i586/ herunter.

Arch Linux Nutzer finden im AUR ein PKGBUILD (https://aur.archlinux.org/packages/?O=0&K=kfritz). Das kompilieren dauert nicht lange.

Andere Distributionen haben auch passende Pakete zur Hand. Genaueres gibt es auf der Entwicklerseite.

As of today KDE SC 4.10 final packages are available for openSUSE 12.2 and Factory users. The new KR410 repo got built and you can replace your KR49 repos with it. KDE SC 4.10 will be part of openSUSE 12.3 and all minor updates for that KDE release will be shipped via the official update channel. Of course KDF does also contain KDE SC 4.10 final.

Currently there are no major bugs known. As already mentioned before, kio_sysinfo got replaced by kinfocenter because kio_sysinfo for openSUSE is unmaintained.

It is recommended to run nepomukcleaner to get rid of all legacy data. Beware though that it might take a long time. If you have nothing valuable in your nepomuk database, it is probably quicker to just remove its data from ~/.kde4/share/apps/nepomuk and start from scratch.

Another thing to note: if nepomuk crashes while indexing you might encounter an almost two years old Qt bug which according to the report, Qt devs are reluctant to fix. The problem of this bug is that after the crash virtuoso-t goes crazy. Thus you have to restart nepomuk via KDE’s systemsettings to make it behave again.

Please report packaging issues to the opensuse-kde mailinglist or #opensuse-kde on IRC. Bugs not specific to openSUSE should be reported upstream at KDE’s bug tracker.

Hot on the heels of the announcement from KDE, the openSUSE KDE team is happy to announce the availability of packages for the latest stable release of the KDE Platform, Workspaces, and Applications.

Packages are available in the KDE:Distro:Factory repository (which is where the packages to land in 12.3 are tested) for openSUSE Factory (soon to be 12.3) and openSUSE 12.2 and soon (when the Open Build Systen finishes rebuilding a number of packages) in the KDE:Release:410  repository for openSUSE 12.2 users.

If you want to contribute and help KDE packaging in openSUSE, use the KDE:Distro:Factory version, otherwise stick to the KDE:Release:410 repository.

Enjoy!