Bon Nadal a tots!
divendres, 24 de desembre del 2010
dimecres, 22 de desembre del 2010
com obrir una finestra de navegador passant-li paràmetres amb submit i post
Un truc amb javascript: com obrir una finestra de navegador passant-li paràmetres amb method="post".
Per exemple, suposem la següent pàgina PHP que recupera els paràmetres amb $_POST. Com ho fem per que s'executi i rebi els paràmetres dins d'una finestra oberta amb open.window?
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title>pagina2</title>
</head>
<body
style="margin-left: 222px; width: 351px; margin-top: 58px; height: 213px;">
<big style="font-weight: bold;"><span
style="font-family: Helvetica,Arial,sans-serif;">Mostra els resultats</span></big><br>
<br>
<span style="font-family: Helvetica,Arial,sans-serif;">Text 1:</span>
<?php echo $_POST["v_Text1"] ?><br>
<br>
<span style="font-family: Helvetica,Arial,sans-serif;">Text 2:</span>
<?php echo $_POST["v_Text2"] ?><br>
<br>
<br>
<a style="font-family: Helvetica,Arial,sans-serif;"
href="javascript:window.close()">Tanca</a><br>
</body>
</html>
Podem invocar la pàgina anterior dins d'una finestra oberta amb open.window i passant-li arguments amb POST amb la següent tècnica:
1 - creant la finestra de destinació en l'event OnSubmit del formulari
2 - indicant en l'Action del formulari la pàgina a la que volem accedir
3 - indicant en el Target del formulari que la destinació és la finestra creada a l'OnSubmit
Per exemple, així:
<html>
<head>
<script language="javascript">
function ObreFinestra() {
var v_Config="top=50px,left=50px,width=640px,height=480px,resizable=yes";
var v_FinestraProva = window.open("", "wndFinestraProva", v_Config);
}
</script>
</head>
<body>
<form
style="margin-left: 172px; width: 508px; margin-top: 76px; height: 161px;"
onsubmit="javascript:ObreFinestra();" target="wndFinestraProva"
method="post" action="pagina2.php" name="Prova"> <big><span
style="font-family: Helvetica,Arial,sans-serif;"></span></big><span
style="font-family: Helvetica,Arial,sans-serif;"><big
style="font-weight: bold;">Obrir formulari amb
post en una finestra separada</big><br>
<br>
Text 1: <input name="v_Text1"><br>
Text 2: <input name="v_Text2"><br>
<br>
<input name="v_Submit" value="Enviar" type="submit"> <input
name="v_Reset" value="Esborrar" type="reset"><br>
</span></form>
</body></html>
Per exemple, suposem la següent pàgina PHP que recupera els paràmetres amb $_POST. Com ho fem per que s'executi i rebi els paràmetres dins d'una finestra oberta amb open.window?
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title>pagina2</title>
</head>
<body
style="margin-left: 222px; width: 351px; margin-top: 58px; height: 213px;">
<big style="font-weight: bold;"><span
style="font-family: Helvetica,Arial,sans-serif;">Mostra els resultats</span></big><br>
<br>
<span style="font-family: Helvetica,Arial,sans-serif;">Text 1:</span>
<?php echo $_POST["v_Text1"] ?><br>
<br>
<span style="font-family: Helvetica,Arial,sans-serif;">Text 2:</span>
<?php echo $_POST["v_Text2"] ?><br>
<br>
<br>
<a style="font-family: Helvetica,Arial,sans-serif;"
href="javascript:window.close()">Tanca</a><br>
</body>
</html>
Podem invocar la pàgina anterior dins d'una finestra oberta amb open.window i passant-li arguments amb POST amb la següent tècnica:
1 - creant la finestra de destinació en l'event OnSubmit del formulari
2 - indicant en l'Action del formulari la pàgina a la que volem accedir
3 - indicant en el Target del formulari que la destinació és la finestra creada a l'OnSubmit
Per exemple, així:
<html>
<head>
<script language="javascript">
function ObreFinestra() {
var v_Config="top=50px,left=50px,width=640px,height=480px,resizable=yes";
var v_FinestraProva = window.open("", "wndFinestraProva", v_Config);
}
</script>
</head>
<body>
<form
style="margin-left: 172px; width: 508px; margin-top: 76px; height: 161px;"
onsubmit="javascript:ObreFinestra();" target="wndFinestraProva"
method="post" action="pagina2.php" name="Prova"> <big><span
style="font-family: Helvetica,Arial,sans-serif;"></span></big><span
style="font-family: Helvetica,Arial,sans-serif;"><big
style="font-weight: bold;">Obrir formulari amb
post en una finestra separada</big><br>
<br>
Text 1: <input name="v_Text1"><br>
Text 2: <input name="v_Text2"><br>
<br>
<input name="v_Submit" value="Enviar" type="submit"> <input
name="v_Reset" value="Esborrar" type="reset"><br>
</span></form>
</body></html>
dissabte, 11 de desembre del 2010
Com migrar de MSOffice a OpenOffice.org (i 2)
En la darrera blocada presentava el pla general de migració de MS Office (en endavant MSO) a OpenOffice.org (en endavant OOo), segons l'esquema que proposa Sun en els seus WhitePapers (WP).
Fer d'ODF el format per defecte a l'organització
Seguint la recomanació del WP cal establir la política de que el format per defecte dels documents a partir d'haver completat la migració sigui el nadiu d'OpenOffice.org, és dir, el format ODF (OpenDocument format) que és un format estàndar ISO i que, això és molt important, també està suportat des del Service Pack 2 de MSO 2007. Per a versions més antigues Oracle-Sun proporciona un plugin ODF que afegeix aquest suport.
ODF és un format adequat, doncs, per a la comunicació amb empreses externes. Tanmateix, per a organitzacions que no siguin capaces de llegir ODF, l'OOo permet enviar correus amb formats PDF i formats de MSO.
Compartir i convertir documents
Els filtres d'importació i exportació de l'OOo seran suficients per a l'amplia majoria de documents de MSO. L'intercanvi de documents amb usuaris de MSO funciona normalment sense problemes, ara bé, els documents poden mostrar-se lleugerament diferents després de la conversió. Les macros d'Excel no funcionaran a l'OOo Calc; en general, les macros de Word i d'Excel probablement no funcionaran. Serà necessari un reajustament manual
Les característiques de l'MSO que caldrà vigilar són:
Word: Objectes OLE, índexos.
Excel: Objectes OLE, Taules pivot, alguns diagrames
Power Point: Objectes OLE, alguns efectes multimèdia
Compartir documents amb usuaris de MSO 2007 (i posteriors)
Les noves versions de MSO introdueixen característiques noves que no són compatibles amb l'OOo i que, de fet, no són compatibles ni amb versions antigues de MSO.
Per tant cal tenir en compte que la probabilitat de trobar-se amb aquestes característiques quan es comparteixen documents amb usuaris de versions recents de MSO és elevada.
Tanmateix, l'MSO implementa el que es coneix com a mode de compatibilitat que avisa als usuaris de que les característiques noves no estan suportades i els permet desar els documents en els formats de MSO97 o MSO2003.
Desant els documents en aquests formats soluciona molts dels problemes de compatibilitat. Tanmateix el mode de compatibilitat a l'MSO no està activat per defecte.
Escenaris i casos d'estudi
Escenari 1. Migrar tota l'empresa de cop.
Aquest escenari és escaient a PIMES. Una planificació i fites possibles per a la migració podrien ser les següents:
1. Començar a experimentar amb OOo. Encetar un programa pilot d'us del l'OOo. Definir un grup d'usuaris que participi en el pilot.
2. Iniciar l'anàlisi dels documents i de l'entorn tecnològic.
2.1 Determinar quins són els documents que necessiten ser convertits, en quin grau. Determinar les dificultats que apareixeran al fer la conversió dels documents.
2.2 Fer servir qüestionaris per a identificar les aplicacions que depenen de, o que proporcionen, interfícies cap l'MSO.
3. Kick Off. Punt de partida oficial del procés de migració. Aquesta fita ve caracteritzada per:
3.1 Instal·lació als clients i els servidors que calguin de l'OOo. OOo i MSO conviuran en aquests sistemes fins la retirada definitiva de l'MSO.
3.2 Organitzar els empleats en equips i formar-los en l'ús de l'OOo, i en com verificar i corregir les lleugeres diferències que provocarà la conversió de plantilles i documents. La formació haurà de tenir en compte que es treballarà en un entorn mixt
4. Iniciar la conversió del documents pertanyents al negoci i als diferents departaments. En encetar aquest punt l'OOo haurà d'estar instal·lat a tots els ordinadors clau de l'empresa.
5. Iniciar l'auditoria dels documents convertits. En aquest punt els documents ja han estat convertits i els usuaris ja estan formats. Els usuaris han d'estar capacitats per verificar la fidelitat dels documents dels documents convertits. Els usuaris que no estiguin participant directament en el procés de migració poden començar a convertir els seus propis documents
6. Iniciar l'ús de l'OOo per a la creació de nous documents. En aquest punt tots els documents crítics ja han estat convertits, auditats i , si ha estat necessari, corregits. Els usuaris poden crear nous documents en el format nadiu i estàndar ISO, l'OpenDocument Format (ODF) fent servir l'OOo. Des d'aquest moment, el MSO només es farà servir per imprimir o editar documents prèviament existents de MSO.
7. Confirmar la data de caducitat definitiva de l'MSO. En aquest punt, tota l'empresa i els diferents grups de treball haurien d'haver estat convertits a ODF. Tots els sistemes de missió crítica haurien d'estar funcionant sobre OOo i tots els usuaris haurien de tenir un bon grau de competència i de productivitat amb l'OOo. Tanmateix, es bo recordar als usuaris que l'MSO serà retirat dels seus escriptoris en breu, de forma que tinguin una idea clara de quant temps els resta per a convertir i revisar els seus propis documents si és que encara els cal fer-ho.
8. Retirar l'MSO. En assolir aquesta fita tothom a l'organització fa servir OOo. I la migració dels documents i solucions de negoci ja hauria d'haver estat completada. És el moment de retirar l'MSO de la xarxa de l'empresa i dels escriptoris dels empleats.
Tanmateix, si s'ha incorregut en retards en la conversió o cal fer la re-enginyeria de fitxers de missió crítica, aleshores cal mantenir almenys una instal·lació d'MSO.
Escenari 2. Migració de l'organització per departaments.
Aquest escenari difereix de l'anterior en que les fites són per als diferents departaments i no per a l'organització. La clau és determinar l'ordre en que migren els diferents departaments.:
- Cal minimitzar els reptes que planteja treballar en un entorn mixt. Començar pels departaments que no els cal intercanviar documents amb altres departaments
- Continuar amb els departaments que només han de visualitzar o imprimir documents d'altres departaments. Aquests departaments hauran de fer servir els filtres d'importació i conversió per a poder visualitzar els documents de MSO.
- Finalment, migra els departaments que han d'intercanviar informació basada en documents amb altres departaments.
Escenari 3. Entorns mixts OOo / MSO
Els entorns mixts són aquells en els que coexisteixen OOo i MSO. Ens aquests entorns hi han dues formes principals de compartir documents: la compartició passiva de documents, i la compartició de documents editables.pr
Compartició passiva de documents
En aquest escenari, els documents compartits s'utilitzen per a distribuir informació i no es requereix cap altre acció. Per exemple, els documents es fan servir per distribuir informació als empleats sobre les noves polítiques corporatives. Un altre exemple: la distribució dels estàndards de condicions contractuals per als clients o per als col·laboradors.
La millor aproximació per a aquest escenari és la distribució dels documents en el format PDF. PDF és fàcil de crear (encara més amb OOo) i és ideal per a catàlegs, cartes, factures i formularis.
Amb l'OOo existeix la possibilitat de descarregar-se l'extensió Sun PDF Import Extension de Sun que permet crear un fitxer híbrid. Aquest plugin permet exportar el document com un fitxer .pdf que conté dos formats de fitxer: PDF i ODF. EL fitxer té l'extensió pdf i és visualitzable amb els visors estàndard de PDF i, a més, pot ser carregat i editat des de l'OOo.
Compartició de documents editables
En aquest escenari els destinataris poden editar els continguts dels documents compartits, per exemple per a proporcionar un feedback, o per afegir continguts abans que els documents passi a terceres parts. El problema més gros d'aquest escenari és que no es poden fer assumpcions sobre la capacitat de llegir documents en format ODF per la tercera part. Majoritàriament, doncs, el format de fitxer comú en un entorn mixt és el format propietari de MSO.
Una aproximació és fer de ODF el format per defecte de l'organització. L'estandarització facilitarà l'intercanvi, el seguiment i el suport als documents. Per a aquesta solució caldrà que els usuaris de MSO disposin d'una instal·lació paralel·la d'OOo, o bé la instal·lació del plugin ODF de MSO. Com s'ha dit anteiorment, el plugin ODF de l'MSO permet obrir, editar i desar en format ODF.
Una altre aproximació és distribuir els documents compartits en format de MSO, especialment si només hi ha un petit percentatge d'usuari treballant amb OOo a l'organització.
Un parell de suggeriments que poden ajudar a millorar la inter-operabilitat en un entorn mixt:
- Fer d'OOo la suite ofimàtica per defecte i ODF el format per defecte en aquells grups on els empleats treballen intensament en col·laboraciço, fins i to encara que part dels membres del grup no formin part de l'organització. Com s'ha dit, el plugin d'ODF de l'MSO ha permet a aquests usuaris llegir i escriure documents ODF.
- Introduir dues fases en la compartició d'un document. Una fase de col·laboració i una fase d'edició. En la fase de col·laboració un document es comparteix un document inicial entre els diferents usuaris de l'entorn mixt. Per a aquesta fase es pot utilitzar el format que d'MSO o d'ODF, però si es tria ODF aleshores cal desplegar el plugin ODF en les instal·lacions dels usuaris de MSO. La decisió de quin format és el que finalment es tria depèn de la suite dels autors. Si la majoria d'autor del document utilitzen OOo aleshores aquest hauria de ser el format de document utilitzat; si no és així, aleshores hauria de ser el de l'MSO.
Un cas d'estudi
Una gran empresa industrial va migrar el 90% de la seva plantilla a StarOffice (la versió d'OOo de pagament de Sun) mitjançant el seu propi departament d'informàtica. Després de la migració van mantenir unes poques instal·lacions d'MSO per a permetre al departament de finances de poder seguir fent servir macros i eines basades en Excel i per a poder assegurar la compatibilitat amb terceres parts com clients o empreses col·laboradores.
Despres de la migració, el format oficial dels documents és ODF per a documents editables i PDF per distribució de informació en documents només de lectura.
Internament,la majoria dels empleats fan servir ODF. Els empleats que encara fan servir els formats de MSO ho fan perquè pertanyen a equips on la documentació circula en aquest format.
Per a la col·laboració entre equips que fan servir formats diferents, es fa servir el format de MSO. Els equips que treballen amb StarOffice fan servir els filtres d'importació i exportació de l'StarOffice per a convertir els documents.
Per a les comunicacions externes es fa servir el format PDF. Si els destinataris externs han d'editar els documents, aleshores han d'instal·lar-se el plugin d'ODF per a poder editar els documents des de l'MSO.
Sumari
La migració a OOo es pot assolir fàcilment amb una bona planificació, recursos suficients i una bona gestió del projecte. L'estalvi que s'obté de migrar a OOo és substancial: El 100% dels costos de llicències. Sense despeses de manteniment, ni l'obligació contractual d'adquirir les actualitzacions. Aquesta llibertat i flexibilitat juntament amb l'estalvi de despesa fa molt interessant iniciar una prova pilot d'avaluació de l'OpenOffice.org.
Documentació i enllaços útils
La documentació Online de l'OpenOffice.org http://documentation.openoffice.org/
Documentació descarregable:
Fer d'ODF el format per defecte a l'organització
Seguint la recomanació del WP cal establir la política de que el format per defecte dels documents a partir d'haver completat la migració sigui el nadiu d'OpenOffice.org, és dir, el format ODF (OpenDocument format) que és un format estàndar ISO i que, això és molt important, també està suportat des del Service Pack 2 de MSO 2007. Per a versions més antigues Oracle-Sun proporciona un plugin ODF que afegeix aquest suport.
ODF és un format adequat, doncs, per a la comunicació amb empreses externes. Tanmateix, per a organitzacions que no siguin capaces de llegir ODF, l'OOo permet enviar correus amb formats PDF i formats de MSO.
Compartir i convertir documents
Els filtres d'importació i exportació de l'OOo seran suficients per a l'amplia majoria de documents de MSO. L'intercanvi de documents amb usuaris de MSO funciona normalment sense problemes, ara bé, els documents poden mostrar-se lleugerament diferents després de la conversió. Les macros d'Excel no funcionaran a l'OOo Calc; en general, les macros de Word i d'Excel probablement no funcionaran. Serà necessari un reajustament manual
Les característiques de l'MSO que caldrà vigilar són:
Word: Objectes OLE, índexos.
Excel: Objectes OLE, Taules pivot, alguns diagrames
Power Point: Objectes OLE, alguns efectes multimèdia
Compartir documents amb usuaris de MSO 2007 (i posteriors)
Les noves versions de MSO introdueixen característiques noves que no són compatibles amb l'OOo i que, de fet, no són compatibles ni amb versions antigues de MSO.
Per tant cal tenir en compte que la probabilitat de trobar-se amb aquestes característiques quan es comparteixen documents amb usuaris de versions recents de MSO és elevada.
Tanmateix, l'MSO implementa el que es coneix com a mode de compatibilitat que avisa als usuaris de que les característiques noves no estan suportades i els permet desar els documents en els formats de MSO97 o MSO2003.
Desant els documents en aquests formats soluciona molts dels problemes de compatibilitat. Tanmateix el mode de compatibilitat a l'MSO no està activat per defecte.
Escenaris i casos d'estudi
Escenari 1. Migrar tota l'empresa de cop.
Aquest escenari és escaient a PIMES. Una planificació i fites possibles per a la migració podrien ser les següents:
1. Començar a experimentar amb OOo. Encetar un programa pilot d'us del l'OOo. Definir un grup d'usuaris que participi en el pilot.
2. Iniciar l'anàlisi dels documents i de l'entorn tecnològic.
2.1 Determinar quins són els documents que necessiten ser convertits, en quin grau. Determinar les dificultats que apareixeran al fer la conversió dels documents.
2.2 Fer servir qüestionaris per a identificar les aplicacions que depenen de, o que proporcionen, interfícies cap l'MSO.
3. Kick Off. Punt de partida oficial del procés de migració. Aquesta fita ve caracteritzada per:
3.1 Instal·lació als clients i els servidors que calguin de l'OOo. OOo i MSO conviuran en aquests sistemes fins la retirada definitiva de l'MSO.
3.2 Organitzar els empleats en equips i formar-los en l'ús de l'OOo, i en com verificar i corregir les lleugeres diferències que provocarà la conversió de plantilles i documents. La formació haurà de tenir en compte que es treballarà en un entorn mixt
4. Iniciar la conversió del documents pertanyents al negoci i als diferents departaments. En encetar aquest punt l'OOo haurà d'estar instal·lat a tots els ordinadors clau de l'empresa.
5. Iniciar l'auditoria dels documents convertits. En aquest punt els documents ja han estat convertits i els usuaris ja estan formats. Els usuaris han d'estar capacitats per verificar la fidelitat dels documents dels documents convertits. Els usuaris que no estiguin participant directament en el procés de migració poden començar a convertir els seus propis documents
6. Iniciar l'ús de l'OOo per a la creació de nous documents. En aquest punt tots els documents crítics ja han estat convertits, auditats i , si ha estat necessari, corregits. Els usuaris poden crear nous documents en el format nadiu i estàndar ISO, l'OpenDocument Format (ODF) fent servir l'OOo. Des d'aquest moment, el MSO només es farà servir per imprimir o editar documents prèviament existents de MSO.
7. Confirmar la data de caducitat definitiva de l'MSO. En aquest punt, tota l'empresa i els diferents grups de treball haurien d'haver estat convertits a ODF. Tots els sistemes de missió crítica haurien d'estar funcionant sobre OOo i tots els usuaris haurien de tenir un bon grau de competència i de productivitat amb l'OOo. Tanmateix, es bo recordar als usuaris que l'MSO serà retirat dels seus escriptoris en breu, de forma que tinguin una idea clara de quant temps els resta per a convertir i revisar els seus propis documents si és que encara els cal fer-ho.
8. Retirar l'MSO. En assolir aquesta fita tothom a l'organització fa servir OOo. I la migració dels documents i solucions de negoci ja hauria d'haver estat completada. És el moment de retirar l'MSO de la xarxa de l'empresa i dels escriptoris dels empleats.
Tanmateix, si s'ha incorregut en retards en la conversió o cal fer la re-enginyeria de fitxers de missió crítica, aleshores cal mantenir almenys una instal·lació d'MSO.
Escenari 2. Migració de l'organització per departaments.
Aquest escenari difereix de l'anterior en que les fites són per als diferents departaments i no per a l'organització. La clau és determinar l'ordre en que migren els diferents departaments.:
- Cal minimitzar els reptes que planteja treballar en un entorn mixt. Començar pels departaments que no els cal intercanviar documents amb altres departaments
- Continuar amb els departaments que només han de visualitzar o imprimir documents d'altres departaments. Aquests departaments hauran de fer servir els filtres d'importació i conversió per a poder visualitzar els documents de MSO.
- Finalment, migra els departaments que han d'intercanviar informació basada en documents amb altres departaments.
Escenari 3. Entorns mixts OOo / MSO
Els entorns mixts són aquells en els que coexisteixen OOo i MSO. Ens aquests entorns hi han dues formes principals de compartir documents: la compartició passiva de documents, i la compartició de documents editables.pr
Compartició passiva de documents
En aquest escenari, els documents compartits s'utilitzen per a distribuir informació i no es requereix cap altre acció. Per exemple, els documents es fan servir per distribuir informació als empleats sobre les noves polítiques corporatives. Un altre exemple: la distribució dels estàndards de condicions contractuals per als clients o per als col·laboradors.
La millor aproximació per a aquest escenari és la distribució dels documents en el format PDF. PDF és fàcil de crear (encara més amb OOo) i és ideal per a catàlegs, cartes, factures i formularis.
Amb l'OOo existeix la possibilitat de descarregar-se l'extensió Sun PDF Import Extension de Sun que permet crear un fitxer híbrid. Aquest plugin permet exportar el document com un fitxer .pdf que conté dos formats de fitxer: PDF i ODF. EL fitxer té l'extensió pdf i és visualitzable amb els visors estàndard de PDF i, a més, pot ser carregat i editat des de l'OOo.
Compartició de documents editables
En aquest escenari els destinataris poden editar els continguts dels documents compartits, per exemple per a proporcionar un feedback, o per afegir continguts abans que els documents passi a terceres parts. El problema més gros d'aquest escenari és que no es poden fer assumpcions sobre la capacitat de llegir documents en format ODF per la tercera part. Majoritàriament, doncs, el format de fitxer comú en un entorn mixt és el format propietari de MSO.
Una aproximació és fer de ODF el format per defecte de l'organització. L'estandarització facilitarà l'intercanvi, el seguiment i el suport als documents. Per a aquesta solució caldrà que els usuaris de MSO disposin d'una instal·lació paralel·la d'OOo, o bé la instal·lació del plugin ODF de MSO. Com s'ha dit anteiorment, el plugin ODF de l'MSO permet obrir, editar i desar en format ODF.
Una altre aproximació és distribuir els documents compartits en format de MSO, especialment si només hi ha un petit percentatge d'usuari treballant amb OOo a l'organització.
Un parell de suggeriments que poden ajudar a millorar la inter-operabilitat en un entorn mixt:
- Fer d'OOo la suite ofimàtica per defecte i ODF el format per defecte en aquells grups on els empleats treballen intensament en col·laboraciço, fins i to encara que part dels membres del grup no formin part de l'organització. Com s'ha dit, el plugin d'ODF de l'MSO ha permet a aquests usuaris llegir i escriure documents ODF.
- Introduir dues fases en la compartició d'un document. Una fase de col·laboració i una fase d'edició. En la fase de col·laboració un document es comparteix un document inicial entre els diferents usuaris de l'entorn mixt. Per a aquesta fase es pot utilitzar el format que d'MSO o d'ODF, però si es tria ODF aleshores cal desplegar el plugin ODF en les instal·lacions dels usuaris de MSO. La decisió de quin format és el que finalment es tria depèn de la suite dels autors. Si la majoria d'autor del document utilitzen OOo aleshores aquest hauria de ser el format de document utilitzat; si no és així, aleshores hauria de ser el de l'MSO.
Un cas d'estudi
Una gran empresa industrial va migrar el 90% de la seva plantilla a StarOffice (la versió d'OOo de pagament de Sun) mitjançant el seu propi departament d'informàtica. Després de la migració van mantenir unes poques instal·lacions d'MSO per a permetre al departament de finances de poder seguir fent servir macros i eines basades en Excel i per a poder assegurar la compatibilitat amb terceres parts com clients o empreses col·laboradores.
Despres de la migració, el format oficial dels documents és ODF per a documents editables i PDF per distribució de informació en documents només de lectura.
Internament,la majoria dels empleats fan servir ODF. Els empleats que encara fan servir els formats de MSO ho fan perquè pertanyen a equips on la documentació circula en aquest format.
Per a la col·laboració entre equips que fan servir formats diferents, es fa servir el format de MSO. Els equips que treballen amb StarOffice fan servir els filtres d'importació i exportació de l'StarOffice per a convertir els documents.
Per a les comunicacions externes es fa servir el format PDF. Si els destinataris externs han d'editar els documents, aleshores han d'instal·lar-se el plugin d'ODF per a poder editar els documents des de l'MSO.
Sumari
La migració a OOo es pot assolir fàcilment amb una bona planificació, recursos suficients i una bona gestió del projecte. L'estalvi que s'obté de migrar a OOo és substancial: El 100% dels costos de llicències. Sense despeses de manteniment, ni l'obligació contractual d'adquirir les actualitzacions. Aquesta llibertat i flexibilitat juntament amb l'estalvi de despesa fa molt interessant iniciar una prova pilot d'avaluació de l'OpenOffice.org.
Documentació i enllaços útils
La documentació Online de l'OpenOffice.org http://documentation.openoffice.org/
Documentació descarregable:
- Installation Guide OOo 3.x (PDF), (ODT)
- Developer's Guide
- Tutorials
- Templates (new Repository)
- OpenOffice.org 3.x Conceptual Guides
- Creating large documents with OpenOffice.org
- User Guides for OOo3.x
- Getting Started Guide (Wiki)
- Writer Guide (Wiki)
- Calc Guide (Wiki)
- Impress Guide (Wiki)
- Draw Guide (Wiki)
- Math Guide (Wiki)
- Individual chapters of all user guides (PDF)
- User Guides for OOo2.x
dijous, 9 de desembre del 2010
Com migrar de MSOffice a OpenOffice.org
La utilització de programari lliure proporciona avantatges evidents. Sens dubte que la més llaminera és la de no haver de pagar per obtenir les llicències per ús.
Parlo de llicències d’ús i no de preu de les aplicacions perquè, de fet, no es compren les aplicacions, sinó llicències per a fer-les servir.
Les llicències d’ús no són pas pocs diners. És un esforç que cal amortitzar. Això porta a que quan es fa una despesa en ofimática, o en aplicacions informàtiques en general, aquell software haurà de ser utilitzat durant un periode de temps prou gran que, al menys, permeti considerar que ha retornat la inversió.
N’hi ha prou amb fer la despesa inicial? No. És necessari un manteniment. En el millor dels casos, amb la llicència també s’obté el dret a actualitzacions automàtiques.
Ara bé, el mecanisme d’actualitzacions automàtiques pot no estar sempre present. Pot ser també que la llicència d’ús adquirida no es correspongui amb la utilització que es doni a l’aplicació i que, per tant, no es pugui actualitzar tot el programari. En el límit, es pot estar usant l’aplicació sense llicència; pot ser també que el suport a l’aplicació quedi discontinuat. En definitiva, no és impensable que abans d’hora calgui fer una despesa adicional per a obtenir llicències per a una nova versió i per al seu manteniment.
El programari lliure senzillament no pateix la servitud de les llicències. En patirà d’altres, per descomptat, i potser la més greu és la dificultat de trobar bons serveis tècnics de manteniment especialitzats en el programari lliure. Tanmateix, aquesta dificultat també es dona amb el programari privatiu.
Una aposta empresarial intel·ligent és la de tractar de reduir la despesa en llicències i manteniment, pel que té de despesa fixa, però també pel risc que representa de despesa imprevista davant la necessitat de renovar el programari instal·lat.
Aquesta aposta implicarà en la majoria d’ocasions una migració. De forma general será migrar des d’una plataforma o des d’aplicacions de pagament a una plataforma o aplicacions de programari lliure.
Aquesta migració total o parcial del sistema d’informació corporatiu és un projecte estratègic en si mateix, i crític degut a que representa canvis en les eines que processen els fluxos de treball i de documents. És necessari garantir que aquests fluxos, si més no, es mantenen i, opcionalment, s'optimitzen. Cal preparar els usuaris per a les noves eines. Cal adaptar la documentació existent als nous formats o assegurar que els formats existents són reconeguts i són útils amb el nou programari.
La migració completa del sistema d’informació corporatiu a programari lliure es pot plantejar com un projecte per fases. Un enfocament posible és plantejar projectes de migració específics per als diferents servidors i aplicacions corporatius: d’intranet, de base de dades, d’ERP, de CRM, d’Intel·ligència de Negoci. I també dels clients d’aquests servidors: l’escriptori dels usuaris, o l’ofimàtica corporativa.
Em concentraré en aquest últim punt: la migració de l’ofimàtica corporativa.
L’ofimàtica corporativa basada en programari lliure té un nom estrella: OpenOffice.org (en endavant OOo). Al seu torn, l’ofimàtica corporativa de pagament té un nom indiscutible: Microsoft Office (en endavant MSO).
Hi han altres opcions d’ofimàtica lliure, en escriptoris Linux basats en KDE es pot trobar el KOffice. En escriptoris del tipus Gnome, es diposa del Gnome Office que és un mix de diverses aplicacions com Abiword (processador de textos), GNUMeric (full de càlcul), Thunderbird (client de correu)…
Però OOo és una opció molt interessant perquè és una suite ofimática completa que és disponible tant en plataformes Windows com en Linux. La migració de MSO a OOo és posible, doncs, sense necessitat de canviar de sistema operatiu. La tria de OOo permet fer un canvi gradual i introduir el programari lliure en un lloc tan visible, i a l’hora, tan crític, com és l’escriptori dels usuaris. La introducció del programari i formats lliures en l’escriptori facilitaran el canvi a la implantació de sistemes operatius lliures en els clients.
L’escenari que es planteja és, doncs la migració de l’ofimàtica del client de MSO a OOo.
Sun (actualment propietat d’Oracle) ha elaborat diversos White Papers (en endavant WP) en el que proposa una metodologia i diferents escenaris per a projectes de migració de MSO a OOo (o a Oracle OpenOffice, l'antic StarOffice, la versió de pagamanet d’OOo propietat de Sun; i cal pensar que el model que plantegen també servirá per al IBM Lotus Symphony, la suite ofimática basada en l’OOo realitzada per IBM i que recupera el nom d’una suite ofimàtica per MSDOS que va ser popular als 80).
A continuació em referiré a la metodología descrita en aquests WP.
Com ja he dit abans, l’ofimàtica de l’usuari és una part fonamental i integrada en els fluxos de treball corporatius de cada dia de la majoria dels treballadors. Per tant, és crític planificar i executar la migració de forma rigurosa.
El WP de SUN proposa sis fases per a la migració:
1. Implementació d’una fase pilot
2. Elaboració d’un catàleg de les eines i solucions que depenen del MSO
3. Identificació dels documents i les macros d'MSO que s’estiguin utilitzant
4. Organització de l’equip de migració
5. Conversió de macros, plantilles i documents crítics dels fluxos de treball
6. Formació i suport post-migració
1. Implementació d’una fase pilot
L’objectiu d’aquesta fase és identificar els problemes que podrien afectar a la migració i que es comprenen els fluxos de treball i els intercanvis de documents.
Per a aquesta fase és necessària la participación d’empleats que siguin representatius funcionalment, amb la preparació adequada per a les tasques i que permetin abastar la major part o, millor, a tots els fluxos de treball.
Aquests usuaris hauran de tenir formació en l’OpenOffice.org o, si més no, disposar del suport de companys formats o d’un helpdesk.
Pot ser interessant comptar amb la col·laboració estratégica d’un “Migration Partner” per a prestar aquest support.
El HelpDesk haurà de prestar suport en qüestions del tipus “Com es fa?”. Cal reportar el errors i els problemes per a poder analitzar-los posteriorment.
Una segona aproximació és prestar aquest suport via correu electrònic.
Per a grans corporacions es pot aprofitar el pilot per a implementar una eina de gestió de HelpDesk, obviament de programari lliure i, preferiblement, amb interfase web, de forma que els mateixos usuaris puguin crear des dels seus navegadors els tickets de les incidències. Aquesta mena d’eines permeten fer un seguiment de la resolució de les incidències trobades i se’n poden obtenir informes i estadístiques.
2. Elaboració d’un catàleg de les eines i solucions que depenen del MSO
Hi han diversos tipus d'aplicacions ERP, CRM i d'altres que depenen o proporcionen interfícies amb l'MSO. Aquestes aplicacions han de ser identificades aviat perquè cal preveure que serà on caldrà posar més esforç per a fer-les treballar amb l'OpenOffice.org.
Els caps d'equip i els gestors de la informàtica corporativa necessiten disposar d'aquesta informació, per tant, és una bona idea demanar-se-la mitjançant qüestionaris. Els qüestionaris poden proporcionar una bona explicació sobre com estan interaccionant aquestes aplicacions personalitzades amb l'MSO.
3. Identificació dels documents i les macros d'MSO que s’estiguin utilitzant
Cal demanar als usuaris que, per una banda, identifiquin els arxius que són importants per al seu treball i, per l'altra, que identifiquin els arxius que ja no es fan servir.
Cal assegurar que tothom fa servir els mateixos criteris per distingir el que es fa servir del que no es fa servir, per això caldrà proporcionar aquests criteris als usuaris:
Arxius que es fan servir: són aquells documents o plantilles que es modifiquen o s'apliquen almenys un cop al mes.
Arxius que no es fan servir: els arxius, documents o plantilles que no es fan servir aleshores es poden classificar com arxivat definitiu, que serien tots aquells que ni es fan servir ni es faran servir en el futur; o com històric que serien aquells fitxers que ocasionalment es poden haver d'imprimir o consultar.
Una solució per a aquests fitxers és algun sistema d'emmagatzematge massiu extern (per distingir-lo de l'emmagatzematge online que seria tenir-los al disc dur.) com podria ser DVD. També es pot plantejar una sol·lució d'escanejat a PDF per a poder-los guardar en un format accessible en el futur.
Els documents que més probablement caldrà arxivar seran la correspondència, factures, calendaris i planificacions, informes de diferents tipus i documents legals. Els documents que tinguin validesa legal no han de ser convertits, doncs, en principi, perdrien la seva validesa si es canvia el seu format.
En l'emmagatzematge de la informació històrica, si s'escau caldrà tenir en compte a Llei Orgànica de Protecció de Dades (LORTAD) .
A més caldrà identificar aquells arxius que es comparteixen entre departaments dins de l'empresa o amb empreses externes que també facin servir l'MSO. Els fitxers compartits que incloguin macros hauran de ser rigorosament monitoritzats per tal de controlar-ne els canvis que pateixin a mida que es van movent entre els diferents ambients del negoci.
4. Organització de l’equip de migració
La dimensió i perfils de l'equip de migració variaran depenent de la mida i estructura de l'organització a migrar. El rol principal és el del gestor de projecte, que preferiblement hauria de ser un perfil sènior del departament d'informàtica.
El gestor de projecte ha de preveure l'entorn post-migració, incloent les adaptacions que calguin per a estabilitzar el funcionament global, tenint en compte als objectius de la corporació, les necessitats dels empleats i la disponibilitat de recursos.
La substitució de l'MSO per l'OOo no és directa, perquè es tracta d'eines diferents. Cal preveure que hi hauran fluxos de treball que caldrà modificar, compensar o adaptar a la nova eina.
El gestor de projecte també determinarà l'abast de la migració a partir de la informació sobre els entorns i els documents recopilada pel seu equip.
A partir d'aquesta informació, el gestor de projecte determinarà un marc temporal (una planificació d'alt nivell) per a la conversió dels documents i solucions personalitzades i una data límit de finalització de l'utilització de l'MSO en la companyia.
L'equip de migració podria incloure també administradors de sistemes i altres personal com facilitadors, desenvolupadors o administratius.
Els administradors de sistemes haurien de ser els responsables de configurar i fer el manteniment dels esquemes de configuració de l'OOo en l'escenari post-migració.
Els tècnics informàtics, adequadament formats, serien els responsables de prestar el suport als usuaris després de la migració. És importants, doncs caldrà prestar algun suport als usuaris per a que esdevinguin productius ràpidament.
Els caps de projecte hauran de gestionar les tasques de migració en els nivells de departaments corporatius. Aquestes tasques de migració inclouen la documentació dels sistemes informàtics departamentals, la identificació de l'efecte de la migració en els workflows d'usuari i de negoci, com impacta la migració en arxius i en dades, i la comunicació i coordinació amb les diferents parts interessades en el procés de migració.
5. Conversió de macros, plantilles i documents crítics dels fluxos de treball
La forma més senzilla de convertir els fitxers Word, Excel i PowerPoint a fitxers en format OpenDocument és fer servir el mateix OOo per obrir-los i desar-los en el nou format.
Una opció és desenvolupar macros que facin això mateix: obrir (importar) successivament els fitxers d'una carpeta i anar-los desant en el format OpenDocumet corresponent.
Per descomptat que s'imposa una revisió manual per part dels propietaris dels fitxers per tal de verificar-ne la validesa de la transformació.
Les macros de MSO no es poden executar directament en OOo perquè els models d'objectes dels documents són del tot diferents. Cal preveure, doncs una tasca de transformació manual de les macros.
Aquesta tasca pot ser una bona oportunitat per a millorar l'eficiència dels processos que les involucren. POt ser un bon moment per a determinar, per exemple, quines són les macros que encara són necessàries i descartar-ne les que ja no ho siguin. També pot ser el moment per a fer una re-enginyeria de les macros existents per a reconvertir-les en objectes de negoci Java o C++ implementats com components UNO (Universal Network Objects, la tecnologia de components subjacent a OOo). Els nous components seran més eficients que les macros en Visual Basic.
Una altre aproximació possible seria reconvertir-les per usar aplicacions basades en web i en java de servidor. Els components de servidor proporcionaran més seguretat en temps d'execució i millor gestió d'errors que les corresponents macros originals en Visual Basic.
6. Formació i suport post-migració
Els usuaris es trobaran amb una experiència d'usuari diferent a la que estaven acostumats. Trobaran els documents transformats i macros diferents. Per tot això, el pla de migració necessàriament a d'incloure un període de formació que ajudi als usuaris a sentir-se còmodes amb la seva nova suite ofimàtica.
Per exemple, es podria mostrar als usuaris la forma de solucionar problemes típics després d'haver convertit un document al nou format OpenDocument.
La formació ha de familiaritzar als usuaris amb la nova interfície d'usuari i seran capaços de dominar ràpidament la seva nova eina.
per tal de minimitzar el nombre peticions de suport i maximitzar la productivitat des d'un bon començament, és recomanable preparar un "Welcome Pack" pels usuaris amb informació sobre el nou entorn d'escriptori. Aquest "Welcome Pack" podria incloure una guia ràpida d'usuari que destaqui les semblances i les diferències entre MSO i OOo. També es podria incloure un manual de programació del llenguatge Basic de l'OpenOffice.org que estaria destinat als usuaris que vulguin crear les seves pròpies macros.
A més, pot ser adequat fer una formació de més alt nivell per a usuaris avançats.
De cara facilitar aquesta etapa de la migració caldria determinar prèviament el nivell dels usuaris (basic, mig, avançat...) aleshores es pot fer una llista dels empleats amb més nivell que poden prestar suport als usuaris menys avançats que requereixin suport.
Finalment, una darrera opció és fer una formació online. La formació online, amb una etapa tutoritzada i suport per xat, pot significar una reducció del cost de formació al no requerir desplaçaments de persones ni sales de formació condicionades i és més flexible per a l'usuari que pot realitzar els cursos en els horaris que més li convinguin.
Migració de solucions basades en MSO
Una suite ofimàtica sovint agrega informació provinent de fons diverses. Aquestes fonts són, en la majoria d'ocasions, altres aplicacions que proporcionen dades que s'afegeixen als documents. MSO proporciona un conjunt de protocols de comunicació per al diàleg amb aquestes aplicacions externes. OOo, per la seva banda, suporta aquests protocols de comunicació, però la diferència entre els models d'objectes de documentes de MSO i OOo fan que la comunicació entre OOo i les aplicacions externes, a priori, no sigui compatible amb la de MSO.
El primer pas és determinar com les diferents aplicacions externes intercanvien la informació amb MSO. Hi han tres mètodes principals:
El més senzill, fent servir fitxers i documents. Aquesta solució crea documents o fitxers de MSO que poden ser carregats per l'MSO. En principi, això ha de continuar funcionant correctament un cop migrat a OOo, perquè OOo és capaç d'importar els formats de MSO.
El segon mètode és fer servir el porta papers per a intercanviar informació entre l'aplicació externa i MSO. Aquesta opció també hauria de funcionar correctament amb l'OOo.
El tercer mètode és quan l'aplicació externa invoca directament el model d'objectes de l'OpenOffice (el mecanisme d'automatització de MSO). Això ni funciona amb OOo.
Tanmateix encara es pot fer alguna cosa. Cal distingir entre interfases fetes a ma entre les aplicacions externes i l'MSO i les aplicacions que "out of the box" ja proporcionen la interfase amb MSO.
En el cas de les aplicacions amb interfase MSO "out of the box" les opcions de migració depenen de la compatibilitat de la solució amb OOo.
En cas de no disposar d'aquesta compatibilitat cal considerar la realització d'un desenvolupament a mida. Ara bé, és millor no reinventar la roda:
Primer de tot, cal demanar al proveïdor de l'aplicació si tenen prevista una versió compatible amb OOo, o si en podria desenvolupar una per al nostre cas. Suposant que el proveïdor ens respon afirmativament a alguna de les qüestions, cal preveure que la versió compatible no serà immediata i que caldrà proporcionar una solució de contingència: per exemple, pot caldre disposar d'una o més instàncies de MSO fins que la versió compatible amb OOo estigui disponible.
Pot resultar que el proveidor no estigui disposat a col·laborar i aleshores serà necessari trobar solucions alternatives. Les solucions alternatives podrien ser desenvolupar una solució a mida des de zero, o canviar l'aplicació externa per una de competidora que sí que sigui compatible amb OOo.
Migració de bases de dades Access
OOo Base és l'aplicació de base de dades de la suite ofimàtica OOo . OOoBase proporciona assistents per a la creació de taules, consultes, formularis i informes.
BAse treballa amb un motor java de base de dades del tipys HyperSonic DataBase Engine, ara bé, OOoBase és capaç de llegir i escriure dades des de MySQL, base de dades JDBC, connexions ODBC (a UNIX també fent servir ODBCUnix), MSAccess, fitxers de text csv, llegeix fulls de càlcul excel, dBase...)
Ara bé, OOo Base no és capaç de reconèixer els formularis, informes i consultes de MSAccess.
La migració d'aplicacions basades en formularis, informes i consultes de MSAccess és també un bon moment per a la reenginyeria i decidir si es migra cap a una solució basada en OOoBase i components UNO, o bé si es marxa cap a una solució basada en web.
Migració de l'Outlook
OOo reconeix l'Outlook com a client de correu per defecte. En general, per tant, no caldrà migrar de client de correu. Tanmateix pot ser interessant migrar d'Outlook a un altre client de correu basat en programari lliure perquè, per exemple, es vol canviar el sistema operatiu d'escriptori de Windows a Linux. I no es disposa d'Outlook a Linux.
En aquest cas, una bona opció es migrar a Mozilla Thunderbird. Mozilla Thunderbird és el client de correu de programari lliure més popular i està basat en el mateix framework del navegador Firefox. Existeixen versions en plataformes Windows i Linux i està disponible en molts llenguatges, en particular, també en català.
Thunderbird diposa d'un assistent d'importació de comptes des d'outlook express que pot fer senzilla la migració. Migrar Thunderbird de Windows a Linux és tan senzill com copiar la carpeta de configuració de l'usuari, que conté les definicions dels comptes, les carpetes i las mailboxes amb els correus enviats i rebuts.
Finalment, Mozilla Lightning és una extensió de Mozilla Thunderbird que li afegeix calendari amb vista diària, setmanal i mensual. Lightning també és programari lliure.
Parlo de llicències d’ús i no de preu de les aplicacions perquè, de fet, no es compren les aplicacions, sinó llicències per a fer-les servir.
Les llicències d’ús no són pas pocs diners. És un esforç que cal amortitzar. Això porta a que quan es fa una despesa en ofimática, o en aplicacions informàtiques en general, aquell software haurà de ser utilitzat durant un periode de temps prou gran que, al menys, permeti considerar que ha retornat la inversió.
N’hi ha prou amb fer la despesa inicial? No. És necessari un manteniment. En el millor dels casos, amb la llicència també s’obté el dret a actualitzacions automàtiques.
Ara bé, el mecanisme d’actualitzacions automàtiques pot no estar sempre present. Pot ser també que la llicència d’ús adquirida no es correspongui amb la utilització que es doni a l’aplicació i que, per tant, no es pugui actualitzar tot el programari. En el límit, es pot estar usant l’aplicació sense llicència; pot ser també que el suport a l’aplicació quedi discontinuat. En definitiva, no és impensable que abans d’hora calgui fer una despesa adicional per a obtenir llicències per a una nova versió i per al seu manteniment.
El programari lliure senzillament no pateix la servitud de les llicències. En patirà d’altres, per descomptat, i potser la més greu és la dificultat de trobar bons serveis tècnics de manteniment especialitzats en el programari lliure. Tanmateix, aquesta dificultat també es dona amb el programari privatiu.
Una aposta empresarial intel·ligent és la de tractar de reduir la despesa en llicències i manteniment, pel que té de despesa fixa, però també pel risc que representa de despesa imprevista davant la necessitat de renovar el programari instal·lat.
Aquesta aposta implicarà en la majoria d’ocasions una migració. De forma general será migrar des d’una plataforma o des d’aplicacions de pagament a una plataforma o aplicacions de programari lliure.
Aquesta migració total o parcial del sistema d’informació corporatiu és un projecte estratègic en si mateix, i crític degut a que representa canvis en les eines que processen els fluxos de treball i de documents. És necessari garantir que aquests fluxos, si més no, es mantenen i, opcionalment, s'optimitzen. Cal preparar els usuaris per a les noves eines. Cal adaptar la documentació existent als nous formats o assegurar que els formats existents són reconeguts i són útils amb el nou programari.
La migració completa del sistema d’informació corporatiu a programari lliure es pot plantejar com un projecte per fases. Un enfocament posible és plantejar projectes de migració específics per als diferents servidors i aplicacions corporatius: d’intranet, de base de dades, d’ERP, de CRM, d’Intel·ligència de Negoci. I també dels clients d’aquests servidors: l’escriptori dels usuaris, o l’ofimàtica corporativa.
Em concentraré en aquest últim punt: la migració de l’ofimàtica corporativa.
L’ofimàtica corporativa basada en programari lliure té un nom estrella: OpenOffice.org (en endavant OOo). Al seu torn, l’ofimàtica corporativa de pagament té un nom indiscutible: Microsoft Office (en endavant MSO).
Hi han altres opcions d’ofimàtica lliure, en escriptoris Linux basats en KDE es pot trobar el KOffice. En escriptoris del tipus Gnome, es diposa del Gnome Office que és un mix de diverses aplicacions com Abiword (processador de textos), GNUMeric (full de càlcul), Thunderbird (client de correu)…
Però OOo és una opció molt interessant perquè és una suite ofimática completa que és disponible tant en plataformes Windows com en Linux. La migració de MSO a OOo és posible, doncs, sense necessitat de canviar de sistema operatiu. La tria de OOo permet fer un canvi gradual i introduir el programari lliure en un lloc tan visible, i a l’hora, tan crític, com és l’escriptori dels usuaris. La introducció del programari i formats lliures en l’escriptori facilitaran el canvi a la implantació de sistemes operatius lliures en els clients.
L’escenari que es planteja és, doncs la migració de l’ofimàtica del client de MSO a OOo.
Sun (actualment propietat d’Oracle) ha elaborat diversos White Papers (en endavant WP) en el que proposa una metodologia i diferents escenaris per a projectes de migració de MSO a OOo (o a Oracle OpenOffice, l'antic StarOffice, la versió de pagamanet d’OOo propietat de Sun; i cal pensar que el model que plantegen també servirá per al IBM Lotus Symphony, la suite ofimática basada en l’OOo realitzada per IBM i que recupera el nom d’una suite ofimàtica per MSDOS que va ser popular als 80).
A continuació em referiré a la metodología descrita en aquests WP.
Com ja he dit abans, l’ofimàtica de l’usuari és una part fonamental i integrada en els fluxos de treball corporatius de cada dia de la majoria dels treballadors. Per tant, és crític planificar i executar la migració de forma rigurosa.
El WP de SUN proposa sis fases per a la migració:
1. Implementació d’una fase pilot
2. Elaboració d’un catàleg de les eines i solucions que depenen del MSO
3. Identificació dels documents i les macros d'MSO que s’estiguin utilitzant
4. Organització de l’equip de migració
5. Conversió de macros, plantilles i documents crítics dels fluxos de treball
6. Formació i suport post-migració
1. Implementació d’una fase pilot
L’objectiu d’aquesta fase és identificar els problemes que podrien afectar a la migració i que es comprenen els fluxos de treball i els intercanvis de documents.
Per a aquesta fase és necessària la participación d’empleats que siguin representatius funcionalment, amb la preparació adequada per a les tasques i que permetin abastar la major part o, millor, a tots els fluxos de treball.
Aquests usuaris hauran de tenir formació en l’OpenOffice.org o, si més no, disposar del suport de companys formats o d’un helpdesk.
Pot ser interessant comptar amb la col·laboració estratégica d’un “Migration Partner” per a prestar aquest support.
El HelpDesk haurà de prestar suport en qüestions del tipus “Com es fa?”. Cal reportar el errors i els problemes per a poder analitzar-los posteriorment.
Una segona aproximació és prestar aquest suport via correu electrònic.
Per a grans corporacions es pot aprofitar el pilot per a implementar una eina de gestió de HelpDesk, obviament de programari lliure i, preferiblement, amb interfase web, de forma que els mateixos usuaris puguin crear des dels seus navegadors els tickets de les incidències. Aquesta mena d’eines permeten fer un seguiment de la resolució de les incidències trobades i se’n poden obtenir informes i estadístiques.
2. Elaboració d’un catàleg de les eines i solucions que depenen del MSO
Hi han diversos tipus d'aplicacions ERP, CRM i d'altres que depenen o proporcionen interfícies amb l'MSO. Aquestes aplicacions han de ser identificades aviat perquè cal preveure que serà on caldrà posar més esforç per a fer-les treballar amb l'OpenOffice.org.
Els caps d'equip i els gestors de la informàtica corporativa necessiten disposar d'aquesta informació, per tant, és una bona idea demanar-se-la mitjançant qüestionaris. Els qüestionaris poden proporcionar una bona explicació sobre com estan interaccionant aquestes aplicacions personalitzades amb l'MSO.
3. Identificació dels documents i les macros d'MSO que s’estiguin utilitzant
Cal demanar als usuaris que, per una banda, identifiquin els arxius que són importants per al seu treball i, per l'altra, que identifiquin els arxius que ja no es fan servir.
Cal assegurar que tothom fa servir els mateixos criteris per distingir el que es fa servir del que no es fa servir, per això caldrà proporcionar aquests criteris als usuaris:
Arxius que es fan servir: són aquells documents o plantilles que es modifiquen o s'apliquen almenys un cop al mes.
Arxius que no es fan servir: els arxius, documents o plantilles que no es fan servir aleshores es poden classificar com arxivat definitiu, que serien tots aquells que ni es fan servir ni es faran servir en el futur; o com històric que serien aquells fitxers que ocasionalment es poden haver d'imprimir o consultar.
Una solució per a aquests fitxers és algun sistema d'emmagatzematge massiu extern (per distingir-lo de l'emmagatzematge online que seria tenir-los al disc dur.) com podria ser DVD. També es pot plantejar una sol·lució d'escanejat a PDF per a poder-los guardar en un format accessible en el futur.
Els documents que més probablement caldrà arxivar seran la correspondència, factures, calendaris i planificacions, informes de diferents tipus i documents legals. Els documents que tinguin validesa legal no han de ser convertits, doncs, en principi, perdrien la seva validesa si es canvia el seu format.
En l'emmagatzematge de la informació històrica, si s'escau caldrà tenir en compte a Llei Orgànica de Protecció de Dades (LORTAD) .
A més caldrà identificar aquells arxius que es comparteixen entre departaments dins de l'empresa o amb empreses externes que també facin servir l'MSO. Els fitxers compartits que incloguin macros hauran de ser rigorosament monitoritzats per tal de controlar-ne els canvis que pateixin a mida que es van movent entre els diferents ambients del negoci.
4. Organització de l’equip de migració
La dimensió i perfils de l'equip de migració variaran depenent de la mida i estructura de l'organització a migrar. El rol principal és el del gestor de projecte, que preferiblement hauria de ser un perfil sènior del departament d'informàtica.
El gestor de projecte ha de preveure l'entorn post-migració, incloent les adaptacions que calguin per a estabilitzar el funcionament global, tenint en compte als objectius de la corporació, les necessitats dels empleats i la disponibilitat de recursos.
La substitució de l'MSO per l'OOo no és directa, perquè es tracta d'eines diferents. Cal preveure que hi hauran fluxos de treball que caldrà modificar, compensar o adaptar a la nova eina.
El gestor de projecte també determinarà l'abast de la migració a partir de la informació sobre els entorns i els documents recopilada pel seu equip.
A partir d'aquesta informació, el gestor de projecte determinarà un marc temporal (una planificació d'alt nivell) per a la conversió dels documents i solucions personalitzades i una data límit de finalització de l'utilització de l'MSO en la companyia.
L'equip de migració podria incloure també administradors de sistemes i altres personal com facilitadors, desenvolupadors o administratius.
Els administradors de sistemes haurien de ser els responsables de configurar i fer el manteniment dels esquemes de configuració de l'OOo en l'escenari post-migració.
Els tècnics informàtics, adequadament formats, serien els responsables de prestar el suport als usuaris després de la migració. És importants, doncs caldrà prestar algun suport als usuaris per a que esdevinguin productius ràpidament.
Els caps de projecte hauran de gestionar les tasques de migració en els nivells de departaments corporatius. Aquestes tasques de migració inclouen la documentació dels sistemes informàtics departamentals, la identificació de l'efecte de la migració en els workflows d'usuari i de negoci, com impacta la migració en arxius i en dades, i la comunicació i coordinació amb les diferents parts interessades en el procés de migració.
5. Conversió de macros, plantilles i documents crítics dels fluxos de treball
La forma més senzilla de convertir els fitxers Word, Excel i PowerPoint a fitxers en format OpenDocument és fer servir el mateix OOo per obrir-los i desar-los en el nou format.
Una opció és desenvolupar macros que facin això mateix: obrir (importar) successivament els fitxers d'una carpeta i anar-los desant en el format OpenDocumet corresponent.
Per descomptat que s'imposa una revisió manual per part dels propietaris dels fitxers per tal de verificar-ne la validesa de la transformació.
Les macros de MSO no es poden executar directament en OOo perquè els models d'objectes dels documents són del tot diferents. Cal preveure, doncs una tasca de transformació manual de les macros.
Aquesta tasca pot ser una bona oportunitat per a millorar l'eficiència dels processos que les involucren. POt ser un bon moment per a determinar, per exemple, quines són les macros que encara són necessàries i descartar-ne les que ja no ho siguin. També pot ser el moment per a fer una re-enginyeria de les macros existents per a reconvertir-les en objectes de negoci Java o C++ implementats com components UNO (Universal Network Objects, la tecnologia de components subjacent a OOo). Els nous components seran més eficients que les macros en Visual Basic.
Una altre aproximació possible seria reconvertir-les per usar aplicacions basades en web i en java de servidor. Els components de servidor proporcionaran més seguretat en temps d'execució i millor gestió d'errors que les corresponents macros originals en Visual Basic.
6. Formació i suport post-migració
Els usuaris es trobaran amb una experiència d'usuari diferent a la que estaven acostumats. Trobaran els documents transformats i macros diferents. Per tot això, el pla de migració necessàriament a d'incloure un període de formació que ajudi als usuaris a sentir-se còmodes amb la seva nova suite ofimàtica.
Per exemple, es podria mostrar als usuaris la forma de solucionar problemes típics després d'haver convertit un document al nou format OpenDocument.
La formació ha de familiaritzar als usuaris amb la nova interfície d'usuari i seran capaços de dominar ràpidament la seva nova eina.
per tal de minimitzar el nombre peticions de suport i maximitzar la productivitat des d'un bon començament, és recomanable preparar un "Welcome Pack" pels usuaris amb informació sobre el nou entorn d'escriptori. Aquest "Welcome Pack" podria incloure una guia ràpida d'usuari que destaqui les semblances i les diferències entre MSO i OOo. També es podria incloure un manual de programació del llenguatge Basic de l'OpenOffice.org que estaria destinat als usuaris que vulguin crear les seves pròpies macros.
A més, pot ser adequat fer una formació de més alt nivell per a usuaris avançats.
De cara facilitar aquesta etapa de la migració caldria determinar prèviament el nivell dels usuaris (basic, mig, avançat...) aleshores es pot fer una llista dels empleats amb més nivell que poden prestar suport als usuaris menys avançats que requereixin suport.
Finalment, una darrera opció és fer una formació online. La formació online, amb una etapa tutoritzada i suport per xat, pot significar una reducció del cost de formació al no requerir desplaçaments de persones ni sales de formació condicionades i és més flexible per a l'usuari que pot realitzar els cursos en els horaris que més li convinguin.
Migració de solucions basades en MSO
Una suite ofimàtica sovint agrega informació provinent de fons diverses. Aquestes fonts són, en la majoria d'ocasions, altres aplicacions que proporcionen dades que s'afegeixen als documents. MSO proporciona un conjunt de protocols de comunicació per al diàleg amb aquestes aplicacions externes. OOo, per la seva banda, suporta aquests protocols de comunicació, però la diferència entre els models d'objectes de documentes de MSO i OOo fan que la comunicació entre OOo i les aplicacions externes, a priori, no sigui compatible amb la de MSO.
El primer pas és determinar com les diferents aplicacions externes intercanvien la informació amb MSO. Hi han tres mètodes principals:
El més senzill, fent servir fitxers i documents. Aquesta solució crea documents o fitxers de MSO que poden ser carregats per l'MSO. En principi, això ha de continuar funcionant correctament un cop migrat a OOo, perquè OOo és capaç d'importar els formats de MSO.
El segon mètode és fer servir el porta papers per a intercanviar informació entre l'aplicació externa i MSO. Aquesta opció també hauria de funcionar correctament amb l'OOo.
El tercer mètode és quan l'aplicació externa invoca directament el model d'objectes de l'OpenOffice (el mecanisme d'automatització de MSO). Això ni funciona amb OOo.
Tanmateix encara es pot fer alguna cosa. Cal distingir entre interfases fetes a ma entre les aplicacions externes i l'MSO i les aplicacions que "out of the box" ja proporcionen la interfase amb MSO.
En el cas de les aplicacions amb interfase MSO "out of the box" les opcions de migració depenen de la compatibilitat de la solució amb OOo.
En cas de no disposar d'aquesta compatibilitat cal considerar la realització d'un desenvolupament a mida. Ara bé, és millor no reinventar la roda:
Primer de tot, cal demanar al proveïdor de l'aplicació si tenen prevista una versió compatible amb OOo, o si en podria desenvolupar una per al nostre cas. Suposant que el proveïdor ens respon afirmativament a alguna de les qüestions, cal preveure que la versió compatible no serà immediata i que caldrà proporcionar una solució de contingència: per exemple, pot caldre disposar d'una o més instàncies de MSO fins que la versió compatible amb OOo estigui disponible.
Pot resultar que el proveidor no estigui disposat a col·laborar i aleshores serà necessari trobar solucions alternatives. Les solucions alternatives podrien ser desenvolupar una solució a mida des de zero, o canviar l'aplicació externa per una de competidora que sí que sigui compatible amb OOo.
Migració de bases de dades Access
OOo Base és l'aplicació de base de dades de la suite ofimàtica OOo . OOoBase proporciona assistents per a la creació de taules, consultes, formularis i informes.
BAse treballa amb un motor java de base de dades del tipys HyperSonic DataBase Engine, ara bé, OOoBase és capaç de llegir i escriure dades des de MySQL, base de dades JDBC, connexions ODBC (a UNIX també fent servir ODBCUnix), MSAccess, fitxers de text csv, llegeix fulls de càlcul excel, dBase...)
Ara bé, OOo Base no és capaç de reconèixer els formularis, informes i consultes de MSAccess.
La migració d'aplicacions basades en formularis, informes i consultes de MSAccess és també un bon moment per a la reenginyeria i decidir si es migra cap a una solució basada en OOoBase i components UNO, o bé si es marxa cap a una solució basada en web.
Migració de l'Outlook
OOo reconeix l'Outlook com a client de correu per defecte. En general, per tant, no caldrà migrar de client de correu. Tanmateix pot ser interessant migrar d'Outlook a un altre client de correu basat en programari lliure perquè, per exemple, es vol canviar el sistema operatiu d'escriptori de Windows a Linux. I no es disposa d'Outlook a Linux.
En aquest cas, una bona opció es migrar a Mozilla Thunderbird. Mozilla Thunderbird és el client de correu de programari lliure més popular i està basat en el mateix framework del navegador Firefox. Existeixen versions en plataformes Windows i Linux i està disponible en molts llenguatges, en particular, també en català.
Thunderbird diposa d'un assistent d'importació de comptes des d'outlook express que pot fer senzilla la migració. Migrar Thunderbird de Windows a Linux és tan senzill com copiar la carpeta de configuració de l'usuari, que conté les definicions dels comptes, les carpetes i las mailboxes amb els correus enviats i rebuts.
Finalment, Mozilla Lightning és una extensió de Mozilla Thunderbird que li afegeix calendari amb vista diària, setmanal i mensual. Lightning també és programari lliure.
dimarts, 7 de desembre del 2010
Com fer una GUI basada en Python i Glade amb Anjuta
Una molt bona opció per a fer aplicacions amb interfase gràfica d'usuari en entorns d'escriptori Gnome, o allà on es tingui disponible el GTK és fer servir la combinació de Glade i Python.
En realitat Glade es pot combinar amb d'altres llenguatges com C/C++, o Java. Tanmateix, la combinació amb Python ofereix alguns avantatges que cal tenir en compte.
la combinació de Python amb Glade ofereix un avantatge fonamental: Python és un llenguatge interpretat d'script. És adequat, per tant, per a l'automatització flexible de processos, diguem-ne macros, i per a tasques d'administració.
Python es pot trobar com llenguatge de macros en diverses aplicacions, com l'OpenOffice, o el Gimp. Amb tot, Python és molt potent, i prou senzill, com per a que se'l trobi en d'altres ambients.
El que faré en l'exercici que presento és crear una GUI amb Glade i connectar-la a un script Python.
L'entorn en el que desenvolupo és un Ubuntu 10.10, Lucid Lynx. Amb Python 2.6 i amb Glade 3.6.7. Faig servir com IDE l'Anjuta 2.30.1.0.
Primer de tot amb l'Anjuta creo un projecte de tipus Python:
Li indico la carpeta de projecte.
Som-hi: afegeixo una pantalla d'interfase gràfica: Fitxer - Nou - Fitxer del Glade.
S'obre la finestra de preferències per a la interfície gràfica. En aquesta primera pantalla el que cal és assegurar-se que és fer servir el GtkBuilder, L'altre opció, LibGlade, està "deprecada". En principi, com no sigui pel fet d'haver de desenvolupar o mantenir interfases en versions antigues de GTK, la LibGlade no l'hauria de fer servir.
Un cop assegurat que el format és del GtkBuilder s'obre el dissenyador d'interfícies. Faig una interfície senzilla com la de la imatge. La he creat a partir d'una finestra de tipus diàleg que ja em proporciona un parell de botons. El nom de la finestra és dialog1. El posa automàticament el Glade. Podré comprovar-ho en revisar el fitxer generat.
He afegit un layout del tipus Vertical Box amb tres files. A la de dalt he posat un label per al títol (label1), a la del mig un camp d'entrada de text (entry1) i a la de sota, un altre camp d'entrada de text (entry2).
El que faré ara serà assignar als l'event clicked de cada botó una funcions que serà el seu "event-handler". És tan senzill com indicar-ho a les propietats.
Al boto1 li assigno l'event-handler on_button1_clicked i al botó 2 el on_button2_clicked
Deso el fitxer generat. És interessant revisar-ne el contingut amb un editor de text.
<?xml version="1.0"?>
<interface>
<requires lib="gtk+" version="2.16"/>
<!-- interface-naming-policy project-wide -->
<object class="GtkDialog" id="dialog1">
<property name="border_width">5</property>
<property name="type_hint">normal</property>
<property name="has_separator">False</property>
<child internal-child="vbox">
<object class="GtkVBox" id="dialog-vbox1">
<property name="visible">True</property>
<property name="spacing">2</property>
<child>
<object class="GtkVBox" id="vbox2">
<property name="visible">True</property>
<child>
<object class="GtkLabel" id="label1">
<property name="visible">True</property>
<property name="xalign">0.47999998927116394</property>
<property name="label" translatable="yes">Una prova amb Glade + Python</property>
</object>
<packing>
<property name="position">0</property>
</packing>
</child>
<child>
<object class="GtkEntry" id="entry1">
<property name="visible">True</property>
<property name="can_focus">True</property>
<property name="invisible_char">●</property>
</object>
<packing>
<property name="position">1</property>
</packing>
</child>
<child>
<object class="GtkEntry" id="entry2">
<property name="visible">True</property>
<property name="can_focus">True</property>
<property name="invisible_char">●</property>
<property name="text" translatable="yes">AAAA</property>
</object>
<packing>
<property name="position">2</property>
</packing>
</child>
</object>
<packing>
<property name="position">1</property>
</packing>
</child>
<child internal-child="action_area">
<object class="GtkHButtonBox" id="dialog-action_area1">
<property name="visible">True</property>
<property name="layout_style">end</property>
<child>
<object class="GtkButton" id="button1">
<property name="label" translatable="yes">Acció</property>
<property name="visible">True</property>
<property name="can_focus">True</property>
<property name="receives_default">True</property>
<signal name="clicked" handler="on_button1_clicked"/>
</object>
<packing>
<property name="expand">False</property>
<property name="fill">False</property>
<property name="position">0</property>
</packing>
</child>
<child>
<object class="GtkButton" id="button2">
<property name="label" translatable="yes">Sortir</property>
<property name="visible">True</property>
<property name="can_focus">True</property>
<property name="receives_default">True</property>
<signal name="clicked" handler="on_button2_clicked"/>
</object>
<packing>
<property name="expand">False</property>
<property name="fill">False</property>
<property name="position">1</property>
</packing>
</child>
</object>
<packing>
<property name="expand">False</property>
<property name="pack_type">end</property>
<property name="position">0</property>
</packing>
</child>
</object>
</child>
<action-widgets>
<action-widget response="0">button1</action-widget>
<action-widget response="0">button2</action-widget>
</action-widgets>
</object>
</interface>
A partit d'aquí ja tenim la GUI preparada, ara cal connectar-la a l'script Python que la mourà. Vet aquí l'script:
Primer de tot, el preparo per a poder executar des de línia de comandes. També li indico que l'encoding per defecte serà el latin-1. Això és important per a poder escriure literals en català. A partir d'aquí, les explicacions es troben als comentaris del codi:
#!/usr/bin/python
# coding: latin-1
#Importo el paquets de Gtk, PyGtk i Glade
import sys
import pygtk
import gtk
import gtk.glade
#Creo una classe que gestionarà la GUI. Serà el controlador bàsic.
class CGui:
# propietats
# Un objecte d'utilitat per utilitzar Glade
Glade = None
# constructor
def __init__( self ):
# carrega la definició de la GUI
# i el posa en l'objecte Glade
self.Glade = gtk.Builder()
self.Glade.add_from_file( "/media/DISC57GB/wk-python/ProvaGUI/src/prova01.glade" )
# assigna events de la GUI a mètodes
dic = {
"on_button2_clicked" : self.quit,
"on_button1_clicked" : self.Mostra,
"on_windowMain_destroy" : self.quit,
}
# els connecta
self.Glade.connect_signals(dic)
# executa la GUI
# carrega la finestra
self.window = self.Glade.get_object('dialog1')
# la mostra
self.window.show_all()
# i inicia el dispatcher,
gtk.main()
# mètode Mostra
# agafa el text de l'Entry2 i el posa a l'entry1 afegint-li un text de sufix
def Mostra(self, widget):
# és interessant veure com obté el widget i les seves propietats
# self.wTree.get_widget("entry11").get_text()
self.Glade.get_object("entry1").set_text(self.Glade.get_object("entry2").get_text() + " Passa a 1")
# mètode sortir
def quit(self, widget):
sys.exit(0)
# El main
# senzillament, executa el constructor
gui = CGui()
Des d'Anjuta es pot executar l'aplicació i obtenim el resultat esperat.
Efectivament, la parella Glade i Python, combinats a l'IDE Anjuta mereix amb tots els honors el qualificatiu de RAD.
Un IDE alternatiu a l'Anjuta és Eclipse amb el plugin PyDev.
En realitat Glade es pot combinar amb d'altres llenguatges com C/C++, o Java. Tanmateix, la combinació amb Python ofereix alguns avantatges que cal tenir en compte.
la combinació de Python amb Glade ofereix un avantatge fonamental: Python és un llenguatge interpretat d'script. És adequat, per tant, per a l'automatització flexible de processos, diguem-ne macros, i per a tasques d'administració.
Python es pot trobar com llenguatge de macros en diverses aplicacions, com l'OpenOffice, o el Gimp. Amb tot, Python és molt potent, i prou senzill, com per a que se'l trobi en d'altres ambients.
El que faré en l'exercici que presento és crear una GUI amb Glade i connectar-la a un script Python.
L'entorn en el que desenvolupo és un Ubuntu 10.10, Lucid Lynx. Amb Python 2.6 i amb Glade 3.6.7. Faig servir com IDE l'Anjuta 2.30.1.0.
Primer de tot amb l'Anjuta creo un projecte de tipus Python:
Li indico la carpeta de projecte.
Som-hi: afegeixo una pantalla d'interfase gràfica: Fitxer - Nou - Fitxer del Glade.
S'obre la finestra de preferències per a la interfície gràfica. En aquesta primera pantalla el que cal és assegurar-se que és fer servir el GtkBuilder, L'altre opció, LibGlade, està "deprecada". En principi, com no sigui pel fet d'haver de desenvolupar o mantenir interfases en versions antigues de GTK, la LibGlade no l'hauria de fer servir.
Un cop assegurat que el format és del GtkBuilder s'obre el dissenyador d'interfícies. Faig una interfície senzilla com la de la imatge. La he creat a partir d'una finestra de tipus diàleg que ja em proporciona un parell de botons. El nom de la finestra és dialog1. El posa automàticament el Glade. Podré comprovar-ho en revisar el fitxer generat.
He afegit un layout del tipus Vertical Box amb tres files. A la de dalt he posat un label per al títol (label1), a la del mig un camp d'entrada de text (entry1) i a la de sota, un altre camp d'entrada de text (entry2).
El que faré ara serà assignar als l'event clicked de cada botó una funcions que serà el seu "event-handler". És tan senzill com indicar-ho a les propietats.
Al boto1 li assigno l'event-handler on_button1_clicked i al botó 2 el on_button2_clicked
Deso el fitxer generat. És interessant revisar-ne el contingut amb un editor de text.
<?xml version="1.0"?>
<interface>
<requires lib="gtk+" version="2.16"/>
<!-- interface-naming-policy project-wide -->
<object class="GtkDialog" id="dialog1">
<property name="border_width">5</property>
<property name="type_hint">normal</property>
<property name="has_separator">False</property>
<child internal-child="vbox">
<object class="GtkVBox" id="dialog-vbox1">
<property name="visible">True</property>
<property name="spacing">2</property>
<child>
<object class="GtkVBox" id="vbox2">
<property name="visible">True</property>
<child>
<object class="GtkLabel" id="label1">
<property name="visible">True</property>
<property name="xalign">0.47999998927116394</property>
<property name="label" translatable="yes">Una prova amb Glade + Python</property>
</object>
<packing>
<property name="position">0</property>
</packing>
</child>
<child>
<object class="GtkEntry" id="entry1">
<property name="visible">True</property>
<property name="can_focus">True</property>
<property name="invisible_char">●</property>
</object>
<packing>
<property name="position">1</property>
</packing>
</child>
<child>
<object class="GtkEntry" id="entry2">
<property name="visible">True</property>
<property name="can_focus">True</property>
<property name="invisible_char">●</property>
<property name="text" translatable="yes">AAAA</property>
</object>
<packing>
<property name="position">2</property>
</packing>
</child>
</object>
<packing>
<property name="position">1</property>
</packing>
</child>
<child internal-child="action_area">
<object class="GtkHButtonBox" id="dialog-action_area1">
<property name="visible">True</property>
<property name="layout_style">end</property>
<child>
<object class="GtkButton" id="button1">
<property name="label" translatable="yes">Acció</property>
<property name="visible">True</property>
<property name="can_focus">True</property>
<property name="receives_default">True</property>
<signal name="clicked" handler="on_button1_clicked"/>
</object>
<packing>
<property name="expand">False</property>
<property name="fill">False</property>
<property name="position">0</property>
</packing>
</child>
<child>
<object class="GtkButton" id="button2">
<property name="label" translatable="yes">Sortir</property>
<property name="visible">True</property>
<property name="can_focus">True</property>
<property name="receives_default">True</property>
<signal name="clicked" handler="on_button2_clicked"/>
</object>
<packing>
<property name="expand">False</property>
<property name="fill">False</property>
<property name="position">1</property>
</packing>
</child>
</object>
<packing>
<property name="expand">False</property>
<property name="pack_type">end</property>
<property name="position">0</property>
</packing>
</child>
</object>
</child>
<action-widgets>
<action-widget response="0">button1</action-widget>
<action-widget response="0">button2</action-widget>
</action-widgets>
</object>
</interface>
A partit d'aquí ja tenim la GUI preparada, ara cal connectar-la a l'script Python que la mourà. Vet aquí l'script:
Primer de tot, el preparo per a poder executar des de línia de comandes. També li indico que l'encoding per defecte serà el latin-1. Això és important per a poder escriure literals en català. A partir d'aquí, les explicacions es troben als comentaris del codi:
#!/usr/bin/python
# coding: latin-1
#Importo el paquets de Gtk, PyGtk i Glade
import sys
import pygtk
import gtk
import gtk.glade
#Creo una classe que gestionarà la GUI. Serà el controlador bàsic.
class CGui:
# propietats
# Un objecte d'utilitat per utilitzar Glade
Glade = None
# constructor
def __init__( self ):
# carrega la definició de la GUI
# i el posa en l'objecte Glade
self.Glade = gtk.Builder()
self.Glade.add_from_file( "/media/DISC57GB/wk-python/ProvaGUI/src/prova01.glade" )
# assigna events de la GUI a mètodes
dic = {
"on_button2_clicked" : self.quit,
"on_button1_clicked" : self.Mostra,
"on_windowMain_destroy" : self.quit,
}
# els connecta
self.Glade.connect_signals(dic)
# executa la GUI
# carrega la finestra
self.window = self.Glade.get_object('dialog1')
# la mostra
self.window.show_all()
# i inicia el dispatcher,
gtk.main()
# mètode Mostra
# agafa el text de l'Entry2 i el posa a l'entry1 afegint-li un text de sufix
def Mostra(self, widget):
# és interessant veure com obté el widget i les seves propietats
# self.wTree.get_widget("entry11").get_text()
self.Glade.get_object("entry1").set_text(self.Glade.get_object("entry2").get_text() + " Passa a 1")
# mètode sortir
def quit(self, widget):
sys.exit(0)
# El main
# senzillament, executa el constructor
gui = CGui()
Des d'Anjuta es pot executar l'aplicació i obtenim el resultat esperat.
Efectivament, la parella Glade i Python, combinats a l'IDE Anjuta mereix amb tots els honors el qualificatiu de RAD.
Un IDE alternatiu a l'Anjuta és Eclipse amb el plugin PyDev.
Subscriure's a:
Missatges (Atom)