[Desktop-packages] [Bug 66566]

2019-02-22 Thread cousteau
I don't see how removing shift-enter and ctrl-shift-enter is even remotely 
related to the original request of making ctrl-enter open URLs in a new tab.  
In addition, it breaks a preexisting functionality of having shift-enter 
automatically add www. .net and ctrl-shift-enter add www. .org.
Personally, if this feature were really necessary (in which case it should have 
been opened as a separate bug), I would rather have it moved to an unused 
combination.  For example, Windows-enter could be "open in new window" and 
Windows-alt-enter for "open in new tab, but on the background".
Or, if it is really that important to have these shortcuts on shift and 
ctrl-shift, even despite of breaking preexisting behavior and getting a lot of 
users upset, at least make windows-enter and ctrl-windows-enter the new .net 
and .org shortcuts so that this functionality is not lost.
(Or going further: use alt for .com, windows for .net, and alt-windows for 
.org, so that ctrl is left for opening on a new tab, be it from the URL bar or 
from a link on the page; now THAT would solve the inconsistency issue the bug 
originally complained about.)

Ultimately, removing the shortcut for .net and .org but keeping it for
.com somehow suggests that .net and .org sites are "less important" than
.com ones.  I could expect that from a browser developed by google.com
or microsoft.com, but not from one developed by mozilla.org.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/66566

Title:
  Inconsistent shortcuts for new tab

Status in Mozilla Firefox:
  Fix Released
Status in firefox package in Ubuntu:
  Won't Fix
Status in firefox-3.0 package in Ubuntu:
  Won't Fix
Status in firefox-3.5 package in Ubuntu:
  Won't Fix

Bug description:
  There are currently too many shortcuts when opening a link in a new
  tab:

   - location bar:  + 
   - GO button:  + click
   - search bar:  + 
   - SEARCH button  + click
   - links:  + click
   - menu bar:  + click
   - BACKWARD/FORWARD button:  + click

  This is one of the reasons I'm keeping with Opera. There it is always
  the shift key and I have to remember only one key.

  Thanks for reading!

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/66566/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1697122] Re: Package Firefox with MOZ_USE_XINPUT2=1 in environment to enable touch gestures

2018-08-31 Thread cousteau
Counter-argument:  Try to zoom in on a PDF with this option on.  (It
goes in increments of 10% *per pixel*.)

This could be considered a bug on Firefox though, so I guess as soon as
those little things are polished this change could be made (but then
again I guess the Firefox devs would include this option by default
themselves).

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1697122

Title:
  Package Firefox with MOZ_USE_XINPUT2=1 in environment to enable touch
  gestures

Status in firefox package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu version:  Kubuntu 17.04
  Firefox version: 53.0.3+build1-0ubuntu0.17.04.2

  In Firefox, two-finger scroll gestures on a touchpad are interpreted
  as scroll wheel rotations, and the content scrolls three lines at a
  time. This is inappropriate behavior for touchpad scrolling; it should
  scroll pixel-by-pixel.

  Firefox already has the ability to do this, you just need to turn it
  on by running the program with MOZ_USE_XINPUT2=1 in the environment:
  for example, by running `MOZ_USE_XINPUT2=1 firefox`, or adding it to
  /etc/environment or something like that.

  Turning on this behavior yields a large usability improvement for
  laptop users. Therefore, I am proposing that MOZ_USE_XINPUT2=1 be
  permanently added to the packaging such that it's always present when
  Firefox runs. This is what Fedora does, and it results in a much
  improved experience for the laptop user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1697122/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1789704] [NEW] Whiteglass right_ptr pointer points incorrectly

2018-08-29 Thread cousteau
Public bug reported:

The "hot point" for /usr/share/icons/whiteglass/cursors/right_ptr seems
to be off by about 9 pixels (for a cursor size of 32 at least).

This is specially annoying because you're not clicking where you think
you're clicking.  In the attached example, the cursor seems to be
pointing to the "i", but it is actually pointing to the [-] box, so
attempting to select text (without noticing that the pointer is not I
-beam-shaped) results in the [-] box being clicked instead.

This problem does not exist in the redglass theme (which is identical
but in red).

Distro/version:Xubuntu 18.04 64b
Screen resolution: 144 dpi
Pointer theme: whiteglass
Pointer size:  32(but also seems to happen at other sizes)
Graphics card: Nvidia GeForce GTX 1050 Mobile
Graphics driver:   nvidia-driver-390

