51:24 -
Received: (qmail 1435 invoked by uid 500); 14 Apr 1999 09:51:23 -
Date: Wed, 14 Apr 1999 02:51:23 -0700
From: Joey Hess <[EMAIL PROTECTED]>
To: debian-policy@lists.debian.org
Cc: joost witteveen <[EMAIL PROTECTED]>
Subject: [PROPOSED] moving the menu hierarchy into debian pol
Could you also consider this:
Add:
Net/WWW (or Net/Browsers)
Net/IRC
Net/News
Net/FTP
Reasoning:
"Net/, when may clients are installed, is overcrowded making it
difficult to differentiate between them
-BEGIN PGP SIGNED MESSAGE-
"Oliver Elphick" writes:
> I should like to create a menu section Apps/Database, which would be
> appropriate for PostgreSQL Mysql and any others.
Hi,
We're sort of in the middle of a discussion of how to improve the
handling of menu policy and the menu heira
>
> Since I first took on the postgresql database package, I have put menu
> entries for it under Apps/Misc; I wasn't too happy about that, but there
> seemed to be nowhere else suitable. Lintian is bugging me even about that
> location, because it isn't listed in the menu documentation.
>
> I s
Since I first took on the postgresql database package, I have put menu
entries for it under Apps/Misc; I wasn't too happy about that, but there
seemed to be nowhere else suitable. Lintian is bugging me even about that
location, because it isn't listed in the menu documentation.
I should like to c
Sorry if this seems like duplicated info; I just want to keep the bug
report up-to-date. Cc'd to -policy only as a courtesy.
I proposed an amendment to JoeyH's proposal as follows:
Tetris-like - games involving falling blocks
Toys - amusements, eye-candy, etc.
+
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Previously Chris Waters wrote:
> > Well, a) people don't pay attention to it, b) none of the discussions
> > about how and what to change have gotten anywhere, and c) based on the
> > evidence of b, there's actually no reason to believe that it *will
Previously Chris Waters wrote:
> Well, a) people don't pay attention to it, b) none of the discussions
> about how and what to change have gotten anywhere, and c) based on the
> evidence of b, there's actually no reason to believe that it *will* be
> changing anytime soon, beyond the proposal that
James LewisMoss <[EMAIL PROTECTED]> writes:
> I agree with Wichert. It's already pseudo-policy (everyone pays
> attention to it). Why put it into the policy manual now if it will
> shortly be changing?
Well, a) people don't pay attention to it, b) none of the discussions
about how and what to c
> On Sat, 1 May 1999 14:53:31 -0700, Joey Hess <[EMAIL PROTECTED]> said:
Joey> Wichert Akkerman wrote:
>> I still feel this way. I really don't see the advantage of putting
>> something in policy right now when we already know it's going to
>> be overhauled anyway. So I guess I propose pos
I agree with Wichert in that first we should agree on a complete
menu structure before making it policy, we already have a base we can work
with, and there were many proposals in it.
I think adding the base to the policy and then changing it would be
a) confusing to people
or is he the lone objector?
I cee his point, and I don't disagree with it. I'm kinda indifferent,
but I do see the point he's trying to make and agree that it's necessary
to modify the menu hierarchy, either now or after it becomes policy.
Either way it needs to happen a
Wichert Akkerman wrote:
> I still feel this way. I really don't see the advantage of putting
> something in policy right now when we already know it's going to be
> overhauled anyway. So I guess I propose postponing this until
> after the overhaul.
I'll say again - it can help enourmously to have
Previously Joey Hess wrote:
> Then the discussion died down. On reviewing the discussion, it looks
> like no-one disagrees that some menu structure should be added to
> policy, but there is some disagreement that the suggested structure
> should go in as-is.
>
> To summarize what people said:
>
>
Joey Hess <[EMAIL PROTECTED]> writes:
>...
> * You need to put commonly accessed menus as close to the root as possible.
> That's why the XShells menu is right on the root, because we know people
> start more xterms than anything else.
Would it be possible to implement drag&drop for menus? If
Peter S Galbraith <[EMAIL PROTECTED]> writes:
> Fabien Ninoles wrote:
>
> >For sure, sections are a good hint to where menu entries
> > goes but they can be different elsewhere you'll get empty menu
> > sections and other too much populate.
>
> Joey Hess wrote:
>
> > With menus, yo
On Sat, Apr 24, 1999 at 12:16:36AM +0200, Juergen A. Erhard wrote:
> > "Michael" == Michael Bramer <[EMAIL PROTECTED]> writes:
>
> Michael> If I don't miss the point, it is all nice by debian. The
> Michael> user can make overwrite the menu items and the menu
> Michael> methods in
ackage sections.
I think this is because both are not ideals ;-) So the creators of the
menu system (or rather, lacking policy, the package/wm maintainers)
chose some hierarchy, similar but not identical to the ftp tree.
>> Yes, I know there's no such thing as a Debian Menu Editor.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Michael" == Michael Bramer <[EMAIL PROTECTED]> writes:
Michael> If I don't miss the point, it is all nice by debian. The
Michael> user can make overwrite the menu items and the menu
Michael> methods in this home dir and can make a
On Wed, Apr 21, 1999 at 06:09:11AM +0200, Juergen A. Erhard wrote:
> > "David" == David Starner <[EMAIL PROTECTED]> writes:
>
> I somewhat agree with you... the only problem being: what if I edited
> my menu and the admin then installs another package, one that I'm not
> interested in?
>
> Wou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "David" == David Starner <[EMAIL PROTECTED]> writes:
[SNIP]
>> I'd propose (if I were a developer), to *not* put everything
>> under the sun into the default menu.
>> Instead, we should make it editable... such that, when the user
s is slightly different from the one
of the package sections.
>
> Yes, I know there's no such thing as a Debian Menu Editor. But I
> think the menu system needs to support editing/customizing the menu
> hierarchy for this to be really useful.
>
> The menu that is displa
"Juergen A. Erhard" wrote:
> Chris> This is why *my* number one, absolute top priority for changes to
> the
> Chris> current menu system is to put in a TOP LEVEL ENTRY NAMED "Help".
> With
> Chris> at least: "Debian Online Help" (currently hidden in Apps/Tools),
> Gnome
> Chri
know there's no such thing as a Debian Menu Editor. But I
think the menu system needs to support editing/customizing the menu
hierarchy for this to be really useful.
The menu that is displayed needs to be separate (on a per-user basis)
From the menu hierarchy in which packages install their e
> "Carl" == Carl R Witty <[EMAIL PROTECTED]> writes:
Carl> Laurent Martelli <[EMAIL PROTECTED]> writes:
>> I think it'd be better to fix window managers so that they can
>> cope with long menus, à la WindowMaker for instance. A decent
>> window manager should be able to do this.
C
Laurent Martelli <[EMAIL PROTECTED]> writes:
> > "Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
>
> Chris> Joey Hess <[EMAIL PROTECTED]> writes:
>
> >> * You need to limit menus to no more than 15 items, 10 is
> >> better. Otherwise they won't fit on some screens.
>
> Chris> This
Quoting Joey Hess <[EMAIL PROTECTED]>:
> [ Note that I think all this discussion is a little premature - I'd still
> like to get the current proposal into policy first. ]
I agree with you, so I move it to debian-devel and change the subject line.
Still need to CC you, joost?
>
> Chris Waters wr
> "Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Joey Hess <[EMAIL PROTECTED]> writes:
>> * You need to limit menus to no more than 15 items, 10 is
>> better. Otherwise they won't fit on some screens.
Chris> This is a whole 'nuther ball of wax. Joost mentioned this
Chr
[ Note that I think all this discussion is a little premature - I'd still
like to get the current proposal into policy first. ]
Chris Waters wrote:
> This is why *my* number one, absolute top priority for changes to the
> current menu system is to put in a TOP LEVEL ENTRY NAMED "Help". With
> at
Chris Waters wrote:
> Well, whichever, I should mention that when I started discussing
> possible changes to menu policy with joost, he said I should go ahead
> and bring it up on -policy, but asked that he be CC'd into the
> discussions, since he's not subscribed to -policty. So, I'd like to
> pa
Joey Hess <[EMAIL PROTECTED]> writes:
> Because they were designed for menus. It's really a very different thing.
> With menus, you have some constraints:
Some of which we can achieve, some maybe not.
> * You need to put commonly accessed menus as close to the root as possible.
> That's why th
ably some disagreements when we start overhauling it, and I think
> getting it into policy is more important than overhauling it (the problems
> with the menu hierarchy as it is now arn't large).
Well, whichever, I should mention that when I started discussing
possible changes to menu policy with
On Wed, Apr 14, 1999 at 02:06:11PM -0400, Peter S Galbraith wrote:
>
> When I started to use Debian, I wondered why the menu sections
> were different categories than the packages sections.
The package sections are a flat list for ftp archive purposes for all Debian
packages.
The menu system is
Fabien Ninoles wrote:
>For sure, sections are a good hint to where menu entries
> goes but they can be different elsewhere you'll get empty menu
> sections and other too much populate.
Joey Hess wrote:
> With menus, you have some constraints:
>
> * You need to put commonly accesse
Quoting Peter S Galbraith <[EMAIL PROTECTED]>:
>
> When I started to use Debian, I wondered why the menu sections
> were different categories than the packages sections.
>
> If the menu sections are so great, why don't we use them to sort
> packages?
>
> If the package sections are so great, wh
so we don't have to
> change policy later..
Well it could be. I just anticipate that there will be a lot of discussion
and probably some disagreements when we start overhauling it, and I think
getting it into policy is more important than overhauling it (the problems
with the menu hierarchy as it is now arn't large).
--
see shy jo
Peter S Galbraith wrote:
> When I started to use Debian, I wondered why the menu sections
> were different categories than the packages sections.
>
> If the menu sections are so great, why don't we use them to sort
> packages?
Because they were designed for menus. It's really a very different thi
When I started to use Debian, I wondered why the menu sections
were different categories than the packages sections.
If the menu sections are so great, why don't we use them to sort
packages?
If the package sections are so great, why don't we use them to sort
menus?
Perhaps this is our chance t
Previously Joey Hess wrote:
> I expect once we get this into policy we'll want to overhaul it a bit. I
> hope we can wait until we've gotten it in to begin that discussion though.
I fail to see why it can't be overhauled first so we don't have to
change policy later..
Wichert.
--
==
On Wed, Apr 14, 1999 at 02:51:23AM -0700, Joey Hess wrote:
> Package: debian-policy
> Severity: wishlist
Seconded.
--
G. Branden Robinson | Reality is what refuses to go away when
Debian GNU/Linux | I stop believing in it.
[EMAIL PROTECTED] | -- Phili
On Wed, Apr 14, 1999 at 02:51:23AM -0700, Joey Hess wrote:
> I propose that the menu hierarchy be taken out of menu.sgml in the menu
> package and added to the policy manual, section 3.6, following the second
> paragraph of that section. [..]
Thirded.
--
Joseph Carter <[EMA
Le Wed, Apr 14, 1999 at 02:51:23AM -0700, Joey Hess écrivait:
> So I'm looking for non-technical corrections to the above, seconds for
> the proposal, and hopefully a consensus on the list that this should become
> a policy amendment.
Seconded.
--
Hertzog Raphaël >> 0C4CABF1 >> http://prope.insa
Package: debian-policy
Severity: wishlist
I propose that the menu hierarchy be taken out of menu.sgml in the menu
package and added to the policy manual, section 3.6, following the second
paragraph of that section. The rationale for doing this is that the menu
hierarchy effects a large number of
43 matches
Mail list logo
