Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
U příležitosti oslav čtyř let prací na debianím balíčku vyšla nová major verze programu GPXSee. Verze 10 přináší zejména možnost zobrazení real-time GPS pozice. Bohužel, zrovna na Linuxu není podpora GPS žádná hitparáda…
Tiskni
Sdílej:
Verze 10 přináší zejména možnost zobrazení real-time GPS pozice. Bohužel, zrovna na Linuxu není podpora GPS žádná hitparáda…Já tomu teda nerozumím, ale tohle jsme s kamarádem řešili tak, že jsme pustili gpsd a pak jsme se připojili na nějaký port na localhostu a tam chodily každou sekundu NMEA zprávy se souřadnicema.
GPSD je kapitola sama pro sebe - například to co píšeš není tak úplně pravda, protože tuhle základní funkcionalitu, co by od toho člověk čekal, že to bude multiplexovat to GPS zařízení to umí jenom tak, že si po připojení musíš nějakým commandem to posílání zpráv zapnout...
Nicméně ten hlavní problém je, že v Qt zvolili jako "backend" technologii Geoclue, což je "GNOME kvalita" v celé své kráse (je to takové peklo, že ač jsem se zařekl, že tyhle politicky nekorektní vyjádření na oficiální stránky dávat nebudu a nechám si je jenom do diskuzí na AbcLinuxu, tak tady jsem se neudržel). Podívej se na to v dokumentaci GPXSee odkazované issue na Githubu, přijde ti toto normální?!
No a jako třešnička na dortu není žádná distribuce linuxu schopná správně sestavit Qt Positioning modul (respektivě jeho pluginy), takže na žádném "běžném" linuxu nelze Qt jednoduše propojit s /dev/ttyACM0 jako to lze na Windows s virtuálním COM portem, na kterém běží ten NMEA stream z USB donglu. Nebo skutečném seriovém portu, ale tam zase je ve zdrojácích Qt natvrdo rychlost 4800bd...
GPS v linuxu je prostě jedna z oblastí, kde na cokoliv šáhneš, je to špatně...
Nicméně ten hlavní problém je, že v Qt zvolili jako "backend" technologii Geoclue, což je "GNOME kvalita" v celé své kráseA se nemůžeš vykašlat na Geoclue a místo toho bude v konfiguraci GPSD host a GPSD port, na který se to připojí a bude to brát polohu z toho?
serialnmea plugin (ten plugin na linuxu normálně funguje, jenom ho distribuce nekompilujou...)Ehm, prečo distribúcie vynechali takúto elementárnu vec?
Těžko říct, jestli je to spíš chyba distribucí, jak ten Qt modul kompilují, nebo chyba Qt jak má udělanou konfiguraci toho modulu. Ale výsledek každopádně je, že prakticky všude ten modul chybí...
To není žádné "ohánění", to je prostě fakt, že ten problém je bug Qt, které za některých (mě neznámých) okolností na některých systémech vrací špatné systémové locale. Takže reportovat a tlačit na opravu je potřeba v Qt bugzille. Z hlediska GPXSee lze akorát hledat nějaký workaround odpovídající závažnosti problému a ten je známý a sám tu o něm píšeš - smazat v programu všechny ostatní lokalizace kromě požadované.
Představa, že veškeré bugy, na které člověk u sebe narazí se musí týkat všech a vývojáři je musí za každou cenu řešit, ať jsou sebemarginálnější, je sice běžná, ale zcela mylná. Řešit obskurní bugy pro 0.00001% uživatelů se prostě nezaplatí, což platí i pro opensource ač tady platidlem nejsou přímo peníze. Opensource SW nicméně přináší tu zásadní výhodu, že má-li člověk opravdu zájem, může si to na své náklady opravit zcela podle jeho představ.
Autor by mel ocenit, ze mu nekdo nahlasil bug a neco s tim provist, pokud neprovede, tak at se nedivi, ze jeho veledilo nikdo pouzivat nebude.
Autor s tím bugem "něco" udělal. Analyzoval, že se jedná o problém Qt na nějaké specifické, neznámé, kombinaci konkrétního OS a konkrétního nastavení locales a odkázal uživatele na místo, kde je potřeba to reportovat/řešit. Protože ten problém nepostihuje jenom jeho SW, ale tisíce dalších a je nesmysl, aby každý takový postižený SW musel obsahovat nějaký workaround pro tento případ. Navíc je známý jednoduchý workaround, který si může uživatel provést sám.
Že by to "veledílo" nikdo nepoužíval se autor opravdu neobává. I s touto "chybou" ten SW používají statisíce uživatelů, kterých se ten bug vůbec netýká a kteří naopak ocení, když místo do výroby nějakého nesmyslného workaroundu budou zdroje na vývoj investovány do něčeho pro ně užitečného.
On totiz ten, kdo mu ten bug hlasi, mozna ve skutecnosti je autorem neceho jinyho.
Pravděpodobnost toho je někde na úrovní "být zasažen meteoritem". Lidi, za kterými je reálný kus práce opravdu "neštěkají" po ostatních v diskuzích pod anonymními účty... Největší "anonymní odborníci" na to, jak by to ostatní měli dělat jsou vždy ti, kteří sami nevytvořili žádný OS SW, nebo mají 300 řádkový skript na Githubu na jehož základě se cítí nesmírně fundovaní školit ostatní jak se takový OS SW projekt vede...
A jestli ho neco nasere, tak pindy o tom, ze si to ma spravit sam.
Osobne mam na svym systemu hromadu veci, ktery sem si opravoval sam, a po presne takovyhle zkusenostech to uz ani nikam nehlasim, protoze i kdyz poslu patch, tak akorat uvidim hromadu keu na tema ze tam mam mezery jinde nez je tvurce chce a podobne, pripadne ten patch pouzije a neuvede me ani jako autora toho patche(natoz aby rek dik) atd atd.
Takže tebe děsně sere, že ti někdo řekne, že jestli to chceš mít upravený/opravený přesně podle tvého gusta, tak si to máš udělat sám a hned v zápětí napíšeš, že přesně tohle vlastně děláš, protože při tvé schopnosti komunikovat s ostatními to jinak nejde?! Řekl bych, že musíš žít v permanentní nasranosti...
Který SW od Applu to na OS X má? Macos human interface guidelines co pamatuju vždy počítaly s jednotnou systémovou změnou v nastavení systému...
Nebudu. Špatná featura je to proto, že když si uživatel změní to systémové nastavení, tak se mu některé aplikace nezmění, protože ty si žijí vlastním životem (podle vlastních preferencí). V okamžiku, kdy by se takhle začala chovat každá aplikace, tak je to systémové nastavení úplně k ničemu. A i když by se tak chovala jenom část aplikací, tak je to pro uživatele pain-in-the-ass po každé změně jazyka hledat v každé jednotlivé aplikaci kde přenastavit něco, co už jednou jinde nastavoval...
To je taky důvod, proč něco takového žádná nativní Apple aplikace na OS X nemá. A vzhledem k tomu, že se ve svých aplikacích snažím ctít ono známé: "When in Rome, do as the Romans do", tak to tam taky nechci.
Ano jsou, ale v takovém případě si každý může tu aplikaci spouštět pomocí:
LANG=pt_BR aplikace
a není nutné do každé aplikace kvůli tomu cpát speciální GUI pro nastavování jazyka a vymýšlet speciální scénáře (pro každou aplikaci samozřejmě zcela jiné), co se má stát, když se to systémové nastavení změní... Na OS X jsou v tomhle, narozdíl třeba od KDE, kde polovina aplikací separátní nastavování jazyka má a druhá polovina nemá, aplikace naštěstí poměrně konzistentní.
V macOS neni nejaka globalni instalace QT, maximalne si jej nekdo stahne jako dependency do /usr/local napr. pres brew. Kdyz je ale apka balena jako cask (neco na styl flatpak) tak ma svuj pisecek s vlastnim QT a configem (treba chybejicim) a nevi standartne zhola nic o nejakem systemovem locale.
Homebrew cask je AFAIK pouze správce balíčků nad "oficiálníma" binárkama, takže GPXSee cask pouze nainstaluje ten oficiální build do /Applications, místo toho, aby to musel dělat uživatel "ručně". Čili GPXSee samozřejmě má přístup k locale systému a také tu informaci normálně využívá pro nastavení lokalizace.
To bude pripad i GPXSee a to je tedy problem maintainera, ktery to odpalkuje ze to je problem zdrojaku z githubu a tedy spatny preset developerem.
Četl jsem tu větu 10x a jediný závěr, ke kterému jsem dospěl je, že to není česky... Ta věta prostě nedává žádný smysl.
Jelikoz developer od toho dava ruce pryc tak by bylo nejlepsi podporu macOS uplne utnout kdyz to neumi/nechce fixnout nebo navrhy uzivatelu na upravu tvrdosijne odmita.
To jako když jednomu z tisíce uživatelů z neznámých důvodů něco nefunguje, tak radši ten SW sebereme i všem ostatním? S takovým přístupem by ti toho na počítači moc nezbylo...
Neber to osobně, ale neumožnit uživateli změnit lokalizaci programu je fail.Je to uplne stejnej fail, jako tam nemit asi milion dalsich features, ktere si kdy nejaky uzivatel vymyslel.
Jenže, když se změní systémové nastavení se dá poznat a pak podle toho nějak jednat. Neber to osobně, ale neumožnit uživateli změnit lokalizaci programu je fail. A argumentovat že "kdyby se takhle chovala každá aplikace" je prostě mimo.
Ne, to opravdu to není fail jak dokazují veškeré nativní aplikace od Applu. To je prostě preferovaný chování aplikací na Mac platformě. Můžeme o tom vést spory, můžeme s tím nesouhlasit, ale to je asi tak všechno, co s tím můžeme udělat...
Tohle je přesně ten špatný gnome přístup.
Jako uživatel to samozřejmě můžeš považovat za špatné a vybrat si jiný desktop/platformu. Ale pokud pro takovou platformu/desktop vyvíjíš software, tak to prostě musíš respektovat, protože ten SW píšeš pro uživatele, kteří si právě kvůli tomuto přístupu tu platformu vybrali.
No jenze GPXSee neni nativni apka.
Není, ale snaží se nativním aplikacím přiblížit jak jen to je možné.
Kdyby tomu tak bylo tak nevybafne v rustine
To jako že Apple SW (OS, knihovny, aplikace, ...) nemá bugy? O vtipu dne je už dneska rozhodnuto...
nebyl by lepsi elektron?
Můžeš to zkusit...
Dobrý den,
děkuji, aplikace vypadá velmi pěkně. Vyzkoušel jsem již před týdnem starší verzi na Librem 5 a moje nagenerované OSM mapy pro Garmin zobrazuje pěkně. Když se aplikace na USB-C docku vytáhne na HDMI monitor nebo pustí přes ssh -X, tak je ovládání a zoomování paráda. Ipřes to, že není pro mobilní nasazení pod posh-em optimalizovaná, tak je v zásadě i na displeji na mobilu funkční. Chybí zoom out, na malém proužku, který zbude z toolbaru není. Zoom in lze docílit double-tapem. Zobrazení a panning OSM ČR je svižné.
Geoclue na Librem 5 chodí out-of-box, zdá se, že GPXsee něco bere. Doma asi pozici podle připojení. Vlastní GPS minimálně na mém kuse, a asi podle reportů i na dalších, má problémy s anténou. Ale když jsem nechal Librem 5 dostatečně dlouho na střeše nad naší firemní kanceláří, tak se dříve chytla. Zkusím to s novým buildem GPXsee, jestli se pozice propadne i do něho.
Pro pohodlné použití na mobilním zařízení by bylo potřeba přidat zoomování prsty. Kolegové z Elektroline mě na základě jejich firemního kódu nad silicon-heaven nasměrovali na QPinchGesture. Fragmenty z jejich software na vizualizaci tramvajových dep
Tak až mi zbude chvíle mezi přípravou na předmět, přednášením, stříháním pro školu a prácí na ESA projektu ve firmě, tak se na to třeba podívám.
QFrame, setDragMode(QGraphicsView::ScrollHandDrag)
grabGesture(Qt::PinchGesture);
grabGesture(Qt::TapAndHoldGesture)
Asi GPXsee zmíním i na Librem 5 fóru. Gnome mapy jsou pěkné, ale zatím umí jen online tiles a nějak shapefiles, ale ty jsem nezkoušel. GPXsee je zatím první, program, který by pro mě mohlo nahradit OSMand, který jsem zkoušel na odloženém Replicantu s robitou RF/GSM částí. Nechci být závislý na datech a ani zatím nejsem rozhodnutý, jestli Librem 5 natrvalo SIM dopřát. Přece jenom zatím na rozumnou dobu v přírodě je výdrž bídná a asi se nepodaří dát dohromady. Ale jako přenosný počítač do Full HD výstupu (na 4k je nepoužitelně pomalý i prohlížeč obrázků), prototyp telefonu a vývojový systém i pro naše industrial aplikace na i.MX je to moc hezký kousek a obrovský pokrok vpřed.
S pozdarvem, Pavel Píša
/usr/sbin/debootstrap \
--keyring=/srv/nfs/pureos-archive-keyring.gpg \
--arch=arm64 \
--include=debian-keyring,mc,libc6-dev,libstdc++6,busybox,aptitude,etckeeper \
byzantium /srv/nfs/pureos-arm64 https://repo.pureos.net/pureos \
/usr/share/debootstrap/scripts/amber
Na x86 i s emulací je build v emulovaném armovém systému použitelně rychlý. Pokud by pak někdo chtěl použít nativní x86 verzi aarch64-linux-gnu-gcc, tak lze deboostrap použít jako sysroot viz moje příklady cross-utils pro cmake, qmake a meson na GitHubu.
moje nagenerované OSM mapy pro Garmin zobrazuje pěkněMůžeš se pochlubit screenshotem, a pokud to bude hezké, nasdílet? :) Já používám http://mapygarmin.wz.cz/, v navigaci to ještě celkem jde, ale na počítači to je úplně příšerně nepřehledné.
Většina OSM map pro Garmin je kartografická tragedie a "České" prakticky všechny. Pár globálních, na které se dá dívat:
Nicméně dokud bude mkgmap generovat ty mapy v 15let starém formátu, který podporuje jenom 24bit souřadnice, tak to nikdy dobře vypadat nebude. S takovým rozlišením není možné ani nakreslit pravoúhlé budovy...
Způsob, kterým se vybírá, která např. sídla to zobrazí, je úplně náhodný. Například při jednom zoomu tam jsou různé vesničky uprostřed ničeho, o kterých nikdo nikdy neslyšel, ale nejsou tam města jako Tišnov nebo Ždírec nad Doubravou.
Ten způsob není náhodný ale podle velikostí měst, tak jak je udává ta která mapa (v rámci jedné velikosti je výběr náhodný). Aktuální OTM mapa definuje pro Ždírec nad Doubravou "level" 0xa, zatímco pro Nové Ransko 0x9 a Krucemburk 0x8 (čím nižší číslo, tím větší město - Praha má 0x1). Takže zobrazený je to správně, co nesedí jsou data mapy.
Sám jsem hodně map na výlety do Garmina z OSM připravoval. Ale kvality od autora WalleyCZ jsem nedosahoval. Na druhou stranu v cizině turistické značení takovou pečlivost nepotřebuje, data nejsou jako z KČT. KOnfigurace pro mkgmap jsem si i trochu upravoval. Takže než rozbalovat a filtrovat již existující image, tak by byla cesta udělat si nové na míru. Jinak ano to omezení rozlišení je na budovách vidět, ale mě zajímaly spíš hory a tam metr, dva nepřesnosti nevadí. I když jednou jsme v zimě šli v Rumunsku přechod v takové mlze, kdy jsme směr drželi jen podle zakreslené stezičky a předchozích záznamů v GPS a strefovali se na pěšiny ve srázech, kde to možná bylo i s potřebou přesnosti pod 10 metrů. Viditelnost byla často nižší.
"Nějak" to na mobilních zařízeních asi díky dosahu Qt i na tyto platformy funguje, ale moc použitelné to nebude. Podle mě se mobilní aplikace musí s tím, že bude mobilní už vyvíjet. To ovládání je prostě diametrálně odlišné. Kdysi někdo "přeportoval" GPXSee na Harmattan/Sailfish a to GUI docela poohýbal.
Tak jsem se neudržel a chvíli v práci úpravě pro Librem 5 věnoval. S Qt mi hodně pomohl kolegové z Elektroline.
https://github.com/tumic0/GPXSee/pull/413
Test fork https://github.com/ppisa/GPXSee
Je dost možné, že jsem pro jiné buildy něco pokazil a obecně nejsem na Qt moc odborník, ale budu rád, pokud se po otestování a případném vyčištění úprava dostane do mainline.
No a jak to dopadlo? Klasika, odkazali ti ze si s patchem muzes vytrit prdel protoze blabla. A hlavne musis podepsat nejakou contributor license
A co asi tak očekáváš, že dostaneš za odpověď od projektu, který v (CONTRIBUTING.md) jasně deklaruje, jaký je aktuální stav přijímání patchů? Když pošleš patch do SQLite nebo Qt, dostaneš taky podobnou odpověď...
Ja uz nad GPXSee autory davno zlomil hul protoze to je jesitna sebranka bez smyslu pro lidskou komunikaci.
Na to, že si nad tím projektem "zlomil hůl", se tady celkem aktivně zapojuješ do diskuze... Nicméně stále čekám na odkaz na ten tvůj projekt(projekty), abych se poučil, jak má taková správná "lidská komunikace" vypadat.
Ano, máte pravdu, LGPL vyžaduje jen možnost záměny použité LGPL knihovny za verzi upravenu uživatelem a zkompilovanou z upravených zdrojových kódů. To lze zařídit buď tak, že je knihovna linkovaná dynamicky nebo že je aplikace, když s ní nejsou šířené zdrojové kódy, dodaná ve formě link kitu, relokovatelných objektových nebo knihovních souborů. Qt ale má snahu motivovat uživatele k nákupu Qt pod placenou licencí, takže postupně různé pokročilejší nadstavby publikuje pouze pod kombinací komerční a striktní GPL licence... Ale tyto nadstavby nepoužíváte.
Ale jinak mají kolegové pravdu, že odpovědmi jen uhýbáte. Na legitimní dotaz, proč s negativním postojem k užitím Vaší aplikace záměrně trváte na její degradaci i při jejím použití ne laptopech s dotykovým displejem neodpovídáte. Ale svého času nelituji, něco jsem si zkusil, možná mnou upravené GPXsee někdy použiji, ale jako perspektivní jí považovat vzhledem k Vašemu přístupu nelze a moje infromování Librem 5 komunity o její použitelnosti bylo asi ukvapené. Když mi zbude čas, tak nyní vidím jako lepší jeho využití pro rozšíření Gnome Maps o offline rederování z OBF formátu.
S přáním zdraví a společnosti lidí, co mají život a tvorbu vlastní i cizí v lásce,
Pavel Píša
Ale jinak mají kolegové pravdu, že odpovědmi jen uhýbáte. Na legitimní dotaz, proč s negativním postojem k užitím Vaší aplikace záměrně trváte na její degradaci i při jejím použití ne laptopech s dotykovým displejem neodpovídáte.
?! Takovou otázku v příspěvku od skunkOS pod kterým diskutujeme opravdu nevidím... A tobě jsem na ní již odpovídal v tom PR na Githubu.
ale jako perspektivní jí považovat vzhledem k Vašemu přístupu nelze a moje infromování Librem 5 komunity o její použitelnosti bylo asi ukvapené.
Tady si mimochodem odpovídáš na tu otázku sám prakticky stejně jako já v tom PR...