Brief - czytnik kanałów RSS, dobre bo polskie! :)

[teo]

Używasz Noię i widocznie Brief nie współgra z tym motywem.
@Ancestor
Coś z tym musisz zrobić. Oprócz tego namieszałem też coś w wyglądzie okna opcji. Przeczytaj pocztę na Gmailu.

[Ancestor]

Może mylące i niespójne, ale chciałam dołączyć się do tej prośby (może w postaci ustawienia w opcjach, czy woli się otwierać wiadomości w nowej czy aktywnej karcie). Środkowy klawisz jest wygodny pod warunkiem, że się o ma :), a niestety standardowy laptop go nie ma.

Ok, to mnie przekonuje. Dodam taką opcję.

A dlaczego nie jest po polsku?? Co???
Przecież nie będę tego tłumaczył :)

należy pamiętać, że jest to wersja beta. Z tego też powodu nie ma jeszcze polskiej wersji za co bardzo przepraszam.

No to poproszę polską wersję ze zmianą Times New Roman na coś innego i zamieszczam w PBR Dlaczego wstawiłeś tą denną czcionkę" Z miejsca ją wywaliłem.

Hmm, zdążyłem zapomnieć, jak kiepsko ta czcionka wygląda na zwykłych monitorach kineskopowych. Zmienię. Natomiast jeszcze nie chciałbym umieszczać rozszerzenia w PBR dopóki sam go oficjalnie nie "wydam", czyli nie opublikuję na stronie mojego projektu na Mozdev.

Coś z tym musisz zrobić. Oprócz tego namieszałem też coś w wyglądzie okna opcji. Przeczytaj pocztę na Gmailu.

Dzięki za propozycje, ale prawdę mówiąc większości tych zmian nie rozumiem. Czemu usuwać min-width, pozbywać się spacerów i generalnie wszystko zmniejszać i bardziej stłaczać? Natomiast dzięki za zwrócenie uwagi na flex na groupboksach.

Jak ktoś otwiera strony interesujących artykułów z czytnika rss i chce powrócić do danych artykułów(interesujących przeczytanych). - aby zobaczyć np nowe komentarze.

Ponieważ stare artykuły są zachowywane, w krótkim czasie przeczytanych artykułów zbiera się o wiele więcej niż nieprzeczytanych. Jeśli więc przeczytanych jest 90%, to wyświetlanie ich osobno prawie nic nie zmienia w porównaniu z wyświetlaniem wszystkich naraz.

I u mnie nie wyświetla się zaokrąglenie z lewej strony przycisku Mark As Read
Nie wiem, co masz na myśli, możesz pokazać zrzut ekranu?

Zrzut :
http://canvas.freehost.pl/dane/Clipboard01.png

Wygląda na to, że jest to jakiś konflikt z Noia, poszukam przyczyny. Dzięki za raport. :)

[wroobel]

Jeżeli chodzi o problem z Noią, to podobny występuje także z motywem PimpZilla.

Ale nie o tym chciałem.

Zauważyłem, że Brief wyświetla wiadomości, z niektórych kanałów (np. Polska Mozilla Planet, PCLab.pl, a nawet RSS Bazy rozszerzeń - chociaż w tym przypadku jest to po prostu wyświetlanie w odwrotnej kolejności) w dziwny sposób, chodzi oczywiście o ich niechronologiczną, a wręcz przypadkową kolejność.
No i w związku z tym pytanie, czy to jest błąd, czy to jakaś funkcjonalność rozszerzenia, której to mój ciasny umysł nie potrafi objąć?

[teo]

Dzięki za propozycje, ale prawdę mówiąc większości tych zmian nie rozumiem. Czemu usuwać min-width, pozbywać się spacerów i generalnie wszystko zmniejszać i bardziej stłaczać? Natomiast dzięki za zwrócenie uwagi na flex na groupboksach.

Usunąłem styl bo określanie wielkości okna jest niepotrzebne gdy w "onload" dałem "sizeToContent()", a gropuboxy dostały flex. Wówczas wielkość okna dopasowuje się do tekstu poszczególnych tłumaczeń, a nie ma obawy, że okno będzie za szerokie, bo tekst jest zwięzły i krótki. Gdyby zachodziła potrzeba można ograniczyć szerokość folders-tree tak jak zmniejszyłem jego wysokość. Dzięki temu okno otrzymało zgrabniejszy wygląd.
Jeśli chodzi o spacery pomiędzy poszczególnymi opcjami, to IMHO są one zupełnie zbyteczne i dlatego je usunąłem.
Co sądzisz o zmianie układu groupboxa "Show"?
To tyle jeśli chodzi o okno opcji.

