Otavio Salvador wrote:
Sven Luther <sven.luther@wanadoo.fr> writes:On Wed, Oct 18, 2006 at 11:06:08AM +0200, Attilio Fiandrotti wrote:-- *Useless* with the current partitionerSub-optimality of standard partitioner is something i've heard many people complaining about. I know xavier oswald once started porting gparted from c++ to plain c: i checked out the svn repo some times ago and found a lot of code was already written. Is someone still working on this? Would a gparted-like partitioner be useful for post-etch? (That's basically a lot of GTK programming, i could work on it too)Another solution is to use gparted and the C++ libraries which go with it. I know that there is a dogma of not using c++, but given the development ongoing on gparted, and that we would basically need to do fork all that development if we want to do our stuff. Adding C++ libraries will add more or less 1MB to the image.I'm not sure that will be just that the needed space for the whole C++ code to be in d-i.
To use GTK in C++ we should also provide GTKMM, and some times ago one of DFB developers reported [1] his own painful experience in porting GTKMM for GTKDFB
From d-i point of view, I think it (use of another partitioner) wouldmake things harder to evolve together since the new features would need to be add in partman and <your pet graphical partitioner here>. I don't know what others thing about this but I think would be better to have a common partitioner for all frontends to avoid that kinda of complication in D-I release and development.
Something still far from GParted, but more user-friendly than current partitioner, would pheraps be possible to obtain if we add to the DEBCONF protocol a command to produce trees. The trees the GTK frontend produces to display countries as leaves to continents and partitions as leaves to disks are just SELECT questions displayed differently.
My two cents for the after-Etch.. cheers Attilio [1] http://mail.directfb.org/pipermail/directfb-users/2006-May/001892.html