That’s my blog… Life and Linux

GNOME Fractional (and multi-monitor) Scaling Hackfest, the report

This wasn't a joke!As previously announced, few days ago I attended the GNOME Fractional Scaling Hackfest that me and Red Hat‘s Jonas Ådahl organized at the Canonical office in Taipei 101.
Although the location was chosen mostly because it was the one closest to Jonas and near enough to my temporary place, it turned out to be the best we could use, since the huge amount of hardware that was available there, including some 4k monitors and HiDPI laptops.
Being there also allowed another local Caonical employee (Shih-Yuan Lee) to join our efforts!

As this being said I’ve to thank my employer, for allowing me to do this and for sponsoring the event in order to help making GNOME a better desktop for Ubuntu (and not only).

Going deeper into the event (for which we tracked the various more technical items in a WIP journal), it has been a very though week, hard working till late while trying to look for the various edge cases and discovering bugs that the new “logically sized” framebuffer and actors were causing.

In fact, as I’ve already quickly explained, the whole idea is to paint all the screen actors at the maximum scale value across the displays they intersect and then using scaled framebuffers when painting, so that we can redefine the screen coordinates in logical pixels, more than using pixel units. However, since we want to be able to use any sized element scaled at (potentially any) fractional value, we might incur in problems when eventually we go back to the pixel level, where everything is integer-indexed.

We started by defining the work items for the week and setting up some other HiDPI laptops (Dell XPS 15 and XPS 13 mostly) we got from the office with jhbuild, then as you can see we defined some list of things to care about:

  • Supporting multiple scaling values: allowing to scale up and down (< 1.0) the interface, not only to well-known value, but providing a wider range of floats we support
  • Non-perfect-scaling: covering the cases in which the actor (or the whole monitor) when scaled up/down to a fractional level has not anymore a pixel-friendly size, and thus there are input and outputs issues to handle due to rounding.
  • GNOME Shell UI: the shell StWidget‘s need to be drawn at proper resource scaling value, so that when they’re painted they won’t look blurred.
  • Toolkit supports: there are some Gtk issues when scaling more than 2x, while Qt has support for Fractional scaling.
  • Wayland protocol improvements: related to the point above we might define a way to tell toolkits the actual fractional scaling value, so that they could be scaled at the real value, instead of asking them to scale up to the upper integer scaling level. Also when it comes to games and video players, they should not be scaled up/down at all.
  • X11 clients: supporting XWayland clients

Read the rest of this entry »

GNOME Hackfest for Fractional Scaling

As Ubuntu users know, Unity desktop shell had HiDPI displays support since 14.04, however while the unity shell has been able to scale at any fractional value (despite we limited the setting to only 8 values per integer), GTK3 and GNOME Shell just supported integer scaling values.

Although I see the technical reason for that (pixels can’t be divided!), I think that our approach still worked quite well by using proper round functions, as it’s really hard to notice the visual flaws that this introduced at such high resolutions.

At the same time, to get proper scaling for GTK apps, we used the stratagem of mixing the UI scaling with the text scaling factor, so that the multiplication between the two values will match the user-requested scaling level.
This worked pretty well in single-monitor instances, while in multi-monitor environments the idea was to use xrandr scaling to get matching results, but this has not been done, mostly due to an X11 bug which didn’t allow to go further…

Anyway, this is the past and present, but let’s talk about the future… Ubuntu will use GNOME Shell (in Wayland, when possible), and so far there’s no support for multi-monitor scaling or fractional scaling, but things are changing!

Jonas Ådahl is leading this efforts and he started with supporting a new configuration API for monitors, that is a prerequisite for pursuing the GNOME Fractional Scaling initiative.
Basically, the main implementation idea is to make GTK and various toolkits to scale at an higher value, and then using mutter to scale actors down at composition level.
While it might be a little more resource intense, it’s also true that this will work nicely (especially in multi-monitor environments with different scaling values) and that there’s no other option, given that GTK scaling system can’t be changed at this point (too many things now assume it’s an integer).

Ubuntu cares about having a proper HiDPI support in next releases, so the Desktop Team decided to join the upstream initiative, and since I’m currently around asia, we’ve organized a GNOME Hackfest, that will be hosted by Canonical in its Taipei office in Taipei 101 in order to continue the work Jonas is doing and plan how to proceed with future work items.


