Steps to reproduce:
1. Set up a ~/.netrc with credentials for a given server
2. Verify that automatic login with those credentials works when using command-line ftp
3. In a Nautilus window, select Connect to Server, enter given server and choose FTP (with login) as type

What happens:
Nautilus prompts for login credentials (User name, Password) with nothing in the fields pre-filled.

What I expect to happen:
For the fields to be automatically filled with the credentials I’ve already specified in ~/.netrc.

Additional info:
Nautilus apparently has its own way of storing credentials (i.e. different from ~/.netrc). When it has credentials of its own for a server, those should obviously come first. But when it doesn’t, it should utilize ~/.netrc if possible.

Lähtökohtaisesti liian pieni teksti ei skaalaudu muun sisällön mukana Chromiumilla zoomatessa.

Rekisteröitymisen yhteydessä käyttäjätunnuskentän alla (hassussa paikassa) luki ”sähköpostiosoite”. Kenttä olisi yhtä hyvin voitu nimetä sähköpostiosoitteelle tarkoitetuksi.

Vaikka otin käyttäjätunnukseksi (kehoitusta noudattaen) sähköpostiosoitteen, yhteystiedoissani sähköpostiosoitteelle varattu kenttä oli taas tyhjä. Samoin sen jälkeen, kun olin täydentänyt yhteystietoihini sähköpostiosoitteeni ja puhelinnumeroni, oli Sähkövahti-palvelua tilatessani lomakkeella taas tyhjä sähköpostiosoite- ja puhelinnumerokenttä. On kyllä hyvä, että palvelun kohteeksi valittavat tiedot voivat poiketa yhteystiedoissa annetuista, mutta ne voisi silti lähtökohtaisesti olettaa yhteystiedoissa jo annetuiksi. Tämä oli kolmas kerta kun jouduin syöttämään järjestelmään yhden ja saman sähköpostiosoitteeni, kun teknisesti yksikin kerta olisi riittänyt.

Rekisteröitymislomakkeessa olevasta rakenteellisesta ongelmasta (asiakastietojen haun edellyttäminen ilman erillisvaihetta) annoin eilen palautetta sivuston varsinaisen palautelomakkeen kautta. Sen asiakaspalvelu lupasi välittää ylläpidolle.

Kirjautumistietojen tallentaminen selaimen muistiin ei joko toimi tai on tahallaan estetty. Jälkimmäiseen ei ole mitään syytä, se ei lisää palvelun turvallisuutta.

Tämän palvelukyselylomakkeen ensimmäinen kysymys ei nähdäkseni tarjoa sellaista vastausvaihtoehtoa, johon käyttötapaukseni (Sähkövahdin tilaus) soveltuisi. Palvelun tilaamista varten jouduin kyllä rekisteröitymään (minkä vaihtoehdon nyt valitsin), mutta se ei ollut käyntini ensisijainen syy.

”Fortum Sähkövahti” on huonoa suomea, niin muotia kuin kahdesta erillisestä sanasta muodostuvat tuotenimet tällä hetkellä ikävä kyllä ovatkin.

Fortum.fi-palvelu on yhdyssana, tässä palvelukyselylomakkeessa sanojen välistä puuttuu yhdysviiva.

Siltä varalta, että käyttöympäristöni tietoja ei kerätä automaattisesti, käytin sivustoa Chromium-selaimen versiolla 17.0.963.79 Ubuntu 12.04:ssä.

Kohtuullisen selkeä navigointi. Ehkä vähän liikaa tavaraa sivulla kerrallaan näkyvissä, mutta toisaalta kaikki tarvitsemani tuntui löytyvän johdonmukaisista paikoista.

Yritin rekisteröityä Fortumin websivustolle. Ennen rekisteröitymislomaketta minulta kysyttiin olenko Fortumin asiakas. Vastasin (rehellisesti) kyllä, minkä jälkeen pääsin täyttämään rekisteröitymislomaketta.

Lomakkeen täytettyäni valitsin sen alalaidassa olevan Lähetä-linkin. Tuloksena oli virheilmoitus: ’Rekisteröityminen epäonnistui. Hae ensin tiedot syöttämällä asiakasnumerosi ja käyttöpaikan numero. Klikkaa sen jälkeen ”Hae tiedot”.’

Miksi käyttäjän tulee erikseen suorittaa tuo tietojensa haku? Miksei lomakkeen Lähetä-toiminto suorita samalla myös Hae tiedot -napin hakutoimintoa?