** Affects: xcursor-themes (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: cursor whiteglass

** Attachment added: "whiteglass_cursor_on_geany.png"
   
https://bugs.launchpad.net/bugs/1789704/+attachment/5182279/+files/whiteglass_cursor_on_geany.png

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xcursor-themes in Ubuntu.
https://bugs.launchpad.net/bugs/1789704

Title:
  Whiteglass right_ptr pointer points incorrectly

Status in xcursor-themes package in Ubuntu:
  New

Bug description:
  The "hot point" for /usr/share/icons/whiteglass/cursors/right_ptr
  seems to be off by about 9 pixels (for a cursor size of 32 at least).

  This is specially annoying because you're not clicking where you think
  you're clicking.  In the attached example, the cursor seems to be
  pointing to the "i", but it is actually pointing to the [-] box, so
  attempting to select text (without noticing that the pointer is not I
  -beam-shaped) results in the [-] box being clicked instead.

  This problem does not exist in the redglass theme (which is identical
  but in red).

  Distro/version:Xubuntu 18.04 64b
  Screen resolution: 144 dpi
  Pointer theme: whiteglass
  Pointer size:  32(but also seems to happen at other sizes)
  Graphics card: Nvidia GeForce GTX 1050 Mobile
  Graphics driver:   nvidia-driver-390

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xcursor-themes/+bug/1789704/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1425972] Re: Firefox no longer supports -remote parameter

2015-03-04 Thread cousteau
When is a patch coming to precise?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to emacs24 in Ubuntu.
https://bugs.launchpad.net/bugs/1425972

Title:
  Firefox no longer supports -remote parameter

Status in exo:
  Fix Released
Status in One Hundred Papercuts:
  Confirmed
Status in emacs24 package in Ubuntu:
  Confirmed
Status in exo package in Ubuntu:
  Confirmed

Bug description:
  When I click a link from an email it does not work any more.

  Instead of opening the link in a new tab, Firefox opens a new empty
  window and does not follow the link.

  If I change the default browser for my desktop from Firefox to Chrome,
  then Chrome can open the link fine.

  I have started seeing this today since firefox was upgraded from v35
  to 36.

  My email client is Mozilla thunderbird at the latest stable version.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: firefox 36.0+build2-0ubuntu0.14.10.4
  ProcVersionSignature: Ubuntu 3.16.0-31.41-generic 3.16.7-ckt5
  Uname: Linux 3.16.0-31-generic x86_64
  AddonCompatCheckDisabled: False
  ApportVersion: 2.14.7-0ubuntu8.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  dpottage   3729 F pulseaudio
  BuildID: 20150224133805
  Channel: Unavailable
  CurrentDesktop: XFCE
  Date: Thu Feb 26 14:30:41 2015
  ForcedLayersAccel: False
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  IncompatibleExtensions:
   English (South Africa) Language Pack - langpack-en...@firefox.mozilla.org
   English (GB) Language Pack - langpack-en...@firefox.mozilla.org
   Français Language Pack - langpack...@firefox.mozilla.org
   Deutsch (DE) Language Pack - langpack...@firefox.mozilla.org
   Default - {972ce4c6-7e08-4474-a285-3208198ce6fd}
  InstallationDate: Installed on 2013-07-02 (604 days ago)
  InstallationMedia: Xubuntu 13.04 Raring Ringtail - Release amd64 
(20130423.1)
  IpRoute:
   default via 192.168.1.254 dev eth0  proto static 
   192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.131  metric 
1
  MostRecentCrashID: bp-86a16931-63d2-435e-8324-421212140304
  Plugins:
   Shockwave Flash - /usr/lib/flashplugin-installer/libflashplayer.so
   LibreOffice Plug-in - /usr/lib/libreoffice/program/libnpsoplugin.so 
(browser-plugin-libreoffice)
   Java(TM) Plug-in 11.25.2 - 
/usr/lib/jvm/java-8-oracle/jre/lib/amd64/libnpjp2.so
  PrefSources: prefs.js
  Profiles: Profile0 (Default) - LastVersion=36.0/20150224133805 (In use)
  RelatedPackageVersions: browser-plugin-libreoffice 1:4.3.3-0ubuntu1
  RfKill:
   0: phy0: Wireless LAN