Teraz główne okno, bo trochę się Briefem pobawiłem. Oto moje przemyślenia:
1. Paski narzędziowe (oba)

• dałbym ikony 16x16
• jeśli już zostawiać 24x24 to niech ikona opcji ma 24x24, a nie 24x29
• usunąć "margin-right: 10px dla textboxa - po co odsuwać ikonę opcj?
• wstawić normalną ikonę z dropmakerem, a nie używać kombinacji ze stackiem
• zmniejszyć pole szukania - powiększa za bardzo panel boczny, który IMHO jest za szeroki

2. Zawartość okna

• zmniejszyć przyciski Mark as... i + z dropmakerem (ta sama uwaga jak wyżej dotycząca stacka) - są za duże i odciągają uwagę od treści

Jak przyjdzie mi jeszcze coś do głowy, to podzielę się uwagami.

[Ancestor]

Zauważyłem, że Brief wyświetla wiadomości, z niektórych kanałów (np. Polska Mozilla Planet, PCLab.pl, a nawet RSS Bazy rozszerzeń - chociaż w tym przypadku jest to po prostu wyświetlanie w odwrotnej kolejności) w dziwny sposób, chodzi oczywiście o ich niechronologiczną, a wręcz przypadkową kolejność.
No i w związku z tym pytanie, czy to jest błąd, czy to jakaś funkcjonalność rozszerzenia, której to mój ciasny umysł nie potrafi objąć? :D

Artykuły są sortowane wg daty. Obserwowane zachowanie, to efekt ułomności tych kanałów - nie zawierają one dat poszczególnych artykułów (lub są one w złym formacie), więc Brief nadaje artykułom datę na podstawie daty ich pobrania.

[Ancestor]

Dzięki za propozycje, ale prawdę mówiąc większości tych zmian nie rozumiem. Czemu usuwać min-width, pozbywać się spacerów i generalnie wszystko zmniejszać i bardziej stłaczać? Natomiast dzięki za zwrócenie uwagi na flex na groupboksach.

Usunąłem styl bo określanie wielkości okna jest niepotrzebne gdy w "onload" dałem "sizeToContent()", a gropuboxy dostały flex. Wówczas wielkość okna dopasowuje się do tekstu poszczególnych tłumaczeń, a nie ma obawy, że okno będzie za szerokie, bo tekst jest zwięzły i krótki. Gdyby zachodziła potrzeba można ograniczyć szerokość folders-tree tak jak zmniejszyłem jego wysokość. Dzięki temu okno otrzymało zgrabniejszy wygląd.
Jeśli chodzi o spacery pomiędzy poszczególnymi opcjami, to IMHO są one zupełnie zbyteczne i dlatego je usunąłem.

Widzisz, to wszystko rzecz gustu. Wg Ciebie całość wygląda zgrabniej, gdy wszystko jest ściśnięte, dopasowane i bez dodatkowej przestrzeni. Ja mam odmienne zdanie. :) Zostawię tak, jak jest.

Co sądzisz o zmianie układu groupboxa "Show"?

Mam mieszane uczucia. Z jednej strony przydałby się jakiś tytuł dla tego groupboksa, ale z drugiej:
1) nie wydaje mi się, aby taki układ, czyli opis opcji jest kontynuacją "zdania" zaczętego w etykiecie grupy, był praktykowany
2) taki sposób przedstawienia sugeruje bliski związek tych opcji, a tymczasem niewiele, poza odnoszeniem się do "pokazywania" czegoś, mają wspólnego

Teraz główne okno, bo trochę się Briefem pobawiłem. Oto moje przemyślenia:
1. Paski narzędziowe (oba)

• dałbym ikony 16x16
• jeśli już zostawiać 24x24 to niech ikona opcji ma 24x24, a nie 24x29

16x16 są za małe. Ikona opcji to przeoczenie, do naprawienia.

• usunąć "margin-right: 10px dla textboxa - po co odsuwać ikonę opcj?
• zmniejszyć pole szukania - powiększa za bardzo panel boczny, który IMHO jest za szeroki

Szerokość panelu możesz sobie zmienić i jest ona zapamiętywana, więc nie widzę problemu. Co do paska narzędzi, zrobię elastyczny układ z fleksem dla textboksa, ale ustawię dla niego jakiś min-width.

2. Zawartość okna

• zmniejszyć przyciski Mark as... i + z dropmakerem (ta sama uwaga jak wyżej dotycząca stacka) - są za duże i odciągają uwagę od treści

Hmm, dzięki za zwrócenie uwagi - a raczej potwierdzenie moich wątpliwości. Z drugiej jadnak strony muszą być duże, bo są bardzo często używane. Ja przeglądając nowe artykuły klikam na Mark as Read kilkadziesiąt razy w ciągu kilku minut. Zastanawiałem się nad -moz-appearance: none i stworzeniem własnych przycisków zamiast natywnych. Spróbuję jednak nadać im przezroczystość - wtedy wilk jest syty i owca cała, a sam efekt wygląda całkiem fajnie.

wstawić normalną ikonę z dropmakerem, a nie używać kombinacji ze stackiem

Pewnie masz rację.

Jak przyjdzie mi jeszcze coś do głowy, to podzielę się uwagami.

Serdeczne dzięki za komentarz. :)

PS. Nie wiem czy wiesz, ale źródła są online: http://www.mozdev.org/source/browse/brief/src/

[teo]

Usunąłem styl bo określanie wielkości okna jest niepotrzebne gdy w "onload" dałem "sizeToContent()", a gropuboxy dostały flex. Wówczas wielkość okna dopasowuje się do tekstu poszczególnych tłumaczeń, a nie ma obawy, że okno będzie za szerokie, bo tekst jest zwięzły i krótki. Gdyby zachodziła potrzeba można ograniczyć szerokość folders-tree tak jak zmniejszyłem jego wysokość. Dzięki temu okno otrzymało zgrabniejszy wygląd.
Jeśli chodzi o spacery pomiędzy poszczególnymi opcjami, to IMHO są one zupełnie zbyteczne i dlatego je usunąłem.

Widzisz, to wszystko rzecz gustu. Wg Ciebie całość wygląda zgrabniej, gdy wszystko jest ściśnięte, dopasowane i bez dodatkowej przestrzeni. Ja mam odmienne zdanie. Zostawię tak, jak jest.

Jeśli chodzi o wstawianie spacerów, to rzeczywiście sprawa gustu, ale wybacz, wstawianie spacera zaraz po caption jest dyskusyjne, bo domyślnie następuje odsunięcie kolejnego wiersza. Pomiędzy opcjami?...
Ważniejsze jest tutaj takie ustawienie parametrów okna jak ja zrobiłem. Z twojej odpowiedzi wynika, że chcesz zostawić takie długie jak jest teraz. Czy dobrze zrozumiałem?

Mam mieszane uczucia. Z jednej strony przydałby się jakiś tytuł dla tego groupboxa, ale z drugiej:
1) nie wydaje mi się, aby taki układ, czyli opis opcji jest kontynuacją "zdania" zaczętego w etykiecie grupy, był praktykowany

Jest praktykowany w wielu rozszerzeniach, a z racji tego co robię przejrzałem ich dużo.

2) taki sposób przedstawienia sugeruje bliski związek tych opcji, a tymczasem niewiele, poza odnoszeniem się do "pokazywania" czegoś, mają wspólnego

Absolutnie nie. Odnosi się do tekstu umieszczonego w caption

16x16 są za małe. Ikona opcji to przeoczenie, do naprawienia.

To daj 20x20. Będą mniejsze niż na pasku narzędzi nawigacyjnych, a większe niż favikony na pasku zakładek osobistych. Ja oglądam to na 1280x1024, a jak spojrzałem na 1024x768 to IMHO są za duże, a jest jeszcze spora grupa osób, które używają 800x600.

Szerokość panelu możesz sobie zmienić i jest ona zapamiętywana, więc nie widzę problemu. Co do paska narzędzi, zrobię elastyczny układ z fleksem dla textboksa, ale ustawię dla niego jakiś min-width.

No kurczę! Czy ty sądzisz, że masz doczynienia z laikiem? Pierwsze co zrobiłem to zobaczyłem jak zmienia się szerokość panelu i co się dzieje. Sztywno ustawiony textbox powoduje znikanie ikony opcji, odsunięcie jej poprzez margin-right tylko zwiększa szybkość jej ukrywania. Rozwiązanie z flexem textboxa jest OK. Min-width spowoduje, że nie zniknie całkowicie. Dla tekstu daj crop i będzie OK.

