Re: Installing Recommends by default (was: kydpdict relationships)

[Steve Langasek]

On Wed, Jul 25, 2007 at 08:26:14AM +0200, Frank Küster wrote:
> Russ Allbery <[EMAIL PROTECTED]> wrote:

> > (I currently can't ues Recommends by default because of lsb-release, so I
> > have a bit of a vested interest in solutions that don't require that.)

> What's the problem with lsb-release?

$ apt-cache show lsb-release | grep Rec
Recommends: lsb, apt
$ apt-cache show lsb | grep Dep
Depends: lsb-core, lsb-graphics, lsb-cxx, lsb-desktop, lsb-qt4
$

That makes for some rather hefty packages pulled in via this Recommends
line.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New Debian Menu & Apps/Tools

[Linas Žvirblis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nico Golde wrote:

> I don't really have a better section proposal but I don't 
> really think it fits there because I would not search for a 
> general user tool in a section for root tools. Also the 

The definition of System/Administration is "Administrative and system
configuration utilities, also tools for personal user settings."

> change of desktop behaviour in my opinion is not a "system-change".

It is. If you change your desktop environment to use single-click
instead of double-click, is that not a "system change"?

> I really think the only sane thing is to 
> ask for Applications/Tools in this case also because alot of 
> other X applications will have the same problem.

No. This has already been discussed a lot. "Tools" is gone for good.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGpwTRztOe9mov/y4RAitVAKC/t/xP7jUxyQws0gM0DkVd6cochgCcCF6W
2v3xIZ9hWbXjfHC875XtrSY=
=F65b
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installing Recommends by default

[Frank Küster]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 08:26:14AM +0200, Frank Küster wrote:
>> Russ Allbery <[EMAIL PROTECTED]> wrote:
>
>> > (I currently can't ues Recommends by default because of lsb-release, so I
>> > have a bit of a vested interest in solutions that don't require that.)
>
>> What's the problem with lsb-release?
>
> $ apt-cache show lsb-release | grep Rec
> Recommends: lsb, apt
> $ apt-cache show lsb | grep Dep
> Depends: lsb-core, lsb-graphics, lsb-cxx, lsb-desktop, lsb-qt4
> $
>
> That makes for some rather hefty packages pulled in via this Recommends
> line.

I see.  I had the impression that there is a consensus that our tools
should install Recommends by default in lenny.  If that is the only bug
that really causes a problem in this respect, why not increase it's
severity?  Chris, what do you think about it?

Otherwise, if there are more "excessive Recommends" bugs that cause
problems, it might be an interesting release goal (but it would need a
person to care for it, not me).

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: New Debian Menu & Apps/Tools

[Linas Žvirblis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nico Golde wrote:

> In my opinion it would be nice to have some kind of misc
> subsection for every section to have a workaround this, just 
> like the wildcard tags in debtags.

No it would not. Already discussed and rejected.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGpwWPztOe9mov/y4RAsnfAJ9/jty3Bw3Ro2+/gcMRtAGYuAJ43QCcDeCH
dhSbLC+WgizyxftHs1tSkr0=
=2RYs
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New Debian Menu & Apps/Tools

[Linas Žvirblis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Russ Allbery wrote:

>> We need a good definition for the section, so that it would not become a
>> dump for packages that do not fit elsewhere. Ideas?
> 
> "Docks, program launchers, clocks, mouse utilities, and other programs to
> add general features to a graphical environment" perhaps?  And yes,
> Applications/Desktop Utilities is better.

What about:

"Docks, launchers, clocks, and other applets to add general features to
a graphical environment, but not system configuration tools."

Removed "mouse utilities" because it is too general. Also changed
"programs" to "applets" to make it more clear that applications that
make major changes should still go to "Administration".

I also do not like the word "utilities", as it is hard to translate.
"Desktop Applets" would be more accurate, in my opinion.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGpwz5ztOe9mov/y4RArHcAKDTOCMAS4vBAliWfYMTO433wESrEQCbBF2n
u430hU1puLGL3OlhvL/xssI=
=tRk9
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 and ASCII character encodings

[Kumar Appaiah]

On 25/07/07, Ben Hutchings wrote:

> GNU Moe is a powerful, 8-bit clean, text editor for ISO-8859 and ASCII
> character encodings.

I don't think we should be adding more programs to the archive that
can't handle multibyte encodings.  I believe the default character
encoding for new installations is UTF-8.


OK. It's in the NEW queue. Could you please tell me the procedure to
prevent it from entering the archives?

Thanks.

Kumar
--
Kumar Appaiah,
462, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600036


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Reasonable maximum package size ?

[Charles Plessy]

Le Tue, Jul 24, 2007 at 06:01:38PM -0400, Yaroslav Halchenko a écrit :
> Hi,
> 
> I am sorry to reincarnate the thread

I think that it is a very good idea indeed. Here is a rough summary of
it: http://wiki.debian.org/DataPackages

Was there any interesting discussion on the subject during Debconf ?
In the meantime, I had a closer look to fink and it seems that it is
mostly a perl library which should be easy to package. I am still
contemplating the idea to release Debian package containing fink .info
files which users could use to build .deb pacakages locally.

Have a nice day,

-- 
Charles


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 and ASCII character encodings

[Neil Williams]

On Wed, 25 Jul 2007 14:13:23 +0530
"Kumar Appaiah" <[EMAIL PROTECTED]> wrote:

> On 25/07/07, Ben Hutchings wrote:
> > > GNU Moe is a powerful, 8-bit clean, text editor for ISO-8859 and ASCII
> > > character encodings.
> >
> > I don't think we should be adding more programs to the archive that
> > can't handle multibyte encodings.  I believe the default character
> > encoding for new installations is UTF-8.
> 
> OK. It's in the NEW queue. Could you please tell me the procedure to
> prevent it from entering the archives?

Retitle the ITP to a RM
http://wiki.debian.org/ftpmaster_Removals
and explain why.

Probably best to also send an email (referencing this thread in the
debian-devel archives) to [EMAIL PROTECTED] asking for
the package to be rejected from NEW.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpK07j8laOm6.pgp
Description: PGP signature

Re: New Debian Menu & Apps/Tools

[Nico Golde]

Hi,
* Linas Žvirblis <[EMAIL PROTECTED]> [2007-07-25 11:12]:
> Nico Golde wrote:
[...] 
> > change of desktop behaviour in my opinion is not a "system-change".
> 
> It is. If you change your desktop environment to use single-click
> instead of double-click, is that not a "system change"?

No? It's a user environment change, system changes are 
reserver to uid 0.

> > I really think the only sane thing is to 
> > ask for Applications/Tools in this case also because alot of 
> > other X applications will have the same problem.
> 
> No. This has already been discussed a lot. "Tools" is gone for good.

Then what was the reason for it? I mean looking at this 
discussion it doesn't look too good to me.
Cheers
Nico
-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgp1wBVLWhp9S.pgp
Description: PGP signature

Re: adding desktop files to misc packages

[Josselin Mouette]

Le vendredi 20 juillet 2007 à 16:26 +0200, Michelle Konzack a écrit :
> But the bigger problem is, that some applications have "titles"
> for applications which go over 1/3 of a 1024x768 screen mostly
> Openoffice Apps like "Openoffice.org Printer Administration"
> where the menu has a width of 372 pixels which is realy annoying.

This sounds exactly like the kind of entries which have nothing to do in
the menu. Printers should be configured centrally and made available to
OOo - in fact, they are. If there are any OOo specific parameters for
printers, they should be made available from inside OOo only, not from
the menu.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit :
> The latter might be fine as a local policy; but surely is not
>  correct as a Debian default.  We should make it _possible_ to implement
>  a local policy of hiding information from users; but we must not let
>  information hiding be the default; nor the only possible local policy.

No. We should hide part of the information by default, but make it both
possible:
  * for users to access the extra information without anything too
complicated;
  * for administrators to really lock information if that's really
useful.

Relevant information easily gets lost when there is too much of it,
which is why a *default* setup should never show all available
information. And this isn't only relevant for menus.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mardi 24 juillet 2007 à 20:13 +0200, Eduard Bloch a écrit :
> > This is a very bad idea. It is going to clutter the freedesktop menu
> > with tons of useless entries with ugly icons and make it as useless as
> 
> Make it short, what is your point? Not allowing others to play in your
> GNOME sandbox?

My point is that currently the GNOME menu is usable, and it's one of the
key parts of this desktop's usability. I'm open to any propositions to
make it better, and closed to propositions that make it worse (e.g. by
making it look like the Debian menu).

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Andreas Barth]

* Josselin Mouette ([EMAIL PROTECTED]) [070725 12:06]:
> Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit :
> > The latter might be fine as a local policy; but surely is not
> >  correct as a Debian default.  We should make it _possible_ to implement
> >  a local policy of hiding information from users; but we must not let
> >  information hiding be the default; nor the only possible local policy.
> 
> No. We should hide part of the information by default, but make it both
> possible:
>   * for users to access the extra information without anything too
> complicated;
>   * for administrators to really lock information if that's really
> useful.

Actually, it might also be useful to allow different window managers to
have different default levels of what information is shown.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 12:12 +0200, Andreas Barth a écrit :
> Actually, it might also be useful to allow different window managers to
> have different default levels of what information is shown.

Definitely.

The freedesktop specification could allow to do that, provided that menu
files are correctly tagged with OnlyShowIn and Categories fields. It
also requires some tweaking from the menu systems maintainers.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 and ASCII character encodings

[Adam D. Barratt]

Neil Williams wrote, Wednesday, July 25, 2007 10:07 AM

On Wed, 25 Jul 2007 14:13:23 +0530
"Kumar Appaiah" <[EMAIL PROTECTED]> wrote:

[...]

> OK. It's in the NEW queue. Could you please tell me the procedure to
> prevent it from entering the archives?

Retitle the ITP to a RM
http://wiki.debian.org/ftpmaster_Removals
and explain why.


You can't remove something that's not in the archive...


Probably best to also send an email (referencing this thread in the
debian-devel archives) to [EMAIL PROTECTED] asking for
the package to be rejected from NEW.


The release team don't manange NEW.

Kumar, you need to e-mail [EMAIL PROTECTED] and ask them to 
reject the upload from the NEW queue.


Adam 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Andreas Tille]

On Wed, 25 Jul 2007, Josselin Mouette wrote:


I'm open to any propositions to make it better,


Well, I made the suggestion of user roles which was more or less ignored
in this thread.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is Andrew Lau (netsnipe) MIA?

[Miles Bader]

Roger Leigh <[EMAIL PROTECTED]> writes:
> The packages he maintains and co-maintains are listed below.  Most are
> GNOME packages he has not apparently uploaded.  Some are already
> comaintained by others.  The two of most concern are cinepaint and
> cupsys-pt, which are not comaintained.  cinepaint has since had
> several NMUs to fix build issues.
...
> openexr   20050819Yes Yes

The openexr package also seems to be fairly out of date -- the current
debian version is 1.2.2 (from 2005); the latest release version (from
savannah.nongnu.org) is 1.5.0.

[I filed a wishlist bug saying this about 6 months ago, with no reply yet.]

-Miles

-- 
Suburbia: where they tear out the trees and then name streets after them.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is Andrew Lau (netsnipe) MIA?

[Adeodato Simó]

* Miles Bader [Wed, 25 Jul 2007 19:57:42 +0900]:

> The openexr package also seems to be fairly out of date -- the current
> debian version is 1.2.2 (from 2005); the latest release version (from
> savannah.nongnu.org) is 1.5.0.

> [I filed a wishlist bug saying this about 6 months ago, with no reply yet.]

I've been pondering becoming a co-maintainer of this package for a while
now. I may upload the new version in the near future, if nobody else
beats me to it.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Old men are fond of giving good advice to console themselves for their
inability to set a bad example.
-- La Rochefoucauld, "Maxims"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Mailadresse

[Simone Geppert]

Ich bitte sie diesen Eintrag zu entfernen, da die Emailadresse
meiner zu ähnlich ist und ich nicht mit diesen Inhalten in Verbindung
gebracht werden möchte.

Simone Geppert

Re: kydpdict relationships

[Marvin Renich]

* Manoj Srivastava <[EMAIL PROTECTED]> [070724 21:05]:
> If we are going to transition to installing Recommends by
>  default in lenny, I would say go with the Recommends, since it caters
>  to more users.
> 
> Or else, use Depends, but that makes the system less efficient
>  for those of our users who decide they want a partially  proprietary
>  solution (which we promise to support as well, as I recall).
> 
> > But we dont care about those non-free files, as they wont ever end up
> > in a thing where you could add some relation in your package control
> > data.
> 
> Sure, but the proprietary .deb could use Enhances :). If ever
>  the packaging system frontends decide to support that, it could still
>  be useful.
> 
> manoj

Why not

Depends: free-dictionary | any-dictionary

and have all (free and non-free) dictionaries Provides: any-dictionary?

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mailadresse

[Frank Küster]

Liebe Frau Geppert,

Simone Geppert <[EMAIL PROTECTED]> wrote:

> Ich bitte sie diesen Eintrag zu entfernen, da die Emailadresse
> meiner zu ähnlich ist und ich nicht mit diesen Inhalten in Verbindung
> gebracht werden möchte.

Da muss ein Missverständnis vorliegen.  Sie haben Ihre Anfrage an die
(englischsprachige) Entwickler-Mailingliste des Debian-Projekts
geschickt.  In dieser Liste gibt es tausende von Beiträgen, es ist
völlig unklar, worauf Sie sich beziehen.  Falls es eine E-Mail an die
Liste ist, so wird es wahrscheinlich nicht möglich sein, etwas aus den
Archiven zu entfernen, die von verschiedensten Leuten kopiert wurden.
Aber da sie von ähnlichen E-Mail-Adressen schreiben, geht es vielleicht
um etwas anderes?

Mit freundlichen Grüßen, Frank Küster

[I'm explaining in german that debian-devel is not the right place and
that she probably mixed up things]


-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: kydpdict relationships

[Marcin Owsiany]

On Tue, Jul 24, 2007 at 07:55:09PM -0500, Manoj Srivastava wrote:
> On Tue, 24 Jul 2007 22:38:37 +0200, Joerg Jaspert <[EMAIL PROTECTED]> said: 
> 
> > On 11090 March 1977, Marcin Owsiany wrote:
> >> Now I need to decide what the relationship between these two should
> >> be.
> 
> > Depends.
> 
> Hmm.  Let us examine the two common cases:
>  a) User has not bought proprietary dictionaries.
> i) With recommends installed by default; they can have a working
>package.  Without that, the binary package is useless.
>ii) With Depends, the binary ackage works.
>  b) User has proprietary dictionaries.
> i) With recommends, the user can just install the proprietary
>package first. The system works
>ii) With Depends, there is a possible conflict; or else you have a
>useless package installed, whether you want it or not.