Soft blocked: yes
Hard blocked: no
  RunningIncompatibleAddons: True
  SourcePackage: firefox
  SubmittedCrashIDs: bp-86a16931-63d2-435e-8324-421212140304
  UpgradeStatus: Upgraded to utopic on 2014-10-29 (119 days ago)
  dmi.bios.date: 11/23/2012
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A08
  dmi.board.name: 0XR1GT
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 3
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA08:bd11/23/2012:svnDellInc.:pnVostro270:pvr:rvnDellInc.:rn0XR1GT:rvrA00:cvnDellInc.:ct3:cvr:
  dmi.product.name: Vostro 270
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/exo/+bug/1425972/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 932177] Re: XFCE (and other non-GNOME) desktops do not initialise gnome-keyring correctly / WARNING: gnome-keyring:: couldn't connect to PKCS11

2014-05-08 Thread cousteau
It's 2014, this bug is already 2 years old, and hasn't been fixed yet, 
at least on Xubuntu 12.04.  Fixing it seems trivial.

Possible solutions:

1. If the package gnome-keyring is not needed on Xubuntu (or other 
   affected Ubuntu flavors), it should be considered to be removed from 
   it as a default package so that other applications don't try to 
   connect to it.

2. If the package gnome-keyring is required, it should be fixed so that 
   it runs properly on all the Ubuntu flavors that use it.  The problem 
   seems to be in /etc/xdg/autostart/gnome-keyring-pkcs11.desktop which 
   is only enabled for Gnome and Unity.
   2.1. Fix the line OnlyShowIn=GNOME;Unity;
2.1.1. by appending XFCE;KDE;LXDE; and any other DE that may 
   need or use pkcs11.
2.1.2. by deleting or commenting out that line so that all DEs 
   may use it (if anything, add a NotShowIn=... blacklist 
   for DEs in which this may cause problems).
   2.2. Make XFCE include an identical .desktop file with 
OnlyShowIn=XFCE; in it, so that the fix for XFCE is independent 
from other DEs.
   2.3. Make XFCE load all Gnome services at startup by default (which 
may also include some unwanted stuff and thus may not be a good 
idea).

3. If the package gnome-keyring is required due to dependencies, but 
   the service pkcs11 is not needed for it and other applications to 
   run properly, the warning message it displays should be removed.
   3.1. Making gnome-keyring not display that warning.
   3.2. Making gnome-keyring inform applications that the service 
pkcs11 is unavailable.
   3.3. Making all applications that use gnome-keyring check whether 
the service pkcs11 is available before requesting it (which 
would imply fixing them one by one, which may be a bad idea).

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/932177

Title:
  XFCE (and other non-GNOME) desktops do not initialise gnome-keyring
  correctly / WARNING: gnome-keyring:: couldn't connect to PKCS11

Status in GNOME keyring services:
  Fix Released
Status in Xfce4 session manager:
  Unknown
Status in Xubuntu:
  New
Status in “gnome-keyring” package in Ubuntu:
  Invalid
Status in “kde-workspace” package in Ubuntu:
  Fix Released
Status in “xfce4-session” package in Ubuntu:
  Fix Released
Status in “gnome-keyring” package in Debian:
  New
Status in “gnome-keyring” package in Fedora:
  Unknown
Status in “gnome-keyring” package in openSUSE:
  Fix Released

Bug description:
  precise + fluxbox (without gnome-settings-daemon) Postler when sending
  a message writes:

  Failed to send a message
  WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-rof1VB/pkcs11: No 
such file or directory

  In gnome-system-monitor:
  /usr/bin/gnome-keyring-demon --start --foreground --components=secrets
  /usr/bin/gnome-keyring-demon --daemonize --login

  with manual start this: OK
  /usr/bin/gnome-keyring-daemon --start --components=pkcs11

  Is it possible to add a string key '--components=pkcs11', so that the 
gnome-system-monitor was:
  /usr/bin/gnome-keyring-demon --start --foreground --components=secrets 
--components=pkcs11

  thanks in advance...

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: gnome-keyring 3.2.2-2ubuntu1
  ProcVersionSignature: Ubuntu 3.2.0-15.24-generic 3.2.5
  Uname: Linux 3.2.0-15-generic x86_64
  ApportVersion: 1.91-0ubuntu1
  Architecture: amd64
  Date: Tue Feb 14 17:47:35 2012
  InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
  ProcEnviron:
   PATH=(custom, no user)
   LANG=ru_UA.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-keyring
  UpgradeStatus: Upgraded to precise on 2012-02-10 (3 days ago)
  mtime.conffile..etc.xdg.autostart.gnome.keyring.gpg.desktop: 