Hmm, dzięki za zwrócenie uwagi - a raczej potwierdzenie moich wątpliwości. Z drugiej jadnak strony muszą być duże, bo są bardzo często używane. Ja przeglądając nowe artykuły klikam na Mark as Read kilkadziesiąt razy w ciągu kilku minut. Zastanawiałem się nad -moz-appearance: none i stworzeniem własnych przycisków zamiast natywnych. Spróbuję jednak nadać im przezroczystość - wtedy wilk jest syty i owca cała, a sam efekt wygląda całkiem fajnie.

Chyba będzie OK.
Tyle uwag mam do tego rozszerzenia, ale chyba dlatego, że jest to chyba najlepszy czytnik jaki do tej pory widziałem i chciałbym, aby wyglądał też ładnie. Możliwość dodawania własnych stylów zwiększy jego atrakcyjność, a jak na mozdev będzie jeszcze wybór gotowych css to będzie fajnie. Może w przyszłości dołączysz do rozszerzenia wybór stylów.

[Ancestor]

Jeśli chodzi o wstawianie spacerów, to rzeczywiście sprawa gustu, ale wybacz, wstawianie spacera zaraz po caption jest dyskusyjne, bo domyślnie następuje odsunięcie kolejnego wiersza. Pomiędzy opcjami?...

Usunąłem część spacerów.

Ważniejsze jest tutaj takie ustawienie parametrów okna jak ja zrobiłem. Z twojej odpowiedzi wynika, że chcesz zostawić takie długie jak jest teraz. Czy dobrze zrozumiałem?

Tak. BTW, persist traci sens jeśli stosuje się sizeToContent() podczas otwierania.

Mam mieszane uczucia. Z jednej strony przydałby się jakiś tytuł dla tego groupboxa, ale z drugiej:
1) nie wydaje mi się, aby taki układ, czyli opis opcji jest kontynuacją "zdania" zaczętego w etykiecie grupy, był praktykowany

Jest praktykowany w wielu rozszerzeniach, a z racji tego co robię przejrzałem ich dużo.

Ale nie rozszerzenia są tutaj dla mnie punktem odniesienia, bo piszą je przecież zazwyczaj amatorzy (jak ja ) i często spotykane są dyskusyjne rozwiązania czy wręcz potworki. Zaś w Firefoksie w takich sytuacjach stosowane są nie grupy ale etykiety (zobacz np. Narzędzia > Opcje > Zaawansowane > Aktualizacja). Grupy nie muszą mieć koniecznie tytułu i właśnie bez tytułu tę grupę zostawię.

16x16 są za małe. Ikona opcji to przeoczenie, do naprawienia.

To daj 20x20. Będą mniejsze niż na pasku narzędzi nawigacyjnych, a większe niż favikony na pasku zakładek osobistych. Ja oglądam to na 1280x1024, a jak spojrzałem na 1024x768 to IMHO są za duże, a jest jeszcze spora grupa osób, które używają 800x600.

To nie są moje własne ikony, lecz "pożyczone". Większości z nich nie mam w innych formatach poza standardowymi 16x16 i 24x24, a zwykły resampling nie wchodzi w grę przy tak małych obrazkach. Nie mam więc wyjścia.

Szerokość panelu możesz sobie zmienić i jest ona zapamiętywana, więc nie widzę problemu. Co do paska narzędzi, zrobię elastyczny układ z fleksem dla textboksa, ale ustawię dla niego jakiś min-width.

No kurczę! Czy ty sądzisz, że masz doczynienia z laikiem? Pierwsze co zrobiłem to zobaczyłem jak zmienia się szerokość panelu i co się dzieje.

Nie mówię, że nie zobaczyłeś.

Sztywno ustawiony textbox powoduje znikanie ikony opcji, odsunięcie jej poprzez margin-right tylko zwiększa szybkość jej ukrywania. Rozwiązanie z flexem textboxa jest OK. Min-width spowoduje, że nie zniknie całkowicie. Dla tekstu daj crop i będzie OK.

Którego tekstu?

