Certo, esistono Gparted e Qtparted, d’accordo, ma quanti di voi hanno sempre pensato che mancava un partizionatore nativo per KDE, qualcosa che si integrasse alla perfezione con il desktop e con i framework che lo costituiscono? Beh io sono uno di quelli, e per fortuna non sono l’unico ;)
Ad esempio uno che ne ha sentito l’esigenza è l’autore di questo spettacolare KDE Partition Manager1 (da qui in poi KPM), che è spuntato dal nulla in versione nominalmente instabile, ma in realtà decisamente usabile. Per completare il quadro dei personaggi, un altro che aspettava un progetto del genere èDario “drf” Freddi, già nel team di Raptor (cfr “Risorge Raptor, ed è (quasi) tutto italiano!”), già autore di PowerDevil (cfr “PowerDevil, gestione dell’alimentazione in KDE4”) ;)
Bene, succede che il nostro italianissimo drf in una uggiosa giornata di fine settembre incontra a Gardaland (!), in circostanze che non ci è dato sapere, il fino ad allora ignoto sviluppatore tedesco di KPM, approcciandolo presumibilmente sulle montagne russe. Potete immaginare con me la confusione in quel frangente:
drf: «KDE Partition Manager spacca di brutto!»
VL: «Was!?»
drf: «Ah, … piacere, io Dario»
VL: «…»
drf: «…dicevo, KDE Partition Manager rulla abbestia!»
VL: «Was hast Du Gesagt!?»
drf: «sì, io Dario “drf” Freddi!»
Eccetera eccetera2. Dopo innumerevoli tentativi i due sono riusciti a capirsi. È spuntato fuori che lo sviluppatore di KPM come professione lavora con le Qt, e a sentire Dario si vede: «funziona da dio e la qualità del codice è eccelsa». A quanto pare anche lui sentiva la mancanza di un’applicazione KDE per gestire le partizioni, quindi l’ha scritta ;)
Dario ha colto la palla al balzo: gli ha proposto di attivare un account svn e mettere KPM in playground, cosa che è già in corso di attuazione! Una volta che i sorgenti saranno nel repository ufficiale di KDE, il nostro ha già alcune idee su come miglioralo: «voglio sostituire quell’orrida treewidget con un bel delegate, per avere una lista simile a quella dei pluginloader e poi mi son già messo d’accordo con lukas per un par di migliorie grafiche». Ci piace!
Visto che si parlava di un’app integrata in KDE gli ho chiesto: «non ha niente a che vedere con solid, visto che poggia su libparted, no?» e la risposta è stata: «esattamente, anche perchè al momento solid non ha nessuna interfaccia che permetta una cosa simile, però è un bel suggerimento decisamente… ne parlerò con ervin». Ehi, certo che a volte mi stupisco di me stesso :D
Viva i KDE System Tools e benvenuto a KDE Partition Manager! ;)
Note all'articolo
- Non so se sia il suo nome, ma su kde-apps risulta com Volker Lanz, e questa è la pagina del progetto [↩]
- Mi perdoneranno i veri protagonisti (cmq Dario è un tipo molto simpatico) ma ovviamente è tutta fiction! :D [↩]
Bello, entusiasmante, e poi con la storiella cucita attorno :D
@felipe
Ma sai che dove lavoro ho appena concluso un progetto fatto interamente con le QT(3)? Mi sa che ora che sto iniziando a maneggiarci bene con ste librerie, dovrei dare anche io il mio contributo alla comunità…
Sono molto contento di vedere una cosa del genere!
Good job!
ma.. ma… sbav!
Felipe il tuo Maxtor è una roccia. :-)
certo che riscrivere un software delicato come un partition manager solo perchè gparted non usa le librerie grafiche più alla moda mi sembra un controsenso totale.
E’ un software che si usa si e no due volte l’anno e chissenefrega se usa le gtk!
… questa corsa alla riscrittura totale globale non giova a nessuno. SIMMP
@6
perchè devo caricare le gtk se non le ho bisogno?
è giusto che si pensi alla “globalizzazione” del proprio DE è come se io facessi un CMS e poi dico prendete i plugin di wordpress :D ahahaha ma non sta ne in cielo ne in terra…
@ Skyline e Ste
Perchè no? Perchè non potresti scriver un cms come lo vuoi tu, e farlo di modo tale da poter usare anche i plug-in di WP?
è un pò il principio del software libero, non riscrivere sempre la ruota. penso…
In parte sono d’accordo con Ste, non bisognerebbe riscrivere sempre lo stesso programma, anche perchè Gparted è già un buon editor di partizioni, come lo è anche Qtparted (ancora di più!). Più che altro, bisognerebbe tornare a scrivere alcune categorie di software come questi indipendenti dall’interfaccia grafica, quindi solo da linea di comando, e poi a parte l’interfaccia, con le librerie che più si gradiscono: molti software fanno così, e mi sembra la soluzione migliore per non reinventare sempre la ruota.
Ma QTparted non è per KDE? secondo voi non si integra bene?
In ogni caso, qualsiasi software buono, è sempre benaccetto all’intera comunità, quindi benvengano nuovi software! =)
Il giorno che farò toccare il mio partizionamento a qualcosa basato su KDE 4 sarà nel 2020 forse.
@Michele
Ma infatti anche questo usa la libparted, come gli altri. O era proprio quello che stavi dicendo tu?
Felipe aspe fammi capire bene
quanta swap c’hai in quell’hd???
@zidagar:
Sono curioso… che progetto? E perché non in Qt4 :)
@non-c’era-bisogno:
No, non c’era bisogno. Però qualcuno l’ha fatto e questo significa che ho più scelta di applicazioni per il mio desktop preferito. Quindi sono contento :)
@Dass:
Hahaha occhio di lince, quello in realtà non è swap, tempo fa dovevo usarlo per Nexenta o qualcosa del genere ma poi mi sono annoiata ho lasciato perdere a metà strada :)
ti sei annoiata? cara…. lol ;-)
@Dass:
Haha confermo la teoria dell’occhio di lince allora :D
Forse nel mio cervello le vocali in “mi sono annoiato e” si sono fuse in una “a”. Oppure no? :D
@felipe
un sw sviluppato per un dispositivo embedded sulla base di un sw Open Source fatto da Bticino. Il progettto -> http://www.myopen-bticino.it
L’interfaccia grafica è scritta in Qt3, per questo abbiamo (a dir la verità io :D) dovuto lavorare con la serie 3 e non 4. Poi non so come si comporterebbe l’hw con le Qt4…
E ti dirò di più, dove lavoro (e non è una piccola azienda) usiamo moltissime macchine Linux (Debian in particolare) sia come workstation di sviluppo, come macchine server e embedded con tutti sw Open Source e altri sviluppati da noi.
Non ho potuto fare a meno di ricollegare questo articolo a un’altro che ho letto alcuni giorni fa a questo indirizzo: http://www.jbkempf.com/blog/post/2007/02/10/Qt4-Interface
che spiega le motivazioni per cui il progetto VLC è passato dalle librerie wx alle qt. A chi ha 5 minuti e capisce l’inglese consiglio di leggerlo perchè è interessante. Per i pigri posto la traduzione della parte più importante.
“Sono così annoiato dalle guerre tra KDE e Ghome e le librerie grafiche…
Sono anche molto annoiato di vedere due volte lo stesso programma una volta sviluppato con le kde libs e un’altra con le Gnome libs, quando potrebbe essere basato semplicemente sulle Qt libs e le GTK libs. Molte cose dovrebbero essere standardizzate e non dovrebbero “pesare” sul desktop manager… (ndt: in pratica dovrebbero essere indipendenti dall’ambiente grafico)
Per quanto riguarda l’integrazione dell’aspetto (look and feel), quando si usano applicazioni GTK in ambiente KDE, viene utilizzato il motore GTK+ ‘gtk2qt’ che fa si che il Qt di default disegni la vostra applicazione.
Ma, sotto gnome, non esiste un motore ‘qt2gtk’ che faccia altrettanto per integrare l’aspetto facendolo disegnare alle librerie GTK+! Perchè?”
Devo dire che pur essendo io più tollerante del tipo che ha scritto queste frasi, non posso dargli torto…
@ tosky
Ma infatti è così tosky: =) 3 programmi che fanno lo stesso…E’ vero come dice felipe che si ha più scelta, ma è anche vero che si disperdono idee ed energie.
Ad esempio Qtparted fa molto di più di Gparted, almeno a quanto mi ricordi io…non vi sembra che questo gap si possa evitare concentrando gli sforzi, dividendoli in backend e frontend?
@Michele
Aspetta, mi sono perso O.o
Il backend, in questo caso, non è proprio la libparted, che fa il lavoro sporco in tutti casi?
sono solo gui
quanto la fate lunga :-)
@ tosky
In effetti, libparted dovrebbe essere solo la libreria alla base del programma, ma ad essa vanno date ancora delle istruzioni per funzionare. Che probabilmente sono scritte tutte nel pacchetto Gparted o qtparted.
Ora pensa invece a questo schema: libparted (libreria) > sulla quale si basa un ipotetico “parted”
il software vero e proprio > infine Gparted o qtparted che sono semplicemente un completamento di parted che creano l’interfaccia grafica con le librerie che si desiderano.
In synaptic ce ne sono di esempio come quello che ho descritto. ora non riesco a fare un esempio, ma è anche quello che si sta cercando di fare con i software web-based, in php, dove si cerca di scindere il più possibile il software dalla grafica, e in questo Smarty o altri template engine ci stanno dando una grossa mano.
Potrei sbagliarmi, e anzi forse lo sto proprio facendo =), ma in ogni caso è un interessante discussione cmq! =) (e come modello di sviluppo non è male)
ma esistono programmi per linux che non sono gui di programmi via shell? :-)
k3b è un esempio molto palpabile, nelle opzioni si può scegliere se dare parametri aggiuntivi a ogni singolo programma testuale su cui si appoggia
penso che in altri casi la cosa sia più “embedded” ma la sostanza non dovrebbe poi cambiare davvero… no?
sono d’accordo: e infatti hai fatto proprio un esempio di programma eccelso…K3b è il top, ed altri come lui, sia in qt che in gtk, non ce ne sono.
Ora la domanda per me è questa: posto che K3b sia scritto indipendente dalle librerie, sarebbe molto più semplice fare un porting di K3b per le librerie Gtk, o continuare a spendere energie sulla miriade di programmi Gtk-based(brasero & co.) che non si avvicinano neanche lontanamente all’ottimo k3b?
il mio non è un disappunto sui vari comunque validi programmi gtk-based, e lungi da me criticare il gran lavoro svolto dai vari team, ma dall’altra parte si è giunti a livelli tali, che è impossibile non fare il paragone ed ambire ad essi =)
P.S. lo stesso non potrebbe valere per amarok? non si potrebbe sperare in un amarogtk?
se tu lo sai fare, e lo vuoi fare, fallo :-)
evidentemente nessun altro ha avuto questa idea e al contempo ne ha le capacità…
per k3b non lo so … ma per Amarok tanto varrebbe rifarlo da capo.
Sono tanti anni oramai che le possibilità offerte dal framework qt influiscono su tutta la progettazione delle applicazioni … non bisogna pensare che siano solo librerie grafiche ed oggi i programmi con una base fortemente indipendente dal framework sono davvero rari.
Basta un esempio … è tutto talmente inperniato su qt … che si sono rimboccati le maniche per portare tutto su windows … come dire che se in un contesto c’è qt, lo sforzo vale la candela … e hanno portato applicazioni che mai si sono sognati di portare in gtk.