Re: adding desktop files to misc packages

[Bruce Sass]

On Thu July 26 2007 01:02:57 am Frank Küster wrote:
> Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > 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.

I'm with Frank; what Josselin said only makes sense to me if 
s/menu/panel or quicklauncher/

> > 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.

I don't think there is any clear dividing line between graphical and 
terminal based apps as far as menus go. I routinely use text based apps 
in a windowed environment and if they didn't have a menu entry I would 
make one because having to open up a term and type in a command or 
start pdmenu is kinda silly when there is a menu system a click away.


The only thing I'm getting outta this round of the discussion is that 
anything less than complete flexibility with respect to which items get 
placed in whatever menus would be a mistake. I.e., code the thing up so 
that it is easy to tell it how to build menus instead of writing it to 
conform to any particular idea of how menus are used.


- Bruce

Re: adding desktop files to misc packages

[Mike Hommey]

On Thu, Jul 26, 2007 at 11:38:59AM +0200, Florent Rougon <[EMAIL PROTECTED]> 
wrote:
> SCNR...
> 
> Frank Küster <[EMAIL PROTECTED]> wrote:
> 
> Frank> That turns out not to be the case. If I use an app frequently, then it
> Frank> goes on the toolbar. The menu is for finding infrequently used apps. 
> For
> Frank> a lot of users, browsing the menu is how they find out what's 
> available.
> 
> Mike> IIRC, gnome is going to switch to gnome-main-menu. There is a reason for
> Mike> this.
> 
> [...]
> 
> Frank> I haven't watched the whole video (it being boring to me), but from the
> Frank> reading I still don't understand which of my statements you want to
> Frank> contradict, let alone why.
> 
> Seems very clear to me: it has been almost a decade now since the GNOME
> project tries hard to get rid of every feature that makes their software
> more usable (I'm speaking here about real usability, not about
> eye-candy).
> 
> Witness:
>   - usable completion in the File Open dialog   -> gone
>   - customizable keyboard shortcuts in apps[1]  -> gone

Both are due to gtk, not gnome.

> And now, a usable menu listing available applications is going to be
> replaced by a "thing" where you have to find your casually-used app in a
> 300-entries unstructered list after clicking on "More applications..."
> (exactly as the "Open With..." in MS Windows works, no wonder where they
> got the idea).
> 
> So, yes, there *is* a reason GNOME is going to switch to
> gnome-main-menu: the previous menu still had a little remainder of
> (real) usability.
> 
> 
>   [1] No, don't tell me that it is a simple matter of adding
>   "gtk-can-change-accels=1" to ~/.gtkrc-2.0. This simply *does*
>   *not* *work*. For instance, even with this, you have to go hunt
>   for the specific option in Gimp's Preferences menu before you can
>   at last add your own keyboard shortcuts. Ugh.

Gimp is not a gnome application.

Mike


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

Re: List of (un)sponsored packages on Mentors (approximate)

[Paul TBBle Hampson]

On Mon, Jul 23, 2007 at 06:35:06PM +0200, Bart Martens wrote:
> Here's also a list of packages needing a sponsor.
> http://people.debian.org/~bartm/borg/needssponsor.html

Your title= tagging has unfortunately barfed on my name, due
to the "TBBle" in it causing the quoted string to terminate
early.

(See the openjpeg entry for example)

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgpj7HdCszZoZ.pgp
Description: PGP signature

Re: adding desktop files to misc packages

[Florent Rougon]

SCNR...

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

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

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

[...]

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

Seems very clear to me: it has been almost a decade now since the GNOME
project tries hard to get rid of every feature that makes their software
more usable (I'm speaking here about real usability, not about
eye-candy).

Witness:
  - usable completion in the File Open dialog   -> gone
  - customizable keyboard shortcuts in apps[1]  -> gone

And now, a usable menu listing available applications is going to be
replaced by a "thing" where you have to find your casually-used app in a
300-entries unstructered list after clicking on "More applications..."
(exactly as the "Open With..." in MS Windows works, no wonder where they
got the idea).

So, yes, there *is* a reason GNOME is going to switch to
gnome-main-menu: the previous menu still had a little remainder of
(real) usability.


  [1] No, don't tell me that it is a simple matter of adding
  "gtk-can-change-accels=1" to ~/.gtkrc-2.0. This simply *does*
  *not* *work*. For instance, even with this, you have to go hunt
  for the specific option in Gimp's Preferences menu before you can
  at last add your own keyboard shortcuts. Ugh.

-- 
Florent


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

Re: Installing Recommends by default

[Reinhard Tartler]

Steve Langasek <[EMAIL PROTECTED]> writes:

> 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.

Well, okay, then let's start filing bugs about these, shall we? 

FYI: This one (lsb-release recommending lsb) is filed as #426807, and
already fixed.

Still, I think local admins should have the possibility to set a local
policy on a package basis for blacklisting packages to bridge until the
package gets fixed.

-- 
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

[Wouter Verhelst]

On Thu, Jul 26, 2007 at 11:37:33AM +0200, Josselin Mouette wrote:
> Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit :
> > One thing I do not like about the GNOME usability philosophy is
> > precisely this: catering for the novice user is great, but the GNOME
> > usability philosophy caters for novice users *at the expense of
> > experienced users*. 
> 
> This widespread belief is entirely untrue.

If it is widespread, then there must be at least some truth to that
statement.

> It is all about making things understandable for the novice user
> without reducing functionality for experienced users;

Personally, I feel that you succeed in the first but not in the last.
You may disagree, but it's still why I don't like the GNOME philosophy
about usability: in my opinion, many of the decisions that are made
under the pretext of being good for the novice user have a number of
seriously negative and problematic repercussions to the experienced
user.

Of course, it's okay for GNOME people to do that, as long as they don't
expect me to use their system :-)

> that doesn't mean removing functionality, but rather removing the
> *need* for some functionality or configurability.

You do not remove the need for some functionality by simply removing the
functionality itself altogether, which is what I see GNOME developers do
more often than other developers.

Anyway, this thread is not about GNOME, but about the menu system, so
let's keep it at that. I'll be happy to bash about GNOME on IRC, if you
want me to :-)

[...]
> > If you want to do that in GNOME, go ahead, be my
> > guest; I couldn't care less anyway. And in fact, I installed GNOME on my
> > parent's machine, since I don't want to have to repeatedly explain them
> > too much, so your philosophy has some uses. But please don't expand that
> > philosophy to the rest of the Debian system, where it is totally
> > useless.
> 
> I have no business into changing other environments' menus.

If you are going to modify the menu system, then that is exactly what
you're doing, even if you want to modify it so that the changes remain
mostly limited to GNOME: by removing the Debian menu from GNOME or
modifying it so that it doesn't show what's available in all other
graphical environments that are available in Debian, you're confusing
users. Users who have used Debian (but not GNOME) before, users who
use Debian with GNOME on one machine and a lightweight window manager on
another (because, say, that other machine has less resources), and so
on.

I think one of the great selling points of Debian is precisely this
unified menu system: no matter what window manager or graphical
environment you use, there is still this single menu system that will be
there, and that will contain all these applications; it is one of the
few things that distinguishes Debian from other distributions.

