In its latest release, 0.5.3, there is a tool to split XML files of any size in smaller fragments. It is also possible to examine a fragment at time in the user interface, without loading it completely in memory.

You can download QXmlEdit at the following link: http://code.google.com/p/qxmledit/downloads

This little tutorial, extracted from the manual, shows how to use the file splitter in details:

When starting, the program will open a welcome dialog leading to the most common operations. Choose “Split a file”. If you choose to hide the dialog next time the program restart and change your mind, you can reactivate it in the configuration panel. You can access this feature also from the menu Tools.

Decide if you want to extract the information or navigate them

If you want only navigate the data without creating any files, uncheck ‘Extract Documents‘. Even if you don’t extract the XML fragments into smaller file, QXmlEdit scans the file and records the fragments for a review.

Choose the file and how to fragment it

Browse to the file to examine, the insert the XPath that identifies a fragment. Insert a string of the form /ROOT/DATA and so on.

Limit the extracted fragments number

Selecting a range permits to extract only a small subset of the original file. You are not obliged to waste space on your disk if you want only a single fragment.

Decide the output folder and the naming

Enter the location where write the extracted fragments and decide if you want to create a folder each N files. Decide also how to name the files and the folders. The combo boxes have some predefined values to ease the task, like a timestamp, or a progressive counter.

Go and examine data

After the start of the operation, in the the main window a navigation box appears. The XML fragments found in the input file are accessible directly with a random access using the information collected in the previous phases. If you choose to split the file in fragments, you can examine them in the extraction directory.

Il cambio di un dirigente di una ditta non ha solitamente grosse ricadute sugli utenti ed in certi casi neppure sulla vita della ditta stessa, ed il fatto che le ditte sopravvivano ai propri amministratori ne è una prova.

Steve Jobs è stato un’eccezione e con lui rischia di scomparire un parte di quello che ha reso il personal computer affascinante, almeno per chi è appassionato di tecnologia.

Chi ha iniziato ad usare i personal computer da piccolo, ha vissuto l’epoca degli 8 e dei 16 bit, con macchine che pur differenziandosi per potenza, dal mondo dell’hobbistico al professionale, si assomigliavano tutte nel modello di utilizzo e di programmazione. La differenza la facevano le periferiche disponibili ed il software per gestirle (chiamarli driver sarebbe forse troppo). Un hard disk ed un buon alimentatore differenziava le macchine di fascia alta da quelle di uso casalingo.

Era possibile scrivere simulazioni, risoluzioni di problemi matematici, piccoli database in Assembler, Basic o Pascal. All’uscita di un nuovo modello ci si procurava i manuali del relativo microporcessore e dell’immancabile versione di Basic per poter programmare, come quando dovendosi recare in un Paese straniero, ci si premura di procurarsi un dizionario ed un manuale di conversazione.

L’avvento dei sistemi ideati da Jobs ha cambiato tutto.

All’uscita del Macintosh in Italia, cercando i manuali del suo Basic, per capire come fosse possibile realizzare un programma come Mac Paint, restai allibito davanti ai volumi di Inside Macintosh.

Non si trattava solo di un sistema con un’interfaccia utente mai vista prima, di una grafica che sembrava uscita da una tipografia, ma anche dell’organizzazione della documentazione, finalmente fuori dai binari di una raccolta di trucchetti, e di come veniva teorizzata la via per scrivere i programmi, del primo tentativo di programmazione object oriented diffusa al di fuori dell’accademia.

Si trattava di tutto quanto assieme, un salto di una decina di anni avanti a tutto quello che era apparso fino a quel momento, quasi in ogni particolare della macchina, ahimè anche nel prezzo, decisamente fuori portata per le tasche di molti, me compreso.