2012-02-14T14:17:23.632015
  mtime.conffile..etc.xdg.autostart.gnome.keyring.pkcs11.desktop: 
2012-02-14T14:17:23.632015
  mtime.conffile..etc.xdg.autostart.gnome.keyring.secrets.desktop: 
2012-02-14T14:17:23.632015
  mtime.conffile..etc.xdg.autostart.gnome.keyring.ssh.desktop: 
2012-02-14T14:17:23.636015

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-keyring/+bug/932177/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1262752] Re: nvidia_304 not blacklisted or removed when nvidia_304_updates is installed.

2014-01-10 Thread cousteau
Personally I have solved this problem by uninstalling nvidia-304-updates and 
nvidia-experimental-304, and reinstalling nvidia-304.
(Probably some of these steps were unnecessary but I was stuck on a TTY and had 
no idea what to do; this solution took me quite a while to figure out)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nvidia-graphics-drivers-304-updates in
Ubuntu.
https://bugs.launchpad.net/bugs/1262752

Title:
  nvidia_304 not blacklisted or removed when nvidia_304_updates  is
  installed.

Status in “nvidia-graphics-drivers-304-updates” package in Ubuntu:
  Confirmed

Bug description:
  Dell Latitude E6520 Laptop

  System had a working nvidia-304 driver package installed (304.88-0ubuntu0.0.3)
  A regular system update installed, build and activated nvidia-304-updates 
(304.108-0ubuntu0.0.1)

  The new driver does not blacklist nvidia-304 which is still available at 
/lib/modules/3.2.0-57-generic/updates/dkms/nvidia_304.ko
  Depending on which driver is found first on the filesystem, it is possible 
that udev loads the wrong driver at system boot. (Driver detection and loading 
based on pci-aliases found in the system).

  Xorg.0.log shows:
  [22.112] (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module. 
Please see the
  [22.112] (EE) NVIDIA(0): system's kernel log for additional error 
messages and
  [22.112] (EE) NVIDIA(0): consult the NVIDIA README for details.
  [22.112] (EE) NVIDIA(0):  *** Aborting ***
  [22.112] (EE) NVIDIA(0): Failing initialization of X screen 0

  Dmesg shows:
  [   22.227733] NVRM: API mismatch: the client has the version 304.108, but
  [   22.227735] NVRM: this kernel module has the version 304.88.  Please
  [   22.227735] NVRM: make sure that this kernel module and all NVIDIA driver
  [   22.227736] NVRM: components have the same version.
  [   22.298983] init: lightdm main process (1406) terminated with status 1

  1) Description: Ubuntu 12.04.03 LTS
   Release: 12.04
  2) Installed: 304.108-0ubuntu0.0.1
  3) Correct nvidia kernel module to be loaded at system boot
  4) Depending on which driver is found first on the filesystem the wrong 
nvidia kernel module can be loaded.

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: nvidia-304-updates 304.108-0ubuntu0.0.1
  ProcVersionSignature: Ubuntu 3.2.0-57.87-generic 3.2.52
  Uname: Linux 3.2.0-57-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.0.1-0ubuntu17.6
  Architecture: amd64
  Date: Thu Dec 19 17:27:29 2013
  InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Release amd64 
(20120423)
  MarkForUpload: True
  ProcEnviron:
   TERM=linux
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: nvidia-graphics-drivers-304-updates
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304-updates/+bug/1262752/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 984785] Re: .goutputstream files polluting $HOME

2013-02-28 Thread cousteau
Shouldn't temporary files be created in /tmp rather than $HOME?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/984785

Title:
  .goutputstream files polluting $HOME

Status in The G Library - GLib:
  Fix Released
Status in Light Display Manager:
  New
Status in X.Org X server:
  New
Status in “glib2.0” package in Ubuntu:
  Fix Committed
Status in “lightdm” package in Ubuntu:
  Invalid
Status in “glib2.0” source package in Precise:
  Triaged
Status in “lightdm” source package in Precise:
  Invalid

Bug description:
  .goutputstream files polluting $HOME.
  Which software or operation is creating these and why?

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: xauth 1:1.0.6-1
  ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
  Uname: Linux 3.2.0-23-generic x86_64
  NonfreeKernelModules: nvidia  ati
  ApportVersion: 2.0.1-0ubuntu4
  Architecture: amd64
  Date: Wed Apr 18 13:29:31 2012
  InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin
  ProcEnviron:
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: xauth
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/glib/+bug/984785/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 518056] Re: cedilla appears as accented c (ć instead of ç) when typing 'c