Throwing it out because you don't like the way it is structured just as
it's about to be restructured seems like throwing out the kid along with
the bath water to me. The right way would be to improve the menu system,
so that you can be happy with it. After all, I'll be the first to agree
that the way the menu system is structured currently is suboptimal.
Having it everywhere, with all applications visible, *except* in GNOME,
would be a big, big shame.

However, I can agree that the menu system can use some improvements, and
that some things (the Python example came up, but surely more can be
found) simply don't belong in the menu. If you can come up with some
examples, I'm sure we can discuss them, do a mass bug filing, and/or
update the menu policy to reflect the stuff we agree on.

[...]
> > I'll agree that some things could be finetuned, and that some things
> > simply don't belong in the menu system. But these things are exceptions,
> > and I think most of the applications that are in the menu system
> > currently do belong there.
> > 
> > Speaking of "modifying the interface", one reason why I think the GNOME
> > people have the idea that nobody ever modifies their interface is that
> > it is simply too hard to modify the interface in GNOME. 
> 
> I don't think anyone claimed that nobody does modify their interface.
> The problem is that the very idea of modifying it is not intuitive.

Then you need to work on that.

> > Adding an icon to the panel or the desktop should be a drag-and-drop
> > operation.
> 
> It is.

Not in my experience. I'll be happy to provide details if you want me
to.

> > Changing the desktop background should not require me to add the
> > image to a list of background images first before I can pick it from
> > that list. 
> 
> Whoa? The background properties capplet features a button that spawns a
> file chooser in which you can choose a picture and get done with it.

I've had to explain that point to my dad far too often.

> And that's for the complicated way; otherwise it's just a matter of
> right-clicking on the picture in epiphany and selecting "use a

Re: adding desktop files to misc packages

[Florent Rougon]

Mike Hommey <[EMAIL PROTECTED]> wrote:

>> >> Witness:
>> >>   - usable completion in the File Open dialog   -> gone

[...]

> Note that AFAIK, completion never disappeared from the file open dialogs.
> You just have to enable it with a keystroke.

I know that; the shortcut is Ctrl-L. But I wrote "usable completion"
because even after hitting Ctrl-L, the kind of completion you get is
*much* less efficient than that you got for free in the good old days of
GTK+ 1.2. IOW, there is no usable completion in GNOME's current File
Open/Save dialogs (neither in Qt, for that matter :-/).

> Even if not, it is a problem with gimp if it refuses to set menu shortcuts
> if you change gtk-can-change-accels in your config.

OK, it's not GNOME. But I had the impression that the original feature,
which was accessible out-of-the-box, was removed/made inaccessible
*because* of GNOME's concerns about "usability". That is why I brought
this point here.

-- 
Florent


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

Re: adding desktop files to misc packages

[Florent Rougon]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> For your information, this was ironic. There is no compositing manager
> in metacity as no one seemed interested enough in developing it.

Ah, I see. Not everyone follows the development of every window manager
on earth, so you couldn't really expect me to get your irony. Anyway...

> Another unfounded assumption: that you need to configure your shortcuts
> to be more productive.

Err, did you ever wonder why Emacs is so popular among people who
actually use their computer?

> A good application should come up with good shortcuts already
> configured. Plus, they should be similar across applications. This is so
> that you don't get lost in front of another account or a new
> application.

I disagree. Applications are different; they provide different features,
and therefore cannot have the same shortcuts except for a handful of
things, such as copy, paste and quit. If you only accept "standard
shortcuts", then all other features are not accessible from the
keyboard, with the result that in most cases, the app won't be very
usable, unless there are means to customize one's own shortcuts.

> The GTK+ development used to be close to that of GIMP, but now it is
> sticking to the GNOME releases and is mostly done by GNOME developers.
> GIMP has still its own team, working with its insane development process
> with one release each time hell freezes.

Okay, so at least this confirms my impression that the GTK+ development
is heavily influenced by the GNOME project.

-- 
Florent


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

Re: List of (un)sponsored packages on Mentors (approximate)

[Kumar Appaiah]

On Thu, Jul 26, 2007 at 07:50:49PM +1000, Paul TBBle Hampson wrote:
> Your title= tagging has unfortunately barfed on my name, due
> to the "TBBle" in it causing the quoted string to terminate
> early.

Well, I don't think this page is necessary anymore, since better
options to check this are available (courtesy this thread). So, don't
bother too much; that page is going away in a while! :-)

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


signature.asc
Description: Digital signature

Bug#434794: ITP: assogiate -- an editor for the GNOME file types database

[Ken Bloom]

Package: wnpp
Severity: wishlist
Owner: Ken Bloom <[EMAIL PROTECTED]>


* Package name: assogiate
  Version : 0.2.1
  Upstream Author : Kevin Daughtridge <[EMAIL PROTECTED]>
* URL : http://www.kdau.com/projects/assogiate/
* License : GPL
  Programming Lang: C++
  Description : an editor for the GNOME file types database

assoGiate is an editor of the file types database for GNOME.  It
allows users to modify the detection and display of file types.

I have patched this version with a component from libeel to allow
users to set the preferred application use to open a document.

I am in need of a sponsor, packages are at
http://lingcog.iit.edu/~bloom/assogiate/ (I've pbuildered them
already, and I'll fix the one last lintian warning as soon as I have a
bug number for this ITP.)

--Ken

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.20-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: List of (un)sponsored packages on Mentors (approximate)

[Raphael Geissert]

On 26/07/07, Kumar Appaiah <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 26, 2007 at 07:50:49PM +1000, Paul TBBle Hampson wrote:
> > Your title= tagging has unfortunately barfed on my name, due
> > to the "TBBle" in it causing the quoted string to terminate
> > early.
>
> Well, I don't think this page is necessary anymore, since better
> options to check this are available (courtesy this thread). So, don't
> bother too much; that page is going away in a while! :-)

He was talking about Bart's page.
I've made some changes to your script in order to improve it's results.
The modified script can be downloaded from here:
http://files.myopera.com/atomo64/files/mentors_comp.py
and the results generated by the modified script:
http://files.myopera.com/atomo64/files/output.test.html

I've also modified it so it doesn't show the 'handled' RFS'.

>
> Kumar
> --
> Kumar Appaiah,
> 462, Jamuna Hostel,
> Indian Institute of Technology Madras,
> Chennai - 600 036
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGqLdySd75awtatOcRAnM8AJ4lYbfhMM2XJeM0XiyOsZNZhrMjMACfZCQD
> ZvVbURkxCSJvkfNtzy10ELI=
> =z4zJ
> -END PGP SIGNATURE-
>
>

Regards,
-- 
Atomo64 - Raphael

Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Say NO to Microsoft Office broken standard.
See http://www.noooxml.org/petition


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

Bug#434826: ITP: eresi -- ERESI Reverse Engineering Software Interface

[Andrés Roldán]

Package: wnpp
Severity: wishlist
Owner: "Andrés Roldán" <[EMAIL PROTECTED]>


* Package name: eresi
  Version : 0.78b3
  Upstream Author : The ERESI team <[EMAIL PROTECTED]>
* URL : http://www.eresi-project.org/
* License : GPL
  Programming Lang: C, C++, Assembly
  Description : ERESI Reverse Engineering Software Interface