Mikäli asiakastietojen täyttäminen ja haku on (aidosti, jostain teknisestä syystä) edellytys sille, että lomakkeella voi edetä kirjautumistietoihin, miksei sitä ole toteutettu (aidosti teknisesti) rekisteröitymisen edellytyksenä? Miksei asiakastietojen kysely siis ole rekisteröitymislomaketta edeltävä erillinen kysely asiakkuuskyselyn tavoin?

Loppujen lopuksi rekisteröitymiseni epäonnistui, sillä toistuvista yrityksistä huolimatta asiakastietojen ”Haku” väitti itsepintaisesti, että ”Tunnistautuminen ei onnistunut. Tarkista, että asiakas- ja käyttöpaikkanumero on kirjoitettu oikein.” Kirjoitin tiedot aivan taatusti oikein: asiakasnumeroni on 3381842 ja käyttöpaikkanumeroni 8956.

Confirming the issue of not being able to get rid of indicator-messages apart from uninstalling it system-wide, but not agreeing with stuffing the menu with another item just for solving this. IMHO Indicator-messages should be de-/selectable in Startup Applications preferences (like indicator-multiload for instance is).

According to an answer on Ask Ubuntu [1], blacklisting all message-providers should hide indicator-messages altogether, but this doesn’t seem to work in 12.04, apparently because status-providers (which are different from message-providers) are still using the menu. (U1 Control Panel also seems to still occupy it despite being blacklisted.)

I’ve even tried overriding indicator-messages’ dbus service file with a hackish solution [2], but the envelope still insists on appearing (though without the associated menu).

* [1] http://askubuntu.com/a/15616/34756
* [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544483#42

There are many windows that would benefit from having the maximize button available but don’t. I produced snapshots of the history window, the ’Downloading Package Information’ window and the ’Mark additional required changes’ window. IIRC, the downloading packages and installing packages windows are also affected, though I couldn’t produce snapshots of those right now without installing sh… numerous packages I don’t want. Software sources is also affected, I guess that should be marked separately.

All these windows tend to have huge listings in them, and scrolling through those listings in cramped space is difficult. They’re already resizable (as they should be), so why not allow easy maximizing as well?

I just had the brightest idea. Two actually:
1. Make the launcher fill itself automatically with the most frequently used apps.
2. Make the launcher infinite in size so that you could (theoretically, should you want to) scroll down to every app you’ve ever launched that the infrastructure knows of.

==Severity==
I’ll elaborate on the justification below based on my use case. Depending on whether it’s a common or a less common one, this report is to be read as severity ’wishlist’ for a system default or an optional feature (an add-on or whatever they’re called in Unity-land).

==Justification==
The way I currently seem to be intuitively using the launcher, manually, is to stack it with apps I use most, with the most used one on top and less used ones descending according to use-frequency down from there.

This is at least an implicit, sometimes explicit [1] use case for the launcher, and something at which computers are by nature better than humans. So why not make the launcher do this automatically?

* [1] https://wiki.ubuntu.com/MaverickMeerkat/ReleaseNotes#Ubuntu_Netbook_Edition

==Requirements==
Sometime in the past (see Bug #893214), the dash seems to have had a ’most frequently used apps’ category, apparently based on Zeitgeist. So the basic infrastructure for this should already exist.

==Affected==
I’m filing this against unity-2d-shell, since that’s what I’m using, but I suppose this applies to 3D as well. Ayatana might be the abstract-level target.

I left an old netbook to do an ”apt-get -y dist-upgrade” overnight, and when I returned to it the next morning, the upgrades were unfinished because libc upgrade was waiting for me to respond to ”Restart services during package upgrades without asking?”

It looks like the question is prioritized depending on whether the upgrade is done on desktop or not, and if it’s not, the priority is set critical. According to documentation [1], critical is for ”Items that will probably break the system without user intervention.” I don’t think restart-without-asking satisfies that condition.

* [1] http://www.debian.org/doc/packaging-manuals/debconf_specification.html#AEN101

”Kyselyyn pääset tästä” -linkki on rikki, se viittaa jonkun jo täyttämän lomakkeen kiitossivulle. Linkin pitäisi ilmeisesti viitata osoitteeseen https://www.tem.fi/banner/112#, josta kukin vastaaja saa oman, uuden lomakkeensa. (Lisäksi suosittelen yleensä linkittämään siten, että linkitetyt sanat kuvaavat linkityksen kohdetta, ei ”tästä”- tai ”tämä linkki” -tyylisesti. Tässä yhteydessä siis esimerkiksi sana ”Kyselyyn” lauseesta ”Kyselyyn voi vastata 26. helmikuuta saakka” olisi luonnollinen kyselyn osoitteeseen linkitettävä.)