Jean-Michel Dault <[EMAIL PROTECTED]> writes: > I am in total admiration by your perl skills. As the Capernaum > Centurion would say if he had been a programmer, "I am not worthy > that thou shouldest come under my roof: but speak the regexp only, > and my code shall be healed."
> However, I am a bit deceived by your elitist attitude. By the sound > of your e-mails, you seem to assume that everyone should know how to > use the DrakX code. sorry if i give you such an attitude but as i receive and answer lots of emails each day, i used to write short, sharp mails. even my familly and my friends keep ask me to write longer, nicer emails :-( as for changelogs and cvs commits, i use to be even more concise. what's more, i was under bugs pressure and my grand father died, so i was still more unpleasant than usual, if possible. sorry if you feel bad because of it[-1] > However, I haven't been able to find any information, > neither on the DrakX web page, or in the drakxtools package itself, or > in perl-MDK, in the twiki, in the CVS, and of course I tried Google. well, in fact, there's no such doc[0] :-( for mdk9.2, i would like to write some inline doc which we would extract in some docbook document like the kernel folks did. for the moment, it's just an idea floating somewhere on my todo list. > The only documentation I could find was: > http://www.mandrakeforum.org/print.php?lang=en&sid=662 > I based DrakClick on that exact same code. do not take it bad: your code was fine as for mdk9.0 (though you should have use interactive instead of directly writing a gtk+ app, but that's not so important). not for mdk9.1. this is not your fault since: - there's no doc anywhere - we have neither the ressources nor the time to write some docs, - some developers think having perl scripts as "binary" is enough as for embedding: here's the story: ----------------- sadly (or happilly, depending on each thoughs), we[1] clean lots of stuff in drakx internals, especially drakconf <--> embedded apps communication. basically, in the old days, the app used to send SIG_USR2 to drakconf to warn mcc it was ready to display. then mcc would hide the icon animation and display the application. on exiting, the app would send SIG_USR1 to tell mcc to display again its icons. there were some obvious flaws in that design: - if app crashed before sending SIG_USR2, mcc would keep display the animation (unless you click on cancel or you manually did a "killall -SIG_USR1 drakconf) - if app unespectly crashed while displaying, the mcc would keep displaying a gray area instead of showing back its icons (unless one manually sent SIG_USR1) - ... while working on the mdk9.2, more bugs came from this approach, mainly: - wait messages were embedded which was horrible (from a gui viewpoint) - hidden tools and lots of embedding bugs in scannerdrake, printerdrake, and other interactive written tools so, i cleaned the way embedded apps and mcc communcate. as the gtk::socket send gtk signals when a application create and display a gtk::plug widget (plug-added signal), or destroy it (plug-removed signal), i decided to remove the somewhat mythical black magic SIG_USRx stuff and to let gtk+ automatically told us when app is ready to display. what's more, as the gtk::plug widget is destroyed when the app exit (either by design decision and proper exit or by unexpected crash), we have automatic mcc icons restoring on app crash, proper exit, ... in the process, i badly introduced the infamous bug #2672 with an additionnal cleanup :-( here's the embedding rule of thumb: ----------------------------------- mcc append "--embedded <XID>" to tools command line arguments when they're embedded. apps have to create a toplevem gtk::window when non embedded and a gtk::plug widget when embeded. the gtk::plug has to be created with the XID (some kind of obscure unique x window id) passed in ARGV so no more magic "kill -USR1, ...." here's the authentification rule of thumb: ------------------------------------------ in mdk9.0 and previous releases, tools use to call "interactive->vnew('su', 'icon name') there's no more banner icon, so no more <icon name> parameter the su part is now handled by common::require_root_capability() splited out so that: - pure gtk+ app can get rid of interactive) - app that still use gtk+1 such as drakcronat do not badly eat all cpu power trying to crash despite gtk-perl exceptions caught by eval {} because of interactive using gtk+2 here's the gui rule of thumb: ----------------------------- as i already write, tools have to create a toplevem gtk::window when non embedded and a gtk::plug widget when embeded. for small stuff, instead of writing pure gtk+ app, you better should use the interactive api/toolkit. there's no real doc. you can look: - at gi/docs/interactive/* in the cvs for basic usage. - drakedm, patched drakclick, drakxtv as for gtk+-2 porting: ---------------------- 1) easy way: run gi/docs/porting-ugtk on your script, then run it until you fixed the port 2) read http://developer.gnome.org/doc/API/ and handly do the port > Re-writing the whole thing and posting new and improved code on > Cooker will not help me write better code. If you could point me to > some documentation, or at least comment what you have done, it will > help me (and everyone reading Cooker), write new tools eventually. hope it helps you or at least make some things clearer btw, if someone can update the page you give the reference ... [-1] always the same bug with email, it's deshumanized and sometimes people feel bad because we lack non verbal signals; that's also why we easily troll by mail or insult other drivers while driving :( [0] but the source and the cvs would had say pixel [1] well, i'm the bastard if you want to blame someone on the embedding point