I don't think the other dictionaries conflict each other.

> If we are going to transition to installing Recommends by
>  default in lenny, I would say go with the Recommends, since it caters
>  to more users.
> 
> Or else, use Depends, but that makes the system less efficient
>  for those of our users who decide they want a partially  proprietary
>  solution (which we promise to support as well, as I recall).

Sounds like a good strategy. I'll make it Recommends, as it will be
better for people using systems like an armel-based nokia (hi, Piotr)
which I suppose doesn't have a particularily large mass storage. If it
turns out that recommends won't be installed by default for lenny, I can
easily turn it into a Depends.

> > But we dont care about those non-free files, as they wont ever end up
> > in a thing where you could add some relation in your package control
> > data.
> 
> Sure, but the proprietary .deb could use Enhances :).

I would be quite astonished if there ever was a deb of any of the
proprietary dictionaries :)

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Marvin Renich]

* Josselin Mouette <[EMAIL PROTECTED]> [070725 06:10]:
> Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit :
> > The latter might be fine as a local policy; but surely is not
> >  correct as a Debian default.  We should make it _possible_ to implement
> >  a local policy of hiding information from users; but we must not let
> >  information hiding be the default; nor the only possible local policy.

Exactly.

> 
> No. We should hide part of the information by default, but make it both
> possible:
>   * for users to access the extra information without anything too
> complicated;
>   * for administrators to really lock information if that's really
> useful.
> 
> Relevant information easily gets lost when there is too much of it,
> which is why a *default* setup should never show all available
> information. And this isn't only relevant for menus.
> 

