Re: [DDR] Re: GNOME Software Map: Reinventing the weel?

[pixel linux-mandrake com]

Matt Wilson <msw@gimp.org> writes:

> Actually, GNOME has had a GUI disk setup tool for ages.  It was
> called gnome-gfdisk written by Maurer Dietmar <dm@vlsivie.tuwien.ac.at>
> A screenshot:
> 
> http://nui.vlsivie.tuwien.ac.at/gfdisk/gfdisk.jpg
> 
> gnome-gfdisk has been in GNOME CVS since around August of 1998.
> Development on it had tapered off, so the disk editing functions were
> taken out and an new front end is mostly written.  It is a GNOME
> Canvas based application, very slick looking IMNSOHO.  A (very
> incomplete) screenshot can be seen:
> 
> http://www.gnome.org/~msw/gnome-ddruid-3.png
> 
> (yes, it's not so colorful at the moment - I'm adding things like
> colored squares based on the partition type in the near future.)
> 
> The GUI front end is going to be the front end (I hope. :) for a new
> combined effort by myself at Red Hat, Andrew Clausen of libresize (the
> algorithms that Pixel's perl code re-implements), and Lennert Buytenhek
> of ext2resize.
> 
> This project has been in planning for a few months.  We're at the
> stage now that we can begin to assemble the three pieces into a very
> impressive disk manipulation package.
> 
> I don't think that the official GNOME disk management program can be
> written sufficiently in perl.  Just because it uses the GTK perl
> bindings doesn't qualify it as being a GNOME program.
> 
> As far as I know, Andrew wasn't contacted by Pixel even after the
> first pass of perl-izing libresize was complete.  This new rewrite has
> effectively branched the libresize code.  So, the re-implementing of
> the wheel has already happened.
> 
> So why haven't you heard about this project yet?  It's not done.
> We're not going to go and publish a press release for half-baked
> software that isn't yet robust enough for general use.  I expect that
> it won't be long until the general API for the library is ready and
> various developers can have a chance to use it.
> 
> Matt
> 

This post is very interesting, thanks for posting this on the diskdrake ml ;-)
This may clear the situation. I've been trying to understand the state of
gnome-ddruid and parted, but that's not clear to me.

As far as i understood, parted is being developed by Andrew and Lennert.
parted would use a replacement of libfdisk written by Matt Wilson.
Then i heard about gnome-ddruid... and then about gnome-parted... which seemed
to be written by Matt Wilson.
The gnome-ddruid has just been removed from the cvs of gnome and been replaced
by parted. gnome-ddruid doesn't seem to be doing anything for the moment (found
in http://www.gnome.org/~msw/). The buttons are there, but that's all.

parted seems to be missing an interface for the moment... But as Andrew told me,
i should keep watching, cuz' it's going to be great :) and i hope so! Diversity
is a good thing in our community. In this manner different ways are tested, and
users have the choice. Of course it wastes some time, but as the source is
available, projects can take advantage of each other.

So i did look around before writing diskdrake, and it seems to me that it's now
the more advanced project. 
Making some fuss around a project is important to show that we (the OpenSource
community) don't have to rely on Partition Magic or System Commander. Making an
announcement before having a stable release is a typical OpenSource way of
doing, calling for help to iron out the bugs! (or maybe i've missed something :)


As for being *The* gnome partionner, i don't see why they couldn't be more than
one. There are at least *6* Mail Clients for the gnome project!! (see
http://www.gnome.org/applist/list-martin.phtml?catno=5)
I don't want to think that gnome is redhat only, that Suse and Caldera are
Kde. Everybody should be able to participate to either projects.

Another thing is the perl that i'm using (everywhere :) 
Why couldn't a perl written application be gnome? For me, gnome always seemed
to be more open to different languages (more than kde). I know writing a
partitionner in perl seems crazy to some. But, in that case, let me say that for
writing a partitionner you just need to be able to open devices and do
read/write/seek!!
I do think using a higher-level language is a strength for a program. In C,
you're stucked all the time with string and list manipulation. Okay, perl is
costly in memory and cpu. But this argument is no good for a partitionner. The
fat_resizer is cleaner in perl than in C (i rewrote it because it was small
enough to be done quickly, the main job of finding the algorithm was already
done by Andrew, thanks to him :).

Using perl i manage to develop much faster and better. When writing C code, i'm
often astonished of the awful way of writing easy things... You end up with
badly written code because you're missing lists, hashes and strings. The
difference is even more important when you're speaking of GUIs. It's no wonder
why tcl/tk, tkinter are well known. It's so much easier!

cu Pixel.


Precision: i do not think that perl is a panacea! i'd love to see some kind of
type inference and static typing added on a subset of perl... Or a java
extension to enable regexps, dynamic scoping, reflexivity, closure and other
functional language stuff (lazy evaluation, map, curryfication) or even
prologisms... ah dreaming... :)