Zápis smazán (diskuse)

[Luboš Doležel (Doli)]

Aby se programátor roztrhl a tvořil všechny verze najednou, jenže to asi nejde.

Programátor má svou hlavu. Vyberte si to, v čem se vám pracuje lépe. Jak jednoduché.

O přemisťování a rozšiřování prvků se sice musí postarat programátor, ale není to nic složitého.

Ha ha... tohle je docela hrůza.

Z kódu pak není vůbec jasné, jak výsledný layout bude vypadat, a zabraňuje to umisťování ovládacích prvků kamkoliv do okna (či kontejneru, nebo jak tomu GTK nadává) a je pak velmi obtížné rozšířit toto okno o další ovládací prvky (či widgety).

Dobrý joke. Proč to píšete ručně místo použití GTK Glade nebo QT designer? Co jsem si hrál s QT Designer 4, tak kam se hrabe návrh GUI ve VS.NET.

Nějaký KDevelop se prostě nemůže rovnat VisualStudiu

A Visual Studio se zase nemůže rovnat GNU autotools. Tečka.

Podle mě by měl vytváření oken a ovládacích prvků obsluhovat samotný X server a neměly by kvůli tomu být vytvářeny takovéto knihovny, kvůli kterým je pak celé grafické rozhraní výrazně pomalejší než na Windows.

Tím jste celému blogu dodal korunu a celá věc se přesouvá do jiné úrovně - vážně si myslíte, že je to tím?

Nevím, jak je to s GTK, ale tuším, že je pod LGPL, ale jestli pak nemusí zveřejnit zdrojáky, to netuším.

Ne, nemusí. To samé se týká toolkitu FLTK.

[unknown_user]

Ty určitě znáš ty kraviny kolem licencí. Chtěl bych se tě zeptat, zda je možné toto: Naprogramuji program, který je založen na jiném programu šířeném pod GPL, ale zdrojové kódy poskytnu pouze za poplatek.

[David Watzke]

Není. Od toho je LGPL.

[maleprase]

udelas to obracene. program das za poplatek a k nemu zdarma zdrojove kody

[David Watzke]

Přidal by sis prosím fotku do profilu?

[unknown_user]

Prosím tě, proč?

[David Watzke]

Abych se ujistil, že existuješ, a že se ještě teď nesměješ a zároveň si mohl zahrát šipky, LOL.

[unknown_user]

Myslím, že kdybych neexistoval, nenapsal bych tento blogpost ani žádné jiné. Šipky si hraj na vlastním portrétu, mně nikdo ksicht rozbodávat nebude a navíc by pak neměla smysl změna mé identity na tomto portále. A nesměji se. Já ten blog myslím vážně.

[David Watzke]

Myslím, že kdybych neexistoval, nenapsal bych tento blogpost ani žádné jiné.

To si jen myslíš. Alespoň doufám, protože jsou věci, kterým prostě nevěřím.

Šipky si hraj na vlastním portrétu, mně nikdo ksicht rozbodávat nebude

Tak nic, zavolám klukům, že se to teda ruší... Škoda.

a navíc by pak neměla smysl změna mé identity na tomto portále

Proč sis jí změnil(a)? Snad se nestydíš za svý názory!

A nesměji se. Já ten blog myslím vážně.

Aha... OK. V tom případě jsem hodnotil správně - nulou.

[unknown_user]

    Proč sis jí změnil(a)? Snad se nestydíš za svý názory!
Přečti si komentáře z minulých blogpostů, zjistíš, že je to právě kvůli tomu, co jsi napsal. Několik let jsem propagoval Linux. Nedavno mě už začali štvát ty nedodělky a tak. Prostě se mi začal víc líbit Windows. Do Linuxu jsem navezl i jednoho kámoše ze školy. Jemu se fakt líbí, rád ho používá a já prostě nechci, aby věděl, že už Linux nemám. Asi jsem blázen.
    Kluk/Holka
Viz Myslím, že kdybych neexistoval, nenapsal bych tento blogpost ani žádné jiné.

[Kyosuke]

Nedodělky? A windows nejsou nedodělek, když k nim s jistotou vyjde další verze?

[Shadow]

Vida, jak je všechno relativní. Programování je zrovna jeden z důvodů, proč jsem velice rád, že jsem na GNU/Linux přešel.