Absolutely *wrong*.

Gnome and KDE are targeted primarily at desktop users, not servers.  If,
as a desktop user, I install a graphical app on my machine, I *expect*
to see that app in the main menu.  The place where I put important
and/or frequently used apps is on a panel/toolbar.

If a novice user installs an app and then goes to the menu and doesn't
find it, how is this user supposed to know what to do?  This is
completely *un*usable.  The more novice the user, the more important it
is for the *default* to be for all graphical apps to be shown.  Then let
the individual user decide which ones are important to him/her.

Menus, by their nature, are inherently unusable for the most frequently
used apps, and we should not be trying to make them more usable at the
expense of making less frequently used apps harder to access.

Menus make less frequently used apps easy to get at, while toolbars make
frequently used apps even easier; use the right tool for the right job.

If Gnome were to have a "menu policy" configuration, with the Debian
default being "show all apps", but which made it easy for the "less is
more useable" camp to accept someone else's idea of "most important
apps" with a single setting rather than having to wade through the menu
editor, I would find that an excellent compromise.

As for multiuser systems and servers, the same logic applies.  The
Debian default should be to show all apps, then let the sysadmin tailor
that for the installation, then let the users fine tune it.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Mike Hommey]

On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL PROTECTED]> 
wrote:
> Absolutely *wrong*.
> 
> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> as a desktop user, I install a graphical app on my machine, I *expect*
> to see that app in the main menu.  The place where I put important
> and/or frequently used apps is on a panel/toolbar.

If you install the python interpreter on your machine, do you also expect it
to appear in the main menu ?

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL PROTECTED]> 
> wrote:
>> Absolutely *wrong*.
>> 
>> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
>> as a desktop user, I install a graphical app on my machine, I *expect*
>> to see that app in the main menu.  The place where I put important
>> and/or frequently used apps is on a panel/toolbar.
>
> If you install the python interpreter on your machine, do you also expect it
> to appear in the main menu ?

No, why do you ask?  The python interpreter isn't a graphical
application.  It also doesn't have a menu entry, so there's nothing to
hide. 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Mike Hommey]

On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster <[EMAIL PROTECTED]> 
wrote:
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL PROTECTED]> 
> > wrote:
> >> Absolutely *wrong*.
> >> 
> >> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> >> as a desktop user, I install a graphical app on my machine, I *expect*
> >> to see that app in the main menu.  The place where I put important
> >> and/or frequently used apps is on a panel/toolbar.
> >
> > If you install the python interpreter on your machine, do you also expect it
> > to appear in the main menu ?
> 
> No, why do you ask?  The python interpreter isn't a graphical
> application.  It also doesn't have a menu entry, so there's nothing to
> hide. 

You obviously never looked at the Debian menu.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster <[EMAIL PROTECTED]> 
> wrote:
>> Mike Hommey <[EMAIL PROTECTED]> wrote:
>> 
>> > On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL 
>> > PROTECTED]> wrote:
>> >> Absolutely *wrong*.
>> >> 
>> >> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
>> >> as a desktop user, I install a graphical app on my machine, I *expect*
>> >> to see that app in the main menu.  The place where I put important
>> >> and/or frequently used apps is on a panel/toolbar.
>> >
>> > If you install the python interpreter on your machine, do you also expect 
>> > it
>> > to appear in the main menu ?
>> 
>> No, why do you ask?  The python interpreter isn't a graphical
>> application.  It also doesn't have a menu entry, so there's nothing to
>> hide. 
>
> You obviously never looked at the Debian menu.