Chyba będzie OK.
Tyle uwag mam do tego rozszerzenia, ale chyba dlatego, że jest to chyba najlepszy czytnik jaki do tej pory widziałem i chciałbym, aby wyglądał też ładnie. Możliwość dodawania własnych stylów zwiększy jego atrakcyjność, a jak na mozdev będzie jeszcze wybór gotowych css to będzie fajnie. Może w przyszłości dołączysz do rozszerzenia wybór stylów.

Dzięki. Też mam nadzieję, że czasem Brief wzbogaci się o więcej stylów.

Nowa wersja jest już na CVS.

[teo]

Tak. BTW, persist traci sens jeśli stosuje się sizeToContent() podczas otwierania.

Absolutnie nie! Persist określa jakie elementy okna zostaną zapisane przy jego zamykaniu, a sizeToContent, że okno po otwarciu ma mieć wielkość dopasowaną do jego zawartości.
Rozpatrzmy konkretny przykład okna opcji Briefa jaki ja ci przesłałem.

Kod: Zaznacz cały

onload="init(); sizeToContent();"
title="&optionsWindow.title;"
persist="screenX screenY width height"

Efekt końcowy jest taki, że okno otwiera się dopasowane do zawartości, a więc ma minimalne wymagane parametry szerokości i wysokości tak, aby wszystko było widać. Ślicznie!
No to teraz przejdźmy do persist, które określa, że przy zamykaniu należy zapamiętać położenie okna na pulpicie przeglądarki i jego szerokość i wysokość. Zmieniamy parametry width i height rozciągając okno. Zamykamy okno i zgodnie z persist ostatnie wartości zostały zapisane w localstore.rdf. No to teraz otwieramy okno ponownie, i co się dzieje? Okno zostaje otwarte wg parametrów zapisanych w localstore.rdf. Bingo!
Co to oznacza w praktyce dla ZU? Ano to, że nie musi ingerować w wielkość okna, bo nie ma takiej potrzeby, a gdy mu się zachce zmieniać wielkość okna, to nowe parametry zostaną zapamiętane.
Oczywiście można zrezygnować z deklarowania width i height w persist, albo w ogóle z tego parametru. To już decyzja należy do developera. Jaka jest przewaga sizeToContent? Ano taka, że ZU nie musi nic kombinować, aby wszystko wyświetlało się dobrze. Ma również kolosalne znaczenie dla lokalizacji rozszerzenia. Bez względu na to ile będą dłuższe od oryginału przetłumaczone frazy zawsze okno będzie się do nich dopasowywało. Jeśli podasz sztywne wartości okna może zachodzić przypadek, że treść nie będzie mieściła się w oknie i wówczas trzeba go powiększać. Chyba nie o to chodzi. Na dodatek parametry okna wstawiłeś do css i nie ma możliwości określenia ich przez tłumacza. Niektórzy developerzy wstawiają je do .dtd. Wówczas tłumacz może dopasować te parametry, ale po co, skoro można na etapie tworzenia rozszerzenia dobrać je tak, że nie ma problemu. Chyba takie jest zadanie twórcy, aby rozszerzenie funkcjonowało bez zastrzeżeń.
Uwagi dotyczące tłumaczeń odnoszą się do rozszerzenia multilanguage, bo jeśli ktoś je zrobi tylko do publikacji w swoich zasobach, to już inna kwestia.

Ale nie rozszerzenia są tutaj dla mnie punktem odniesienia, bo piszą je przecież zazwyczaj amatorzy (jak ja ) i często spotykane są dyskusyjne rozwiązania czy wręcz potworki. Zaś w Firefoksie w takich sytuacjach stosowane są nie grupy ale etykiety (zobacz np. Narzędzia > Opcje > Zaawansowane > Aktualizacja). Grupy nie muszą mieć koniecznie tytułu i właśnie bez tytułu tę grupę zostawię.

Akurat podany przez ciebie przykład nie jest najszczęśliwszy, bo w tym przypadku elementy zostały wstawione na żywo do prefpana, lub taboxa (nie chce mi się sprawdzać). Gdyby dodać do nich groupboxa i caption, to byłoby właśnie to co ja zrobiłem. . Ty w swojej wersji dałeś groupbox bez caption. Chyba właściwszym przykładem byłoby okno Bezpieczeństwo. Oprócz tego zobacz jak graficznie niespójnie wyglądają poszczególne okna opcji Firefoksa po ostatnich zmianach - vide panele Karty, Kanały i wskazana przez ciebie karta w Zaawansowanych. Było to zgłaszane na Bugzilli. Konkluzja była taka, że albo zrezygnować z groupboxów wszędzie, albo wszędzie je wstawić.