[#Tom]

Programování není jenom vytváření uživatelského rozhraní. Naštěstí. Pokud jde o ty velké soubory, je třeba použít funkce podporující 64-bitové velikosti a polohy. Platí to jak pro funkce ANSI, tak pro funkce POSIX, obvykle stačí název funkce doplnit o znaky 64 na konci. Píše se o tom v infostránkách.

[unknown_user]

Chceš říct, že existuje fopen64? Mě totiž fopen vrátil NULL při otvírání 5GB souboru. To by mohlo být to ANSI. POSIX bude asi open, read, write. Bohužel jsem to zkoušel. Open sice soubor otevřel, ale ani polocí lseek64 nebo llseek jsem se nemohl dostat nakonec souboru a zjistit jeho velikost. O read64 a write64 jsem nikde zmíňku nenašel, asi neexistují.

[unknown_user]

Bohužel jsem to zkoušel --> Bohužel to také nefungovalo

[#Tom]

Tak to zkus ještě jednou a lépe.

[-zz-]

pri kompilacii skus pouzit:

-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE

[Heron]

Celé jsem to nečetl, ale večer si udělám čas.

Málem bych zapomněl. Ještě jsem nepřišel na to, jak v Linuxu pracovat s velkými soubory (nad 4GB). Prolezl jsem kde co, ale nikde prostě nic nebylo.

Zvláštní, já tu mám pár souborů nad 10GB a nemám s nimi nejmenší problém. Není chyba náhodou v tobě?

Btw: jaké to je chlubit se vlastní neschopností?

[unknown_user]

Myslím pracovat s nimi v C++, jako otevřít, číst, zapsat, přemisťovat pozici atd. Jinak vypalovat např. 7GB ISO není prolém, to funguje.

[Heron]

Proč zrovna v C++?

$cat Test10GB.java
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;

public class Test10GB {

        public static void main (String[] args) throws IOException {
                String filename = "test10gb.bin";
                int fileSizeKB = 10*1024*1024;

                File f = new File (filename);

                if (!f.createNewFile()) {
                        System.err.println("Can't create file!");
                        return;
                }

                byte [] buffer = new byte [1024];

                FileOutputStream fos = new FileOutputStream(filename);

                for (int i = 0; i < fileSizeKB; i++)
                        fos.write(buffer, 0, 1024);

                fos.close();

        }

}
$javac Test10GB.java
$java Test10GB
$ls -lh
total 11G
-rw-rw-r--  1 tomas tomas  10G Apr 12 19:46 test10gb.bin
-rw-rw-r--  1 tomas tomas 1.1K Apr 12 19:41 Test10GB.class
-rw-rw-r--  1 tomas tomas  562 Apr 12 19:41 Test10GB.java

[unknown_user]

Hlavně proto, že na rozdíl od javy nemusím pouštět nějaký stupidní interpreter, aby můj program fungoval.

[Kníže Ignor]

Jseš debil.

[unknown_user]

A máš k tomuto tvrzení důkaz? Jestli ne, tak tě zažaluju za pomluvu.

[Kníže Ignor]

Nemám, buzno. A zažalovat mě nemůžeš, protože mezi tebou a unknown userem v okamžiku činu neexistovala žádná vazba. Takže jsem tě nijak nemohl poškodit. Anonymům se prostě může nadávat dle libosti.

[Kyosuke]

To nemusíš ani v Javě, pokud máš dost mozku v hlavě... (Hele, ono se to dokonce rýmuje... )

[Michal Čihař]

C++ moc neznám, ale v C ani v Pythonu s tím nemám problém .

[unknown_user]

Tak mi řekni, jak v C otevíráš např 10GB soubor, jak se přesuneš do poloviny a přepíšeš 1 bajt. Mě prostě fopen vrátí NULL, pokud otevřu velkej soubor, přitom třeba 20MB soubor je v poho.

[Luboš Doležel (Doli)]

char bajt = 0;
int fd = open("file.dat", O_WRONLY | O_LARGEFILE);
lseek64(fd, lseek64(fd,0,SEEK_CUR)/2, SEEK_SET);
write(fd, &bajt, 1);
close(fd);

[Luboš Doležel (Doli)]

Místo SEEK_CUR má být SEEK_END.

[unknown_user]

To je škoda, že to už nemůžu vyzkoušet. Já zkoušel číst 5GB soubor nějak takto a nefungovalo to:

int fd = open("file.dat", O_RDONLY | O_LARGEFILE);
char *buffer = (char*)malloc(1024*1024);
while( true )
{
  precteno = read( fd, buffer, 1024*1024 );
  if( precteno < 0 ) return; //chyba
  if( precteno == 0 ) break; //konec souboru
  udelej_neco_s_daty(buffer,precteno);
}
close(fd);

[Sinuhet]

Mimochodem, jsme v open source, ne? Tak si stahnete zdrojaky od dd, cp, cat, mkisofs, growisofs, nebo kde/qt a kouknete se, jak to delaji tam.

[#Tom]

To je rukama.

[RTOS]

Jen jednu poznamecku, ve Windows se take nemusi a nepouziva jenom WinAPI.

Na zbytek nema cenu reagovat a zbytecne flamovat, protoze je to relativni (stejne jako vsechno, ze jo? ).

[unknown_user]

Vážně? Škoda jen, že Qt a GTK pro windows stejně jako MFC a VCL jen obalují WinAPI.
Pokud myslíš jen konzolové aplikace bez netextového GUI, máš pravdu.

[Luboš Doležel (Doli)]

QT a GTK pro Unix zase jen obalují Xlib

[unknown_user]

A právě proto je to pomalé Neříkám, že mfc, vcl pomalé není. Nejlepší je použít čisté WinAPI bez "obalů" a je to slušně rychlé.

[Luboš Doležel (Doli)]

To je blbost. Ve Windows je taky nějaký theme engine, který vykresluje nad nějakým kreslícím API (obdoba Xlib).

[Pavel Stárek]

Škoda jen, že Qt a GTK pro windows stejně jako MFC a VCL jen obalují WinAPI.

A v Linuxu zase obalují volání X serveru, popřípadě o něco vyšší úrovně Xlib. Takže ono je to jedno.

[Petr Jelínek]

Hmm, další záminka. Jen tak dál.

Jinak Tvůj důvod, proč jsi si změnil nick, je mírně řečeno divnej...

[Jan Zahornadsky]

Je chybou, že existuje nějaké GTK a Qt. Podle mě by měl vytváření oken a ovládacích prvků obsluhovat samotný X server a neměly by kvůli tomu být vytvářeny takovéto knihovny, kvůli kterým je pak celé grafické rozhraní výrazně pomalejší než na Windows.

Aha, takže ta snaha modularizovat X.org je naopak to nejhorší, co se mohlo stát? Právě jediné správné je nastrkat do jediné aplikace vše, co potřebuješ? To si nemyslím.

I v Microsoftu mají určitě interně oddělenou komponentu na kreslení od komponenty na okénka. Akorát málokdo zná ten interface, který musí splňovat, takže je malá šance, že se někomu podaří nahradit za jinou. Kdežto naopak u X máš ten interface tak nádherně popsaný, že není problém napsat jakoukoli komponentu a vložit ji místo stávající. To je, myslím si, pointa objektově orientovaného programování.

A k pomalosti: ano, komunikace mezi jednotlivými komponentami systému ve windows je natolik znásilněna, že to jde docela rychle. Ale připsat funkci je nadlidský úkon. Ono asi má nějaký důvod to prosazování .NET, to by jim odpadl obrovský kus práce s údržbou WinAPI, které prostě už nevyhovuje (dokonce WinAPI bude co jsem slyšel ve Vistě emulováno právě přes .NET). No a nevím jak u tebe (možná záleží na konkrétním HW), ale mně se jeví .NET kreslení okýnek o dost pomalejší než to Qt.

[Jindřich 'GoldenShit' Plešinger]

Programování

Ano. Programování je další důvod, proč jsem přešel na Windows.

Linux je znám nejednotností grafických rozhraní a GUI toolkitů. Je těžké si zvolit ten správný. Některý uživatel by rád, aby byl program v GTK, druhý v Qt, další by chtěl integraci s Gnome a další integraci s KDE. Aby se programátor roztrhl a tvořil všechny verze najednou, jenže to asi nejde. Ve windows je pouze WinAPI, které je narozdíl od Qt a GTK o dosti rychlejší (jedinou výjimkou je snad treeview).

Je sice pravda, že v GTK a Qt dochází k automatické změně a automatickému přemisťování prvků při změně velikosti okna, k přizpůsobování tlačítek dle velikosti fontu, ale to vše je na úkor rychlosti. Není ale pravda, že to nejde ve WinAPI. Přizpůsobování prvků dle velikosti fontů lze dosáhnout použitím tzv. resource souborů. Při psaní dialogu mu nastavíte font "MS Shell Dlg" a poté se nastaví systémový font všem ovládacím prvkům v daném dialogu a veškeré souřadnice prvků se přepočítají podle tohoto fontu. Takže v resource editoru vytvoříte dialog s ovládacími prvky uzpůsobenými vašemu fontu a uživatelovi programu se pak ukáže okno správně rozložené i s jinou velikostí fontu a nehrozí, že by se třeba text nevešel do tlačítka. Jenom dodám, že v resource souborech se nepoužívají pro umisťování prvků pixely ale jak se to jen jmenuje, teď mi to vypadlo z hlavy.

O přemisťování a rozšiřování prvků se sice musí postarat programátor, ale není to nic složitého. GTK to např. řeší za programátora, ale musíte se při vytváření layoutu okna starat o ty VBoxy, HBoxy, tabulky a já nevím co. Z kódu pak není vůbec jasné, jak výsledný layout bude vypadat, a zabraňuje to umisťování ovládacích prvků kamkoliv do okna (či kontejneru, nebo jak tomu GTK nadává) a je pak velmi obtížné rozšířit toto okno o další ovládací prvky (či widgety).

Pro Windows existuje řada kvalitních vývojových prostředí, od těch jednodušších (DevC++) až po složité RAD nástroje (VisualStudio,Delphi). Nějaký KDevelop se prostě nemůže rovnat VisualStudiu (mimochodem, Microsoft nabízí verzi express, jíž můžete po jeden celý rok používat zcela zdarma). Rozhraní KDevelopu je (alespoň podle mě) velmi nepřehledné a velmi obtížně se s ním pracuje a nemůžete v něm používat vizuální návrh. Monodevelop má sice vizuální návrh (v nové verzi), ale kvůli použití mona a C# programy v něm napsané pomalejší (někdy méně, někdy více), než ten samý program napsaný v C++. Vlastně oni jsou všechny programy napsané v GTK znatelně pomalejší, než programy pro Qt a jsou více paměťově náročné, avšak Qt aplikace jsou zase většinou nepřehledné a přeplácané samými panely nástrojů a různými úchyty pro panely (např. nevím, proč jsou v k3b samé úchyty pro panely, jako je prohlížeč souborů. Málokdo si bude tyto panely zavírat, protože by pak do projektu musel tahat soubory přes často padající Konqueror).

Je chybou, že existuje nějaké GTK a Qt. Podle mě by měl vytváření oken a ovládacích prvků obsluhovat samotný X server a neměly by kvůli tomu být vytvářeny takovéto knihovny, kvůli kterým je pak celé grafické rozhraní výrazně pomalejší než na Windows.

Další nevýhodou pro programátory může být licence GPL. Ano. Někdo by třeba rád vytvořil program, zveřejnil ho například na internetu, ale z nějakých důvodu k němu nezveřejnil zdrojový kód. To mu však GPL nedovoluje. A pokud program vytvoří např. pomocí Qt knihoven, můsí program vydat pod touto licencí (OK, nemusí, ale potom by musel zaplatit komereční verzi). Nevím, jak je to s GTK, ale tuším, že je pod LGPL, ale jestli pak nemusí zveřejnit zdrojáky, to netuším.

Tak toto téma uzavírám, omlouvám se za případné chyby v textu (asi jich bude hodně) a nezapomeňte ... pokračování bude. Update

Málem bych zapomněl. Ještě jsem nepřišel na to, jak v Linuxu pracovat s velkými soubory (nad 4GB). Prolezl jsem kde co, ale nikde prostě nic nebylo.

[#Tom]

Díky, já už jsem to okno mezitím stihl zavřít. Byla by hrozná škoda přijít o tyto vzácné perly.

[-zz-]

a skusal si to s tymto?

-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE

ako som uz uvadzal

[Heron]

Super nápad. Jeho předchozí smazané blogposty náhodou nemáš? Díky.

[Michal Vyskočil]

Zeptej se Leoše, určitě má zálohy databáze