How do you come to that conclusion?  On the contrary, I use it
frequently (there's other menu in my WM).  

But from Marvin's sentence (which I think is right) 

,
| If, as a desktop user, I install a graphical app on my machine, I
| *expect* to see that app in the main menu
`

you cannot conclude on his (or my) expectations regarding python, because
python is not a graphical application.



In case you are in fact interested in the unrelated question "Should
non-graphical applications have a menu entry?", here's my opinion:  In
most cases I think they shouldn't.  All those interpreters in
Applications/Programming are a good example for executables which IMHO
don't need a menu entry.  

There may be cases, though, were a menu entry makes sense.  In
particular for programs which usually need their own terminal, anyway,
and are likely to stay open for a while (e.g. mutt).  Selecting
appropriate settings for the terminal used is a different issue...

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Frank Küster <[EMAIL PROTECTED]> wrote:

> Mike Hommey <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster <[EMAIL PROTECTED]> 
>> wrote:
>>> Mike Hommey <[EMAIL PROTECTED]> wrote:
>>> 
>>> > On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL 
>>> > PROTECTED]> wrote:
>>> >> Absolutely *wrong*.
>>> >> 
>>> >> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
>>> >> as a desktop user, I install a graphical app on my machine, I *expect*
>>> >> to see that app in the main menu.  The place where I put important
>>> >> and/or frequently used apps is on a panel/toolbar.
>>> >
>>> > If you install the python interpreter on your machine, do you also expect 
>>> > it
>>> > to appear in the main menu ?
>>> 
>>> No, why do you ask?  The python interpreter isn't a graphical
>>> application.  It also doesn't have a menu entry, so there's nothing to
>>> hide. 
>>
>> You obviously never looked at the Debian menu.
>
> How do you come to that conclusion?  

Well, that's clear, since it actually has a menu entry.  I looked in
/usr/share/menu but overlooked it.  But that's still completely
irrelevant for the question at hand.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Mailadresse

[Thomas Viehmann]

[maybe this is better on -project]
Frank Küster wrote:
> [I'm explaining in german that debian-devel is not the right place and
> that she probably mixed up things]
Well, some joe job porn spam on l.d.o is the #1 result when googling for
her name, so she is quite right to contact the list on whose archive it is.

If the one thing keeping us from deleting list spam (which I found out
after reporting entire months of d-devel spam) is the indexing and thus
linking, I'd happily try to come up with a patch that makes mhonarc deal
with the gaps.
I'm not particularly interested to code things (and perl at that) just
for rotting and being mentioned as obscure patches on some BoFs, though,
and I have no aspirations to become a listmaster. I'm just bothered by
the spam in our list archive and would prefer to do something about it,
so I'd volunteer to help in order to not bother the listmasters too much
with it.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#434206: ITP: moe -- powerful text editor for ISO-8859 and ASCII character encodings

[Kumar Appaiah]

On 25/07/07, Adam D. Barratt wrote:

You can't remove something that's not in the archive...


Right!

Kumar, you need to e-mail [EMAIL PROTECTED] and ask them to 
reject the upload from the NEW queue.


I have mailed them with a citation to this thread.

Also, I have closed the bug report, with a similar citation.

Thanks for bringing this issue to my notice. I shall, henceforth, keep this in 
mind before filing that brand new ITP. :-)

Kumar
--
Kumar Appaiah,
462, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600036


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Michael Biebl]

Frank Küster schrieb:
> Frank Küster <[EMAIL PROTECTED]> wrote:
> 
>> Mike Hommey <[EMAIL PROTECTED]> wrote:
>>
>>> On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster <[EMAIL PROTECTED]> 
>>> wrote:
 Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL 
> PROTECTED]> wrote:
>> Absolutely *wrong*.
>>
>> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
>> as a desktop user, I install a graphical app on my machine, I *expect*
>> to see that app in the main menu.  The place where I put important
>> and/or frequently used apps is on a panel/toolbar.
> If you install the python interpreter on your machine, do you also expect 
> it
> to appear in the main menu ?
 No, why do you ask?  The python interpreter isn't a graphical
 application.  It also doesn't have a menu entry, so there's nothing to
 hide. 
>>> You obviously never looked at the Debian menu.
>> How do you come to that conclusion?  
> 
> Well, that's clear, since it actually has a menu entry.  I looked in
> /usr/share/menu but overlooked it.  But that's still completely
> irrelevant for the question at hand.
> 

Actually, it's not. That's Joss' whole point. We should hide entries,
such as the python interpreter for novice users (at least in
environments like KDE/GNOME/XFCE, which target the novice users).
If the Debian menu is too overloaded, it becomes less useful.
Sometimes, less is more imho.

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: adding desktop files to misc packages

[Frank Küster]

Michael Biebl <[EMAIL PROTECTED]> wrote:

> Actually, it's not. That's Joss' whole point. We should hide entries,
> such as the python interpreter for novice users (at least in
> environments like KDE/GNOME/XFCE, which target the novice users).
> If the Debian menu is too overloaded, it becomes less useful.
> Sometimes, less is more imho.

I tend to disagree, simply because I think that python shouldn't have a
menu entry at all.  Who wants to convince me (or give me an URL to an
archived discussion) that it should have one?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

debian-policy: New virtual package: wims-extra

[L. Redrejo]

Package: debian-policy 
Priority: wishlist

Hi all,
   Wims is a recent Debian package which will be more widely used in the near 
future
as a part of Debian-Edu (currently it is a dependency on its metapackage 
education-services)
and it's being use in Linex (Extremadura region official debian based 
distribution) schools.

Its installation can be done by requiring the package wims, which
depends from the package wims-modules. When installed, they feature a
webserver for educational exercises of outstanding quality, localised in
many languages.

However most of the "meat" is provided by the packages wims-extra-xx,
which contain hundreds of educational modules (this number hopefully
will grow quickly). In July 2007, the installed size of   wims-extra-all
is roughly 200 MBytes.  Some webmasters might want to install less rich
sets of modules, for example only the modules localised in their
language, or a set of modules targeted to a particular domain of study.
There is already a package wims-extra-es with Spanish-only modules, and
some other packages might be made available in the near future, like a
French-only collection, or a collection dedicated to physics and
chemistry, etc.

The current wims maintainer (who is in the cc'ed list for this mail)
asked me to sponsor this package, and, after some conversations with
him, we both agree that wims package should have a recommends to a
virtual package called "wims-extra", so people may provide packages for
the "meat" with their particular flavor, while the package
wims-extra-all providing wims-extra would be part of the official
distribution. 

Currently wims-extra is a real package, which is part of Debian Stable
(version 3.60-1), so the situation would be the following after an
acceptation of its name for a virtual package:
   - newer versions of wims and wims-modules (3.62) would enter Unstable
 and their dependencies would entail the replacement of any older
 version of wims-extra.
   - the new version of wims-extra (3.62) would be a virtual package.
   - wims-extra-all (version 3.62) would enter Unstable and provide
 wims-extra.
   - wims-extra-es (already part of the distro Linex) would provide
 wims-extra.

So, I propose to add this entry to the virtual package list:

wims-extra - extra exercises, translations and modules that enhance wims 
functionalities.


Best regards,
José L.



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Bug#434654: ITP: autodocksuite -- analysis of ligand binding to protein structure

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller <[EMAIL PROTECTED]>

* Package name : autodocksuite
Version : 4.0.1
URL : http://autodock.scripps.edu
License : GPL
Description : analysis of ligand binding to protein structure

AutoDock is a well-established suite of programs for the molecular
analysis the docking of a smaller chemical compounds to their receptors
of known structure.

The AutoDock program performs the docking of the ligand to a set of
grids describing the target protein. AutoGrid pre-calculates these grids.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit :
> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> as a desktop user, I install a graphical app on my machine, I *expect*
> to see that app in the main menu.  The place where I put important
> and/or frequently used apps is on a panel/toolbar.

Do you expect to see console applications in the menu as well? All
interpreters and shells? Window managers?

> If a novice user installs an app and then goes to the menu and doesn't
> find it, how is this user supposed to know what to do?

This bit is correct: someone installing an app can reasonably expect to
see it in the menu. However you are drawing wrong conclusions:

>   This is
> completely *un*usable.  The more novice the user, the more important it
> is for the *default* to be for all graphical apps to be shown.  Then let
> the individual user decide which ones are important to him/her.

If the users installs the distribution with default settings or starts a
session on a multi-user setup, he should find a usable menu, not a menu
with all possible applications he never wanted to install.

> Menus, by their nature, are inherently unusable for the most frequently
> used apps, and we should not be trying to make them more usable at the
> expense of making less frequently used apps harder to access.

Why shouldn't we attempt to make menus usable?

> Menus make less frequently used apps easy to get at, while toolbars make
> frequently used apps even easier; use the right tool for the right job.

Guess what, toolbars are not used by a good share of users. Toolbars
sound obvious for experienced users, but a novice will never have the
idea to modify the interface that is shown to him; which is why this
interface must be as straightforward as possible - and that also
includes good default shortcuts in the toolbar.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Installing Recommends by default

[Russ Allbery]

Frank Küster <[EMAIL PROTECTED]> writes:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
>> On Wed, Jul 25, 2007 at 08:26:14AM +0200, Frank Küster wrote:
>>> Russ Allbery <[EMAIL PROTECTED]> wrote:

 (I currently can't ues Recommends by default because of lsb-release, so I
 have a bit of a vested interest in solutions that don't require that.)

>>> What's the problem with lsb-release?

>> $ apt-cache show lsb-release | grep Rec
>> Recommends: lsb, apt
>> $ apt-cache show lsb | grep Dep
>> Depends: lsb-core, lsb-graphics, lsb-cxx, lsb-desktop, lsb-qt4
>> $

>> That makes for some rather hefty packages pulled in via this Recommends
>> line.

> I see.  I had the impression that there is a consensus that our tools
> should install Recommends by default in lenny.  If that is the only bug
> that really causes a problem in this respect, why not increase it's
> severity?  Chris, what do you think about it?

Chris apparently concurs and just hadn't had time to look at my bug (which
wasn't that old), as a new version was just uploaded without that
Recommends.  Thank you very much!

I'm much less attached to being able to turn off Recommends now.  :)

(lsb-release is very handy for configuration management systems such as
Puppet.)

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: New Debian Menu & Apps/Tools

[Russ Allbery]

Linas Žvirblis <[EMAIL PROTECTED]> writes:

> What about:

> "Docks, launchers, clocks, and other applets to add general features to
> a graphical environment, but not system configuration tools."

> Removed "mouse utilities" because it is too general. Also changed
> "programs" to "applets" to make it more clear that applications that
> make major changes should still go to "Administration".

> I also do not like the word "utilities", as it is hard to translate.
> "Desktop Applets" would be more accurate, in my opinion.

Works for me.  You may want to say "not system configuration or monitoring
tools" to explicitly exclude gkrellm, xload, etc., which have another
category into which they fit better.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mercredi 25 juillet 2007 à 16:40 +0200, Frank Küster a écrit :
>> Michael Biebl <[EMAIL PROTECTED]> wrote:
>> 
>> > Actually, it's not. That's Joss' whole point. We should hide entries,
>> > such as the python interpreter for novice users (at least in
>> > environments like KDE/GNOME/XFCE, which target the novice users).
>> > If the Debian menu is too overloaded, it becomes less useful.
>> > Sometimes, less is more imho.
>> 
>> I tend to disagree, simply because I think that python shouldn't have a
>> menu entry at all.  Who wants to convince me (or give me an URL to an
>> archived discussion) that it should have one?
>
> As long as it is not shown, it doesn't matter, so I guess we can agree
> on this matter.

No, not at all.  I have not yet seen a convincing argument for hiding
menu entries.  The only ones were "less is more", which is to vague to
get one much further, and "we need to hide stuff like python", which is
plain wrong IMHO because I think python shouldn't have a menu entry at
all. 

In particular, nobody has yet answered Marvin's argument about not
mixing up the purpose of the menu and the toolbar,

,
| Gnome and KDE are targeted primarily at desktop users, not servers.  If,
| as a desktop user, I install a graphical app on my machine, I *expect*
| to see that app in the main menu.  The place where I put important
| and/or frequently used apps is on a panel/toolbar.
`

Mike overlooked the word "graphical", and since then we are discussing
python, not menu/.desktop.


Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 16:40 +0200, Frank Küster a écrit :
> Michael Biebl <[EMAIL PROTECTED]> wrote:
> 
> > Actually, it's not. That's Joss' whole point. We should hide entries,
> > such as the python interpreter for novice users (at least in
> > environments like KDE/GNOME/XFCE, which target the novice users).
> > If the Debian menu is too overloaded, it becomes less useful.
> > Sometimes, less is more imho.
> 
> I tend to disagree, simply because I think that python shouldn't have a
> menu entry at all.  Who wants to convince me (or give me an URL to an
> archived discussion) that it should have one?

As long as it is not shown, it doesn't matter, so I guess we can agree
on this matter.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit :
>> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
>> as a desktop user, I install a graphical app on my machine, I *expect*
>> to see that app in the main menu.  The place where I put important
>> and/or frequently used apps is on a panel/toolbar.
>
> Do you expect to see console applications in the menu as well? 

With some exceptions, no.

> All
> interpreters and shells? 

No.

> Window managers?

Yes, in an appropriate category.  *That* one could be a candidate for
hiding.  If I'm not mistaken KDE, Gnome and friends only work with
certain window managers, so switching doesn't make sense.

>>   This is
>> completely *un*usable.  The more novice the user, the more important it
>> is for the *default* to be for all graphical apps to be shown.  Then let
>> the individual user decide which ones are important to him/her.
>
> If the users installs the distribution with default settings or starts a
> session on a multi-user setup, he should find a usable menu, 

ACK

> not a menu
> with all possible applications he never wanted to install.

That depends...  But indeed, on a multi-user system the local admin
should be able to taylor the default menu according to their
expectations of the users.  In the same line, a maintainer of a desktop
environment might do the same.  I don't like the latter, but it would be
just one *more* reason for me not to use a desktop environment, so I
don't care much.

>> Menus, by their nature, are inherently unusable for the most frequently
>> used apps, and we should not be trying to make them more usable at the
>> expense of making less frequently used apps harder to access.
>
> Why shouldn't we attempt to make menus usable?

Because, as Marvin wrote in the text you cite, the drawback is that it
makes less frequently used applications harder to access.

There are other ways to make menus usable even for frequently used
applications, without these drawbacks:  For example, if a user can
influence the order of entries, that would help much more.

But I agree with Marvin (and that's also my usage scheme) that menus
should provide access to the less frequently used applications, not the
ones started very often.  I don't have toolbars in my WM, but it starts
the frequently used apps without asking me, so I use the menu for the
rare ones.

>> Menus make less frequently used apps easy to get at, while toolbars make
>> frequently used apps even easier; use the right tool for the right job.
>
> Guess what, toolbars are not used by a good share of users. Toolbars
> sound obvious for experienced users, but a novice will never have the
> idea to modify the interface that is shown to him; which is why this
> interface must be as straightforward as possible - and that also
> includes good default shortcuts in the toolbar.

I have little experience with such users; the ones I know and would call
"computer illiterate" use the windows desktop or the Mac dock for
starting their pet applications.  If there's actually a considerable
number of people who don't even get that far, I'm not sure how to help
them.  Maybe you are right, and hiding stuff is a possibility.
Automatically moving the often-used entries to a well-visible toolbar is
an alternative; I generally don't like if computers change their
appearance based on what they perceive my usage patterns, but maybe it's
the better choice here than hiding.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Bruce Sass]

On Wed July 25 2007 10:57:54 am Josselin Mouette wrote:
> If the users installs the distribution with default settings or
> starts a session on a multi-user setup, he should find a usable menu,
> not a menu with all possible applications he never wanted to install.

Well, if there is stuff he never wanted to install then his first clue 
they are cluttering up his system will be their appearance in the 
menus. It also gives him an opportunity to easily fire them up to see 
what the ones he's never heard of are so he can decide if they should 
be purged or kept. If they are not in the menus then he either tracks 
them down manually and starts them from the commandline, or notices 
them if he pays close enough attention to upgrades.

I think you've hit on a good reason to default to including everything 
in the menus.


- Bruce


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Steve Greenland]

