Re: Graphical D-I test install
Otavio Salvador wrote:
Sven Luther <firstname.lastname@example.org> writes:
On Wed, Oct 18, 2006 at 11:06:08AM +0200, Attilio Fiandrotti wrote:
-- *Useless* with the current partitioner
Sub-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
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  his own painful experience in porting
GTKMM for GTKDFB
From d-i point of view, I think it (use of another partitioner) would
make 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
My two cents for the after-Etch..