gqview-2.1.1-1

[Paweł Sakowski]

On Fri, 2005-10-14 at 17:35 +0200, Daniel Mróz wrote:
> Wysoki stopien "wkurzalnosci" komunikatu nie implikuje jego bezuzytecznosci.

Zgoda. Co innego jeśli wkurzenie jest jedynym efektem komunikatu (bo nie
niesie on użytecznej informacji). W przypadku dowiedzenia się po raz
n-ty, że program jest betą, IMO zachodzi taki przypadek.

Podobna dyskusja była w przypadku bannerów %post. Tam stanęło na tym, że
użyteczność pierwszego wystąpienia informacji o czymkolwiek jest
dyskusyjna, ale od drugiego razu wzwyż informacja jest zbędna.

> Jesli program jest produktem beta, moze
> posiadac
> drobne bledy, o ktorych nie trzeba uzytkownika informowac za kazdym
> razem kiedy wystapia. Przesledz sobie np. uruchamianie programow z KDE.
> Wywalaja tam mnostwo komunikatow, z czego kilka jest typu "Nie moge
> otworzyc pliku X". Plik X nie jest wymagany do poprawnego dzialania
> aplikacji,

Jeśli plik powinien gdzieś być (powinien w sensie rpm -V), to chciałbym
o tym że go nie ma wiedzieć (i naprawić albo kogoś opieprzyć). Nawet
zadowolił bym się ubiciem programu na pierwszym nieznalezionym pliku,
chociaż w tej kwestii oczywiście YMMV.

Ale jeśli plik jest opcjonalny, to informacji "gdybyś miał /etc/foorc,
to bym z niego skorzystał, a tak to korzystam z /etc/barrc" szukałbym w
dokumentacji, a nie na konsoli. Analogia z bannerami jest aż nadto
wyraźna.

> ale dla ktoregos uzytkownika akurat moze byc to wazne (bo ma
> taki plik, tylko np. w innym miejscu niz sie tego spodziewa aplikacja).

Taki człowiek (który trzyma pliki w niestandardowych miejscach) pewnie
szybciej odpali `strace...|grep ENOENT` niż spojrzy na jakikolwiek
komunikat albo dokumentację.

> > Informacja że to beta ma sens w description i/lub dokumentacji, nie przy
> > każdym starcie.
> Nie miala by zadnego sensu jesli bylaby wyswietlana w postaci okienka.
> Jesli jest to komunikat na konsoli to nie widze zadnych przeciwskazan.

A jakie widzisz zawskazania? Wątek zaczął się od tego, że userzy abrama
właśnie przeciwskazania zobaczyli.

> Powtarzam jeszcze raz: jesli Ci to przeszkadza, to mozesz sobie
> przekierowac stderr i stdout do /dev/null i masz problem z glowy.

Niepotrzebnie. Ja sobie tak czy inaczej poradzę. Chodzi o to jak być
powinno.

> >>Nie, konsola jest zawsze miejscem do wyrzucania bledow, nawet
> >>jednoczesnie ze stosownym okienkiem 
> > Przeczytaj w http://www.faqs.org/docs/artu/ nt. "Rule of silence".
> Ech. Jest tez kilka dokumentow i ksiazek, w ktorych jest napisane aby
> komunikaty wrzucac na konsole. To co? Zaczynamy sie scigac na ilosc? ;)

Na jakość, Raymond raczej pisuje rzeczy przemyślane.

gcc nie krzyczy o błędach kompilacji na /dev/dsp0; fsck niepodpiętych
inodeów nie raportuje na /dev/lp0; python nie ogłasza SyntaxError na
forum Onetu. Program niekonsolowy nie ma żadnego interesu w pluciu na
stdout. Informacja powinna być udostępniana jeśli jest (ew. może być)
użyteczna, a przede wszystkim tam, gdzie jej udostępnienie będzie (ew.
może być) użyteczne.

> Od tylu lat nie slyszalem zeby ktos sie
> na to skarzyl, a Ty chcesz wszystko zmieniac, bo Tobie nie pasuje.

Sprostowanie: nie tylko mi, nie ja zacząłem ten wątek.

>  To
> jest akurat przydatny ficzer i jak widac stosowany przez wiekszosc
> programistow.

"Większość" to argument z serii ścigania się na ilość, do tego trudny do
obronienia. Nie zdarzyło mi się, żeby galeon& wypisywał coś na konsoli.
xmms& też nie. pysol& też nie. Te programy informacje o problemach
wypisują tam gdzie powinno (wg mojego osobistego rozumienia "powinny").
Nie wątpię, że jesteś w stanie podać kontrprzykłady.

To, że jacyś programiści (czy ich jest 1% czy 99%) coś praktykuje, nie
znaczy że jest to słuszne.

-- 
Paweł Sakowski <saq w pld-linux.org>
PLD Linux Distribution