On Wed, 2003-03-19 at 04:06, Thierry Vignaud wrote: > 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
Thierry, If you take this e-mail clean it up just a bit... it would make a dang good mini-data sheet on how to write/develop for MCC. I would think that you could scratch one more item off of your to-do list with this one. James