The ERESI Reverse Engineering Software Interface is a unified
multi-architecture binary analysis framework enhanced for UNIX operating
systems based on the Executable & Linking Format (ELF). ERESI has a real
dedicated reverse engineering language that makes it programmable and
adaptable to the precise needs of its users. The framework provides more
than 10 innovative and exclusive features that turns it into an
environment of choice for the instrumentation, analysis, debugging,
tracing, hooking, or simply integrity checking and events logging of
binary programs. As for the visual interface, it has an advanced
interactive command line and it can generate pictures of different kind
of graphs on demand, using its automated code analysis primitives. 

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Re: adding desktop files to misc packages

[Joey Hess]

Steve Greenland wrote:
> 1. The format that will be used by Debian packages to specify their menu
> entry. I think the consensus in this thread is that the FDo format is
> better and more flexible than the current Debian menu system format.

I wouldn't argue that it's better or more flexible. It is, however, a
broadly accepted standard, and quite likely "good enough".

> Transitioning to the FDo format is doable by coding a menu-method for
> each WM/panel/whatever that does not currently support the FDo format
> directly, and adjusting the menu package to prefer FDo format entries
> over the current format.

Once menu is able to read .desktop files, and extract the same
information from them that it extracts from menu file, there should be
no need of any new menu-methods.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Joey Hess]

Frank Küster wrote:
> > 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.

Window managers are already not displayed on the gnome or kde menus.
Hiding all text-mode programs from those menus could be accomplished
trivially:

[EMAIL PROTECTED]:~>diff -u /etc/menu-methods/xdg-desktop-entry-spec-apps 
xdg-desktop-entry-spec-apps 
--- /etc/menu-methods/xdg-desktop-entry-spec-apps   2006-03-20 
08:44:23.0 -0500
+++ xdg-desktop-entry-spec-apps 2007-07-26 18:35:53.0 -0400
@@ -25,7 +25,6 @@
 
 supported;
  x11 = AppEntry("false");
- text = AppEntry("true");
 endsupported;
 
 startmenu = "";

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Installing Recommends by default

[Steve Greenland]

On 26-Jul-07, 02:25 (CDT), Reinhard Tartler <[EMAIL PROTECTED]> wrote: 
> Still, I think local admins should have the possibility to set a local
> policy on a package basis for blacklisting packages to bridge until the
> package gets fixed.

man apt_preferences:


   P < 0
   prevents the version from being installed


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: adding desktop files to misc packages

[Steve Greenland]

On 26-Jul-07, 13:41 (CDT), Russ Allbery <[EMAIL PROTECTED]> wrote: 
> Steve Greenland <[EMAIL PROTECTED]> writes:
> 
> > 3. The actual contents and structure of the default menu in each WM etc.
> > This is a matter of Policy and ENTIRELY orthogonal to issues 1 and 2.
> > In particular, just saying "we're going to use the FDo format now" does
> > nothing to prevent the kind of mess you see in the Debian menu. OTOH,
> > setting an acceptable policy would clean up not only the GNOME menu but
> > all the other menu systems.
> 
> Except that the freedesktop.org specification comes with its own set of
> categories, registration system, and classification system, which does not
> match the Debian system.  I suppose we could use the format without using
> its categorization system, but that seems a bit strange and Debian's
> current menu structure doesn't have the concept of primary and additional
> categories the way that the freedesktop.org specification does.

That's okay. It's just a simple matter of policy making :-)

Or, the Debian GNOME maintainers (and KDE maintainers, etc.) can just
ignore the Debian menu entries and make a package of FDo menu entries
for all the packages they want in their menu. 

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: adding desktop files to misc packages

[Wouter Verhelst]

On Thu, Jul 26, 2007 at 04:33:17PM +0200, Josselin Mouette wrote:
> Le jeudi 26 juillet 2007 à 12:59 +0200, Wouter Verhelst a écrit :
> > You do not remove the need for some functionality by simply removing the
> > functionality itself altogether, which is what I see GNOME developers do
> > more often than other developers.
> 
> This seems to be based solely on hearsay. 

No, this is based on me using GNOME for about nine months in 2005 until
I got fed up with the behaviour I described.

[...]
> The Debian menu in GNOME has been secondary for quite some time, and the
> source of confusion is rather having two menus than having a menu which
> isn't the same as WindowMaker's.

I'm not saying there isn't confusion in having two menu systems.

I'm saying there's *also* confusion in having a menu which isn't the
same as WindowMaker's, but for a different class of users than the ones
that will get confused by having two menu systems.

> > I think one of the great selling points of Debian is precisely this
> > unified menu system: no matter what window manager or graphical
> > environment you use, there is still this single menu system that will be
> > there, and that will contain all these applications; it is one of the
> > few things that distinguishes Debian from other distributions.
> 
> This used to be true five years ago. Now, other distributions have moved
> and worked on their menu systems, and Debian has not.

Hmm. I must admit I haven't tried another distribution in years.

[...]
-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
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 jeudi 26 juillet 2007 à 12:59 +0200, Wouter Verhelst a écrit :
> You do not remove the need for some functionality by simply removing the
> functionality itself altogether, which is what I see GNOME developers do
> more often than other developers.

This seems to be based solely on hearsay. 

> Anyway, this thread is not about GNOME, but about the menu system, so
> let's keep it at that.

Well, I'm interested in a menu system which is usable for GNOME; which
means if it has to be shared with other environments with different
paradigms, the system has to be flexible enough.

> > I have no business into changing other environments' menus.
> 
> If you are going to modify the menu system, then that is exactly what
> you're doing, even if you want to modify it so that the changes remain
> mostly limited to GNOME: by removing the Debian menu from GNOME or
> modifying it so that it doesn't show what's available in all other
> graphical environments that are available in Debian, you're confusing
> users. Users who have used Debian (but not GNOME) before, users who
> use Debian with GNOME on one machine and a lightweight window manager on
> another (because, say, that other machine has less resources), and so
> on.

The Debian menu in GNOME has been secondary for quite some time, and the
source of confusion is rather having two menus than having a menu which
isn't the same as WindowMaker's.

> I think one of the great selling points of Debian is precisely this
> unified menu system: no matter what window manager or graphical
> environment you use, there is still this single menu system that will be
> there, and that will contain all these applications; it is one of the
> few things that distinguishes Debian from other distributions.

This used to be true five years ago. Now, other distributions have moved
and worked on their menu systems, and Debian has not.

> Throwing it out because you don't like the way it is structured just as
> it's about to be restructured seems like throwing out the kid along with
> the bath water to me. The right way would be to improve the menu system,
> so that you can be happy with it. After all, I'll be the first to agree
> that the way the menu system is structured currently is suboptimal.
> Having it everywhere, with all applications visible, *except* in GNOME,
> would be a big, big shame.

Show me the code. If this wonderful menu system existed somewhere
outside your imagination, I guess we could happily used it.

Meanwhile, real world people have moved to the freedesktop menu, which
despite its flaws is more flexible, more beautiful and allows a better
structure designed for each environment.

> > I don't think anyone claimed that nobody does modify their interface.
> > The problem is that the very idea of modifying it is not intuitive.
> 
> Then you need to work on that.