Ubuntu goes GNOME, theming stays. Let’s test (and tune) it!

Hi guys! Again… Long time, no see you :-).

As you surely know, in the past weeks Ubuntu took the hard decision of stopping the development of Unity desktop environment, focusing again in shipping GNOME as default DE, and joining the upstream efforts.

While, in a personal note, after more than 6 years of involvement in the Unity development, this is a little heartbreaking, I also think that given the situation this is the right decision, and I’m quite excited to be able to work even closer to the whole opensource community!

Most of the aspects of the future Ubuntu desktop have to be defined yet, and I guess you know that there’s a survey going on I encourage you to participate in order to make your voice count…

One important aspect of this, is the visual appearance, and the Ubuntu Desktop team has decided that the default themes for Ubuntu 17.10 will continue to be the ones you always loved! Right now some work is being done to make sure Ambiance and Radiance look and work good in GNOME Shell.

In the past days I’ve released a  new version of ‘light-themes‘ to fix several theming problems in GNOME Shell.

This is already quite an improvement, but we can’t fix bugs we don’t know about… So this is where you can help make Ubuntu better!

Read the rest of this entry »

Introducing Locally Integrated Menus to Unity 7

Hey Ubuntu folks¹!

This is the Unity desktop team and during the last months we focused, as always, in polishing and improving the user experience of our default window manager for the next upcoming LTS!
In fact, while in the last months most of the Canonical commitment to Ubuntu has been directed to the Touch form factors, the “classic” desktop has not been forgotten at all and, we’re still working hard on it, to give our users the best experience and to approach smoothly to the convergence vision that we’ll get with Unity 8.

Part of this work have been the spread improvements, the HighDPI support, the new decorations and tons of various bugs fixed; however with this important milestone coming we also wanted to finally propose a solution to fix the main UX bug we have in Unity since its very first release: the menus being hard to find or too far from their parent window.

In fact, having the applications menus in the top panel really worked very well in small screens but now, especially with HiDPI monitors getting more and more popular, the top panel could be really too far from the actual window location… The solution, that the UX designer JohnLea has defined are the Locally Integrated Menus (LIM).

Ubuntu Unity Integrated Menus

People might recall that also at 12.04 times we implemented a first prototype of LIM, however due to some very-hard-to-fix issues we had with core applications, we decided not to try to propose an half-working solution for an LTS.

So, almost 2 years have passed, but our intent to get this feature done was still strong, although this time we wanted to implement LIMs in the proper way, as Ubuntu quality standards deserve. In addition designers defined a new and improved revision of their work, proposing to show the menus inside the decorations themselves in horizontal mode (until we’ve room for them); so, continuing to save the precious vertical space and keeping the nice look of menu-less windows unchanged.

To be honest, we’d loved to land this way before, but the amount of technical work needed has not to be underestimated.
Being more precise, one of the blockers we had in 12.04 was our dependency on the legacy compiz decor plugin + gtk-window-decorator, that has worked “OK” in the last years but – a part from using deprecated technologies (gtk2 in primis) – it really would have made this concept impossible to realize.

So, the first step has been moving away from the old gtk2-based decorations and writing brand new decorations supporting Gtk3 CSS theming² inside Unity itself; this has been an huge work (including writing a brand-new widget system for handling compiz textures in a more natural way), but it gave us great benefits in the end such as much faster windows resizing , improved look, support for dynamic scaling (for both HighDPI and accessibility reasons).

Once we had this new layout where to place any widget quite easily, all took shape in few lines, we only had to handle the fact that now menus opens on mouse button release and only if the user doesn’t keep it pressed for too long³, while a slightly trickier part was to handle the case where we had a too small window to show menus in horizontal mode, and where we had to fallback to a dropdown menu.

LIM’s dropdown, shown if we have not enough space

As this is an LTS release, before setting this menu mode as the default we wanted to have some community feedback. For now, you have to enable it using the Unity Control Center Appearance panel, and let us know what you think!

Unity Control Center with Application Menu settings

Tweakers might be happy to know that there are also other settings you can use to adjust your LIM experience under the com.canonical.Unity.IntegratedMenus gsettings schema, that allows to define the pressure and movements thresholds, and to also enable double-click over the menus (to maximize the window, if you’re fast enough); However, while you can adjust the settings for now, we encourage to use the defaults as they are based on wide user testing and are coherent with our design guidelines.

