Fórum Root.cz
Hlavní témata => Desktop => Téma založeno: krouziciorel 06. 02. 2026, 10:04:31
-
Pro evidenci dětských táborů využívám již mnoho let kombinaci Libre Office Writer (přihlášky) a Libre Office Calc (databáze účastníků a fakturace). Toto řešení je plně funkční, rád bych však využil vhodnou formu automatizace. Již nějakou dobu pokukuji po Libre Office Base, která tufo možnost nabízí a má výhodu integrace s ostatními částmi kancelářského balíku.
Jen se mi zdá, že právě tato součást je nejméně udržovaná. Vývojářů je málo, dokumentace nedrží krok s vydáváním nových verzí a několikaletý přechod z interní databáze HSQLDB na Firebird stále není dokončen. Z dokumentace jsem vyzkoušel příklad databáze sportovního klubu a podobnou bych rád vytvořil pro dětské tábory. Budu jediným administrátorem, takže mi vyhovuje některá z vestavěných databází pouze pro lokální přístup.
V dávné době mé praxe v bazaru s prodejem starších počítačů jsme pro evidenci používali aplikaci napsanou v Excelu se spoustou maker, stabilita byla opravdu nízká. V pozdějí firemní praxi jsem se setkal s větší aplikací napsnou v Accessu, ta již byla robustnější, i ona však měla se stabilitou své problémy.
Proto mám několik dotazů ideálně na čtenáře, kteří mají s Base reálnou zkušenost.
1. Provozujete v Base podobnou evidenční nebo fakturační aplikaci s lokálním přístupem? Jak je to s celkovou stabilitou řešení? Zůstáváte na výchozí databázi HSQLDB nebo využíváte Firebird? Byly nějaké problémy při případném přechodu z jedné databáze na druhou? Já při testech migrace starších volně dostupných databází na internetu nebyl vždy úspěšný.
2. Nastudoval jsem si oficiální příručku (v němčině je zatím aktuální verze 25.8, v ostatních jazycích 7.3, i zde je vidět nedostatek překladatelů), která radí s vhodnou zálohovací strategií a popisuje úskalí jediného .odb souboru, kde při ukládání mohou nastat problémy. Setkali jste se nimi? Funkční .odb mohu naštěstí přejmenovat na .zip a následně z něj data ručně obnovit, pokud však tato možnost selže, mohl by nastat problém.
3. Pro práci s databází mohu využívat nástroj Report Builder nebo zkombinovat funkcionalitu Base a Writeru pomocí Průvodce hromadnou korespondencí. Používám Arch linux a zde se Report Builder v balíčku Libre Office nevyskytuje z důvodu nestability a příliš silné závislosti na Javě (tu však má HSQLBD také). Debian nebo Ubuntu balíček libreoffice-report-builder nabízejí. Máte osobní zkušenost s Report Builderem?
Tak to by bylo z dotazů vše, předem se omlouvám za poněkud košatější zprávu. Budu však vděčný za jakékoliv zkušenosti, ať již s osobním nebo s firemním využitím Base.
-
Sice nepouzivam Base, ale Firebird ano. Bezi nam na tom instance MES systemu po celem svete s tim ze ty nejvetsi maji nekolik set aktivnich spojeni do DB (bezne vidam 300-400). Bezi to 24/7 s odstavkou jednou rocne o vanocich. Velikost DB cca 0.5TB. Takze Firebirdu bych se nebal.
-
Děkuji za informaci, ano, také jsem se v minulosti setkal s účetním systémem napsaným v Delphi využívajícím databázi Firebird o velikosti cca 20 GB a ani desítky připojených uživatelů nepředstavovaly problém. Base v současné době využívá Firebird ve starší verzi 3, což by nevadilo, jen jsem se díval na fórum a kvůli většímu počtu chyb v implementaci byl přesunut zpět mezi experimentální funkce, proto jsem opatrný. Na druhou stranu jsem si z .odb souboru vyzobal záložní .fbk a pomocí nástroje gbak (z aktuální řady Firebird 5, kterou v Archu používám) obnovil .fdb, vše proběho na první dobrou, takže Firebirdu dám šanci.
-
Pokud ma Base moznost se pripojit na Firebird server, tak nainstalujte verzi 5.0.3. Je tam vyrazny kvalitativni rozdil proti 3. Jak rychlost, tak stabilita, tak featury jelikoz 3 byla prvni verze s shared cache.
-
Jde o databázi HyperSQL DataBase https://hsqldb.org/web/openoffice.html a je to stabilní prověřená databáze vhodná pro řadu drobných použití.
I tak je ale podle mě praktičtější použít externí databázi - je to vhodnější pro zálohování, možnost náhledu na sql data externím programem apod. S Firebird na žádné omezení asi nenarazíte, pokud existuje PostgreSQL konektor tak jste na tom ještě lépe (Postgres je velmi kvalitní databáze, viz zdejší články od Pavla Stěhule).
Ohledně samotné zkušenosti s Base - ta mne taky zajímá. Když jsem to zkoušel kdysi já, měl jsem z toho rozpačité pocity. Chtěl jsem nějaké UI pro databázi, které by fungovalo bez programování a bylo srozumitelné a pohodlně použitelné i pro neprogramátora. Ale obecně je mi koncepce Office balíků dost vzdálená a nepřišel jsem tomu na chuť :D
-
Pokud ma Base moznost se pripojit na Firebird server, tak nainstalujte verzi 5.0.3. Je tam vyrazny kvalitativni rozdil proti 3. Jak rychlost, tak stabilita, tak featury jelikoz 3 byla prvni verze s shared cache.
Ano, Base komunikuje s různými typy databází a zvládne i Firebird (někteří uživatelé Base využívají pouze jako GUI), v Archu mám aktuální právě verzi 5.0.3. Jen je tu trochu více režie s tím, že v případně novějších verzí nestačí interní SDBC ovladač, ale budu potřebovat Jaybird JDBC a já bych nejraději využíval interní databázi bez jakýchkoliv externích nástrojů. Ale uznávám, že verze 5.0.3 je velikým krokem vpřed a za humny je šestková řada, magazín EmberWings už na ní láká. Vyzkouším obě varianty a uvidím, která mi bude více vyhovovat, pro menší táborovou databázi je určitě možné využít obě řešení, jen ta stabilita.
-
Jde o databázi HyperSQL DataBase https://hsqldb.org/web/openoffice.html a je to stabilní prověřená databáze vhodná pro řadu drobných použití.
I tak je ale podle mě praktičtější použít externí databázi - je to vhodnější pro zálohování, možnost náhledu na sql data externím programem apod. S Firebird na žádné omezení asi nenarazíte, pokud existuje PostgreSQL konektor tak jste na tom ještě lépe (Postgres je velmi kvalitní databáze, viz zdejší články od Pavla Stěhule).
Ohledně samotné zkušenosti s Base - ta mne taky zajímá. Když jsem to zkoušel kdysi já, měl jsem z toho rozpačité pocity. Chtěl jsem nějaké UI pro databázi, které by fungovalo bez programování a bylo srozumitelné a pohodlně použitelné i pro neprogramátora. Ale obecně je mi koncepce Office balíků dost vzdálená a nepřišel jsem tomu na chuť :D
Přesně tak, databáze HyperSQL pro mé potřeby více, než dostačuje, autoři se ale rozhodli dát šanci Firebirdu, i když narazili na své časové limity jeho implementace. Jak jsem již uváděl výše, zkusím použít Jaybird JDBC oproti aktuálnímu Firebirdu 5.0.3, Postgresql už je pro tento typ použití přeci jen příliš kanónovrabcovitý (to už bych mohl využít Odoo, které ale patří přeci jen spíše do firem).
Mě na Base láká hlavně ta skutečnost, že mám letité zkušenosti s Writerem a Calcem a mohu využít integraci mezi těmito nástroji. Také špičkový manuál potěší a dnes mi i umělá hloupost parádně pomůže s vytvořením nové databáze. Práce s tabulkami, dotazy, formuláři a sestavami už je poměrně intuitivní, zkusil jsem si pracovat se vzorovou databází, pohrál jsem si s tou sportovní a juknul na pár starších, ale funkčních řešení od uživatele "Thefrugalcomputerguy", takže dám Base šanci a uvidím. Vždycky se mohu vrátit ke stávajícímu řešení nebo využít např. kombo Lazarus/Firebird pro aplikaci na míru, možností je naštěstí dosti.
-
Dá se někde vidět, co ta Base dnes umí? Jako použití na frontend k DB a nějaké forumě použitelné formuláře?
-
Dá se někde vidět, co ta Base dnes umí? Jako použití na frontend k DB a nějaké forumě použitelné formuláře?
Base bych dnes označil jako univerzální frontend pro tabulky, dotazy, formuláře i sestavy pro většinu používaných databází. Podporuje JDBC i ODBC, takže by s připojením neměl být problém. Nejnovější verze 26.2 už je označena jako multiuživatelská (ale je to její jediná opravdu viditelná novinka), takže konečně může více uživatelů pracovat na jedné databázi. Podporuje formuláře, vnořené podformuláře, je zde vizuální návrhář dotazů a to vše je parádně popsané v příručkách, o kterých jsem psal výše (český překlad je sice starší, ale stále plně použitelný). Takže za mě perfektní nástroj, jen menší množství vývojářů a i po letech stále nedokončený přechod z HyperSQL na Firebird (plus oba v zastaralých verzích) mě nabádá k opatrnosti, to však vždy mohu řešit externí databází. Kromě příručky jsou k mání starší, ale parádní videa https://thefrugalcomputerguy.com/seriespg.php?ser=15/ nebo šikovné šablony https://sites.google.com/site/libreofficedatabases/home . Vesměs se ale jedná o starší materiály, je jasné, že Base se dnes široce nepoužívá. Každopádně jí dám šanci a uvidím.
-
Forum mi prave smazalo pracne napsany post, tak to zkratim. Base je peklo, da se rozsirit Pythonem, ale to nefunguje dobre. Je to legacy vec, radim se tomu vyhnout. Mluvim z bohate praxe. Misto toho zkuste Google Sheets a Google Apps Script, kod nechte udelat AI a dostanete krasne moderni reseni pristupne z prohlizece odkudkoliv. Nebo nejake jine, modernejsi reseni.
-
pete: Nesežalo, jen jsi narazil na oblíbený bug fóra: "po přihlášení hop do jiného threadu". Postnul jsi to do threadu o scrumu.
-
Forum mi prave smazalo pracne napsany post, tak to zkratim. Base je peklo, da se rozsirit Pythonem, ale to nefunguje dobre. Je to legacy vec, radim se tomu vyhnout. Mluvim z bohate praxe. Misto toho zkuste Google Sheets a Google Apps Script, kod nechte udelat AI a dostanete krasne moderni reseni pristupne z prohlizece odkudkoliv. Nebo nejake jine, modernejsi reseni.
Děkuji za názor a souhlasím, že Base není technologicky zrovna na výši a vyznat se v jeho API bude náročné plus zase jsme u toho nedostatku vývojářů. Ano, Basic s GOTO nebude nic moc, jeden kamarád vývojář podobně nadává na VBA v produktech od Mikrosoftu. Je-li Python nestabilní, to opravdu našve, právě tento jazyk by mohl tyvýše uvedené nahradit. Ovšem nic s tím nenaděláme, jako možnou cestu vidím jednoho MS inženýra, který by rád do roku 2030 přespal maximum jejich kódu do jazyka Rust s využitím umělé hlouposti (dále jen áíčko) s tím, že její výstupy budou zkušení vývojáři kontrolovat, necháme se překvapit jak to dopadne. Ovšem u Base je něco takového spíše v nedohlednu, já vím.
Webová řešení typu Google Sheets plus Google Apps Script nebo třeba Airtable jsou určitě v dnešní době správným krokem. Parádně importují .csv soubory s přihláškami a dokáží vygenerovat potvrzené přihlášky i faktury. Práce se stále se zlepšujícím áíčkem je trefa do černého, mimochodem když už dnes tahle vychytávka dokáže napsat céčkový kompilátor, co dokáže zítra (třeba i mojí oblíbenou Adu, kdo ví...).
Já se ale přiznám, že v tomto případě (stejně jako např. u účetnictví) preferuji desktopové řešení. Pokud to jde, raději se vyhnu umístění citlivých tábornických dat někdo do oblak a budu postupovat stejně jako u desktopové datovky a desktopového účetnictví.
Suma sumárum, protože používám odolný, ale méně výkonný laptop (Arch Linux + desktopové prostředí MATE), mám rád data uložená lokálně s využitím vhodné zálohovací strategie, rozhodl jsem se, že pro mě bude nejvhodnější napsat si desktopovou aplikaci na míru, která bude zabírat minimum systémových prostředků. Jako ideální mi přijde kombinace Lazarus a databáze SQLite. Já vím, že Paskal není dnes žádné terno, jeho moderní objektová verze na tom není vůbec zle, áíčko s ní umí parádně pracovat včetně podpory lokálních modelů a případné propojení s Pythonem také není žádný problém. Věřím, že SQLite bude plně dostačovat, vždy mohu přejít např. na můj oblíbený Firebird.
Mimochodem také jsem si užil své u psaní dlouhých komentářů na fóra, teď to řeším tak, že si vše napíši do obyčejného texťáku Pluma a teprve pak odešlu internetem, tohle funguje parádně.
Ještě jednou moc děkuji za názor a to všem diskutérům, dostal jsem parádní rady a jsem za ně velmi vděčný.
-
Suma sumárum, protože používám odolný, ale méně výkonný laptop (Arch Linux + desktopové prostředí MATE), mám rád data uložená lokálně s využitím vhodné zálohovací strategie, rozhodl jsem se, že pro mě bude nejvhodnější napsat si desktopovou aplikaci na míru, která bude zabírat minimum systémových prostředků. Jako ideální mi přijde kombinace Lazarus a databáze SQLite. Já vím, že Paskal není dnes žádné terno, jeho moderní objektová verze na tom není vůbec zle, áíčko s ní umí parádně pracovat včetně podpory lokálních modelů a případné propojení s Pythonem také není žádný problém. Věřím, že SQLite bude plně dostačovat, vždy mohu přejít např. na můj oblíbený Firebird.
Lazarus bych vynechal a napsal to celé v Pythonu, který umí skvěle pracovat s SQLite i s GUI.
Mimochodem také jsem si užil své u psaní dlouhých komentářů na fóra, teď to řeším tak, že si vše napíši do obyčejného texťáku Pluma a teprve pak odešlu internetem, tohle funguje parádně..
Řeším to tak, že během psaní si nechávám několikrát vygenerovat náhled.
-
Ještě ohledně zálohování: Osvědčil se mi Git, umí zálohovat i na flešku nebo na jiný disk.
-
Pane kolego, ze vy mate lasku ke starym technologiim. Taky programuju uz dlouho, ale musime jit s dobou. Delphi nechme Jablotronu, kde na tom furt jedou, a devadesatym letem. Souhlasim s kolegou Kitem, vzit na to Python a je to. Neni se ceho bat, AI napovi. A rozhodne AI napovi lip Python nez neco co je bud vic ukecane nebo hur zdokumentovane nebo to neni mainstream.
-
Ještě je možnost kombinace HTML + JS + IndexedDB (Dexie.js). Aplikace i data lokálně, stačí internetový prohlížeč.
-
Ještě je možnost kombinace HTML + JS + IndexedDB (Dexie.js). Aplikace i data lokálně, stačí internetový prohlížeč.
Na kombinaci HTML + JS + IndexedDB se podívám, tu neznám. Ještě je možné, aby mi toto či podobné řešení běželo např. v Dockeru, to mi ale pro táborovou evidenci připadá přeci jen už zbytečné. Se zálohováním na Gitu souhlasím, sám jej používám, kamarád programátor si i v dnešní době stále pochvaluje SVNko, proč ne. Já vím, ten dnes tak oblíbený Python válcuje vše a proč ne, přiznám se, že když mi na tábor dorazí někdo se zájmem o vývojařinu, téměř bez výjimky si tento jazyk pochvaluje. A když napíši kód v libovolném jazyce, áíčko si jej stejně louská pomocí Pythonu, takže je mi jasné, že s ním pracuje asi nejlépe (ale ani s moderním Paskalem není problém, což mě překvapilo). Takže dobře, dám Pythonu šanci, kombinace např. s CustomTKInter a SQLite bude pro takovou aplikaci určitě to pravé.
-
Pane kolego, ze vy mate lasku ke starym technologiim. Taky programuju uz dlouho, ale musime jit s dobou. Delphi nechme Jablotronu, kde na tom furt jedou, a devadesatym letem. Souhlasim s kolegou Kitem, vzit na to Python a je to. Neni se ceho bat, AI napovi. A rozhodne AI napovi lip Python nez neco co je bud vic ukecane nebo hur zdokumentovane nebo to neni mainstream.
Odhalil jste mě přesně, jen doplním, že kromě starých technologií mám lásku i k těm novým a jako hračička jsem se rozhodl pro Arch linux, protože mám rád i vše čerstvé. Naprosto souhlasím, že musíme jít s dobou, na druhou stranu chápu, že Jablotron, Štajner, Stármon nebo uživatelé Kádvojky u Delphi setrvávají, ať již z jakýchkoliv důvodů, zažil jsem dobu přechodu IS z Delphi na .NET a pamatuji si, že to bylo veselé.
Jen vůbec nejsem zkušený programátor, pracoval jsem jako systémový administrátor (ale bez nějakých těch skriptů v Pythonu to samozřejmě nešlo) a nyní provozuji tábory u koní, íťařina je ovšem stále mým koníčkem. U nás na českolipsku vznikl starý dobrý PC Fand, možná byste nevěřil, že se s ním stále setkávám (ordinace soukromého lékaře, lékárny, tichoježkové účetnictví, na které dámy účetní v požehnaném věku stále nedají dopustit, cyklo či hračkoprodejny - jen to propojení s moderními Wokny, tiskárnami a státní správou je jaxi krkolomné). A měl opravdu mnoho zajímavých myšlenek, které se dnes uplatní v low-code prostředí.
A když jsme u toho low-code, zkusil jsem tuto aplikaci pomocí áíčka vytvořit v javoském rámci OpenXava, výsledek je překvapivě dobrý. Ale stejně jako např. Odoo (které mimochodem vzbudilo můj zájem o Python, protože přeci jen jsem byl zvyklý na IS v Delphi, Javě či .NET) se jedná o řešení do firem, ne na tábor.
Neopomněl jsem prubnout také editor Emacs a jeho org-mode, ten má díky LaTeXu opravdu pěkné pédéef výstupy. Jen se při jeho ovládání cítím jako chobotnice, jak jednou popsal jeden diskutér, takže nejspíše zamířím jiným směrem.
Souhlasím s tím Paskalem a Lazarusem, je to technologie letitá a právě Lazarus bojuje s nedostatkem vývojářů podobně jako Base. Vím, že vypadá jako relikt z devadesátek, bedlivě jej však sleduji a líbí se mi stále více. Moderní herní rámec CGE umožňující export her i na mobilní platformy, planetárim Skychart, Lazmapviewer, GHTopo, ZCAD, Pascalscada, CHROMuLAN, manažer souborů Double Commander, účetní program Gestinux (ano, s opravdu hnusným GUI), PASLLM s podporou lokálních modelů, čerstvě vyvíjený nástroj Pasbuild ála Maven, GUI pro Bhyve ve Freebsd, webové aplikace (např. rámec MORMot2 někteří uživatelé označují jako jedno z nejrychlejších řešení v tomto segmentu), zajímavé řešení D2Bridge (snad bude lazarusí verze brzy i pro Linux), aktuální učebnice přímo pro Lazarus, aktuální kurzy na Udemy (v některých zemích je Paskal stále oblíbený) a opravdu blesková rychlost a malá výsledná binárka, to vše má stále něco do sebe. Díky podpoře QT6 není vzhled výsledných aplikací vůbec špatný (škoda, že to GTK ustrnulo) plus jedna perlička - Lazarus stále funguje v oknech dvoutisícovkách. Pokud se nemýlím, Lazarus má i v dnešní době stále co nabídnout, škoda, že podobný nástroj nemáme pro Python. Určitě u něj rád zůstanu, otázku, má-li smysl v dnešní době áíčka, zatím nechám budoucnosti.
Ale můj nejoblíbenější jazyk je Ada, která se nástrojem Alire dostala do moderního světa, jen ta ukecanost, já vím a je možné, že i ve své hlavní doméně bude přeci jen nahrazena Rustem (jsem zvědav na Mikrosoft, zda se mu přepis nakonec podaří).
Takže pánové vývojáři, máte recht s tím Pythonem, dnes se mu neubráním a upřímně řečeno ani nechci. Když se s někým bavím o vývojařině, z více než devadesáti procent si vyslechnu radost nad tímto jazykem. Obrovský ekosystém a skvělou práci s áíčkem nemohu nevidět, v případě potřeby lze Python/SQLite/CustomTKInter řešení nahradit např. Flaskem nebo Djangem. Samozřejmě jsem jako hračička neodolal Antigravity a pro agentické programování bude toto zadání jako stvořené, používám sice zadarmózní verze modelů, ale není kam spěchat. Prubnu Lazarus i Python verzi, už se těším na obě.
A aby toho nebylo málo, kamarád programátor mi nabídl možnost napsat tento program v jeho low-code prostředí, které vyvinul na platformě .NET, což dnes v Linuxu nebude problém, takže společně prubneme i ten.
Pokud se nepletu, dnes v době áíčka jde hlavně o to, popsat mu správnou architekturu a návrhové vzory, vysvětlit strukturu aplikace a nechat ho kódovat, za ty dva roky, co s ním pracuji, vidím obrovský skok a naprosto netuším, kam se posune. Jazyky typu Ada nebo Java, které vývojáře plácly přes prsty, když udělal něco nepěkného, nebudou dnes už tak důležité, ta architektura alespoň zatím ano.
Ještě jednou děkuji za názory a pohledy na věc, ty jsou pro mě nejdůležitější. Jdu si na uzdu svého koně vedle nápisů Ada a Paskal přimalovat krajtu, ať je vidět, že jsem se polepšil.
-
Souhlasím, že na ledacos se během vývoje IT průmyslu rezignovalo a stará řešení že mají něco do sebe. Mainstream často neznamená nejvyšší kvalitu. Už z principu vítězí průměr - lidé jsou v průměru průměrní a tak většina ani nedokáže ocenit kvalitu, která je vždy výsadou elity (proto má takový význam vzdělávání).
Pokud znáte Javu tak doporučuju JavaFX (https://openjfx.io/), píše se v tom docela pohodlně - oddělení logika v javě, binding na UI které je by default deklarativní v xml s možností stylovat pomocí stylesheetu, tedy vysokoúrovňový přístup podobný jako v QT, podobný je i defaultní vzhled, ale je to java. Má to slušnou podporu a stabilní vývoj, ale bohužel to není moc rozšířené - většina dává z nepochopitelných důvodů přednost webovým nedodělkům (které v naprosté většině ignorují to dobré, k čemu se v návrhu UI historicky došlo).
-
Možná budu za blázna, ale když jsem četl o HTML a JS, napadlo mne využití redakčního systému GRAV...
Grav je jednoduchý, souborový redakční systém, který funguje bez klasické databáze – všechna data ukládá do běžných textových souborů YAML/JSON. To znamená, že ho spustíte prakticky kdekoliv: na obyčejném webhostingu, na lokální LAMP/WAMP/XAMPP instalaci nebo i na vestavěném PHP serveru. Instalace je snadná, stačí rozbalit ZIP a otevřít adresu v prohlížeči. Grav používá běžné webové technologie (HTML, Twig šablony, YAML konfigurace) a nevyžaduje žádné specializované prostředí ani databázový server.
Pro malé evidence nebo jednoduché interní aplikace nabízí Grav modul Flex Objects, který umožňuje vytvářet vlastní typy dat s formuláři, tabulkovým zobrazením, filtrováním a plnohodnotným CRUDem přímo v administračním rozhraní. Každý záznam je uložen jako samostatný YAML/JSON soubor v adresáři user/data, takže zálohování znamená prostě zkopírovat složku. Flex Objects dokáže nahradit malou databázi – a protože je celé řešení postavené na souborech, je přenositelné, snadno verzovatelné (třeba přes Git) a nehrozí problémy typu poškozená databáze.
Nad tím vším stojí Admin plugin, který poskytuje čisté webové rozhraní přístupné z prohlížeče. Umožňuje spravovat data, instalovat pluginy, vytvářet formuláře, prohlížet zálohy nebo upravovat stránky bez psaní kódu. Pro uživatele, který nikdy předtím o Gravu neslyšel, je překvapivě univerzální: může sloužit jako redakční systém, ale i jako malé interní nástroje — evidence členů, kontaktní databáze, jednoduché CRM nebo sběr dat z formulářů. A protože vše běží v prohlížeči a ukládá se do textových souborů, je řešení dlouhodobě udržitelné a snadno přenositelné mezi počítači i hostingy.
Nebyl by to směr?