On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> If an application is used so infrequently, it shouldn't have its place
> in a menu.

That turns out not to be the case. If I use an app frequently, then it
goes on the toolbar. The menu is for finding infrequently used apps. For
a lot of users, browsing the menu is how they find out what's available.

No, I'm not arguing every shell, interpeter, or other text app needs a
menu a entry, I agree with you on that.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installing Recommends by default

[Reinhard Tartler]

Frank Küster <[EMAIL PROTECTED]> writes:

>>> What's the problem with lsb-release?
>>
>> $ apt-cache show lsb-release | grep Rec
>> Recommends: lsb, apt
>> $ apt-cache show lsb | grep Dep
>> Depends: lsb-core, lsb-graphics, lsb-cxx, lsb-desktop, lsb-qt4
>> $
>>
>> That makes for some rather hefty packages pulled in via this Recommends
>> line.
>
> I see.  I had the impression that there is a consensus that our tools
> should install Recommends by default in lenny.  If that is the only bug
> that really causes a problem in this respect, why not increase it's
> severity?  Chris, what do you think about it?

I think this example shows that installing Recommends by default alone
is hardly a solution which serves the majority of users. I think that we
also need a blacklist (or policy or however you want to call it) of
packages in addition. Frontends like apt-get would consult that local
policy when considering to install a "recommended" package.

Debian can then still decide to ship an example local policy which
e.g. prevents the "lsb" package to be installed despite being
recommended by lsb-release.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland <[EMAIL PROTECTED]> 
> wrote:
>> On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
>> > If an application is used so infrequently, it shouldn't have its place
>> > in a menu.
>> 
>> That turns out not to be the case. If I use an app frequently, then it
>> goes on the toolbar. The menu is for finding infrequently used apps. For
>> a lot of users, browsing the menu is how they find out what's available.
>
> IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
> this.

What does that mean?  What is gnome-main-menu?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Marvin Renich]

* Josselin Mouette <[EMAIL PROTECTED]> [070725 12:57]:
> Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit :
> > Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> > as a desktop user, I install a graphical app on my machine, I *expect*
> > to see that app in the main menu.  The place where I put important
> > and/or frequently used apps is on a panel/toolbar.
> 
> Do you expect to see console applications in the menu as well? All
> interpreters and shells? Window managers?

My original message was specifically concerned with graphical apps.  I'm
not sure which console apps should be displayed; for the most part, I
think the Debian maintainer should decide whether it deserves to be
displayed by default.

Window managers *definitely* should be displayed.  If I went to the
trouble of installing sawfish in addition to metacity, I would like to
be able to use both.  Yes, from the menu.

> > If a novice user installs an app and then goes to the menu and doesn't
> > find it, how is this user supposed to know what to do?
> 
> This bit is correct: someone installing an app can reasonably expect to
> see it in the menu. However you are drawing wrong conclusions:
> 
> >   This is
> > completely *un*usable.  The more novice the user, the more important it
> > is for the *default* to be for all graphical apps to be shown.  Then let
> > the individual user decide which ones are important to him/her.
> 
> If the users installs the distribution with default settings or starts a
> session on a multi-user setup, he should find a usable menu, not a menu
> with all possible applications he never wanted to install.

Usable, yes; minimal, no.  See the next paragraph:

> > Menus, by their nature, are inherently unusable for the most frequently
> > used apps, and we should not be trying to make them more usable at the
> > expense of making less frequently used apps harder to access.
> 
> Why shouldn't we attempt to make menus usable?

I didn't say we should not make them usable, I said we should not try to
make them more usable *by reducing access to less frequently used apps*.

> > Menus make less frequently used apps easy to get at, while toolbars make
> > frequently used apps even easier; use the right tool for the right job.
> 
> Guess what, toolbars are not used by a good share of users. Toolbars
> sound obvious for experienced users, but a novice will never have the
> idea to modify the interface that is shown to him; which is why this
> interface must be as straightforward as possible - and that also
> includes good default shortcuts in the toolbar.