After some words, I guess it’s time to see them in action, and upgrade your Ubuntu Trusty machine to enjoy them!

Youtube Video

[1] Hello Planet, I should also probably say! 😉
[2] We really encourage and support anyone who wants to update its theme to support Unity
[3] Maximum press time is configurable, but default values are based on design user testing

Welcome back on….

Me, behind UbuntuSalve gente! Oh, no ora si parla “inglese” via….

Hi there!
This is the first blog post here after soooo many years… Something like almost 7 years, really?!?

Oh, yes… You all thought that I was dead as a blogger I guess, and well mostly I am as my time for writing really went below 0 during this time, and then… Well as always I wanted to keep this thing updated following “my rules” of keeping the timeline in sync with actual events, but this failed everytime… And so, yeah here we are after so much time!

The main reason why I become unresponsive during these years was that instead of writing text, I moved to write code (for real) and I found it much more fun and useful for the people around me.

More importantly during this period my commitment with the Free Software  increased and I  joined or submitted patches to various projects such as Compiz, Openmoko, EFL (Enlightment Foundation Libraries), GNOME, and… Well how you might think from the pic, Ubuntu.

Ubuntu took a very important role in my life since about the last months of 2010, when Unity, was proposed as the new default desktop environment, I liked a lot the idea, but it was still a new baby with many missing features and bugs and so I decided to jump on the boat to give my help to make Unity the best desktop.
This involvement lead me to join to my first, beloved, UDS in Budapest where I met for the first time a lot of “ubuntu-dev-heroes”. Once back I continued contributing a lot, as I enjoyed so much that experience that I wanted to make it something more than just an hobby…
And well, long story short, I’m now working at Canonical for more than 2 years as a Software Engineer for the Unity Shell! I love this job and I think we’re doing great things, trying to make the Ubuntu vision happen in every form factor.

You might be able to read more about this experience on my Google+ page or looking at my opensource contributions at ohloh.

PS: But… Is still anyone reading? 🙂 – Un Planet per i Blog Italiani dedicati a Linux

TuxFeed LogoMentre il caldo e qualche blackout stanno mettendo a dura prova tanto me quanto le mie periferiche, mi è giunta la notizia della nascita di un progetto di cui sentivo la mancanza da tempo e che io stesso avrei voluto avviare se nessuno si fosse fatto avanti prima, vale a dire l’apertura di un Planet in cui aggregare i blog italiani dedicati a Linux!
Questo progetto ha preso forma grazie ad Alessandro Pagano e Leonardo Racanelli sotto il nome di TuxFeed e raccoglie già da adesso i feed dei blog dedicati al Pinguino più noti nel panorama italiano di cui mi vanto di far parte.

Se siete autori di un blog in cui si trattano anche argomenti legati a linux, potrete richiedere di essere aggiunti tra le fonti per aumentare la vostra visibilità.
Se invece siete semplici lettori da oggi avrete un metodo rapido ed efficiente per tenervi aggiornati su quanto avviene nella blogosfera linuxiana sottoscrivendo un solo feed.

Sperando che questo aggregatore cresca bene (magari con una struttura più simile ai veri planet) e ben popolato da blog di qualità vi lascio ad una sua visita più approfondita:

Bye 😉 

Linux prende possesso della Camera dei Deputati

Tux alla Camera dei DeputatiDopo la migrazione del Parlamento Francesce a Linux (kubuntu, per la precisione), anche la Camera dei Deputatidopo aver accolto anche me, ai tempi della quarta liceo – ha scelto di far entrare "Il Pinguino" dentro al cuore della Democrazia Italiana.

Come riporta La Repubblica Il 10 luglio, è stato approvato dalla Camera un piano proposto dai Deputati dell’Unione Pietro Folena e Franco Grillini affinché vengano migrati tutti i computer del Parlamento da Windows a Linux.

La migrazione comprenderà obbligatoriamente circa 3500 macchine, sia desktops che servers, di uso “pubblico”, mentre ciascun Deputato e ciascuna segreteria di partito potranno anche migrare i propri computer (privati) a sistemi operativi Liberi.

Questa scelta è stata presa per varie ragioni… Innanzi tutto permetterà un bel risparmio economico, risparmando più di 3 millioni di Euro ciascun anno (le licenze di ciascuna macchina attualmente costano in media 900€ annui), ma si tratta anche di un bel passo avanti dal punto di vista della libertà ed indipendenza tecnologica, abbandonando sistemi proprietari che contrastano con il senso della Democracy stessa.
Tuttavia non vanno tralasciati i motivi tecnici che sono sostanzialmente legati alla sicurezza del Parlamento (e quindi a quella di tutti i cittadini).

Con questa decisione Folena spera che anche le amministrazioni locali inizino una migrazione verso sistemi liberi così come la provincia di Bolzano ha già fatto con il FUSS! project (di cui ne ha parlate anche Report).

Visto l’importanza della notizia (che finalmente pare rispettare il programma di Governo – dopo diversi erroracci), ho deciso di parlarne anche qui nonostante sia spesso restio a raccontare news di massa, ma anche di scrivere un articolo in inglese che spero possiate votare su digg (o diggare, se preferite) per dare una maggiore ampiezza a questa notizia anche a livello internazionale, dopo che è stata trattata quasi in sordina anche in Italia (quando ci si potrebbe vantare…).

EDIT [12-07-2007]: in base all’articolo del The Inquirer (che pare abbia intervistato Folena) oltre al fatto che si sottolinea che il passaggio sarà automatico per tutte le ~3500 postazioni pubbliche, mentre diventerà opzionale per 630 parlamentari (diventando così una delle migrazioni più imponenti in ambito amministrativo), si afferma che dal prossimo Settembre ed in circa 2 anni di switching, il Parlamento passerà a SuSE Linux e oggi [13-07-2007] Folena spiega brevemente che tale decisione è dovuta al fatto che la Camera aveva già un contratto con Novell e sfruttandolo anche per la migrazione si ridurrebbero anche i problemi ad essa collegati (mhmhm…).
Per un amante di Ubuntu come me non è esattamente la scelta migliore, ma anche se Novell ha fatto un patto con il Diavolo (leggasi Micro$oft) usa comunque il “nostro” kernel 😛

Grazie per aver votato questa notizia su Digg!

Compiz Fusion AMD-64 Ubuntu Repository

Compiz Fusion AMD 64 repositoryPrima della pubblicazione del MakeFusionDebs ho ricevuto davvero molte richieste dei pacchetti sorgenti per crearsi i pacchetti per la propria distribuzione ed architettura, successivamente mi ha fatto molto piacere vedere che in tantissimi si sono messi a creare pacchetti fatti in casa con il mio script ed ancora di più veder nascere repository per Debian Sid che lo sfruttano.

Ciò nonostante, le richieste di un vero e proprio repository per Ubuntu a 64bit (parallelo a quello per i386) da parte del popolo di utilizzatori di architetture AMD-64, non è mai cessato e visto che nessuno si faceva avanti con un proprio spazio, ho accettato la collaborazione di Bernardo Bandos che da oggi in poi mi invierà i pacchetti di Compiz Fusion compilati per i processori a 64bit che io inserirò nel nuovo repository eyecandy per amd64!

Per aggiungere il repository alla vostra lista, editate – con permessi di amministrazione (sudo) – il file /etc/apt/sources.list, aggiungendovi quanto segue:

# Treviño’s Ubuntu Deisty EyeCandy Repository (GPG key: 81836EBF)
# Many eyecandy 3D apps: Beryl, Compiz, Fusion, AWN and kiba-dock
# built by jbs using latest available (working) sources from git/svn/cvs…
deb feisty eyecandy-amd64
deb-src feisty eyecandy

Quindi, date la fiducia alla mia chiave GPG pubblica con:

wget -O- | sudo apt-key add –

Una volta fatto questo, per installare il tutto (e correggere eventuali problemi) valgono le stesse identiche indicazioni date per Compiz, CompizConfig e Compiz Fusion per i386.

Per ulteriori informazioni sull’installazione e l’ottimizzazione di Compiz Fusion, consultate il wiki italiano di Ubuntu che ho aggiornato anche con questi ultimi dettagli.

Compiz Fusion inizia a parlare Italiano: Aiutiamolo!

