1
Desktop / Re:Manuální úprava GTK theme
« kdy: 30. 05. 2025, 10:21:30 »Zkus mrknout na tohle:
https://www.dedoimedo.com/computers/gnome-40-edit-theme.html
Díky, to vypadá jako cesta, zkusím
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Díky, to vypadá jako cesta, zkusím
2
Desktop / Re:Manuální úprava GTK theme
« kdy: 29. 05. 2025, 13:51:59 »
Obsahem toho souboru je v Gnome i v Xfce, právě toto:
Kód: [Vybrat]
cat /usr/share/themes/Adwaita/gtk-3.0/gtk.css
/* Adwaita is now part of GTK+ 3, this file is no longer used */
3
Desktop / Manuální úprava GTK theme
« kdy: 28. 05. 2025, 17:33:29 »
Zdravím,
už se nějaký čas potýkám s nepochopitelným trendem designerů UI, webů apod. cpát všude čím dál nečitelnější písmo (aka světle šedivá na špinavě bílém pozadí). Aktuálně mě nejvíc štve kontrast písma v Ubuntu Gnome (GTK), kde se čitelnost zhoršila s vydáním 22.04. a kde je to na slabších displejích opravdu nepříjemné. Přitom QT aplikace jsou na tom výrazně lépe.
Dřív (GTK 2.0) jsem byl schopen manuálně opravit příslušné .css a .rc soubory a fungovalo to. Teď (GTK 3.0) je to v nějakém binárním .gresource souboru, a nevím co s tím.
Umím si z toho vyextrahovat příslušný soubor, třeba gtk.css, a najít v něm problematická místa (v tomto případě barvu #3D3D3D).
Otázky:
1) jak ten upravený soubor dostanu co nejjednodušeji zpět do .gresource ? Neboli jak mám správně použít glib-compile-resources ?
2) který .gresource je ten správný? Ubuntu používá jako výchozí theme Adwaita, ale k tomu žádný .gresource neexistuje, pouze se tam píše že je to součástí GTK 3.0 a konec. Na druhou stranu theme Yaru tam má zřejmě všechno, ale to vypadá že se používá jen na ikony.
Díky
už se nějaký čas potýkám s nepochopitelným trendem designerů UI, webů apod. cpát všude čím dál nečitelnější písmo (aka světle šedivá na špinavě bílém pozadí). Aktuálně mě nejvíc štve kontrast písma v Ubuntu Gnome (GTK), kde se čitelnost zhoršila s vydáním 22.04. a kde je to na slabších displejích opravdu nepříjemné. Přitom QT aplikace jsou na tom výrazně lépe.
Dřív (GTK 2.0) jsem byl schopen manuálně opravit příslušné .css a .rc soubory a fungovalo to. Teď (GTK 3.0) je to v nějakém binárním .gresource souboru, a nevím co s tím.
Umím si z toho vyextrahovat příslušný soubor, třeba gtk.css, a najít v něm problematická místa (v tomto případě barvu #3D3D3D).
Otázky:
1) jak ten upravený soubor dostanu co nejjednodušeji zpět do .gresource ? Neboli jak mám správně použít glib-compile-resources ?
2) který .gresource je ten správný? Ubuntu používá jako výchozí theme Adwaita, ale k tomu žádný .gresource neexistuje, pouze se tam píše že je to součástí GTK 3.0 a konec. Na druhou stranu theme Yaru tam má zřejmě všechno, ale to vypadá že se používá jen na ikony.
Díky
4
Software / Re:Změna velikosti LUKS oddílu
« kdy: 12. 09. 2024, 20:13:46 »
Díky, povedlo se.
Problém byl v tom, že první dva kroky byly v návodu řešeny odkazem do jiné části, což jsem přehlédl a skočil rovnou na lvm pv ...
Kdyby to ještě někoho zajímalo tak
https://wiki.archlinux.org/title/Resizing_LVM-on-LUKS
Problém byl v tom, že první dva kroky byly v návodu řešeny odkazem do jiné části, což jsem přehlédl a skočil rovnou na lvm pv ...
Kdyby to ještě někoho zajímalo tak
https://wiki.archlinux.org/title/Resizing_LVM-on-LUKS
5
Software / Re:Změna velikosti LUKS oddílu
« kdy: 11. 09. 2024, 18:06:23 »
Zálohu mám a návod jsem slepě následoval do okamžiku kdy jsem narazil na rozpor mezi "Free PE" v návodu a u mě :-)
Hádám, že musím ve správném pořadí resiznout xubuntu--vg-root a sda3_crypt, ale návod(y) se tváří, že se začíná sda3_crypt, což evidentně nejde ...
Celkovým cílem akce je mít v systému dual-boot (Linux+Linux) obojí šifrovaně. Čímž vyvstává další otázka, jestli je lepší aby sdílely společný oddíl pro /boot (jestli to vůbec jde) nebo raději každý zvlášť.
Kód: [Vybrat]
sudo lsblk -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sda
├─sda1 vfat 0E56-902D 504,9M 1% /boot/efi
├─sda2 ext4 5fc7fbbf-bd9f-4e00-98b0-0bb0e14d58b8 432,1M 31% /boot
└─sda3 crypto_LUKS 4da8c2a5-50d6-4202-8538-5fb41755c0a0
└─sda3_crypt LVM2_member 3Pi3ex-DjWF-Ady0-Yq1e-1b29-G75r-m9xBSS
├─xubuntu--vg-root ext4 5fac7e61-970e-461a-b5d1-f6aa702d59fe 175,3G 61% /
└─xubuntu--vg-swap_1 swap 1cd7d618-7270-4726-b91a-22875dc5772c [SWAP]
Kód: [Vybrat]
sudo pvdisplay /dev/mapper/sda3_crypt
--- Physical volume ---
PV Name /dev/mapper/sda3_crypt
VG Name xubuntu-vg
PV Size 464,54 GiB / not usable 4,00 MiB
Allocatable yes (but full)
PE Size 4,00 MiB
Total PE 118922
Free PE 0
Allocated PE 118922
PV UUID 3Pi3ex-DjWF-Ady0-Yq1e-1b29-G75r-m9xBSS
Hádám, že musím ve správném pořadí resiznout xubuntu--vg-root a sda3_crypt, ale návod(y) se tváří, že se začíná sda3_crypt, což evidentně nejde ...
Celkovým cílem akce je mít v systému dual-boot (Linux+Linux) obojí šifrovaně. Čímž vyvstává další otázka, jestli je lepší aby sdílely společný oddíl pro /boot (jestli to vůbec jde) nebo raději každý zvlášť.
6
Software / Změna velikosti LUKS oddílu
« kdy: 11. 09. 2024, 16:17:49 »
Ahojte,
chtěl bych zmenšit šifrovaný LVM ext4 oddíl. Nikdy jsem to nedělal, ale podle návodů online by to mělo po odemknutí běžnou cestou jít (např. přes GParted).
Nicméně, na všech LUKS discích co mám mi všechny partitioning-tooly ukazují 100% obsazenost, v nejlepším případě volných 12 MiB z 230 GiB. Dá se to nějak zredukovat na skutečnou obsazenost? Jak mám ten oddíl příště vytvořit aby se to chovalo lépe?
chtěl bych zmenšit šifrovaný LVM ext4 oddíl. Nikdy jsem to nedělal, ale podle návodů online by to mělo po odemknutí běžnou cestou jít (např. přes GParted).
Nicméně, na všech LUKS discích co mám mi všechny partitioning-tooly ukazují 100% obsazenost, v nejlepším případě volných 12 MiB z 230 GiB. Dá se to nějak zredukovat na skutečnou obsazenost? Jak mám ten oddíl příště vytvořit aby se to chovalo lépe?
7
Sítě / Re:Interference Bluetooth a Wi-Fi na 2,4 GHz
« kdy: 14. 03. 2024, 17:40:49 »802.11n a jeho 40MHz pásmem
Díky, tohle přesně pomohlo. Teď to běhá naplno i se současně připojenou BT myší a sluchátky ..
8
Sítě / Interference Bluetooth a Wi-Fi na 2,4 GHz
« kdy: 13. 03. 2024, 12:59:16 »
Zdravím,
na NTB mám kombinovaný adaptér WLAN/Bluetooth, nějaký bazmek od Realteku. Při zapnutí BT se WiFi 2.4G drasticky zpomalí, asi nic překvapujícího...
Otázka:
1. Dá se s tím něco dělat, kromě přepnutí na 5GHz ? Hádám, že asi ne, když BT přeskakuje v celém rozsahu 2.4G pásma, a tím pádem nepomůže přeladit WiFi na jiný kanál ....
2. Je to specifikum kombinovaných adaptérů? Funguje to líp u separovaných modulů?
3. Je to stejné i u ostatních značek nebo se to někde chová líp?
na NTB mám kombinovaný adaptér WLAN/Bluetooth, nějaký bazmek od Realteku. Při zapnutí BT se WiFi 2.4G drasticky zpomalí, asi nic překvapujícího...
Otázka:
1. Dá se s tím něco dělat, kromě přepnutí na 5GHz ? Hádám, že asi ne, když BT přeskakuje v celém rozsahu 2.4G pásma, a tím pádem nepomůže přeladit WiFi na jiný kanál ....
2. Je to specifikum kombinovaných adaptérů? Funguje to líp u separovaných modulů?
3. Je to stejné i u ostatních značek nebo se to někde chová líp?
9
Vývoj / Re:GDrive, vlastní .apk obsahuje virus
« kdy: 24. 01. 2024, 16:48:58 »
Ano, tohle jsem taky našel, ale není to tím, v releasu mám debuggable off. Právě naopak, musím debuggable zapnout, aby to fungovalo
10
Vývoj / GDrive, vlastní .apk obsahuje virus
« kdy: 22. 01. 2024, 17:38:29 »
Ahojte,
jako Java amatér jsem zkusil začít dělat i něco pro Android. Ubuntu, Android studio, všechno tak nějak ve výchozím stavu. Mám 4 různé aplikace se stejným nastavením projektu. U dvou z nich, když je zbuilduju jako release, tak Google Drive řve, že jsou zavirované (ty .apk soubory), debug není problém. Zbylé dvě fungujou i jako release.
Evidentně v tom nejsem na světě sám, ale řešení google nenabízí..
Podobná zkušenost? nějaký tip? Díky
jako Java amatér jsem zkusil začít dělat i něco pro Android. Ubuntu, Android studio, všechno tak nějak ve výchozím stavu. Mám 4 různé aplikace se stejným nastavením projektu. U dvou z nich, když je zbuilduju jako release, tak Google Drive řve, že jsou zavirované (ty .apk soubory), debug není problém. Zbylé dvě fungujou i jako release.
Evidentně v tom nejsem na světě sám, ale řešení google nenabízí..
Podobná zkušenost? nějaký tip? Díky
11
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 23. 05. 2023, 16:25:30 »
Díky za podněty, z uvedeného mi přijde, že hypotéza ohledně JIT nejvíce odpovídá reálnému chování.
Celkem uspokojivě jsem to vyřešil pomocí toho ByteBufferu. Čím větší tím je to rychlejší (a blíží se výkonu MappedByteBufferu), ale zase se potýkám s konzumací až 2-násobného množství RAM, což začíná být významné u souborů přes 500MB. Takže jsem zvolil nějaký přiměřeně velký buffer.
Celkem uspokojivě jsem to vyřešil pomocí toho ByteBufferu. Čím větší tím je to rychlejší (a blíží se výkonu MappedByteBufferu), ale zase se potýkám s konzumací až 2-násobného množství RAM, což začíná být významné u souborů přes 500MB. Takže jsem zvolil nějaký přiměřeně velký buffer.
12
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 21. 05. 2023, 10:58:07 »
Našel jsem řešení, tedy spíše workaround (příčinu stále neznám):
Namísto
Použít
takže to zřejmě souvisí s implementací metod readXxx() v DataInputStreamu, v tomto konkrétním případě DataInputStream.read(byte[] bytes) je lepší než DataInputStream.readFloat()
Namísto
Kód: [Vybrat]
DataInputStream dis = new DataInputStream(new BufferedInputStream(new FileInputStream(file)));
float[] pole = new float[size];
for (int i = 0; i < size; i++)
pole[i] = dis.readFloat();
Použít
Kód: [Vybrat]
byte[] bytes = new byte[4];
ByteBuffer buf = ByteBuffer.wrap(bytes);
for (int i = 0; i < size; i++) {
dis.read(bytes);
buf.rewind();
pole[i] = buf.getFloat();
}
takže to zřejmě souvisí s implementací metod readXxx() v DataInputStreamu, v tomto konkrétním případě DataInputStream.read(byte[] bytes) je lepší než DataInputStream.readFloat()
13
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 19. 05. 2023, 19:36:28 »Citace
Je zpomalené čtení celého souboru, nebo třeba jen první čtení, nebo dokonce ještě před prvním čtením?
Načítám do paměti celý soubor, viz:
Kód: [Vybrat]
DataInputStream dis = new DataInputStream(new BufferedInputStream(new FileInputStream(file)));
float[] pole = new float[size];
for (int i = 0; i < size; i++)
pole[i] = dis.readFloat();
dis.close();
Tohle trvá napoprvé těch 15s. Opakovaně už jen 5s se stejným nebo jiným souborem, třeba i se stejnou kopií toho prvního. Chová se to stejně na Win10 + Java8 Oracle, Ubuntu 20.04 /22.04 + Java11 openJDK. Poměr času je zachován, na rychlejším stroji je to 5s vs 1.7s.
Ještě mě napadlo jestli to nějak nemůže souviset s tím, že to pouštím v samostatném vlákně skrze java.util.concurrent.Executor, protože dokud je to uvnitř vlákna tak i opakované čtení je pořád stejně pomalé, ale jakmile to spustím znovu (v samostaném vlákně) tak už je to OK ...
14
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 19. 05. 2023, 13:04:42 »
OK díky, mrknu na to.
On by ten samotný ByteBuffer asi nakonec stačil, ale chtěl jsem využít mj. i DataInputStream.readUnsignedByte() a readUnsignedShort() abych se vyhnul ruční konverzi uint8 -> short a uint16 -> int. Předpokládám, že tyto vestavěné funkce jsou efektivnější než když to budu implementovat sám.. ale nakonec na výsledku uvidím
On by ten samotný ByteBuffer asi nakonec stačil, ale chtěl jsem využít mj. i DataInputStream.readUnsignedByte() a readUnsignedShort() abych se vyhnul ruční konverzi uint8 -> short a uint16 -> int. Předpokládám, že tyto vestavěné funkce jsou efektivnější než když to budu implementovat sám.. ale nakonec na výsledku uvidím
15
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 19. 05. 2023, 10:02:43 »
Pomalé je první čtení celého souboru. Mám datové soubory velikosti stovek MB a různě s nimi pracuju. S prvním souborem trvá načtení třeba 15s, poté už okolo 5s. Kdybych to mohl udělat jednoduše přes read(byte[]) v BufferedInputStream a potom jako celek zkonvertovat skrze ByteBuffer, tak je to asi za 2s (vždycky). Ale chci/potřebuju využívat ty metody specifické v DataIntputStreamu. Každopádně 5s je OK, potřebuju urychlit těch 15s.
Co třeba pomůže je načíst nejdřív malý soubor (2-3 MB) předem a pak už i ten první velký jde rychle. Ale když jsem zkusil takové iniciální "předčtení" přidat automaticky k načtení velkého souboru (načíst nejdřív malou část a pak znovu všechno), tak to nepomohlo.
Shrnuto:
DataInputStream: nejprve 15s a dále 5s
BufferedInputStream: nejprve 2s a dále 2s
Ano, je to první IO volání po spuštění
Co třeba pomůže je načíst nejdřív malý soubor (2-3 MB) předem a pak už i ten první velký jde rychle. Ale když jsem zkusil takové iniciální "předčtení" přidat automaticky k načtení velkého souboru (načíst nejdřív malou část a pak znovu všechno), tak to nepomohlo.
Shrnuto:
DataInputStream: nejprve 15s a dále 5s
BufferedInputStream: nejprve 2s a dále 2s
Ano, je to první IO volání po spuštění