That a novice will not know that he can change the interface is even
more reason to make sure the (graphical) app that he installed is in the
menu.  A good system of hints that includes one about putting
applications on the toolbar would be very helpful.

Also, my experience is that a good share of less-technically-oriented-
but-comfortable-using-a-computer users actually do use toolbars.

Josselin, we have not met face-to-face, and email does not convey
emotion very well, so I want to make sure you know that this is not a
personal attack.  Your contribution to Debian is significant, and I
appreciate it (along with that of the many other DD's).  I respect the
technical opinions that you have expressed on the debian mailing lists,
and agree with many of them.  But I strongly disagree with you on this
issue.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Gabor Gombas]

On Wed, Jul 25, 2007 at 06:57:54PM +0200, Josselin Mouette wrote:

> If the users installs the distribution with default settings or starts a
> session on a multi-user setup, he should find a usable menu, not a menu
> with all possible applications he never wanted to install.

So the menu system should know if an application was explicitely
selected by the user during installation or it was pulled in due to some
strange dependency? And in the latter case, the menu system should know
that the user _wanted_ the application to be installed regardless (and
therefore he/she expects to see a menu entry by default)?

> Why shouldn't we attempt to make menus usable?

IMHO the best would be a uniof of the two viewpoints: show everything by
default, and gradually hide entries that were not used for some time. Or
did Microsoft patent that?

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is Andrew Lau (netsnipe) MIA?

[Paul Wise]

On 7/26/07, Roger Leigh <[EMAIL PROTECTED]> wrote:


cinepaint probably needs removing; it's very buggy and is dead upstream.


Last upstream release is 0.22-1 from June 12, 2007.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is Andrew Lau (netsnipe) MIA?

[Bernd Zeimetz]

Paul Wise wrote:
> On 7/26/07, Roger Leigh <[EMAIL PROTECTED]> wrote:
> 
>> cinepaint probably needs removing; it's very buggy and is dead upstream.
> 
> Last upstream release is 0.22-1 from June 12, 2007.

Also cinepaint has several features which are missing in GIMP and other
tools, like proper HDR file handling. It should stay in the archive imho
- as long as there're no real reasons to get rid of it.


-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Desktop teams could draft policies to inform developper on their expectations.

[Charles Plessy]

Le Wed, Jul 25, 2007 at 04:12:04PM +0200, Michael Biebl a écrit :
> 
> Actually, it's not. That's Joss' whole point. We should hide entries,
> such as the python interpreter for novice users

It would be however much simpler if the responsible of the GNOME, KDE
and XFCE desktop packages told us what to hide, instead of us having to
take the python example and generalise to any package. This discussion
is getting very anecdotical and is not producing usable information for
developpers wondering how to write a .desktop which can at the same time
please the GNOME team and be used to generate a .menu file. In the
absence of any clear guideline, my approach would be rather to be
liberal by default and wait for bug reports... But I repeat, I am sure
that developpers only want to trust the GNOME, KDE and XFCE teams, and
just hide what has to be hidden, *if they are told what to hide*.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: adding desktop files to misc packages

[Cliffton Beach]

>That's a good reason to improve the menu system, but not really a good
>reason to just go ahead and ship two versions of basically the same
>information, IMO.

Recent version(s) of lynx have an icon in my KDE menu.  I'd really rather not 
have it there, and was curious if anyone had filed a bugreport about it.  I can 
remove it manually of course, but by default I feel rather strongly it should 
not be there.  It is a console app, and people who are interested in using it 
can presumably launch it from there.  People like me, when I am on a console.

Reading some of the mails in this thread, there are people who feel everything 
should be in the menu.  These people aren't typical KDE/Gnome users.  

I think it's a fine idea to have two menu systems, one including the kitchen 
sink and one catering to more standard desktop use and excluding lynx, window 
managers etc.

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 16:17 -0400, Marvin Renich a écrit :
> My original message was specifically concerned with graphical apps.  I'm
> not sure which console apps should be displayed; for the most part, I
> think the Debian maintainer should decide whether it deserves to be
> displayed by default.

I still disagree. The policy should enforce detailed tagging that allows
window managers and menu systems maintainers to filter out entries they
don't want to display.

> Window managers *definitely* should be displayed.  If I went to the
> trouble of installing sawfish in addition to metacity, I would like to
> be able to use both.  Yes, from the menu.

Sorry, but the menu is not a holdall where we put all functionality that
we don't know where to put without thinking a few minutes.

A window manager choice has nothing to do in an application menu, as it
is not an application. This is a matter for a configuration tool,
whatever form it takes.

> > Why shouldn't we attempt to make menus usable?
> 
> I didn't say we should not make them usable, I said we should not try to
> make them more usable *by reducing access to less frequently used apps*.

As things are, even with the best possible menu system one can imagine,
you won't manage to make a menu with 500 entries as usable as one with
100.

> > Guess what, toolbars are not used by a good share of users.

> Also, my experience is that a good share of less-technically-oriented-
> but-comfortable-using-a-computer users actually do use toolbars.

These affirmations are not contradictory. I don't deny that many users
make use of their toolbar, but I think we should keep the menu usable
for users who don't.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: adding desktop files to misc packages

[Andreas Tille]

On Wed, 25 Jul 2007, Andreas Tille wrote:


I'm open to any propositions to make it better,


Well, I made the suggestion of user roles which was more or less ignored
in this thread.


While beeing uncomfortable to reply to my own mail it seems that the
proposal is quite to abstract to get any comment, perhaps a screenshot
I'm using in my talks makes clear what I mean.  Here you can see a
menu of a user that is in the role "med" (for "medicine") and has for
testing purpose also added to the role "junior" (there are no offcial
packages that feature the Dabian-Jr. menu.

http://people.debian.org/~tille/talks/img/menu-en.png

Those users that are not in role "med" do not see the "Med" menu entry
(resp. for "Junior" or whatever menu structure is used).  Currently the
implementation of roles is done as UNIX groups which is suboptimal and
thus the implementation is realised as a plugin system.  Perhaps some
LDAP plugin could be written.

I really wonder whether this concept of user roles are really that strange
or stupid that all posters seem to ignore this idea.  (Feel free to teach
me in private to keep silent with those stupid ideas.)

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Mike Hommey]

On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland <[EMAIL PROTECTED]> 
wrote:
> On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> > If an application is used so infrequently, it shouldn't have its place
> > in a menu.
> 
> That turns out not to be the case. If I use an app frequently, then it
> goes on the toolbar. The menu is for finding infrequently used apps. For
> a lot of users, browsing the menu is how they find out what's available.

IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
this.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Intention to drop sparc32 support for Lenny

[Turbo Fredriksson]

> "Uwe" == Uwe Hermann <[EMAIL PROTECTED]> writes:

Uwe> OK, not being a SPARC expert myself, I'd still like to see a
Uwe> list of issues or bugs which are worth dropping a whole
Uwe> sub-architecture.

Well, if I remember correctly, it was the kernel that was the problem.
There is no support for sparc32 in the kernel any more. Or at least,
no major development

So the primary thing is to be the upstream maintainer for the sparc32
kernel port...

Uwe> Well, I just saw three or more sparc32 patches being
Uwe> committed to Linus' git tree today or yesterday, so that may
Uwe> not be quite correct.