Work on brainwashing users so that they want to modify their interface?
What if they don't care and just want something working out of the box?

> > > Adding an icon to the panel or the desktop should be a drag-and-drop
> > > operation.
> > 
> > It is.
> 
> Not in my experience. I'll be happy to provide details if you want me
> to.

Please file a bug with details, yes.

> > And that's for the complicated way; otherwise it's just a matter of
> > right-clicking on the picture in epiphany and selecting "use as
> > background".
> 
> This should also be possible in nautilus, IMO.

This is already the case in eog (which is the default image viewer).

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

Bug#434748: ITP: qink -- Simple printer ink level monitor based on libinklevel and Qt4

[Le_Vert]

Package: wnpp
Severity: wishlist
Owner: "Adam Cécile (Le_Vert)" <[EMAIL PROTECTED]>

* Package name: qink
  Version : 0.3.1
  Upstream Author : Moris Ravasio <[EMAIL PROTECTED]>
Matvey Kozhev <[EMAIL PROTECTED]> (current maintainer)
* URL : http://code.google.com/p/qink/
* License : GPL
  Programming Lang: C++
  Description : Simple printer ink level monitor based on libinklevel and 
Qt4

QInk is a simple printer ink level monitor based on libinklevel.
.
It is a fork of KInk (development of which ceased in 2003), but ported 
to Qt4 and the most recent, API-incompatible versions of libinklevel.
.
 Homepage: http://code.google.com/p/qink/


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (400, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Re: adding desktop files to misc packages

[Mike Hommey]

On Thu, Jul 26, 2007 at 02:07:17PM +0200, Josselin Mouette <[EMAIL PROTECTED]> 
wrote:
> Le jeudi 26 juillet 2007 à 13:35 +0200, Florent Rougon a écrit :
> > > Eye candy... oh right, this must be why there are so many people
> > > interested in bringing a compositing manager to metacity, rather than
> > > improving performance or rendering quality.
> 
> For your information, this was ironic. There is no compositing manager
> in metacity as no one seemed interested enough in developing it.

Actually, there is one.

> > YMMV, but IMHO, I don't think compositing will much improve my
> > efficiency at using a computer (and that's precisely where I measure
> > "usability").
> 
> Exactly my point, thanks.

Actually, it can help improve usability, but that is OT.

Mike


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

[OT] Gnome usability [Was: adding desktop files to misc packages]

[Andreas Tille]

[Sorry for beeing OT - it will be my only contribution to this thread]

On Thu, 26 Jul 2007, Josselin Mouette wrote:


Le jeudi 26 juillet 2007 à 13:33 +0200, Andreas Tille a écrit :

I found (at least one) counter example:  I never managed to get rid
of the stupid nautilus behavour to open new windows.


Edit -> Preferences -> Behaviour -> Always open in navigation windows

If the option name isn't clear enough, feel free to propose an alternate
wording; there's definitely room for improvement here.


Well, there is no doubt that there is anywhere in the n-th hierarchy
of option settings menu the option I'm looking for is hidden.  It is
just the question whether I'm willing to spend my time to seek for
it and I have to admit - I'm not.  This is no particular Gnome feature -
I even prefer Gnome over KDE for the same reason.


> the GNOME usability philosophy caters for novice users *at the
> expense of experienced users*.

This widespread belief is entirely untrue.


My mail was about telling you that the quote above is _not_ _entirely_
_untrue_ because I would consider myself an experienced user and I
told you only one problem I have to safe the time of the readers of
this list.


I was even not
able to get rid of this nautilus thingy at all because killing it opens
a new one.


This is intentional, nautilus is a fundamental piece of the desktop. You
can remove it by editing the session, still.


Sure there is such an option - but it is just deeply hidden.


So the proposition was disproved by a counter example and thus is not true.


This is because of wrong assertions on your side: that you need nautilus
not to run, for example.


Well, it is the usual way what I'm doing with every program that does
not what I want it to do.

My mail was rather not about criticising Gnome (or KDE).  It was about
ignorance of developers who just refuse to hear at their potential
users and just ignore problems they do not like.  If I would hear
wide spread rumors about the program I want to make better I would
try to find out what really causes the rumor instead of telling people
who share the same idea as those "rumors" that they are just not right.

To became on-topic again: It is quite similar with the rumor that
Debian is not for newbees.  While I personally don't think so I try
to listen to those people who share this idea and ask them why they are
using something else instead of telling them: You are not right.

Got the idea?

  Andreas.

--
http://fam-tille.de

Re: adding desktop files to misc packages

[Josselin Mouette]

Le jeudi 26 juillet 2007 à 08:25 +0200, Frank Küster a écrit :
> > 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.

As long as they are consistently tagged, I have nothing against .desktop
files for window managers.

This category doesn't exist in the freedesktop specification, but you
can add new categories, like X-WindowManager.

> Could you give guidelines how a maintainer of an application should
> classify their app,

Using categories described in [0] is a good start. The maintainers would
also have to agree on new categories if the ones listed are not
sufficient.

Also, the OnlyShowIn field is a good one for applications that are
really too KDE- or GNOME-specific to be shown in other menus. On the
contrary, NotShowIn should be used if similar functionality is available
in one or several environments and displaying an icon would only be a
source of confusion.

For applications that aren't useful in the general case, NoDisplay=true
should be set. Let me show an example: gstreamer-properties used to have
an icon in the menu. In current releases, the appropriate sinks to use
(esd, alsa, etc.) are autodetected which means there is no *need* for
users to launch it, and this allowed us to set NoDisplay=true. The same
should hold for configuration dialogs that are specific to an
application and already available from it.

> and how Gnome would decide which classes to hide?

ConsoleOnly, Shell, Screensaver, X-WindowManager are good candidates. We
could also exclude things like FileManager as nautilus is always
launched, for example. Sound judgement should do the rest.

 [0] http://standards.freedesktop.org/menu-spec/latest/apa.html

-- 
 .''`.
: :' :  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 jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit :
> One thing I do not like about the GNOME usability philosophy is
> precisely this: catering for the novice user is great, but the GNOME
> usability philosophy caters for novice users *at the expense of
> experienced users*. 

This widespread belief is entirely untrue. It is all about making things
understandable for the novice user without reducing functionality for
experienced users; that doesn't mean removing functionality, but rather
removing the *need* for some functionality or configurability.

Many Unix users are used to a high level of configurability, and it is
definitely frustrating not to encounter it when you are used to. But in
the end I find myself gaining a lot of time, because the only things
that are shown in the interface are the things I actually need.

> If you want to do that in GNOME, go ahead, be my
> guest; I couldn't care less anyway. And in fact, I installed GNOME on my
> parent's machine, since I don't want to have to repeatedly explain them
> too much, so your philosophy has some uses. But please don't expand that
> philosophy to the rest of the Debian system, where it is totally
> useless.

I have no business into changing other environments' menus. This is why
I suggested that we keep the Debian menu as it is for those who prefer
it. As people seem to want to switch to the freedesktop menu given its
superiority, I only want to ensure the GNOME menu is improved by the
process rather than being turned into garbage.

> I'll agree that some things could be finetuned, and that some things
> simply don't belong in the menu system. But these things are exceptions,
> and I think most of the applications that are in the menu system
> currently do belong there.
> 
> Speaking of "modifying the interface", one reason why I think the GNOME
> people have the idea that nobody ever modifies their interface is that
> it is simply too hard to modify the interface in GNOME. 

I don't think anyone claimed that nobody does modify their interface.
The problem is that the very idea of modifying it is not intuitive.

> Adding an icon
> to the panel or the desktop should be a drag-and-drop operation.

It is.

> Changing the desktop background should not require me to add the
> image to a list of background images first before I can pick it from
> that list. 

Whoa? The background properties capplet features a button that spawns a
file chooser in which you can choose a picture and get done with it. And
that's for the complicated way; otherwise it's just a matter of
right-clicking on the picture in epiphany and selecting "use as
background".

> These are useless hoops to jump through; and even Windows has
> been doing this correctly for about 10 years.

Talking about Windows in a thread about menus sounds... well, no
comment.

-- 
 .''`.
: :' :  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 Tille]

On Thu, 26 Jul 2007, Josselin Mouette wrote:


Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit :

One thing I do not like about the GNOME usability philosophy is
precisely this: catering for the novice user is great, but the GNOME
usability philosophy caters for novice users *at the expense of
experienced users*.


This widespread belief is entirely untrue.


This is the proposition.


It is all about making things
understandable for the novice user without reducing functionality for
experienced users; that doesn't mean removing functionality, but rather
removing the *need* for some functionality or configurability.

Many Unix users are used to a high level of configurability, and it is
definitely frustrating not to encounter it when you are used to. But in
the end I find myself gaining a lot of time, because the only things
that are shown in the interface are the things I actually need.


I found (at least one) counter example:  I never managed to get rid
of the stupid nautilus behavour to open new windows.  I was even not
able to get rid of this nautilus thingy at all because killing it opens
a new one.  I just renamed it and killed it to get rid of.

So the proposition was disproved by a counter example and thus is not true.

q.e.d.

  Andreas.

--
http://fam-tille.de

Re: adding desktop files to misc packages

[Mike Hommey]

On Thu, Jul 26, 2007 at 01:13:13PM +0200, Florent Rougon <[EMAIL PROTECTED]> 
wrote:
> Hi,
> 
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> 
> >> Witness:
> >>   - usable completion in the File Open dialog   -> gone
> >>   - customizable keyboard shortcuts in apps[1]  -> gone
> >
> > Both are due to gtk, not gnome.
> 
> From my limited end-user POV (a user who used to like GTK+ and GNOME in
> the old days), I had the impression that it is the GNOME project that
> influenced the GTK+ team in this way. Do you think this is wrong?

There might be influence, but not every change in gtk is due to gnome.
Note that AFAIK, completion never disappeared from the file open dialogs.
You just have to enable it with a keystroke.

> >>   [1] No, don't tell me that it is a simple matter of adding
> >>   "gtk-can-change-accels=1" to ~/.gtkrc-2.0. This simply *does*
> >>   *not* *work*. For instance, even with this, you have to go hunt
> >>   for the specific option in Gimp's Preferences menu before you can
> >>   at last add your own keyboard shortcuts. Ugh.
> >
> > Gimp is not a gnome application.
> 
> Hmmm. If GTK+ decisions are not influenced by the GNOME project, fair
> enough. But I doubt this is the case...

Even if not, it is a problem with gimp if it refuses to set menu shortcuts
if you change gtk-can-change-accels in your config.

Mike


-- 
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 26-Jul-07, 04:37 (CDT), Josselin Mouette <[EMAIL PROTECTED]> wrote: 
> I have no business into changing other environments' menus. This is why
> I suggested that we keep the Debian menu as it is for those who prefer
> it. As people seem to want to switch to the freedesktop menu given its
> superiority, I only want to ensure the GNOME menu is improved by the
> process rather than being turned into garbage.

Sigh. You're still conflating 3 issues: 

1. The format that will be used by Debian packages to specify their menu
entry. I think the consensus in this thread is that the FDo format is
better and more flexible than the current Debian menu system format.
Transitioning to the FDo format is doable by coding a menu-method for
each WM/panel/whatever that does not currently support the FDo format
directly, and adjusting the menu package to prefer FDo format entries
over the current format.

2. Whether or not we can just dump the Debian menu system in favor of
the FDo system. IMPORTANT: by "Debian menu system" I mean the ability to
support the same menu entry (as specified by the package, in whatever
format we choose) in a variety of WMs, menu systems, etc. I don't think
this is acceptable to most of the participants in this thread. (Which
doesn't keep the GNOME desktop maintainers from ignoring the Debian menu
entries.)

3. The actual contents and structure of the default menu in each WM etc.
This is a matter of Policy and ENTIRELY orthogonal to issues 1 and 2.
In particular, just saying "we're going to use the FDo format now" does
nothing to prevent the kind of mess you see in the Debian menu. OTOH,
setting an acceptable policy would clean up not only the GNOME menu but
all the other menu systems.

Regards,
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: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Meanwhile, real world people have moved to the freedesktop menu, which
> despite its flaws is more flexible, more beautiful and allows a better
> structure designed for each environment.

Tell me, in which world do I live if its not the real world?

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

Draft: empty source package (was: Re: Reasonable maximum package size ?)

[Michael Hanke]

Hi,

On Tue, Jul 24, 2007 at 06:01:38PM -0400, Yaroslav Halchenko wrote:

> > I guess an evil solution to *** that doesn't cause problems with ###
> > would be to create a dummy source package that Build-Depends: on the
> > exact version of the package it builds, so that uploads include a
> > >...<
> here is where I got stuck with such approach: conventionally I just
> dgetted sources and tried to build the package with dpkg-buildpackage.
> Of cause I failed to accomplish the mission since Build-Depends weren't
> satisfied... so indeed it seems to be confusing or my brain is not
> working now...
> 
> My suggestion (I might be duplicating someone else' idea, please pardon
> me) -- for arch 'all': automatically download (copy) data during
> build of the package.  I know that somewhere now I will hit the roof in
> debian policy, but for whatever it is worth.
I tried to implement Anthony Towns idea of the 'empty' source packages. I
attached a tarball with my current draft. It contains a source package and the
two binary packages it builds.

If you want to try it, extract the source package (and do not install the
binary packages). Try building it -- it fails because the binary
packages with the required data is missing. Override the
dependency-check with e.g. debuild -d

Now the package builds the two binary packages that are also in the
tarball. This is achieved by invoking an included script that gets the
data from 'upstream'.

The source package makes use of CDBS and debhelper. The core parts are
the rules file with two special targets:
 - orig-src: build the orig.tar.gz (what else)
 - populate-src-package: import the required datasets from available
   sources.

+ a special clean target.

The core of the populate-src-package target is a call to a script called
dh_datapkg. It checks whether the binary packages (it builds) are
installed and copies the required datasets from the installed packages
using dh_install configuration. When no binary packages are availabe it
invokes a custom script that can download the data from somewhere (or
whatever).

The 'special' clean target takes care of adding the build-dependencies
to all arch indep packages that are build by the source package and also
cleans the datasets from the source package -- again by using dh_install
configuriation.

I applied this idea to two different 'in-house' data packages with each
1GB we use here and it seems to be a flexible and convenient approach.

However, one currently cannot use everything that debhelper allows you
to do (dh_installexamples, dh_installdocs). But I think this 'empty'
source package concept should be limited to real dataset packages, so
this should not be a major problem.

Any comments?

If such package with 800 MB of brain data would hit the NEW queue, what would
happen?

Is it still to big? Should the upstream license be part of the orig.tar.gz
or is the debian/copyright sufficient? Anything else missing?


Cheers,

Michael


-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


datapkdemo.tar.gz
Description: Binary data


signature.asc
Description: Digital signature

Re: adding desktop files to misc packages

[Josselin Mouette]

Le jeudi 26 juillet 2007 à 13:35 +0200, Florent Rougon a écrit :
> > Eye candy... oh right, this must be why there are so many people
> > interested in bringing a compositing manager to metacity, rather than
> > improving performance or rendering quality.

For your information, this was ironic. There is no compositing manager
in metacity as no one seemed interested enough in developing it.

> YMMV, but IMHO, I don't think compositing will much improve my
> efficiency at using a computer (and that's precisely where I measure
> "usability").

Exactly my point, thanks.

> > This feature, despite its coolness, was more a source of annoyance by
> > setting shortcuts by mistake than anything else.
> 
> I don't remember having been bitten by it (it might be, but at least if
> it did happen, it didn't leave any bad sequels ;-). And anyway, if
> you're bitten once, you learn; it takes you, what, one minute? And then
> you'll be more productive. Not during one minute, *always* (well, until
> they remove said feature...).