Compiz Fusion Italian LogoCome avranno visto gli utilizzatori dei miei pacchetti o del mio script impacchettatore, da qualche giorno sia CompizConfig Settings Manager che i plugin di Fusion supportano l’internazionalizzazione (i18n).
Io, già da qualche giorno, ho ritirato fuori il mio vecchio mestiere da traduttore, e mi sono messo a tradurre CCSM (lavoro relativamente breve), ma quando è arrivato il momento dei Plugin di Compiz Fusion mi sono reso conto che non potevo fare da solo visto che ci troviamo davanti a quasi 500 stringhe (tra l’altro spesso molto tecniche), da rendere appetibili per gli utenti italiani…

Mi è quindi sembrato ovvio rivolgere questa chiamata ai miei amati lettori ed in generale a chiunque voglia aiutare questo nuovo progetto ed abbia una sufficiente conoscenza dell’inglese (e di Compiz)…
Già poche persone volenterose dovrebbero essere in grado di rendere questo lavoro piuttosto rapido ma sopratutto efficace. Quindi collaborate!

Per quanti di voi si fossero avvicinati solo ora alla traduzione di software in ambienti liberi, ci sono degli strumenti ormai considerati standard che fanno capo a gettext rendendo questo processo molto semplice ed intuitivo (oltre che assistito) sia per gli sviluppatori che per i traduttori.
Dal vostro/nostro punto di vista (di traduttore, ndr) vi basterà usare tool come kbabel (se utenti KDE), gtranslator (se utenti GNOME), poEdit (se indipendenti) o un semplice editor di testo (se siete utenti duri e puri) per modificare il file *.po che di fatto risulta essere il nostro dizionario particolare (maggiori informazionisezione italiana del Translator Project).

Ora che vi ho elencato un po’ di risorse per modificare i file PO, guardiamo come ottenere e di lavorare sul file di traduzione italiano di Compiz Fusion… Per farlo ci sono due modi:

  1. Scaricate e salvate il file it.po (il link punta sempre all’ultima versione) e iniziate a tradurlo con il tool che preferite, quindi salvate tutto ed inviatemi il file it.po risultante dal vostro lavoro.
    Riscaricate il file ogni volta che ci rilavorate per evitare di perdervi nuove traduzioni…
  2. Usando il GIT, date i seguenti comandi:
          git-clone git://
    Quindi traducete usando il vostro tool preferito (con cui dovrete aprire il file in i18n/po/it.po), quindi eseguite (dentro alla cartella i18n):
          git-diff-files -p > /tmp/it-po.patch
    Speditemi il file /tmp/it-po.patch e nel caso vogliate ritradurre date il comando sotto per aggiornare i files (dentro alla cartella i18n):
          git-diff-files -p | patch -Rp1 && git-pull

  3. Installare Gobby, accedere al server porta 6523, la password è cfteam e traducete direttamente online editando il file it.po!

Siccome io e pochi altri abbiamo la possibilità di modificare il repository git i18n di Fusion, e non essendo stata creata ancora né una mailing-list né un vero e proprio gruppo di lavoro per le traduzioni, l’unico modo per rendere effettivo quanto avete italianizzato – come già detto – è quello di inviarmi il vostro it.po (o la patch generata) affinché io inserisca tutto in git…

Sperando che si uniscano quante più persone possibili a questo appello, prego chiunque ci lavori sopra, di non tradurre subito la prima stringa disponibile (per evitare di fare il lavoro doppio), ma di andare un po’ a caso :P. Magari potreste inserire qui tra i commenti quanto state facendo così da evitare inutili sovrapposizioni.
Resta comunque il fatto che prima mi inviate il file tradotto, e prima io posso inserirlo in git così da facilitare il lavoro di tutti.

A presto (attendendo i vostri it.po) ^_^… 

EDIT [19-09-2007]: è tempo di fare un resoconto di quanto è stato fatto fino ad adesso.

Hanno contribuito (fin’ora):

Da qualche settimana il maintainer ufficiale della traduzione italiana è Milo Casagrande, fate riferimento a lui per ogni cosa inerente l’i18n di Compiz e Compiz Fusion.

Impacchettare Compiz Fusion GIT con MakeFusionDebs