2013-01-08 Thread cousteau
Ok, I spent quite long to figure out why cedilla was the new acute.

Since my keyboard already has a Ç key (which I use very rarely) I'm
quite annoyed with the decision of making dead_acute + c become a c with
cedilla instead of a c with acute (which doesn't have any other input
method that doesn't involve writing Unicode codes).  Wouldn't it be
possible to use a different combination for ç, such as dead_grave + c
(or the already existing AltGr-,)?  Or use ~/.XCompose or instead of
overriding it with a custom configuration.  If none of those seem
feasible, maybe giving cacute a different combination, such as
dead_grave + c, could do  (although in my opinion it makes far more
sense that the dead ACUTE key, followed by the C key, prints a C with
ACUTE rather than a C with CEDILLA).

Among all possible solutions, I think that the best one would be to just
make the default input method use X11's Compose, which already solved
this problem in a localized way by having a special key composition file
for pt_BR locale which maps dead_acute c to ccedilla while keeping
other locales with the default cacute setting, in addition to allowing
the user to have a custom ~/.XCompose file.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gtk+2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/518056

Title:
  cedilla appears as accented c (ć instead of ç) when typing 'c

Status in “gtk+2.0” package in Ubuntu:
  Confirmed

Bug description:
  
  When typing in a US-international keyboard with dead-keys (or 
UK-international), 
  typing 'c results in an accented c instead of a cedilla.

  There is a workaround, which is editing the

  /usr/lib/gtk-2.0/2.10.0/immodule-files.d/libgtk2.0-0.immodules

  file and changing the line

  cedilla Cedilla gtk20 /usr/share/locale
  az:ca:co:fr:gv:oc:pt:sq:tr:wa

  to

  cedilla Cedilla gtk20 /usr/share/locale
  az:ca:co:fr:gv:oc:pt:sq:tr:wa:en

  (add the 'en' at the end).

  However, every time some update on this file is applied, one looses the 
change,
  and we get back to the accented c. That means having to modify the file again,
  logout and login.

  For me this is no problem. But for my brother, mom, dad, etc, it is always 
something
  that at least makes me less proud of having convinced them to use Ubuntu, 
because
  they don't know what to do each time this happens.

  I think we really need a configurable keyboard layout, or at least (and that 
would
  be very easy), the inclusion of alternate layouts on install that for the 
dead-key
  options (as US-deadkey and UK-deakey), alternate layouts as 
US-deadkey-cedilla.

  This change is relevant for at least Portuguese and French.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/518056/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 18995]

2012-10-04 Thread cousteau
This is my view of the perfect Open with/Save dialog:

File: name of the file (type, size)
Two tabs:  Save as... and Open with...
Under Save as..., the typical Save as dialog.  By default, displaying the 
last directory selected, or the default one (usually Downloads).
Under Open with..., a list of installed applications.  The list will be 
headed by the 3 most used applications for that type.  If possible, it would be 
nice that the rest of applications were grouped by categories (Linux) or mimic 
the Start menu (Windows); this is how PCManFM looks and it's quite handy.  
Under it, a Custom command box (which would allow to enter commands with 
arguments or paths to executables), optionally with a Browse... button.
At the bottom, the buttons Ok and Cancel, and a Do this automatically for 
this type checkbox.

What do you think?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/18995

Title:
  [MASTER] Open With dialog not user-friendly

Status in The Mozilla Firefox Browser:
  Confirmed
Status in One Hundred Paper Cuts:
  Triaged
Status in “firefox” package in Ubuntu:
  Triaged
Status in “firefox-3.0” package in Ubuntu:
  Won't Fix
Status in “firefox-3.5” package in Ubuntu:
  Confirmed
Status in “mozilla-thunderbird” package in Ubuntu:
  Confirmed

Bug description:
  When choosing to open a file in Firefox, an Open With dialog appears. 
  You can choose to save the file or open it with a program from the list.
  However, if the desired program to open the file with is NOT listed, the user
  must navigate the filesystem to /usr/bin (or wherever) and select the
  appropriate program.

  A more user-friendly way would be to list all of the known programs installed
  that are available to open files with, and then have an Other... or
  Advanced... button for the user who would rather navigate the filesystem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/18995/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp