Digia rozpoczęła proces wydzielania firmy córki, która będzie odpowiadała za zarządzanie całym ekosystemem Qt. Decyzja została podyktowana tym, że dwie strony: qt.digia.com i qt-project.com od długiego czasu konkurowały ze sobą, zamiast współpracować Pierwsza odpowiadała za cały biznes komercyjny, natomiast druga to była społeczność open source. Problemem tutaj okazały się pakiety i instalator, które były zupełnie różne dla obu wersji.
Aby zapobiec dalszemu rozwarstwieniu, Digia rozpoczęła powolne likwidowanie qt.digia.com i włączanie wszystkiego w qt-project.org, jako ujednolicony projekt. Nastąpi pełne połączenie bibliotek Qt oraz instalatora w wersji komercyjnej i open source. Wszystkie zmiany powinny być gotowe do października tego roku, wraz z premierą Qt 5.4.
Paweł Gałwa liked this on Facebook.
Ostatnio mnie Qt rozłożył.
To jest biblioteka ultra-portatywna. To, co napisze się pod Linuksa można bez większych zmian skompilować na Windowsie. Nawet biblioteka portu szeregowego działa bez problemu.
Ale ustawienia to domyślnie windowsowa wersja trzyma w rejestrze, a linuksowa w pliku. Miłego przenoszenia ustawień. I to podejście wprowadzili dopiero w 4.x.
Konsolidacja wersji Open z komercyjną zapewne okaże się adware/nagware.
To, że stanie się adware jest raczej bardzo pesymistycznym wariantem. Wątpię, żeby tak się stało.
Co do rejestru, to część gier na Steam robi podobnie z postępami gracza – na windowsie zapisy gry trzymane są w rejestrze, ale już na linuksie/osx ta sama gra trzyma zapisy tradycyjnie w pliku na dysku.
Mnie chodziło by program, mały bo mały, dwa ustawienia trzyma na krzyż, ale żeby dało się przechodzić z nimi między Okienkami a Pingwinem. Szczególnie, że zamierzam puścić program na GPLu.
Więc na razie program trzyma ustawienia w plikach INI. W Windows – w katalogu aplikacji, w Linuksie – w domowym z kropką przed nazwą.
Bardzo mi brakuje Documents – był taki komponent do Kylix’a, przydałoby się żeby w Qt to wprowadzili. Problem jest taki:
Jest sobie program, który wykorzystuje do działania pewne pliki (nazwijmy je skrypty). Jest dostarczany z powiedzmy kilkudziesięcioma eksploatacyjnymi skryptami. Użytkownik może tworzyć własne skrypty, zapisywać je z innymi a potem je wykorzystywać. W Windows to jest proste, ładuje się wszystko w katalog aplikacji, mało eleganckie, ale rączki umyte :). W Linuksie z wieloma użytkownikami tak dobrze już nie jest. Katalogu common (jak w BeOS’ie) nie ma i Documents to załatwiał tworząc coś w rodzaju wirtualnego katalogu.
„W Windows to jest proste, ładuje się wszystko w katalog aplikacji, mało eleganckie, ale rączki umyte :). W Linuksie z wieloma użytkownikami tak dobrze już nie jest. ”
Równie dobrze możesz wymusić jedyną słuszną konfigurację w /etc, bo jak aplikacje windowsową wsadzisz, gdzieś do Program Files będzie konieczne odpalenie z uprawieniami admina, aby zapisać zmiany w cfg w owym katalogu. Nawet na windowsie od dawna stosuję się trzymanie osobnych konfiguracji dla różnych użytkowników więc warto abyś w swoim programie jednak coś takiego uwzględnił ;-) .
Ten program jest dość charakterystyczny i trzymania go w Program Files nie przewiduję. Gdybym przewidywał, zamiast katalogu programu wybrałbym na ustawienia katalog użytkownika (Users…).
Program to coś w rodzaju interfejsu-automatu, jego się podczepia pod inny program do sterowania, który siedzi w n kopiach w katalogach projektów użytkownika (każdy projekt ma swoją kopię programu sterowania – nie ja to wymyśliłem). Więc tego programu musi być parę sztuk, czasami są różne konfiguracje w różnych projektach i stąd trzymanie w katalogu z EXEkiem. Pod Linuksem robi się tylko projekt startowany już na maszynie z Windowsami, więc mogłem dać katalog domowy.
To była kwestia ustawień, czyli np. ile razy ma sprawdzić się komunikacja przez USB i na jak długo wstrzymać się po resecie, żeby sprzęt ogarnął że istnieje.
A jak wygląda konsolidacja plików „od programu” i „od użytkownika”?
Pomyślałem, że może Windowsowymi specjalnymi katalogami (tymi z identyfikatorami w klamrach) dałoby się tak połączyć katalog skryptów programu i użytkownika (programu – read only, użytkownika – do wyboru) – ale potem przenoszenie tego na Linuksa chyba tylko przez dowiązania.
Chyba, że kopiowanie każdemu plików domyślnych do katalogu ustawień. Potem jeden zmieni, drugi nie i będą „jaja”.
Problem w tym, że ta biblioteka przegrywa życie. Kojarzona jest raczej z natywną biblioteką linuksową dla korpo.
Korpo generalnie żyje we własnym świecie pełnym dziwnych i nielogicznych decyzji. Zanim tam zapadnie jakaś poważna decyzja o nastawieniu się do produkcji softu minimum kilkanaście wyżej postawionych osób musi się ogarnąć (ewentualnie konkurencja pierwsza musi zarobić na tym poważny hajs).