Più tardi appresi che la macchina era curata anche al suo interno, in luoghi che l’utente non avrebbe mai raggiunto (si veda la storia su http://folklore.org/StoryView.py?project=Macintosh&story=PC_Board_Esthetics.txt).

Qualche tempo più tardi, al mio primo lavoro, parlando dell’argomento, un ingegnere mi disse letteralmente “real programmers don’t use icons”. Oggi tutti i sistemi sono essenzialmente dei Macintosh, perfino i telefoni.

Quando uscì il NeXT, forse il capolavoro di Jobs, abituato ai sistemi che le altre ditte comunemente costruivano per il mercato professionale, mi chiesi come fosse possibile avere pensato così in grande nel produrre qualcosa che comunque era soggetto alle regole di mercato e come mai nessun altro lo avesse fatto.

Il NeXT era esagerato in tutto e, come al solito, anni avanti agli altri sistemi, soprattutto nel software. Il Macintosh di oggi non è che la sua evoluzione adattata ai tempi.

I sistemi progettati da Jobs sono sempre stati innovativi e curati con perfezione maniacale. Se pure Jobs non ha scritto una riga di codice, la sua mano si vede in ogni prodotto che è sempre un piccolo gioiello.

Jobs è stato non solo geniale, ma ha segnato il proprio tempo con visioni che andavano al di là del presente. Come lui, nel suo campo sono stati, ognuno a modo suo ed in misura diversa, pochi altri: Clive Sinclair, Richard Stallman, Linus Torvalds, Alan Kay, Jay Miner fra quelli che conosco.

Quello che Jobs ci ha insegnato è che anche nel mondo del lavoro, a volte così concreto da sfiorare la grettezza, è possibile realizzare qualcosa di solido e di elegante, che va al di là di quello che sembra possibile quando ci si accontenta di fare quello che si è sempre fatto, perché si è sempre fatto così.

A proposito di Jobs mi sembra giusto chiudere con una citazione da “Cena ad Audoghast” di B. Sterling:

 “Non mi fiderei di nessun indovino del commercio. Per conoscere il mercato bisogna conoscere il cuore della gente, e per questo occorre un buon poeta.”

The navigation is possible in two ways:

• Double clicking an item on the types list centers the relative item in the graphics view.

• Selecting an item with a reference to a type in the graphics view and using the context menu.

While jumping from a type to another one, the previous item is remembered and it possible to return to it as is usual with Internet browsers.

A bonus of the navigator is the possibility to export the graphical view in SVG or PDF format.

The types and elements can be searched and the navigation panel can be hidden to leave all the available space to the schema representation.

The navigator is now accessible directly from the main window if the content declares itself as a XML Schema type file.

XSD viewer screenshot

What’s really difficult in such a program is to establish a mapping between the images that the program provides and the concepts that the user has in mind when interacting with them. This mapping is even more difficult if the viewer will be transformed in an editor in some future.

The program needs a cut, it is important to determine which are the main concepts to show and what needs to be removed from the scene. If all the objects defined by the language have the same importance, the scene will be filled with a lot of informations, hiding the basic concepts that the user is trying to model, making the visual editor almost useless compared to a text-based editor.

To achieve this goal, some information, especially those relating to the elements and the types must be automatically and silently changed as the user decides to change the relationship graphically.

A small change in terms of visual representation, such as adding an attribute to an element, has great implications in terms of XSD syntax. When the user decides that an element can have an attribute, the semantic change is very small, but for the scheme it may involve the transformation of a simple type in a complex one.

To access the XSD Viewer in QXmlEdit, load a XSD Schema file in the editor, then use the Tools > Plugins > XSD Viewer menu.

The data presentation in a Qt Item View like a TreeView or a TableView is made by means of components that implement a QAbstractItemDelegate interface.

Write a custom delegate to gain full control on how the data are rendered forces us to face all the subtle details and intricacy of the measuring and styling of graphics items with the risk of producing a component that does not fit well with the style used in the host system. Moreover, speaking in a C++ term, we don’t know what is the base class that a particular view is using, so we can’t subclassing it to alter its behavior.

If our needs are limited, for example, to display a decoration over a read only standard item, a simple solution can be to use the existing view delegate to do the hard work, then render the decoration over the painted surface.

We can create a delegate deriving from QAbstractItemDelegate class, inquire the view that we want to manipulate about its actual delegate and store it as an internal variable of the new delegate. Our class can act as a bridge, implementing all the interface functions and the slots of a delegate and redirect incoming calls to the old delegate.

Our class will look like this (some code omitted for clarity)

class ElementItemDelegate : public QAbstractItemDelegate
{
    Q_OBJECT
    QAbstractItemDelegate *baseDelegate;
public:
    explicit ElementItemDelegate(QAbstractItemDelegate *newBaseDelegate, QObject *parent = 0);
    virtual ~ElementItemDelegate();
    virtual QWidget * createEditor ( … ) const;
    virtual bool editorEvent ( );
    virtual void paint ( ... ) const;
...
};

At the window creation we can retrieve the actual delegate from e. g. a tree widget and pass it to our delegate:

void MainWindow::setUpDelegates()
{
    QAbstractItemDelegate *oldDelegate = treeWidget->itemDelegate();
    ...
    ElementItemDelegate *newDelegate = new ElementItemDelegate( oldDelegate, this );
    ...
    treeWidget->setItemDelegateForColumn(0, newDelegate);
}

Each incoming call to our delegate is then redirected to the existing delegate.
The only method we are interested about is the paint() one. We let the old delegate do the hard work, then we paint:

void ElementItemDelegate::paint ( QPainter *painter, const QStyleOptionViewItem & option, 
   const QModelIndex & index ) const
{
    QStyleOptionViewItemV4 option4(option);
    // call the default delegate
    baseDelegate->paint(painter, option, index );
    Element * element = Element::fromModelIndex(index);
    if( NULL != element ) {
        QRect markRect = option.rect;
        if( option4.viewItemPosition == QStyleOptionViewItemV4::Beginning ) {
            markRect.setLeft(0);
        }
        markRect.setWidth(WIDTH_BAND);
        if( element->saved() ) {
            painter->fillRect(markRect, savedBrush);
        } else if ( element->edited() ) {
            painter->fillRect(markRect, editedBrush);
        } else {
            painter->fillRect(markRect, normalBrush);
        }
    }
}

Un politico influente, attualmente in crisi, ha cercato di ingraziarsi i propri sostenitori attaccando la scuola pubblica italiana.

Non si può tacere di fronte ad una cosa del genere; la convinzione che la scuola pubblica appartenga ad una parte politica e come tale vada combattuta, è preoccupante.

Per fortuna sabato si è tenuta una manifestazione in favore della scuola pubblica in diverse città italiane

Alla manifestazione cui ho assistito ho visto solo presone che sembravano appartenere alla categoria dei docenti e mi sono chiesto dove fossero gli altri e perché la cosa non interessasse tutti.

La vista dei professori che indossavano sulle spalle la bandiera italiana mi ha fatto ricordare di quando da piccolo vedevo i lavoratori vestire nello stesso modo la bandiera rossa, ed ho realizzato quanto abbiamo perso in questi anni se la bandiera nazionale è diventata solo uno stendardo di parte.

Ma solo ai docenti deve interessare questo argomento?

Fra i primi danneggiati da una scuola elitaria ci sono gli imprenditori che vedranno ridotto, ad esempio, il numero di ingegneri bravi e motivati tra cui reclutare i nuovi assunti dato che si restringerà la base di chi può permettersi di frequentare l’università. Saranno costretti a reclutare gli ingegneri all’estero, in Paesi (Cina, …) in cui comunque la formazione è delegata alla scuola pubblica.

L’idea della scuola pubblica sopravvisse perfino alla restaurazione sopraggiunta alla fine del periodo napoleonico, perché ci si accorse che è un valore.

La scuola pubblica è una conquista e non un danno per il Paese.

One of QXmlEdit peculiar characteristics is the possibility to change the quantity and the type of informations shown on a XML file to examine it from various prospectives.

If the XML file is very large and complex it happens to focus on some details missing the big picture. Let us take for example a Qt user interface file, we can face the following situation:

it is very difficult, at least for me, to follow the widgets’s structure or differentiate between them. As a first help we can activate a display style that can list in the space reserved to element tag name, the value of one or more attributes that can characterize the element itself. The predefined style provided with QXmlEdit installer displays near to the element tag, the value of ‘name’, ‘id’ or ‘build’ attributes, if any. The styles can be created and installed by the end users; they can be applied using the ‘paint can’ icon button at the bottom right of the data tree.

The style makes the visualization more intuitive and the data structure stand out very quickly.

To solve the problem of seeing the element text together with his tag, we can activate the compact view visualization as shown in the following screenshot. The text, if present and if no attributes exist, appears in the column reserved to the attributes with a different color.

We can have an overview of the XML file while maintaining the desired level of detail.

It is very easy to use, but you should remember that it is a very simple tool and not a full fledged IDE.

The plugin can be activated via ‘Tools’ menu, as in the following screenshot:



The plugin window is divided in two: the upper part is dedicated to the Balsamiq sources to translate, the bottom one contains the destination directory where a MXML Application file is generated for each selected source file.

The translation is done by transforming the source using templates that can refer original attributes or calculated fields.

Data bound controls are supported by generating data sources as mx:Array containing mx:Object in a global section.

Not all Balsamiq controls are supported, only a subset of most commonly used ones, controls not supported are converted to mx:Label

List of supported controls:

• Button

• Label

• LinkBar

• DataGrid

• List

• TabBar

• VRule

• HRule

• TextInput

• ComboBox

• TextArea

• Paragraph

• CheckBox

• RadioButton

• Tree

]]> http://lbell.wordpress.com/2010/09/24/generate-flex-code-from-balsamiq-mockup-sources/feed/ 0 lbell balsamiq1 balsamiq2 http://lbell.wordpress.com/2009/11/16/sfruttare-il-system-tray-per-controllare-i-job-di-kde/ http://lbell.wordpress.com/2009/11/16/sfruttare-il-system-tray-per-controllare-i-job-di-kde/#comments Mon, 16 Nov 2009 22:07:47 +0000 lbell http://lbell.wordpress.com/?p=169 ]]> Una delle funzionalità offerte da KDE4 a sviluppatori ed utenti è quella di gestire i lavori a lungo termine delle applicazioni mediante un componente del vassoio di sistema. L’infrastruttura mette a disposizione dell’utente un unica locazione dalla quale può controllare l’andamento delle operazioni, opzionalmente sospenderle, sbloccarle o controllarne l’esito anche dopo il loro termine. Si evita così che ogni applicazione che intende avvalersi di questa funzionalità debba implementare una interfaccia di controllo. Dal punto di vista del programmatore, la fatica di imparare una nuova serie di API è ripagato dal fatto che è l’ambiente a prendersi in carico il compito di interagire con l’utilizzatore, sia per quello che riguarda l’aspetto funzionale, sia per l’interfaccia utente. Ovviamente i soli lavori di cui dovrà essere notificato lo stato di avanzamento mediante questa caratteristica sono solo quelli a lungo termine, per evitare di confondere l’utente con una miriade di messaggi irrilevanti.