Another unfounded assumption: that you need to configure your shortcuts
to be more productive.

A good application should come up with good shortcuts already
configured. Plus, they should be similar across applications. This is so
that you don't get lost in front of another account or a new
application.

> > The software you are talking about was rejected for inclusion in GNOME
> > 2.18, and is not part of the GNOME 2.19 desktop.
> 
> Err, but didn't Mike write:
> 
>   IIRC, gnome is going to switch to gnome-main-menu.
> 
> So? It is not (currently) part of the GNOME 2.19 desktop, you say, but
> it is just a matter of time? i.e., are you playing on words, or actually
> contradicting Mike?

I'm not aware of such a move. Currently gnome-main-menu is not part of
the proposed modules for 2.20. This could still change, of course, but
last time it was proposed there was a strong opposition among
developers.

> > This is a problem in GIMP, not in GNOME.
> 
> Hmmm. GOTO my-answer-to-mike. Nothing to add here.

The GTK+ development used to be close to that of GIMP, but now it is
sticking to the GNOME releases and is mostly done by GNOME developers.
GIMP has still its own team, working with its insane development process
with one release each time hell freezes.

-- 
 .''`.
: :' :  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

[Wouter Verhelst]

On Wed, Jul 25, 2007 at 06:57:54PM +0200, Josselin Mouette 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?

Some of them. The ``mc'' file manager is an example of a console
application that I expect to find in the menu. So are the games from the
``bsdgames'' package. The ``fortune'' program is an example of something
I do not expect to find there.

> All interpreters and shells?

No, certainly not.

> Window managers?

Yes. Some window managers support starting another window manager
without terminating the X session, which is an interesting feature. The
"window managers" menu entry is only shown in those window managers that
have this feature, anyway, so I don't see why it should be hidden in
others.

Perhaps a menu method implementation should be allowed to place the
"Window Managers" menu someplace else than right along with the other
menu entries (the "logout" menu in IceWM, or the "System" menu in GNOME
spring to mind), but that's about it.

> > 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.

I think you are mixing two distinct matters in this argument.

If a user installs the distribution with default settings and finds that
too much software is available in the menu, then this is an indication
of there being too much software being installed by default. Rather than
aiming to reduce the usefulness of the menu system, you should be aiming
to reduce the number of useless applications installed by default.

If the user starts a session on a multi-user setup that has way too many
entries in the menu, then this is an indication of a sysadmin not doing
their job properly. Not much we can do about that, except properly
documenting (with examples) how a sysadmin can modify the menu system so
that they can hide certain classes of applications to certain classes of
users.

> > 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 by making them more usable for the frequent user in the way you
are suggesting, you make them *less* usable for the casual user. This is
a tradeoff; and since I believe the menu system is mainly meant for the
casual user (frequent users have scripts or panel shortcuts or desktop
icons anyway, or they know the menu system by heart and don't care how
much applications there are), I don't think we should be reducing the
usefulness of the menu system for the casual user.

> > 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.

Guess what, toolbars are used by most users I know of.

> Toolbars sound obvious for experienced users, but a novice will never
> have the idea to modify the interface that is shown to him;

One thing I do not like about the GNOME usability philosophy is
precisely this: catering for the novice user is great, but the GNOME
usability philosophy caters for novice users *at the expense of
experienced users*. If you want to do that in GNOME, go ahead, be my
guest; I couldn't care less anyway. And in fact, I installed GNOME on my
parent's machine, since I don't want to have to repeatedly explain them
too much, so your philosophy has some uses. But please don't expand that
philosophy to the rest of the Debian system, where it is totally
useless.

I'll agree that some things could be finetuned, and that some things
simply don't belong in the menu system. But these things are exceptions,
and I think most of the applications that are in the menu system
currently do belong there.

Speaking of "modifying the interface", one reason why I think the GNOME
people have the idea that nobody ever modifies their interface is that
it is simply too hard to modify the interface in GN

Re: adding desktop files to misc packages

[Florent Rougon]

Hi,

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Eye candy... oh right, this must be why there are so many people
> interested in bringing a compositing manager to metacity, rather than
> improving performance or rendering quality.

YMMV, but IMHO, I don't think compositing will much improve my
efficiency at using a computer (and that's precisely where I measure
"usability").

To be efficient, I don't need *one* desktop with little miniatures of
windows I don't currently work with, because these windows, even if
small, take up useful screen space. My efficient way of working is to
have each major app (which requires almost the full screen, programs
running in xterms are different) in its own workspace, and to be able to
reach each of them *directly* with one keystroke (where "directly"
means: not having to hit Alt-right-arrow or whatever and needing to
check each time, until the desired workspace appears).

To switch to the workspace where Galeon usually runs, I hit Alt-1.
To switch to the workspace where Emacs usually runs, I hit Alt-2.
To switch to the workspace where I put my first xterms, I hit Alt-3.

...

If I want to do work as root, this is Alt-6.

Every task has a *direct* shortcut that brings me right there in a
fraction of a second. /That/ is efficient. And I don't see how
compositing will improve that. Sure, it's nice, but for me, this mostly
counts as eye-candy.

(for those who're wondering: I'm using WindowMaker; which does have its
flaws, but has a simple and quite efficient workspace handling)

>> Witness:
>>   - usable completion in the File Open dialog   -> gone
>
> And back in GTK 2.10.

Oh, dear, how many years have we been waiting for this? I'm longing to
see it. :)

> This feature, despite its coolness, was more a source of annoyance by
> setting shortcuts by mistake than anything else.

I don't remember having been bitten by it (it might be, but at least if
it did happen, it didn't leave any bad sequels ;-). And anyway, if
you're bitten once, you learn; it takes you, what, one minute? And then
you'll be more productive. Not during one minute, *always* (well, until
they remove said feature...).

> Plus, as you wrote later, it is hidden, not removed.

It was quite convenient to use. Now, it is relatively difficult to use,
if not impossible (do all GNOME apps support it nowadays?). And it's
even more difficult to discover if nobody tells you about it, since you
can't find it "by mistake" anymore.

> The software you are talking about was rejected for inclusion in GNOME
> 2.18, and is not part of the GNOME 2.19 desktop.

Err, but didn't Mike write:

  IIRC, gnome is going to switch to gnome-main-menu.

So? It is not (currently) part of the GNOME 2.19 desktop, you say, but
it is just a matter of time? i.e., are you playing on words, or actually
contradicting Mike?

> This is a problem in GIMP, not in GNOME.

Hmmm. GOTO my-answer-to-mike. Nothing to add here.

-- 
Florent


-- 
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 jeudi 26 juillet 2007 à 13:33 +0200, Andreas Tille a écrit :
> I found (at least one) counter example:  I never managed to get rid
> of the stupid nautilus behavour to open new windows.  

Edit -> Preferences -> Behaviour -> Always open in navigation windows

If the option name isn't clear enough, feel free to propose an alternate
wording; there's definitely room for improvement here.

> I was even not
> able to get rid of this nautilus thingy at all because killing it opens
> a new one.  

This is intentional, nautilus is a fundamental piece of the desktop. You
can remove it by editing the session, still.

> So the proposition was disproved by a counter example and thus is not true.

This is because of wrong assertions on your side: that you need nautilus
not to run, for example.

-- 
 .''`.