To nie są moje własne ikony, lecz "pożyczone". Większości z nich nie mam w innych formatach poza standardowymi 16x16 i 24x24, a zwykły resampling nie wchodzi w grę przy tak małych obrazkach. Nie mam więc wyjścia.

Sprawdzałem jak wyglądają po zmianie na 20x20 i ... wcale nieźle. Skombinuj wektory, to zrobi się cacka.

Którego tekstu?

No... szukanego.

[Ancestor]

Tak. BTW, persist traci sens jeśli stosuje się sizeToContent() podczas otwierania.

Absolutnie nie! Persist określa jakie elementy okna zostaną zapisane przy jego zamykaniu, a sizeToContent, że okno po otwarciu ma mieć wielkość dopasowaną do jego zawartości.

Zgadza się. Myślałem jednak, że ponieważ sizeToContent() jest wywoływane bezwarunkowo podczas otwarcia, będzie ono zastępowało wartości zapisane w localstore.rdf. Okazuje się, że nie. Inna sprawa, że zapomniałem dodać resizeable do cech okna, więc i tak persist nie miało znaczenia. :P

Co to oznacza w praktyce dla ZU? Ano to, że nie musi ingerować w wielkość okna, bo nie ma takiej potrzeby, a gdy mu się zachce zmieniać wielkość okna, to nowe parametry zostaną zapamiętane.
Oczywiście można zrezygnować z deklarowania width i height w persist, albo w ogóle z tego parametru. To już decyzja należy do developera. Jaka jest przewaga sizeToContent? Ano taka, że ZU nie musi nic kombinować, aby wszystko wyświetlało się dobrze. Ma również kolosalne znaczenie dla lokalizacji rozszerzenia. Bez względu na to ile będą dłuższe od oryginału przetłumaczone frazy zawsze okno będzie się do nich dopasowywało. Jeśli podasz sztywne wartości okna może zachodzić przypadek, że treść nie będzie mieściła się w oknie i wówczas trzeba go powiększać. Chyba nie o to chodzi. Na dodatek parametry okna wstawiłeś do css i nie ma możliwości określenia ich przez tłumacza. Niektórzy developerzy wstawiają je do .dtd. Wówczas tłumacz może dopasować te parametry, ale po co, skoro można na etapie tworzenia rozszerzenia dobrać je tak, że nie ma problemu. Chyba takie jest zadanie twórcy, aby rozszerzenie funkcjonowało bez zastrzeżeń.
Uwagi dotyczące tłumaczeń odnoszą się do rozszerzenia multilanguage, bo jeśli ktoś je zrobi tylko do publikacji w swoich zasobach, to już inna kwestia.

Zgadza się. I właśnie takie rozwiązanie wybrałem - wstawiłem odpowiednią encję i lokalizator może określić szerokość okna. Chyba to przeoczyłeś. ;)

Akurat podany przez ciebie przykład nie jest najszczęśliwszy, bo w tym przypadku elementy zostały wstawione na żywo do prefpana, lub taboxa (nie chce mi się sprawdzać). Gdyby dodać do nich groupboxa i caption, to byłoby właśnie to co ja zrobiłem. :). Ty w swojej wersji dałeś groupbox bez caption. Chyba właściwszym przykładem byłoby okno Bezpieczeństwo. Oprócz tego zobacz jak graficznie niespójnie wyglądają poszczególne okna opcji Firefoksa po ostatnich zmianach - vide panele Karty, Kanały i wskazana przez ciebie karta w Zaawansowanych. Było to zgłaszane na Bugzilli. Konkluzja była taka, że albo zrezygnować z groupboxów wszędzie, albo wszędzie je wstawić.

Tak też mówi Gnome HIG. Nie chcę z tej grupy rezygnować, a jedynie pozostawiam ją bez tytułu, bo nie chcę wymyślać go na siłę.. Wg mnie zaproponowany przez ciebie format jest nieintuicyjny. Grupy są służą do wizualnego połączenia kilku opcji, są dodatkiem, który zauważymy zazwyczaj tylko podświadomie, a nie częścią opisu niezbędną do zrozumienia danej opcji. Nie ma co dzielić włosa na czworo, takie rozwiązanie mi nie leży. ;)

To nie są moje własne ikony, lecz "pożyczone". Większości z nich nie mam w innych formatach poza standardowymi 16x16 i 24x24, a zwykły resampling nie wchodzi w grę przy tak małych obrazkach. Nie mam więc wyjścia.

Sprawdzałem jak wyglądają po zmianie na 20x20 i ... wcale nieźle. Skombinuj wektory, to zrobi się cacka.

Ja też właśnie sprawdziłem i wygląda o kilka klas gorzej. ;) Co najmniej połowy ikon nie mam możliwości zdobycia w postaci wektorowej.

Którego tekstu?

No... szukanego.

Skąd ja wezmę crop na textboksie??

[teo]

Nie będę zamieszczał już cytatów, tylko odpowiem ci bezpośrednio:
1. Pomyliłem parametry wielkości okna z wielkością folders-tree, które zamieściłeś w css - masz rację. Po co takie wielkie. To przez nie jest takie wysokie to okno.
2. Nie mogę zrozumieć twojego uporu dotyczącego sztywnych parametrów okna? Po co? Skoro moje rozwiązanie automatycznie dopasowuje parametry okna do zawartości. Lokalizator nie potrzebuje określać żadnych parametrów!
3. Ten crop, to był za szybki skrót myślowy.
4. Jeszcze nie zaglądałem do CVS.

Edit:
Zajrzałem. Nawet searchbar-container margin-right nie zmieniłeś. Po co ikona opcji jest odsuwana od textboxa??

[Ancestor]

2. Nie mogę zrozumieć twojego uporu dotyczącego sztywnych parametrów okna? Po co? Skoro moje rozwiązanie automatycznie dopasowuje parametry okna do zawartości. Lokalizator nie potrzebuje określać żadnych parametrów!

Ponieważ sizeToContent() ustawia minimalną wielkość okna potrzebną do zmieszczenia zawartości - a ja wolę układ bardziej przestronny i liczę, że lokalizator zachowa ten styl.

[teo]

Ponieważ sizeToContent() ustawia minimalną wielkość okna potrzebną do zmieszczenia zawartości - a ja wolę układ bardziej przestronny i liczę, że lokalizator zachowa ten styl.

Teraz to już nie mam argumentów. "De gustibus non est disputandum". Mamy zupełnie inne poczucie estetyki. Dla mnie okna dialogowe powinny być jak najmniejsze, ale czytelne i zrozumiałe i nie powodujące utrudnień. Po co bawić się w dopasowywanie skoro zrobi się to automatycznie?
Szerokość twojego okna jest chyba taka sama jak z sizeToContent. Wysokość jest dla mnie nie do przyjęcia.

[teo]

Jeszcze jedna propozycja,
Po otwarciu danego artykułu powinien on automatycznie być oznaczany jako przeczytany.
Chyba zapomniałeś o przypadłości Fx, że jeśli nie ma tooltipa, to wyświetla puste okienko lub ostatnio wyświetlony tooltip. Tak dzieje się z ikoną na pasku stanu.

[Ancestor]

Jeszcze jedna propozycja,
Po otwarciu danego artykułu powinien on automatycznie być oznaczany jako przeczytany.

Planuję taką opcję.

Chyba zapomniałeś o przypadłości Fx, że jeśli nie ma tooltipa, to wyświetla puste okienko lub ostatnio wyświetlony tooltip. Tak dzieje się z ikoną na pasku stanu.

To przypadłość bety - jeszcze go zaimplementowałem. Będzie pokazywał dokładniejsze informacje o nieprzeczytanych artykułach.

[teo]

Kolejne odkrycie, to niestety nie pasująca ikona czyszczenia pola szukania. Ten krzyżyk jest zawsze dedykowany do zamykania. Tutaj wprowadza w błąd, bo czyści pole, a nie zamyka.

[Ancestor]

Kolejne odkrycie, to niestety nie pasująca ikona czyszczenia pola szukania. Ten krzyżyk jest zawsze dedykowany do zamykania. Tutaj wprowadza w błąd, bo czyści pole, a nie zamyka.

Zmieniłem ikonę.

[teo]

Chyba masz już mnie dość.

[Ancestor]

Ależ nie! Naprawdę każda uwaga jest dla mnie cenna. Właśnie na taki potok propozycji i komentarzy liczyłem zakładając ten wątek.

[teo]

No to dobrze, bo podobno upierdliwy jestem do bólu. Tak niektórzy tłumacze mówią jak sprawdzam ich robotę.