Make-Compiz-Fusion-ScriptCi siamo! Come avevo anticipato nel post precedente, mi sono messo di buzzo buono, ed ho terminato il lo script dinamico per impacchettare Compiz e Compiz Fusion direttamente da GIT.
Infatti, già quando iniziai ad impacchettare Beryl-SVN, come presupposto iniziale mi scrissi uno script che chiamavo rudimentalmentemakedebs‘ che mi permetteva di fare tutto il lavoro senza troppo sforzo e, sopratutto, senza necessità di una grossa manutenzione
Col breve passaggio di Beryl da SVN a GIT, aggiornai lo script per funzionare anche con il Software di Controllo delle Versioni Distribuito di Torvalds (= git) e con l’arrivo di CompComm (poi Compiz Fusion) l’ho aggiornato ulteriormente…

Il maggior problema di Compiz Fusion è il fatto che non vengono distribuite delle cartelle debian, di default che consentono la realizzazione dei pacchetti, per tanto (com era già avvenuto anche per alcune parti di Beryl e come succede quasi sempre per gli altri pacchetti che produco) le ho dovute fare io, praticamente da 0…
Avendo ricevuto l’accesso in scrittura al GIT di OpenCompositing qualche settimana fa, ho deciso che il nuovo sistema sarebbe stato molto più git-based.

Con un po’ di ritardo, stasera ho inserito in GIT tutte le cartelle debian necessarie alla creazione di pacchetti .deb, quindi dopo diversi aggiornamenti, ho inserito anche il nuovo makefusiondebs che vi permetterà di compilare e pachettizzare tutto!

Le modifiche rispetto alla versione precedente sono:

  • Autoupdate (lo script si auto-aggiorna all’avvio)
  • Supporto ad un file di configurazione (makefusiondebs-options)
  • Supporto per le patch debian (sistema quilt)
  • Controllo dell’ABIVERSION dei plugin (permette la ricompilazione automatica)
  • La versione di base ora viene letta anche dal
  • Supporto per il prefisso delle versioni debian (#:versione)
  • Corretta la rimozione dei suffissi debian alla versione
  • Possibilità di definire il nome delle cartelle in cui salvare i dati
  • Spostamento dei vecchi deb basato anche sul pacchetto sorgente
  • Le cartelle debian utente, ora hanno priorità su quelle scaricate
  • Codice ripulito
  • Altre correzioni sparse che non ricordo 🙂

Per avere tutto questo, dopo che avete ripulito il vostro sistema dalle installazioni di compiz in /usr/local (soprattutto rimuovendo i file /usr/local/lib/pkgconfig/compiz*.pc), vi basterà dare i seguenti comandi:

git-clone git://
cd compiz-fusion-debian-builder

A questo punto lo script tenterà prima di aggiornare sé stesso (ed in caso positivo di riavviarsi), se non impostato diversamente (vedi sotto), e poi scaricare (o aggiornare) tutte le sezioni del GIT definiti (che comprendono sia compiz-fusion-debian che compiz-wrapper – tra l’altro quest’ultimo è stato integrato in questi giorni proprio nei pacchetti di Ubuntu Gutsy!!) nelle opzioni…

Ho parlato di opzioni, sì, perché essendo l’autoaggiornamento basato su GIT, per evitare problemi col passare del tempo, ho deciso di dare la possibilità di definire le proprie impostazioni in un file parallelo, impostato di default a makefusiondebs-options, che potrete editare (mantenendo la sintassi bash) per personalizzare l’impacchettamento (piuttosto che toccando lo script stesso, per cui semmai inviatemi delle patch, ma che è meglio non modificare direttamente!).

Infine, un accenno ai parametri accettati dallo script:

./makefusiondebs                 # esegue tutti i passaggi (aggiorna ed impacchetta)
./makefusiondebs update          # esegue solo l’aggiornamento dei pacchetti
./makefusiondebs build           # impacchetta solo ciò che serve
./makefusiondebs <item>          # impacchetta solo <item> (se necessario)
./makefusiondebs rebuild <item>  # forza la ricompilazione di <item>
./makefusiondebs repack <item>   # forza il rimpacchettamento di <item>

Adesso se non potete o non volete usare i miei deb di Compiz, sarà possibile e molto facile creare pacchetti anche per tutte le distribuzioni (basate su debian) e tutte le architetture; se vi dovesse servire hosting per i vostri pacchetti – per un eventuale repository – contattatemi pure

Maggiori informazioni le troverete sicuramente in questo thread di OpenCompositing.

Bye ^_^ 

« Previous Entries