: :' :  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

[Ross Burton]

On Thu, 2007-07-26 at 13:33 +0200, Andreas Tille wrote:
> I found (at least one) counter example:  I never managed to get rid
> of the stupid nautilus behavour to open new windows.

In Nautilus enable Edit -> Preferences -> Behaviour -> Always open in
browser windows.

> I was even not
> able to get rid of this nautilus thingy at all because killing it opens
> a new one.  I just renamed it and killed it to get rid of.

If you don't use nautilus, why not remove the package?  If you want to
keep the package installed but never use it, why not remove it from the
session?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part

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

[Georges Khaznadar]

Thank you Magnus for this quick reply.

Just one point: I have read the paragraph about cooperating groups of
packages too, and I did not figure exactly what to do.

As we are to make a virtual package named wims-something, there is little
chance that we are going to annoy other people, since nobody will choose
the prefix "wims" for her packages in a near future unless they are
related  to the wims project hosted at wims.unice.fr currently. So there
is little foreseeable side-effect.

Does it mean that in such a case, creating the virtual package and
dropping one notice would be enough? If so, just don't reply, or agree,
and we proceed.

Best regards,   Georges.


Magnus Holmgren a écrit :
> 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)



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Re: Is Andrew Lau (netsnipe) MIA?

[Roger Leigh]

