gqview-2.1.1-1

[Daniel Mróz]

Paweł Sakowski napisał(a):
>>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.
No wlasnie, nie jest na tyle wazny zeby usera o tym powiadamiac natychmiast
(w postaci okienka), wiec sobie pisze na stderr. Jak user bedzie chcial
sobie obejrzec komunikaty, to sobie odpali spod konsoli. Nadal nie
rozumiem dlaczego Wam to przeszkadza.

> 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.
To jest troche inna bajka.

> 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.
I po kazdej aktualizacji aplikacji okienkowej mam przeczesywac dokumentacje
w poszukiwaniu informacji czy przypadkiem sie cos nie pozmienialo w
plikach? Przelicz sobie z grubsza ile czasu zajmie Ci przeszukanie
dokumentacji, a ile uruchomienie programu na konsoli i obejrzenie
komunikatow startowych.

>>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ę.
Daj spokoj. Nie znasz wszystkich uzytkownikow.

>>>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.
No to niech sobie abram przekieruje stderr/stdout do /dev/null. Ludzie,
przeciez po to sa te przekierowania wyjsc. Jesli abram sobie nie moze
poradzic z tak trywialna rzecza, to jest jego problem. Modyfikowanie
aplikacji dystrybucyjnych z tego powodu jest conajmniej glupie, tym
bardziej, ze wiele osob z tego korzysta.

>>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.
Powinno byc tak jak jest.

> 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.
Przeciez jest udostepniona. Standardowo jej nie widac, ale wiadomo gdzie
jest i jak sie do niej dostac w razie potrzeby.

>>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.
No to jest dwoch adminow, bo userow nie licze (maja prawo nie wiedziec
jak sobie poradzic z czyms takim). Jak dla mnie to za malo zeby zmieniac
wszystkie programy okienkowe.

> To, że jacyś programiści (czy ich jest 1% czy 99%) coś praktykuje, nie
> znaczy że jest to słuszne.
To, ze dwoch adminow mysli, ze cos jest zle, nie znaczy ze jest to sluszne.

Z mojej strony EOT, bo to nie ma sensu. Mam nadzieje, ze jesli
zaczniecie zmieniac dystrybucyjne aplikacje, to ktos Was powstrzyma.


Pozdrawiam
Beorn