Vediamo ora come si può sfruttare questa funzionalità:

Le applicazioni che intendono sfruttare il sistema di notifica devono incapsulare direttamente o indirettamente l’attività in una struttura KIO::Job, ad esempio derivando da essa la nostra classe di esempio KJobTest.

	#include <kjob.h>
	class KJobTest : public KIO::Job

Se si desidera che l’utente, una volta comparsa la notifica, possa mettere i lavori in pausa, riprenderli o annullarli occorre, nella nostra classe, chiamare la funzione

    setCapabilities()

cui va passato come argomento un insieme di flag che ne determinano il comportamento. Con il valori Kjob::Suspendable si concede all’utente la possibilità di sospendere un lavoro, con KJob::Killable anche di terminarlo. Per abilitare entrambe le funzionalità, scriveremo:

    setCapabilities(KJob::Killable|KJob::Suspendable);

Quando si è pronti per presentare il job all’utente, lo si deve registrare presso una struttura globale:

	KIO::getJobTracker()->registerJob(m_jobTest);

Da questo punto in poi il job è visibile all’utente. Emettendo il segnale ‘infoMessage‘ si può forzare il pannello a mostrare la descrizione desiderata per indicare il proprio job.

Il job può essere attivato in modalità sincrona o asincrona. Nel primo caso tutto quello che dovrà fare l’applicazione per gestire il job sarà richiamarne il metodo ‘exec‘, definito nella classe base, che restituirà l’esito mediante un valore booleano. Dietro le quinte verrà attivato un loop di messaggi nascosto. Riporto l’esempio di utilizzo definito nella documentazione KDE:

void SomeClass::methodWithSynchronousJobCall()
 {
   KJob *job = someoperation( some parameters );
   if ( !job->exec() )
   {
       // An error occurred
   }
   else
   {
       // Do something
   }
 }

Nel caso si intenda utilizzare il job in modo asincrono, metodo preferito per la gestione di operazioni a lungo termine, occorre attivare il job attraverso il metodo start(), richiamato in modo nascosto anche nel caso sincrono, e mettersi in attesa dei risultati collegando il segnale ‘result‘ ad uno slot. Ecco l’esempio relativo, sempre tratto dalla documentazione KDE:

 void SomeClass::methodWithAsynchronousJobCall()
 {
   KJob * job = someoperation( some parameters );
   connect( job, SIGNAL(result(KJob*)), this, SLOT(handleResult(KJob*)) );
   job->start();
 }
 void SomeClass::handleResult( KJob *job )
 {
   if ( job->error() )
       doSomething();
 }

Nel metodo start(), da reimplementare nella nostra classe derivata da KJob, occorre utilizzare un meccanismo asincrono, come ad esempio un timer di tipo oneShot, per innescare il job, per evitare che un’attivazione direttamente nella funzione start() provochi un malfunzionamento della gestione sincrona del job attraverso la funzione exec(), per motivi derivanti dall’implementazione della funzione exec stessa. Se abbiamo deciso di non utilizzare mai l’interfaccia sincrona potrebbe sembrare una precauzione inutile, ma scrivendo codice che si deve integrare in un ambiente, occorre sempre rispettarne i dettami.