"Paul Wise" <[EMAIL PROTECTED]> writes:

> 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.

Hmm, I missed that when I checked on it.  I must have been looking at
a filtered view of the download section.  Let's hope it fixes some of
the major bugs; I had it repeatedly segfault on me when I tried fairly
simple operations (such as changing the bit depth).

Is anyone interested in picking up cinepaint?


Thanks,
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.


pgpPIIX1VB6oH.pgp
Description: PGP signature

Re: [OT] Gnome usability [Was: adding desktop files to misc packages]

[Ross Burton]

On Thu, 2007-07-26 at 14:10 +0200, Andreas Tille wrote:
> >> I found (at least one) counter example:  I never managed to get rid
> >> of the stupid nautilus behavour to open new windows.
> >
> > Edit -> Preferences -> Behaviour -> Always open in navigation windows
> >
> > If the option name isn't clear enough, feel free to propose an alternate
> > wording; there's definitely room for improvement here.
> 
> Well, there is no doubt that there is anywhere in the n-th hierarchy
> of option settings menu the option I'm looking for is hidden.  It is
> just the question whether I'm willing to spend my time to seek for
> it and I have to admit - I'm not.  This is no particular Gnome feature -
> I even prefer Gnome over KDE for the same reason.

N-th hierarchy?  Seeking?

Edit->Preferences isn't exactly buried.  I'd say that most applications
have the preferences there.

The Preferences dialog has four tabs.  One of them is called Behaviour.
Under that the third button is "Always open in browser windows".

I don't call that buried away, or hidden.  It's about as visible as it
could be without actually being a toggle button in the nautilus toolbar,
which would be silly.

> > This is intentional, nautilus is a fundamental piece of the desktop. You
> > can remove it by editing the session, still.
> 
> Sure there is such an option - but it is just deeply hidden.

Preferences -> Session -> Current Session -> Remove is "deeply hidden"?
Can you suggest a better location?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part

Re: adding desktop files to misc packages

[Russ Allbery]

Steve Greenland <[EMAIL PROTECTED]> writes:

> 3. The actual contents and structure of the default menu in each WM etc.
> This is a matter of Policy and ENTIRELY orthogonal to issues 1 and 2.
> In particular, just saying "we're going to use the FDo format now" does
> nothing to prevent the kind of mess you see in the Debian menu. OTOH,
> setting an acceptable policy would clean up not only the GNOME menu but
> all the other menu systems.

Except that the freedesktop.org specification comes with its own set of
categories, registration system, and classification system, which does not
match the Debian system.  I suppose we could use the format without using
its categorization system, but that seems a bit strange and Debian's
current menu structure doesn't have the concept of primary and additional
categories the way that the freedesktop.org specification does.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#434740: ITP: btanks -- Fast 2d tank arcade game with multiplayer and split-screen modes

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz <[EMAIL PROTECTED]>


* Package name: btanks
  Version : 0.5.4539
  Upstream Author : Vladimir Menshakov <[EMAIL PROTECTED]>
* URL : http://btanks.sourceforge.net
* License : GPL
  Programming Lang: C++
  Description : fast 2D tank arcade game with multiplayer and split-screen 
modes

Battle Tanks is a funny battle on your desk, where you can choose one of
three vehicles and eliminate your enemy using the whole arsenal of
weapons. has original cartoon-like graphics and cool music, it is fun
and dynamic, it has several network modes for deathmatch and
cooperative.

What else is needed to have fun with your friends?


-- 
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 jeudi 26 juillet 2007 à 11:38 +0200, Florent Rougon a écrit :
> Seems very clear to me: it has been almost a decade now since the GNOME
> project tries hard to get rid of every feature that makes their software
> more usable (I'm speaking here about real usability, not about
> eye-candy).

Eye candy... oh right, this must be why there are so many people
interested in bringing a compositing manager to metacity, rather than
improving performance or rendering quality.

> Witness:
>   - usable completion in the File Open dialog   -> gone

And back in GTK 2.10.

>   - customizable keyboard shortcuts in apps[1]  -> gone

This feature, despite its coolness, was more a source of annoyance by
setting shortcuts by mistake than anything else. Plus, as you wrote
later, it is hidden, not removed.

