Re: [RFH] libfm package description
Hi Justin,
Thanks for your help.
I answered some questions, but not sure if my point of view is
appropriated and maybe the description need to be adjust also?
Justin B Rye wrote:
> If this was a library to serve the "programming needs" of
> developers, it would belong in libdevel. Describe the function of
> libfm0 for the end users who are going to have it installed:
>
> Description: file management support - core library
I think the library description basicly are for user who has programming
needs as end user won't need to install a library via aptitude, except
he or she has programming needs.
And the library should be installed by selected application which
depends on this library via aptitude for end user.
>> LibFM is a library packaging GLIB/GIO and provide higher level API and
>> related window components as a library for file management programming
>> needs, and make it easy to reuse for other programs.
>
> This again is the wrong content (as well as being obviously
> non-native-speakerish); this stuff about APIs is a completely
> developer-centric description of the library's function.
>
> It wouldn't be hard to fix if I could understand it, but I can't
> make sense of it. What is "a library packaging GLIB/GIO"? How does
> LibFM "provide [an] API and related window components as a library"?
>
> Cutting ruthlessly, I'll suggest:
>
> LibFM provides Glib/GIO file management widgets.
Sorry for the confusion on my bad English. What I want to express is the
libfm integrated GLIB/GIO and provide a higher level API for file
management functions.
>> Features:
>> * Independent to any platform/desktop environment
>
> Pedantically speaking, I'm fairly sure it's dependent on a
> von-Neumann-architecture programmable computer... will it even
> work if I don't have X installed? It requires *some* desktop
> environment, it's just not explicitly part of GNOME.
I believe it would works without X installed, eg: an ncurses-based
application uses it's functions for file management.
> Except that in fact it Depends on libgconf2, libgnome-keyring0, and
> libgvfscommon0, which together pull in so much GNOME stuff that I've
> uninstalled pcmanfm on Squeeze. How does this count as
> desktop-neutral?
I guess you mean the pcmanfm in sid depends on such packages?
Newer pcmanfm(0.9.x) has separated GUI and file management(as libfm)
design. So the depends will be different in libfm.
>> * Use gio/gvfs as same as Nautilus to support remote storage, with
>> faster experience to users.
>> * Support GVFS and remote storage access (Windows SMB, FTP, SFTP,
>> WebDav...)
>
> Merge, Englishify and treat end-users as the default. Also,
> incorporate the line lower down about Trash support:
>
> * Uses GIO/GVFS (like Nautilus) for Trash Can support and access to
> remote file systems (FTP, SFTP, WebDav, Windows shares, etc.);
No question on this part. :)
>> * Fast, low memory usage and low latency which is friendly to less
>> powerful hardware such as netbook and thin client/server.
>
> When you say "low latency", is that talking about *network* latency?
> You've already said libfm's fast... but I can't see how it's going
> to reduce the latency of connections to my file server, or why that
> would be particularly helpful on antique hardware.
The 'low latency' doesn't mean *network* sepcific, it means faster
response generally. I don't know which word is more suitable for this.
> (And why would a thin client *server* be "less powerful hardware"?
> Do you just mean the client?)
>
> * Fast and light on memory usage, which is friendly to less
> powerful hardware such as netbooks and thin clients;
Thin client means all/most of it's applications are running on server.
So it might be suitable to say it's suitable to run on thin client/server?
>> * Trash can support (provided by gvfs).
>
> Absorbed into the GIO/GVFS bulletpoint above.
>
>> * Clipboard operations are compatible for both GTK+, Gnome and QT/KDE
>
> If GTK+ and GNOME are separate options, shouldn't the same apply to
> QT and KDE? Or would it make more sense to say:
>
> * Clipboard operations are compatible with GTK+/GNOME and QT/KDE;
>
>> * Core function separated from GUI, be able reuse with UI toolkit other
>> than GTK+, eg Qt4 or Enlightenment.
>
> This should be explained in terms of what benefit (if any) that
> brings to end users of libfm0. The nearest I can get is
>
> * Reusable design with the core functions separated out to simplify
> porting to other GUIs;
>
> I've left out the names of GUIs that aren't currently supported on
> the grounds that you probably don't want to have to keep editing
> this to keep the list up to date.
You are right. This is a much better description. I like it. :)
>> * Supports Drag and drop handling and supports XDS (X Direct Save).
>
> Abbreviations are pointless if they have to have their expanded
> forms following them around everywhere. Not that X Direct Save is
> much more intelligible than the raw TLA, but never mind.
>
> * Supports Drag-and-Drop, using the X Direct Save protocol.
Much better.
>> * Provides some widgets for file management needs that are missing in
>> GTK+ and glib.
>
> This as far as I can tell is just a restatement of what should have
> been the first line.
>
> (Quite a lot of the above might boil down to a single bulletpoint
> saying "Freedesktop standards-compliant", but I'm not sure how
> much.)
Hum, it's hard to answer very detail here.
Basicly it offer some missing widgets in GTK+ and glib to provide file
management functions, eg: you may do file management within file
selection popup window in GTK+ with this libfm.
>> This package contains the core function library.
>
> That bit's fine. So reshuffling into a more coherent order I get:
>
> Description: file management support - core library
> LibFM provides Glib/GIO file management widgets. Features:
> * Fast and light on memory usage, which is friendly to less
> powerful hardware such as netbooks and thin clients;
> * Uses GIO/GVFS (like Nautilus) for Trash support and access to
> remote file systems (FTP, SFTP, WebDav, Windows shares, etc.);
> * Clipboard operations are compatible with GTK+/GNOME and QT/KDE;
> * Supports Drag-and-Drop, using the X Direct Save protocol;
> * Reusable design with the core functions separated out to
> simplify porting to other GUIs.
> .
> This package contains the core function library.
>
> (With bulleted lists it's nice if you can make them all structurally
> parallel - all adjectival, all nouns, or whatever. Here, I haven't
> managed that, so I'd be glad to see suggestions.)
Good point. And yours are much better than my original one.
>> Package: libfm-gtk0
> [...]
>> Description: libraries for file management programming needs - GTK+ GUI
> [...]
>> .
>> This package contains the GTK+ GUI.
>
> Description: file management support - GTK+ GUI library
> $BOILERPLATE
> .
> This package contains the GTK+ GUI.
>
>> Package: libfm-dev
> [...]
>> Description: libraries for file management programming needs - developments headers
>
> (Well, for a start that's too long. I also notice these packages
> have the word "Features:" in the boilerplate unindented, as if it
> was a field in its own right. Or is that just an artefact of the
> quoted-printable mail format?)
> [...]
>> .
>> This package contains the development headers.
>
> Description: file management support - development headers
> $BOILERPLATE
> .
> This package contains the development headers.
I prefer the same short summary description for each binary package and
with additional description after "-".
>> Package: libfm-utils
> [...]
>> Description: libraries for file management programming needs - utilities
> [...]
>> .
>> This package contains the utilities(demo program).
>
> If this is a single "demo" X executable interesting only to C
> programmers, the package probably shouldn't be called "-utils"; if
> it's multiple commandline tools, it might not belong in "Section:
> libs". I was going to cheat and read the filelist from the Ubuntu
> version to find out, but that says it's empty:
> "http://packages.ubuntu.com/lucid/i386/libfm-utils/filelist";
>
> I'm guessing that ideally it would be:
>
> Package: libfm-bin
> Description: file management support - demo binary
> $BOILERPLATE
> .
> This package contains a demonstration program.
>
> ...though my patch doesn't go so far as to change the name.
I will make some changes in the contents of this binary package, it
won't be the same as package from ubuntu.
I also consider to drop this to make this package simple.
>> Package: libfm0-dbg
> [...]
>> Description: library for creating files manager - debugging symbols
> [...]
>> This package contains the debugging symbols.
>
> This one just needs the boilerplate changes.
Do you think we need to adjust the descriptions or just your the one you
attached originaly?
Thank you very much for the help,
-Andrew
Reply to: