Byly zveřejněny informace o kritické zranitelnosti CVE-2025-55182 s CVSS 10.0 v React Server Components. Zranitelnost je opravena v Reactu 19.0.1, 19.1.2 a 19.2.1.
Bylo rozhodnuto, že nejnovější Linux 6.18 je jádrem s prodlouženou upstream podporou (LTS). Ta je aktuálně plánována do prosince 2027. LTS jader je aktuálně šest: 5.10, 5.15, 6.1, 6.6, 6.12 a 6.18.
Byla vydána nová stabilní verze 3.23.0, tj. první z nové řady 3.23, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Přehled novinek v poznámkách k vydání.
Byla vydána verze 6.0 webového aplikačního frameworku napsaného v Pythonu Django (Wikipedie). Přehled novinek v poznámkách k vydání.
Po více než 7 měsících vývoje od vydání verze 6.8 byla vydána nová verze 6.9 svobodného open source redakčního systému WordPress. Kódové jméno Gene bylo vybráno na počest amerického jazzového klavíristy Gene Harrise (Ray Brown Trio - Summertime).
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za listopad (YouTube).
Google Chrome 143 byl prohlášen za stabilní. Nejnovější stabilní verze 143.0.7499.40 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 13 bezpečnostních chyb.
Společnost Valve aktualizovala přehled o hardwarovém a softwarovém vybavení uživatelů služby Steam. Podíl uživatelů Linuxu dosáhl 3,2 %. Nejčastěji používané linuxové distribuce jsou Arch Linux, Linux Mint a Ubuntu. Při výběru jenom Linuxu vede SteamOS Holo s 26,42 %. Procesor AMD používá 66,72 % hráčů na Linuxu.
Canonical oznámil (YouTube), že nově nabízí svou podporu Ubuntu Pro také pro instance Ubuntu na WSL (Windows Subsystem for Linux).
Samsung představil svůj nejnovější chytrý telefon Galaxy Z TriFold (YouTube). Skládačka se nerozkládá jednou, ale hned dvakrát, a nabízí displej s úhlopříčkou 10 palců. V České republice nebude tento model dostupný.
Ne, tento blog opravdu nemá nic společného s vývojem Linuxového jádra :-) Jako "Jaderný blog" jsem jej pojmenoval jen kvůli mé oblibě jaderné fyziky a chemie.
Věnovat se chci především Linuxu a Free Softwaru, prezentovat zde svůj pohled na věc a věnovat se všem palčivým otázkám a problémům, na které narazím. Určitě se zde také objeví články týkající se KDE, jelikož jsem velkým milovníkem tohoto desktopového prostředí a obecně eye-candy (k velké nevůli "pravověrných" Linuxáků ;-)).
No a když už se to tu jmenuje Jaderný blog, možná se někdy dočkáte i nějakého populárně-vědeckého příspěvku, především pokud se bude jednat o nějaké ožehavé aktuální téma...
Před nedávnem jsem se začal učit Python a PyQT. Nadchla mě úžasná jednoduchost a přitom propracovanost tvorby UI v Qt Designeru. Nicméně nelíbilo se mi, že musím vygenerované .ui soubory vždy ručně "kompilovat" do pythonových zdrojáků pomocí utility pyuic, přijde mi to jako krok zpět. Proto jsem napsal v Pythonu modul, který tento proces automatizuje.
Je to de facto moje první dílo v Pythonu (nějaké primitovní "Hello World"-like aplikace v PyQT nepočítám
), proto bych chtěl poprosit všechny zdejší pythonýry, zda by se mohli na skript kouknout a ohodnotit mi ho (kde dělám např. něco né zrovna nejlépe, abych se nenaučil nějakým špatným návykům, atp.).
Na skript se můžete podívat ZDE, použití je jednoduché:
import pyuic
UIClass = pyuic.uiload("cesta/k/souboru.ui").getclass()
Ještě než jsem začal tento skript psát, narazil jsem i na možnost použití třídy QWidgetFactory z modulu qtui (součást PyQT). Tato třída generuje UI za běhu z .ui souboru. Jenže jsem narazil na problém - pokud tuto Qt třídu využijete, nejste pak v Pythonu schopni nijak propojovat sloty a signály. Vysvětluju si to tím, že objekty odpovídající danému UI jsou vytvořeny na úrovni Qt a Python o nich nemá pomnětí. Našel jsem dokonce článek Wrapper For QWidgetFactory, tam nabízené řešení funguje, ale přijde mi to jako takový ošklivý hack
Co vy na to, máte s QWidgetFactory v PyQT nějaké zkušenosti? Máte nějaké rady, řešení?
Další otázku bych měl okolo importování vygenerované UI třídy - ve svém skriptu pyuic.py (tedy konkrétně v třídě uiload) mám i metodu setclass, která by měla prostě a jednoduše vložit vygenerovanou UI třídu přímo do jmenného prostoru (podobně jako když použijete příkaz "from modul import třída"). Je to zařízeno celkem jednoduše:
def setclass(self):
setattr(sys.modules['__main__'], self.uiclass, self._import_pyui())
Jenže bohužel to nefunguje jak bych si představoval, zjevně sys.modules['__main__'] odkazuje na jmenný prostor v modulu pyuic, né ve skriptu kam jsem pyuic importoval (i když jsem zkusil použít volání stylem "from pyuic import uiload"). Napadá vás jak toto řešit?
Poslední otázku bych měl ohledně zjišťování jména vygenerované UI třídy. V současnosti to v metodě _get_classname řeším tak, že prostě parsuju soubor, který pyuic (ten původní Cčkový pyuic z PyQT, ne můj pyuic.py
) vygeneroval. Nepřijde mi to ale jako zrovna moc dobré řešení, nešlo by nějak zjistit jméno té třídy přímo z už importovaného modulu? Mohl bych se třeba dotázat pomocí funkce dir() na vše co je obsaženo ve jmenném prostoru modulu, který jsem naimportoval pomocí mod = __import__(self.pyuimod), jenže tam je i obrovská hromada PyQT metod, takže mi takové řešení nepřijde moc dobře realizovatelné. Máte někdo nějaký nápad?
Tiskni
Sdílej:
for se mi zda nejakej divnej...
PyUI_mod_list nebo pyui_mod_list byly pythonoidnejsi nez pyuimod_list...os.utime(filename, None) by se dalo pouzit misto carovani s modulem time
metoda _import_pyui() importuje modul s tou UI třídou (vygenerovaný pomocí klasického pyuic) a v té následné for smyčce je získán odkaz přímo na onu UI třídu v tom modulu (a ten pak ta metoda vrací). Inspiroval jsem se v referenční příručce k Pythonu, konkrétně v 2.1 Built-in Functions (kde je k funkci __import__ uveden obdobný příklad).Njn, evidentne jsem tedka vecer moc retardovanej. Stejne to nechapu :).
Jak říkam začal jsem se Python učit teprve nedávno... jaký zápis jmen je tedy "pythonoidnější"? Jaká jsou pro to pravidla? Četl jsem i PEP 8 -- Style Guide for Python Code, tam byla zmiňována hromada způsobu notací (CamelCase, podtržítková, atd.), ale žádná pokud si to pamatuji nebyla uvedena jako preferovaná...No... :)
"Global Variable Names [...] The conventions are about the same as those for functions"
"Function Names
Function names should be lowercase, with words separated by underscores
as necessary to improve readability.
mixedCase is allowed only in contexts where that's already the
prevailing style (e.g. threading.py), to retain backwards compatibility.
"Method Names and Instance Variables - Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability."
Cili imho pouzivat_maly_pismena_s_podtrzitkama.
Kdybych to udělal takto, tak sice nemusim importovat modul time, ale neměl bych na 100% zaručeno, že budou ty dva soubory mít stejný čas modifikace. Nebo se pletu?Nepletes. A nestaci ti, aby byl ten PyUI novejsi nez .ui?
a co takhle pouzit ihooks a umoznit tak "primy" import ui souboru, jako by to byl .py soubor? Funguje tak treba kid. To by bylo elegantnejsi nez prezentovany zpusob.
from qt import *
from qtui import *
import sys
class FasaOknoBezUIC(QMainWindow):
def __init__(self):
QMainWindow.__init__(self)
self.win = QWidgetFactory.create("form1.ui")
def show(self):
self.win.show()
if __name__ == '__main__':
app = QApplication(sys.argv)
w = FasaOknoBezUIC()
app.setMainWidget(w)
app.connect(app, SIGNAL("lastWindowClosed()"), app, SLOT("quit()"))
w.show()
ret = app.exec_loop()
sys.exit(ret)
from qt import *
from qtui import *
import sys
class FasaOknoBezUIC(QMainWindow):
def __init__(self):
QMainWindow.__init__(self)
self.win = QWidgetFactory.create("form1.ui")
self.pushButton1 = self.win.child('pushButton1')
self.connect(self.pushButton1, SIGNAL("clicked()"), self.pushButton1_clicked)
def pushButton1_clicked(self):
print 'clicked'
def show(self):
self.win.show()
if __name__ == '__main__':
app = QApplication(sys.argv)
w = FasaOknoBezUIC()
app.setMainWidget(w)
app.connect(app, SIGNAL("lastWindowClosed()"), app, SLOT("quit()"))
w.show()
ret = app.exec_loop()
sys.exit(ret)
Zkoušel jsem ovšem předtím něco podobného, jen s tím že jsem si tam nedefinoval widgety jako např. u vás self.pushButton1 = self.win.child('pushButton1'), a to právě nefungovalo. Pokud to tohle řeší, můžu se přeptat na magii která za tím stojí?
Já že s tou metodou child() jsem se nikde nikdy zatím nesetkal...
V okamžiku kdy volám app.setMainWidget(w), tak schytám SIGSEGV a s Pythonem je ámen :-/ Nicméně to samé nyní dělá ten můj předchozí pokus (u kterého sice nefungovalo propojení signálů a slotů, ale aspoň se zobrazilo UI
), takže bych řekl že je něco shnilého ve státě Dánském, respektive v mém systému
Zajímalo by mě, jestli s tím má co do dočinění upgrade na PyQT 3.16...
Zkoušel jsem gdb, ale vzhledem k tomu že mám vše zkompilováno bez debugging symbolů, tak jsem nějaký užitečný výsledek ani moc nečekal. Nicméně přesto tu něco je:
(no debugging symbols found) ... nekonečná řada dalších stejných zprávCož vyvolává podezření, že za to může SIP. Ostatně ten jsem upgradoval ve stejné době jako PyQT (na verzi 4.4)... tak, teď co dál.. (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211967808 (LWP 19040)] 0xb7f92531 in initsip () from /usr/lib/python2.4/site-packages/sip.so
pvanek@pvanek:~> rpm -qa python-qt python-qt-3.5.1-5 pvanek@pvanek:~> sip -V 4.2.1 (4.2.1-297)a vsechno jede velice mazane a bez padu. Jeste to o vikendu mozna vyzkousim na ~x86 gentoo. Ale co tak google tvrdi, tak tyhle sip.so pady se obcas obejvily a zase zahadne zmizely
Nicméně netušíš jak naimportovat tu vytvořenou UI třídu do nadřazeného modulu? Myslím to co popisuju v té mé otázce v blogpostu... tu mojí metodu setclass().