Quando l’utente decide di intervenire nella vita del job cambiandone lo stato, il pannello del vassoio di sistema richiamerà metodi doSuspend(), doResume() e doKill() del nostro job, mediante i quali si potranno realizzare le dovute azioni.

Durante il suo ciclo di vita, il job può inviare al pannello segnali riguardo il proprio stato o la percentuale di avanzamento.

Emettendo il seguente segnale:

emit infoMessage(job, messageText, messageRichText );

si può provocare la comparsa della scritta relativa allo stato puntuale del job. Allo stesso modo è possibile inviare informazioni relative alla velocità attuale ed alla unità di misura utilizzata, nel caso sia compresa tra quelle dell’enumeratore ‘Unit’ di KJob.

Come esempio di utilizzo possiamo utilizzare un semplice programma, jobsample, mediante il quale è possibile provare le tecniche esposte, configurare i parametri principali a disposizione di un job ed osservare i risultati.

I sorgenti di jobsample sono disponibili a questo indirizzo:

http://www.tsc4.com/lbell/presentazioni/src/jobsample.tgz

Finestra principale di jobsample:

job sample in esecuzione:

module qt-copy
	#opzioni di compilazione
	configure-flags -system-zlib -qt-gif -system-libjpeg -system-libpng \
			-no-exceptions -fast -debug -dbus \
	            -no-phonon # Phonon built separately
	make-options -j2

	# opzioni di gestione git
	branch 4.6-stable-patched
	repository http://git.gitorious.org/+kde-developers/qt/kde-qt.git
end module

Sito di kdesvn-build:

http://kdesvn-build.kde.org/releases/kdesvn-build-1.10.php