Google Chrome 140 byl prohlášen za stabilní. Nejnovější stabilní verze 140.0.7339.80 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Vylepšeny byly také nástroje pro vývojáře.
LeoCAD (Wikipedie) je svobodná multiplatformní aplikace umožňující také na Linuxu vytvářet virtuální 3D modely z kostek lega. Vydána byla verze 25.09. Zdrojové kódy a AppImage jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
RubyMine, tj. IDE pro Ruby a Rails od společnosti JetBrains, je nově zdarma pro nekomerční použití.
Český LibreOffice tým vydává překlad příručky LibreOffice Calc 25.2. Calc je tabulkový procesor kancelářského balíku LibreOffice. Příručka je ke stažení na stránce dokumentace.
Byla vydána (Mastodon, 𝕏) vývojová verze 3.1.4 příští stabilní verze 3.2 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání.
Zakladatel ChimeraOS představil další linuxovou distribuci zaměřenou na hráče počítačových her. Kazeta je linuxová distribuce inspirována herními konzolemi z 90. let. Pro hraní hry je potřeba vložit paměťové médium s danou hrou. Doporučeny jsou SD karty.
Komunita kolem Linuxu From Scratch (LFS) vydala Linux From Scratch 12.4 a Linux From Scratch 12.4 se systemd. Nové verze knih s návody na instalaci vlastního linuxového systému ze zdrojových kódů přichází s Glibc 2.42, Binutils 2.45 a Linuxem 6.15.1. Současně bylo oznámeno vydání verze 12.4 knih Beyond Linux From Scratch (BLFS) a Beyond Linux From Scratch se systemd.
Organizátoři konference LinuxDays ukončili veřejné přihlašování přednášek. Teď je na vás, abyste vybrali nejlepší témata, která na letošní konferenci zaznějí. Hlasovat můžete do neděle 7. září. Poté podle výsledků hlasování organizátoři sestaví program pro letošní ročník. Konference proběhne 4. a 5. října v Praze.
Byla vydána verze 11.0.0 vizuálního programovacího jazyka Snap! (Wikipedie) inspirovaného jazykem Scratch (Wikipedie). Přehled novinek na GitHubu.
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. Vypíchnout lze, že v Plasmě byl implementován 22letý požadavek. Historie schránky nově umožňuje ohvězdičkovat vybrané položky a mít k ním trvalý a snadný přístup.
Zápis smazán z osobních důvodů.
Tiskni
Sdílej:
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 VisualStudiuA 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.
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 nebudeTak 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áleProč 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.
Provokace, nic víc, hodnotím opět nulou.
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
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í?
$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
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);
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);
Š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.
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.
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
ako som uz uvadzal