Re: Project name



On Tue, 30 Aug 2005, Peter Nugent wrote:

> Just in case this is not a joke, in my opinion the project name should
> relate to what we're doing , not the name of my favourite opera,
> children, football team or the like

I don't agree.  It's a name afterall, not an acronym, summary, or
description.  Think like cairo, poppler, evince, enchant, etc.
Most of them were chosen after the "related" namespace was
exhausted by other projects: xpdf, libxpdf, pdflib, gpdf, kpdf,
apdf, vpdf, viewpdf, pdfkreator, ... and spell, ispell, pspell,
aspell, rspell, hspell, jspell, xspell, rspell, tspell, uspell,
gtkspell, abispell, spellchecker, ... (source: freshmeat.net)



See:

- libi18n, a module in Mozilla:
  http://www.google.ca/search?q=libi18n

- glocale, apart from being Bruno's code in gettext already,
  slackware package for glibc locale data:
  http://slackware.osuosl.org/slackware-8.0/slakware/d1/diskd1


I picked giovanni through grep '^g.*n' /usr/share/dict/words
BTW, and thing it's as good as a name should be, pleasing, easy
to remember, and unique.


I will bang my head against the nearest wall the next time I see
somebody starting a library named with the "free" prefix.  That
made a lot of sense in 80s, but even then RMS was wise enough not
to do that!



behdad



> Peter
>
>
>
> Behdad Esfahbod ha scritto:
> >
> > I declare my final suggestion on the name: giovanni.
> > Think Don Giovanni, use your imagination ;-).
> >
> > And lets not add a lib prefix, since we pretty much may want to
> > include applications in it (the user configuration applet, etc.)
> > We work in the giovanni module.  Inside that, the libraries go
> > into libsomething.
> >
> > I suggest we follow the Glib/Gtk+ naming convention and prefix
> > all libraries involved with the same major prefix.  That makes
> > users feel they are using one unified library, which is good.
> > The prefix then can be gvni for example, gvni_locale_foo,
> > gvni_unicode_bar, gvni_cldr_lowlevelfoo, etc...
> >
> > Vote in.
> >
> >
> > On Mon, 2005-08-29 at 14:46 +0200, Bruno Haible wrote:
> >
> >>The desire to not use glib is not a joke:
> >>...
> >>hence a dependency on a desktop GUI library is not welcome.
> >
> >
> > Just for the record, I should mention that glib is by no means a
> > GUI library.  It's a C convenience library, which is much
> > appreciated as soon as you write your first application based on
> > it.  This happened for me in the past couple of weeks, and I
> > cannot imagine myself writing applications from scratch without
> > using it.  Just to list a few features that I used from glib:
> >
> >   - GHashTable: Hash tables.
> >   - GSList: Linked lists.
> >   - GKeyFile: .ini-like config file handling.
> >   - GMainLoop: Main loop with timeouts.
> >   - GString: autoresized strings.
> >   - GIOChannel: line-oriented file IO with automatic buffer management.
> >   - GLog: log level/message handling.
> >
> > and going to switch from getopt to GOption pretty soon.  These
> > makes life with C quite a lot easier.  Remember how much time you
> > have to spend on simply formatting and updating the output of
> > --help from your program?  Or autoresizing your buffers?  Glib
> > provides pretty much what is granted with almost every other
> > programming language, with a low overhead.
> >
> > --behdad
> > http://behdad.org/
> > _______________________________________________
> > locale-list mailing list
> > locale-list gnome org
> > http://mail.gnome.org/mailman/listinfo/locale-list
>
>

--behdad
http://behdad.org/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]