Apparently that is not enough. There is no maintainer for it (that
I know of).
-- 
Albanian subway Panama Nazi radar Cuba nitrate 747 $400 million in
gold bullion nuclear Legion of Doom munitions class struggle
arrangements SEAL Team 6
[See http://www.echelonwatch.org/ for more about this]
http://www.theregister.co.uk/2001/09/06/eu_releases_echelon_spying_report/
http://www.aclu.org/safefree/nsaspying/23989res20060131.html#echelon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Gabor Gombas <[EMAIL PROTECTED]> wrote:

> IMHO the best would be a uniof of the two viewpoints: show everything by
> default, and gradually hide entries that were not used for some time. Or
> did Microsoft patent that?

The result being that if I use the application again for work of type B
after only using it for type A for three weeks, everything that is only
used for B will be hidden.

No, thanks.

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 25, 2007 at 09:56:11PM +0200, Frank Küster <[EMAIL PROTECTED]> 
> wrote:
>> Mike Hommey <[EMAIL PROTECTED]> wrote:
>> 
>> > On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland <[EMAIL 
>> > PROTECTED]> wrote:
>> >> On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
>> >> > If an application is used so infrequently, it shouldn't have its place
>> >> > in a menu.
>> >> 
>> >> That turns out not to be the case. If I use an app frequently, then it
>> >> goes on the toolbar. The menu is for finding infrequently used apps. For
>> >> a lot of users, browsing the menu is how they find out what's available.
>> >
>> > IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
>> > this.
>> 
>> What does that mean?  What is gnome-main-menu?
>
> apt-get install gnome-main-menu.

That won't help unless I start Gnome, which I won't.

> http://reverendted.wordpress.com/2007/02/14/show-me-that-updated-gnome-main-menu/

I haven't watched the whole video (it being boring to me), but from the
reading I still don't understand which of my statements you want to
contradict, let alone why.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Mike Hommey]

On Wed, Jul 25, 2007 at 09:56:11PM +0200, Frank Küster <[EMAIL PROTECTED]> 
wrote:
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Jul 25, 2007 at 01:50:20PM -0500, Steve Greenland <[EMAIL 
> > PROTECTED]> wrote:
> >> On 25-Jul-07, 13:28 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> >> > If an application is used so infrequently, it shouldn't have its place
> >> > in a menu.
> >> 
> >> That turns out not to be the case. If I use an app frequently, then it
> >> goes on the toolbar. The menu is for finding infrequently used apps. For
> >> a lot of users, browsing the menu is how they find out what's available.
> >
> > IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
> > this.
> 
> What does that mean?  What is gnome-main-menu?

apt-get install gnome-main-menu.

http://reverendted.wordpress.com/2007/02/14/show-me-that-updated-gnome-main-menu/

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Thoughts about the bug tracking system

[Lionel Elie Mamane]

On Sat, Jul 21, 2007 at 12:52:43AM +0200, Carl Fürstenberg wrote:

> When I'm locking at the BTS, (...) Not that it isn't effective, as
> when you have learned the whole system, you can query it pretty
> fast, but the threshold is pretty steep.

> (...) make it a bit more user friendly, but perhaps it's time to do
> something?

> The major problem with the current system, is that it requires that
> the reporter has access to a mail server, if they want to use the
> more easier variant by using reportbug script.

No, not really.

> their other alternative is to send an email from their webmail (I
> assume that they don't have access to an smtp server, and are
> prohibited to use one by them self by port 25 blocking) using a
> complicated syntax to be able to send "correct" reports.

If they have such a restricted Internet connection that they don't
have access to _any_ SMTP server, in last resort they can use the "-o"
option of reportbug to save it in a file and then paste it in their
webmail or any other MUA they may be using on any OS.

But frankly, ISPs that don't give access to at least their own relay
SMTP server, err... do they get any customer? Also note that AFAIK, on
installing Debian, exim-config will have asked them for their
smarthost, so actually usually (smarthost available) "reportbug" will
work out of the box.

> Perhaps I'm out on deep water here, but just wanted to give a
> thought.  perhaps a web-based solution (with backward compabillity
> to current system) would be the most optimal solution?

I wouldn't oppose adding a web-based interface, as long as I can
ignore it, that is I can still use email for everything, and users are
kindly asked to give the same information than in reportbug (including
package-specific information currently asked or collected by scripts
in /usr/share/bug). Hmm... Now that I think of it, a web submission
interface cannot run a script of its choosing on the user's machine,
so there is at least one way it will be less user-friendly and
beginner-friendly: users will have to do (some of) the work that is
now done in /usr/share/bug by hand...

-- 
Lionel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ftp.debian.org lacking behind and p.d.o too

[Paul Donohue]

It appears broken again...

ftp://ftp.debian.org/debian/project/trace/ftp-master.debian.org has date stamp 
'07/18/2007'

Thanks!
-Paul

>On Mon, Jul 02, 2007 at 01:44:04PM -0400, Anthony Towns wrote:
>> On Mon, Jul 02, 2007 at 02:48:34PM +0200, Daniel Leidert wrote:
>> > Can someone tell me, why ftp.debian.org is lacking behind? 
>> Apparently it's out of disk :(
>
>This is now fixed. Thanks for the report.
>
>Cheers,
>aj


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mercredi 25 juillet 2007 à 19:35 +0200, Frank Küster a écrit :
>> >> Menus, by their nature, are inherently unusable for the most frequently
>> >> used apps, and we should not be trying to make them more usable at the
>> >> expense of making less frequently used apps harder to access.
>> >
>> > Why shouldn't we attempt to make menus usable?
>> 
>> Because, as Marvin wrote in the text you cite, the drawback is that it
>> makes less frequently used applications harder to access.
>
> If an application is used so infrequently, it shouldn't have its place
> in a menu. 

It seems we have a very different notion of what a menu is.  To me, the
reply "Exactly because it is used infrequently it should have its place"
is obvious and follows strictly from my understanding of a menu, I don't
even need an argument for that.  To you, it seems to be the contrary.

> Furthermore, in the case a user needs it more often, he can
> add it to the menu. This becomes even easier if the menu entry is only
> hidden, not absent.

But it seems to be harder than adding it to the toolbar/dock/whatever.