> And now, a usable menu listing available applications is going to be
> replaced by a "thing" where you have to find your casually-used app in a
> 300-entries unstructered list after clicking on "More applications..."
> (exactly as the "Open With..." in MS Windows works, no wonder where they
> got the idea).
> 
> So, yes, there *is* a reason GNOME is going to switch to
> gnome-main-menu: the previous menu still had a little remainder of
> (real) usability.

The software you are talking about was rejected for inclusion in GNOME
2.18, and is not part of the GNOME 2.19 desktop.

>   [1] No, don't tell me that it is a simple matter of adding
>   "gtk-can-change-accels=1" to ~/.gtkrc-2.0. This simply *does*
>   *not* *work*. For instance, even with this, you have to go hunt
>   for the specific option in Gimp's Preferences menu before you can
>   at last add your own keyboard shortcuts. Ugh.

This is a problem in GIMP, not in GNOME.

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

Bug#434838: ITP: libcompress-base-perl -- base Class for IO::Compress modules

[Damyan Ivanov]

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov <[EMAIL PROTECTED]>

* Package name: libcompress-base-perl
  Version : 2.005
  Upstream Author : Paul Marquess <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~pmqs/
* License : same as Perl (choose Artistic or GPL)
  Programming Lang: Perl
  Description : base Class for IO::Compress modules

Abstract Perl classes, subclassed by other IO::Compress modules like
Compress::Zlib, IO::Compress::GZip etc.

Contains:
 * File::GlobMapper (alpha release)
 * IO::Compress::Base
 * IO::Compress::Base::Common
 * IO::Uncompress::AnyUncompress
 * IO::Uncompress::Base
===
This package is needed by the new upstream release of
libcompress-zlib-perl. See #434639

--
dam


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

Re: ITP: libcompress-base-perl -- base Class for IO::Compress modules

[Damyan Ivanov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

retitle 434838 ITP: libio-compress-base-perl -- base Class for IO::Compress 
modules
thanks

 -=| Damyan Ivanov, 27.07.2007 07:48 |=-
> * Package name: libcompress-base-perl
The proper name is of course libio-compress-base-perl.

- --
dam JabberID: [EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqX7gHqjlqpcl9jsRAtbHAJ44lChZyxtE7C75eHNXc+Hbzg0npQCfUA4p
+CXMCRrTIR1ph+CL/+WurfY=
=XgZV
-END PGP SIGNATURE-


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

Bug#434840: ITP: libio-compress-zlib-perl -- perl interface for manupulatin gzip and zip files

[Damyan Ivanov]

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov <[EMAIL PROTECTED]>

* Package name: libio-compress-zlib-perl
  Version : 2.005
  Upstream Author : Paul Marquess <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~pmqs/IO-Compress-Zlib-2.005/
* License : same as Perl (choose Artistic or GPL)
  Programming Lang: Perl
  Description : perl interface for manupulatin gzip and zip files

Provides object-oriented Perl interface for working with files,
supported by zlib - gzip, zip, inflate/deflate

Contains the following modules:
 * IO::Compress::Adapter::Deflate
 * IO::Compress::Adapter::Identity
 * IO::Compress::Deflate   Write RFC 1950 files/buffers
 * IO::Compress::Gzip  Write RFC 1952 files/buffers
 * IO::Compress::Gzip::Constants
 * IO::Compress::RawDeflateWrite RFC 1951 files/buffers
 * IO::Compress::Zip   Write zip files/buffers
 * IO::Compress::Zip::Constants
 * IO::Compress::Zlib::Constants
 * IO::Compress::Zlib::Extra
 * IO::Uncompress::Adapter::Identity
 * IO::Uncompress::Adapter::Inflate
 * IO::Uncompress::AnyInflate  Uncompress zlib-based (zip, gzip)
   file/buffer
 * IO::Uncompress::Gunzip  Read RFC 1952 files/buffers
 * IO::Uncompress::Inflate Read RFC 1950 files/buffers
 * IO::Uncompress::RawInflate  Read RFC 1951 files/buffers
 * IO::Uncompress::Unzip   Read zip files/buffers
=
This package is needed by the new upstream release of
libcompress-zlib-perl. See #434639


--
dam


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

Work-needing packages report for Jul 27, 2007

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 386 (new: 7)
Total number of packages offered up for adoption: 80 (new: 1)
Total number of packages requested help for: 39 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   djtools (#434099), orphaned 5 days ago
 Description: Tools for HP DeskJet printer
 Installations reported by Popcon: 298

   gringotts (#434519), orphaned 2 days ago
 Description: store passwords in an encrypted file
 Installations reported by Popcon: 148

   libgringotts (#434517), orphaned 2 days ago
 Description: Development files for the Gringotts data encapsulation
   library
 Reverse Depends: gringotts libgringotts-dev
 Installations reported by Popcon: 153

   libwhisker-perl (#434393), orphaned 3 days ago
 Reverse Depends: nikto
 Installations reported by Popcon: 374

   lxdoom (#434100), orphaned 5 days ago
 Description: sound effects server for lxdoom
 Reverse Depends: lxdoom lxdoom-sndserv lxdoom-svga lxdoom-x11
 Installations reported by Popcon: 618

   lxmusserv (#434101), orphaned 5 days ago
 Description: Linux music server for Doom and Heretic
 Installations reported by Popcon: 380

   smpeg-xmms (#434102), orphaned 5 days ago
 Description: SDL MPEG Player Library - XMMS plugin
 Installations reported by Popcon: 398

379 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   xinetd (#434357), offered 3 days ago
 Description: replacement for inetd with many enhancements
 Reverse Depends: firebird1.5-classic firebird2.0-classic
 Installations reported by Popcon: 1799

79 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 763 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client-core
 Installations reported by Popcon: 99

   apt-build (#365427), requested 453 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 801

   apt-cacher (#403584), requested 220 days ago
 Description: caching proxy system for Debian package and source
   files
 Installations reported by Popcon: 353

   apt-show-versions (#382026), requested 352 days ago
 Description: lists available package versions with distribution
 Installations reported by Popcon: 2804

   athcool (#278442), requested 1003 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 284

   cvs (#354176), requested 518 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (17
   more omitted)
 Installations reported by Popcon: 18632

   dpkg (#282283), requested 978 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb clamsmtp crosshurd (87 more
   omitted)
 Installations reported by Popcon: 56474

   dsniff (#430162), requested 34 days ago
 Description: Various tools to sniff network traffic for cleartext
   insecurities
 Installations reported by Popcon: 963

   elvis (#432298), requested 17 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 263

   gentoo (#422498), requested 81 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 257

   gpsdrive (#406522), requested 196 days ago
 Description: Car navigation system
 Installations reported by Popcon: 415

   grub (#248397), requested 1172 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild replicator
 Installations reported by Popcon: 51399

   ispell-et (#391105), requested 295 days ago
 Description: Estonian dictionary for Aspell/Ispell/MySpell
 Installations reported by Popcon: 33

   kradio (#429873), requested 36 days ago
 Description: Comfortable Radio Application for KDE
 Installations reported by Popcon: 247

   lighttpd (#401575), requested 234