Your message dated Mon, 16 Jul 2007 15:04:04 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Bug#128681: [PROPOSAL]: Debian Menu Policy
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case
Here it is - a complete package. Hopefully it can now be posted on
debian-devel, only you approval is missing, Bill.
Regards,
Linas
P.S. Sorry for CC'ing you, could not resist.
-- The Menu Structure --
Applications [was:Apps]
Normal applications. This is top level
section, do not put entries
One more thing. I have just noticed that we have one very content
oriented subsection in "Games".
> Sports
> Games derived from real world sports.
> billard-gl, csmash, asciijump
Yes, "Sports". The games it contains are not in any way identifiable by
the way they interact with player.
It seems t
Linas Zvirblis <[EMAIL PROTECTED]> wrote:
> Network/Communication (merged "Mail and News")
> Mail, USENET news, chat, instant messaging,
> IP telephony, video conferencing software.
> xchat, gaim, mutt
>
> Network/Web News
> Web feed (RSS, Atom etc.)
> and podcast aggregators.
> akregator,
Frank Küster wrote:
> I want menu entries (on the top level, of course), for "emacs -f gnus",
> "emacs -f dired", "emacs -f svn-status", "emacs -f doctor" etc.
How about a single entry named "Do it!" instead? :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Tro
Frank Küster wrote:
> That sounds good; you can also use "Usenet News", I think that's even
> the official term, http://www.ietf.org/rfc/rfc1036.txt.
Here goes...
Network/Mail and News
Mail and USENET News clients,
mail notification applets etc.
mutt, thunderbird, tin
>> Although I am not
Linas Zvirblis <[EMAIL PROTECTED]> wrote:
> How about?
>
> Network/Mail and News
> Mail and News/Usenet clients,
> mail notification applets etc.
> mutt, thunderbird, tin
That sounds good; you can also use "Usenet News", I think that's even
the official term, http://www.ietf.org/rfc/rfc1036.
Linas Zvirblis <[EMAIL PROTECTED]> wrote:
> Some people depend on a word processor as much as some on terminal
> emulator. So should word processors be available in a top level section?
I want menu entries (on the top level, of course), for "emacs -f gnus",
"emacs -f dired", "emacs -f svn-status"
Yavor Doganov wrote:
>>> I see your point. But then there is no reason to separate terminal
>>> emulators from other applications, therefore I suggest moving them to
>>> "Applications/Terminal Emulators". It might confuse old users, but
>>> having things organized in a consistent intuitive way is
Frank Küster wrote:
>>Network/Mail [new]
>>Mail and Usenet readers, mail
>>notification applets etc.
>>mutt, thunderbird, tin
> [...]
>>Network/News [new]
>>Newsfeed and podcast agregators.
>>akregator, kitty, liferea
>
> Usenet readers are more frequently called "news
On Thu, 30 Mar 2006 12:44:18 +0200, Bill Allombert wrote:
> On Mon, Mar 20, 2006 at 12:12:40AM +0200, Linas Zvirblis wrote:
>>
>> I see your point. But then there is no reason to separate terminal
>> emulators from other applications, therefore I suggest moving them to
>> "Applications/Terminal Em
Linas Zvirblis <[EMAIL PROTECTED]> wrote:
> Unless there is something obviously wrong with the draft, I guess it is
> now ready for public announcement on debian-devel. The "translate_menu"
> file is also almost done. Did I forget anything?
Sounds good. One point though:
>Network/Mail [new]
Bill Allombert wrote:
>> Another alternative would be:
>>
>> Screen/Security - for locking
>> Screen/Power- for blanking the screen
>
> I don't think anybody will guess what that means...
> (Especially if the Screen Security team start to wear "Screen Power!"
> tee-shirt).
Yes, that could be
On Mon, Mar 20, 2006 at 12:12:40AM +0200, Linas Zvirblis wrote:
> Bill Allombert wrote:
>
> > Well I see the Terminal entry as a window-manager specific
> > configuration, so it does not belong in Debian menu.
>
> I see your point. But then there is no reason to separate terminal
> emulators from
Bill Allombert wrote:
> Well I see the Terminal entry as a window-manager specific
> configuration, so it does not belong in Debian menu.
I see your point. But then there is no reason to separate terminal
emulators from other applications, therefore I suggest moving them to
"Applications/Terminal
On Sat, Feb 04, 2006 at 10:31:31PM +0200, Linas Zvirblis wrote:
> Bill Allombert wrote:
>
> >This is icons and translations. Both are going to be handled specially
> >and I won't be able to accept their addition until the special way is
> >implemented. I won't repeat the detail in this thread, bu
Bill Allombert wrote:
This is icons and translations. Both are going to be handled specially
and I won't be able to accept their addition until the special way is
implemented. I won't repeat the detail in this thread, but feel free
to ask for them if you cannot find them in the archive.
Does
On Thu, Feb 02, 2006 at 10:37:09PM +0200, Linas Zvirblis wrote:
> Bill Allombert wrote:
>
> >More precisely which field would be needed ?
>
> I was thinking about Name[locale], GenericName[locale] and
> Comment[locale]. Also maybe adding icon24x24, icon48x48 and iconSVG (or
> some of them) coul
Bill Allombert wrote:
More precisely which field would be needed ?
I was thinking about Name[locale], GenericName[locale] and
Comment[locale]. Also maybe adding icon24x24, icon48x48 and iconSVG (or
some of them) could be useful for fancy desktop environments.
I have no objection providing
On Sat, Jan 28, 2006 at 11:45:43PM +0200, Linas Zvirblis wrote:
> Bill Allombert wrote:
>
> >Note that menu actually allow programms to create there own 3rd level
> >(or 4th level) section for private purpose, to group related entries
> >(like xteddy and mozilla does). There is no need to document
Bill Allombert wrote:
Note that menu actually allow programms to create there own 3rd level
(or 4th level) section for private purpose, to group related entries
(like xteddy and mozilla does). There is no need to document them.
Of course there is, to make it easier for translators. I know that
On Sat, Jan 28, 2006 at 02:38:41AM +0200, Linas Zvirblis wrote:
> Bill Allombert wrote:
>
> >Try
> >
> >translate section->section
> > Apps/Database "Apps/Data management"
> >endtranslate
> >
> >substitute section->section
> > Apps/Applications/
> >endtranslate
>
> Thank you, that wor
Bill Allombert wrote:
Try
translate section->section
Apps/Database "Apps/Data management"
endtranslate
substitute section->section
Apps/Applications/
endtranslate
Thank you, that worked. Things suddenly started making sense after
couple hours of sleep. Anyway, I have one more
On Mon, Jan 23, 2006 at 11:40:33PM +0200, Linas Zvirblis wrote:
> Bill Allombert wrote:
>
> >You are correct in that menu handle third level sections fine.
> >What is missing is the support for automatically flattening the
> >third level sections if they are nearly empty.
>
> Would that not caus
Bill Allombert wrote:
You are correct in that menu handle third level sections fine.
What is missing is the support for automatically flattening the
third level sections if they are nearly empty.
Would that not cause "I installed one more package and menu changed all
of the sudden" confusion
On Sun, Jan 22, 2006 at 06:32:59PM +0200, Linas Zvirblis wrote:
> Bill Allombert wrote:
>
> >The main issue I have is that I did not make progress in implementing
> >the handling of third level sections in menu.
>
> What is missing? There already are third level entries like "Apps >
> System > A
Bill Allombert wrote:
The main issue I have is that I did not make progress in implementing
the handling of third level sections in menu.
What is missing? There already are third level entries like "Apps >
System > Admin". Or am I confusing something?
We should avoid renaming sections if w
On Tue, Jan 10, 2006 at 04:39:46PM +0200, Linas Zvirblis wrote:
> I did not receive any feedback, but posting this little update anyway.
>
> New things include:
>
> Accessibility
> Project Management
> TV and FM Radio
>
> I do realize that I might have got carried away a bit, but this was
>
I did not receive any feedback, but posting this little update anyway.
New things include:
Accessibility
Project Management
TV and FM Radio
I do realize that I might have got carried away a bit, but this was
going to happen sooner or later, I guess. Please do look at it and post
your comme
So here is another update of the draft.
I decided to add a section called "Mobile devices" for tools that allow
interfacing with mobile phones, PDA's, portable audio players etc. I do
not have much experience with such tools, but it seems a good idea as I
noticed that most of them are either i
Frank Küster wrote:
I didn't know this (and the only dictionary I use from the menu, ding,
is in "Tools". Just submitted a bug report.
10% of *everything* in Debian Menu is in "Tools". A lot of bug reports
will be needed once it will be no more...
--
To UNSUBSCRIBE, email to [EMAIL PROTEC
Linas Zvirblis <[EMAIL PROTECTED]> wrote:
> Frank Küster wrote:
>
>> Where would timetable managers (KOrganizer...), group task trackers,
>> etc. be sorted, both one-person-standalone, group-wise-networked, and
>> connect-me-to-my-palm, or allinone?
>
> Office?
Fine.
>> I guess dictionaries, the
James R. Van Zandt wrote:
To go along with
Apps/Math
Apps/Science
I suggest
Apps/Engineering
We have quite a few finite element programs that could go there.
Electronics applications should either go there, or else add
Apps/Engineering/Electronics
These definitely need to be reorga
Frank Küster wrote:
Where would timetable managers (KOrganizer...), group task trackers,
etc. be sorted, both one-person-standalone, group-wise-networked, and
connect-me-to-my-palm, or allinone?
Office?
I guess dictionaries, thesauri etc. are best in databases, but maybe the
name should some
Linas Zvirblis <[EMAIL PROTECTED]> wrote:
> This is what we have so far.
>
>
> Draft 0.3 [2005-12-13] (Only covers Apps)
>
> Section: Apps/Databases
> Description: Interactive database programs, including collection managers,
> bibliography tools etc.
> Example apps: gaby, alexandria, mdbto
To go along with
Apps/Math
Apps/Science
I suggest
Apps/Engineering
We have quite a few finite element programs that could go there.
Electronics applications should either go there, or else add
Apps/Engineering/Electronics
Would you put photo management software (annotation, tagging,
c
Linas Žvirblis <[EMAIL PROTECTED]> wrote:
>> I don't think we should exclude them from Apps/Science without bothering
>> to provide an alternative (they would end up in misc, wouldn't they?).
>> So either we create Apps/Science/humanities, or we change the
>> description of the Science section so
This is what we have so far.
Draft 0.3 [2005-12-13] (Only covers Apps)
+ Apps
|
| - Admin
| - Databases
| - Editors
| - Education
| - Electronics
| - Emulators
| - File management
| - Graphics
| - Hamradio
| - Math
| - Misc
|
| + Net
| | - Chat
| | - File transfer
| | - Mail
I don't think we should exclude them from Apps/Science without bothering
to provide an alternative (they would end up in misc, wouldn't they?).
So either we create Apps/Science/humanities, or we change the
description of the Science section so that social sciences and
humanities are allowed in.
Linas Zvirblis <[EMAIL PROTECTED]> wrote:
> Hi, Frank,
>
>> It seems "Science" here has the meaning "natural sciences", I guess
>> that's usual in english. But how about pieces of software for social
>> sciences or humanities (I don't know of any, because I'm a biochemist,
>> but for sure there a
Section:Apps/CD and DVD
Description:Software for CD/DVD burning and related tools
Example apps: graveman, gnome-baker, dvdisater
We should probably try to be more generic here.
What about merging this with File Management? (dvdisaster would fit into
System just fine)
Well we
Hi, Frank,
It seems "Science" here has the meaning "natural sciences", I guess
that's usual in english. But how about pieces of software for social
sciences or humanities (I don't know of any, because I'm a biochemist,
but for sure there are some)?
Probably too few to bother, if any.
And I
Hi Linas, hi Bill,
> [M]
> Section: Apps/Science
> Description: Scientific programs used by medics, teachers, biologists etc.
> Example apps: ncbi-epcr, earth3d, therion
It seems "Science" here has the meaning "natural sciences", I guess
that's usual in english. But how about pieces of sof
On Sat, Dec 10, 2005 at 06:41:56PM +0200, Linas ??virblis wrote:
> While I am at it, here is an update. Hope you will find it useful.
> [+]
> Section: Apps/CD and DVD
> Description: Software for CD/DVD burning and related tools
> Example apps: graveman, gnome-baker, dvdisater
We should proba
While I am at it, here is an update. Hope you will find it useful.
Draft 0.2 [2005-12-10] (Only covers Apps)
Draft 0.1 [2005-12-08] (Only covers Apps)
Legend:
[!] Unmodified
[M] Modified
[+] New
[?] Need more information and/or unsure about what to do with it
Apps (normal applications):
[+]
Se
Please see Debian policy 9.6. Menus:
Oh, thanks. I do miss obvious things from time to time.
I would personnaly keep openoffice.org-cacl and openoffice.org-math from
Math and only keep softwares that are used for mathematics rather than
accounting, etc. but I am biaised fue to my work.
I inc
On Thu, Dec 08, 2005 at 11:55:37PM +0200, Linas Zvirblis wrote:
> One more thing on the policy. I did not manage to locate anything about
> the requirement of having a menu entry. It seems that it is completely
> optional. Maybe it should not be? There is no good reason for an
> interactive prog
Bill Allombert wrote:
I am certainly interested with your draft, provide you keep backward
compatibility as much as is practical. We are just at the right time of
the release to update the Debian menu sub-policy for Etch.
Here it is (tab indented text file, long lines). As I have already
men
On Wed, Dec 07, 2005 at 04:02:56PM +0200, Linas ??virblis wrote:
> There are many more examples, but the point is that it is very difficult
> (if not impossible) to predict the location of an entry in a menu.
>
> I would suggest redefining Debian Menu sub-policy to include more
> detailed sectio
Hello,
The thing that bothers me is that Debian Menu structure is too
simplified (it has even less sections that Debian package repository)
and unclear, so this may lead to confusion about which section does a
package belong in.
For example, there are sections called Tools (simple apps, like
On Tue, 2005-11-15 at 12:08 +0100, Bill Allombert wrote:
> On Mon, Nov 14, 2005 at 09:29:07PM -0700, Dan Car wrote:
> > What do you think about updating debian menu policy to say something
> > about allow a GUI app to update the menus? There is nothing in the
> > current de
On Mon, Nov 14, 2005 at 09:29:07PM -0700, Dan Car wrote:
> What do you think about updating debian menu policy to say something
> about allow a GUI app to update the menus? There is nothing in the
> current debian menu policy that stops this, but there isn't anything in
> th
What do you think about updating debian menu policy to say something
about allow a GUI app to update the menus? There is nothing in the
current debian menu policy that stops this, but there isn't anything in
there that makes it simple either.
My personal opinion is that menu structure is fa
53 matches
Mail list logo