>> But I agree with Marvin (and that's also my usage scheme) that menus
>> should provide access to the less frequently used applications, not the
>> ones started very often.  I don't have toolbars in my WM, but it starts
>> the frequently used apps without asking me, so I use the menu for the
>> rare ones.
>
> This is also my usage scheme: everyday apps in the session, less
> frequently used apps in the menu, rarely used apps in a terminal or a
> launching tool.

I don't make this distinction between "less used" and "rarely used", and
I'm not even sure what a launching tool is.  I nearly never start a
graphical application from the terminal, and I don't need to be able to
start terminal applications from the menu: For me that is the
only reason for deciding whether something should have a (possibly
hidden) menu entry.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Thoughts about the bug tracking system

[Paul Wise]

On 7/26/07, Lionel Elie Mamane <[EMAIL PROTECTED]> wrote:


> reportbug-ng does *not* gather all the information about the
> reporters system... see #422085

Oh? And gnome-reportbug does or not?


gnome-reportbug doesn't work well enough to do anything.

In theory it does everything reportbug does because it is a user
interface module for reportbug, a bit like the reportbug -u urwid
option, instead of a reimplementation like reportbug-ng.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Thoughts about the bug tracking system

[Lionel Elie Mamane]

On Sat, Jul 21, 2007 at 01:36:49PM +0200, Brice Goglin wrote:
> Sune Vuorela wrote:

>> I prefer reportbug-ng over any webinterface to recieve bug
>> reports. All the information about the reporters system that is
>> automatically gathered about architecture, package versions and
>> such.

> reportbug-ng does *not* gather all the information about the
> reporters system... see #422085

Oh? And gnome-reportbug does or not?

-- 
Lionel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: First call for vortes: GR: Accept the concept of Debian Maintainers

[NOKUBI Takatsugu]

... Ah, I mistook again... Sorry and ignore please...
-- 
NOKUBI Takatsugu
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED] / [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mercredi 25 juillet 2007 à 16:17 -0400, Marvin Renich a écrit :
>> My original message was specifically concerned with graphical apps.  I'm
>> not sure which console apps should be displayed; for the most part, I
>> think the Debian maintainer should decide whether it deserves to be
>> displayed by default.
>
> I still disagree. The policy should enforce detailed tagging that allows
> window managers and menu systems maintainers to filter out entries they
> don't want to display.

ACK

>> Window managers *definitely* should be displayed.  If I went to the
>> trouble of installing sawfish in addition to metacity, I would like to
>> be able to use both.  Yes, from the menu.
>
> Sorry, but the menu is not a holdall where we put all functionality that
> we don't know where to put without thinking a few minutes.
>
> A window manager choice has nothing to do in an application menu, as it
> is not an application. This is a matter for a configuration tool,
> whatever form it takes.

The Debian menu has more Categories than just applications.  In
particular, it has a category for window managers.

If you desktop environment guys want to go a different way and hide this
category (and instead allow for window manager switching somewhere else,
like some control center) that's fine.  But that doesn't say that window
managers shouldn't have a menu file, or .desktop if that is going to be
its successor.

>> > Why shouldn't we attempt to make menus usable?
>> 
>> I didn't say we should not make them usable, I said we should not try to
>> make them more usable *by reducing access to less frequently used apps*.
>
> As things are, even with the best possible menu system one can imagine,
> you won't manage to make a menu with 500 entries as usable as one with
> 100.

Could you give guidelines how a maintainer of an application should
classify their app, and how Gnome would decide which classes to hide?

>> > Guess what, toolbars are not used by a good share of users.
>
>> Also, my experience is that a good share of less-technically-oriented-
>> but-comfortable-using-a-computer users actually do use toolbars.
>
> These affirmations are not contradictory. I don't deny that many users
> make use of their toolbar, but I think we should keep the menu usable
> for users who don't.

I don't use a toolbar, but for me "usable" means that everything is
there... 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: First call for vortes: GR: Accept the concept of Debian Maintainers

[NOKUBI Takatsugu]

> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 211227d8-5b0a-4ff4-8837-915d24867d33
> [ 1 ] Choice 1: Endorse the concept of Debian Maintainers
> [ 2 ] Choice 2: Further discussion
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-


pgpGOsF5C3aim.pgp
Description: PGP signature

Re: Installing Recommends by default

[Steve Langasek]

On Wed, Jul 25, 2007 at 08:54:27PM +0200, Reinhard Tartler wrote:
> Frank Küster <[EMAIL PROTECTED]> writes:

> >> $ apt-cache show lsb-release | grep Rec
> >> Recommends: lsb, apt
> >> $ apt-cache show lsb | grep Dep
> >> Depends: lsb-core, lsb-graphics, lsb-cxx, lsb-desktop, lsb-qt4
> >> $

> >> That makes for some rather hefty packages pulled in via this Recommends
> >> line.

> > I see.  I had the impression that there is a consensus that our tools
> > should install Recommends by default in lenny.  If that is the only bug
> > that really causes a problem in this respect, why not increase it's
> > severity?  Chris, what do you think about it?

> I think this example shows that installing Recommends by default alone
> is hardly a solution which serves the majority of users.

I disagree.  I think what it shows is that currently, Debian policy's
description of the 'Recommends' field is not very well adhered to by
existing packages.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Josselin Mouette]

Le mercredi 25 juillet 2007 à 19:35 +0200, Frank Küster a écrit :
> >> Menus, by their nature, are inherently unusable for the most frequently
> >> used apps, and we should not be trying to make them more usable at the
> >> expense of making less frequently used apps harder to access.
> >
> > Why shouldn't we attempt to make menus usable?
> 
> Because, as Marvin wrote in the text you cite, the drawback is that it
> makes less frequently used applications harder to access.

If an application is used so infrequently, it shouldn't have its place
in a menu. Furthermore, in the case a user needs it more often, he can
add it to the menu. This becomes even easier if the menu entry is only
hidden, not absent.

> There are other ways to make menus usable even for frequently used
> applications, without these drawbacks:  For example, if a user can
> influence the order of entries, that would help much more.

Or that could be even more confusing.

> But I agree with Marvin (and that's also my usage scheme) that menus
> should provide access to the less frequently used applications, not the
> ones started very often.  I don't have toolbars in my WM, but it starts
> the frequently used apps without asking me, so I use the menu for the
> rare ones.

This is also my usage scheme: everyday apps in the session, less
frequently used apps in the menu, rarely used apps in a terminal or a
launching tool.

> I have little experience with such users; the ones I know and would call
> "computer illiterate" use the windows desktop or the Mac dock for
> starting their pet applications.  If there's actually a considerable
> number of people who don't even get that far, I'm not sure how to help
> them.  Maybe you are right, and hiding stuff is a possibility.
> Automatically moving the often-used entries to a well-visible toolbar is
> an alternative; I generally don't like if computers change their
> appearance based on what they perceive my usage patterns, but maybe it's
> the better choice here than hiding.

Things like slab are an attempt in this direction, by making frequently
used applications automatically directly accessible, but last time I
looked at it I was not convinced at all by the result. I also agree that
changing the appearance depending on usage is not a good idea.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: adding desktop files to misc packages

[Marvin Renich]

* Frank Küster <[EMAIL PROTECTED]> [070725 10:08]:
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster <[EMAIL PROTECTED]> 
> > wrote:
> >> Mike Hommey <[EMAIL PROTECTED]> wrote:
> >> 
> >> > On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich <[EMAIL 
> >> > PROTECTED]> wrote:
> >> >> Absolutely *wrong*.
> >> >> 
> >> >> Gnome and KDE are targeted primarily at desktop users, not servers.  If,
> >> >> as a desktop user, I install a graphical app on my machine, I *expect*
> >> >> to see that app in the main menu.  The place where I put important
> >> >> and/or frequently used apps is on a panel/toolbar.
> >> >
> >> > If you install the python interpreter on your machine, do you also 
> >> > expect it
> >> > to appear in the main menu ?
> >> 
> >> No, why do you ask?  The python interpreter isn't a graphical
> >> application.  It also doesn't have a menu entry, so there's nothing to
> >> hide. 
> >
> > You obviously never looked at the Debian menu.
> 
> How do you come to that conclusion?  On the contrary, I use it
> frequently (there's other menu in my WM).  
> 
> But from Marvin's sentence (which I think is right) 
> 
> ,
> | If, as a desktop user, I install a graphical app on my machine, I
> | *expect* to see that app in the main menu
> `
> 
> you cannot conclude on his (or my) expectations regarding python, because
> python is not a graphical application.
> 

Thanks Frank; that is exactly what I meant.

...Marvin

PS  Please do not CC me when replying to the list, I am subscribed.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#434651: debian-policy: New virtual package: wims-extra

[Magnus Holmgren]

On Wednesday 25 July 2007 17:35, José L. Redrejo wrote:
> So, I propose to add this entry to the virtual package list:
>
> wims-extra - extra exercises, translations and modules that enhance wims
> functionalities.

I don't think you need to have wims-extra added to the virtual package names 
list. There is an exception in policy for virtual package names 
used "privately, amongst a cooperating group of packages", which the wims and 
wims-related packages seem to be.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpqVpx9y2sov.pgp
Description: PGP signature

Re: Is Andrew Lau (netsnipe) MIA?

[Roger Leigh]

Adeodato Simó <[EMAIL PROTECTED]> writes:

Hi dato,

> * Miles Bader [Wed, 25 Jul 2007 19:57:42 +0900]:
>
>> The openexr package also seems to be fairly out of date -- the current
>> debian version is 1.2.2 (from 2005); the latest release version (from
>> savannah.nongnu.org) is 1.5.0.
>
>> [I filed a wishlist bug saying this about 6 months ago, with no reply yet.]
>
> I've been pondering becoming a co-maintainer of this package for a while
> now. I may upload the new version in the near future, if nobody else
> beats me to it.

I was planning on orphaning cinepaint, cupsys-pt and openexr and
asking getting debian-qa to adopt them.

Given that Andrew Lau has been MIA for nearly a year and a half, I
don't see a problem if you wanted to hijack openexr.  I have attempted
to contact Andrew, but have not yet received a reply.  cinepaint
probably needs removing; it's very buggy and is dead upstream.  I will
probably request its removal in a month or so, barring any contact
with Andrew.  cupsys-pt could be adopted by the Debian Printing Group,
but as this is also another legacy GTK+-1.2 application with no
upstream, it should probably also be removed.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpDFiBRFkZb5.pgp
Description: PGP signature