[Bug 811921] Re: Clicking on icons in Nautilus changes focus

2012-04-07 Thread Greg Merchan
Guess there's no way to withdraw a comment.

This is an old bug present in perhaps every X toolkit and window
manager. Fixing it requires fixing both of those and perhaps the
applications, depending on how the toolkit is fixed. There is at present
either not the knowledge or not the will to make the necessary changes,
in part because keeping support for anything other than click-to-focus
is tricky.

I've seen that Bill Spitzak is working on making sure Wayland gets drag
and drop right from the start, so maybe some future X-less Nautilus will
work right on Wayland. From the look of it, Wayland was headed for
"freezing in" the bad assumptions people have made on X before Bill
showed up; at least X is only made to seem awful in this regard because
people misuse it.

GNOME's BTS doesn't allow for bugs that are due to multiple components
and their interaction, so it's necessary to have multiple reports. Bugs
there against against one component which is part of the problem have
been marked as duplicates of other bugs which are part of the problem.
This means there's no tracking of the issues particular to the
components, and defeats the purpose of a bug tracking system.

Launchpad does allow for bugs which affect multiple components, so this
could be merged with bug #803872 . But that bug was already changed from
affecting nautilus to affecting compiz. It affects both . . . and Gtk+.
(It can't be fixed in Nautilus until Gtk+ is fixed, unless Nautilus does
some really hacky stuff or changes toolkit.)

But it's been over 8 years since I presented a solution. The
aforementioned work in Wayland can replicate the solution because
Wayland doesn't have X's political baggage. I'm tired of this.

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

Title:
  Clicking on icons in Nautilus changes focus

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

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 811921] Re: Clicking on icons in Nautilus changes focus

2012-04-06 Thread Greg Merchan
Looking for the duplicate which doesn't exist, I've seen your actions
related to this bug and concluded I was wasting my time.

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

Title:
  Clicking on icons in Nautilus changes focus

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

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 811921] Re: Clicking on icons in Nautilus changes focus

2012-04-05 Thread Greg Merchan
Then please mark this as a duplicate of that report.

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

Title:
  Clicking on icons in Nautilus changes focus

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

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 388247] Re: Nautilus windows don't steal focus when files are dragged into them

2012-03-10 Thread Greg Merchan
Zach is correct; this is not a duplicate of bug #29560. That bug is a
filed against metacity, which is only one of the components contributing
to the failure of Ubuntu to provide a smooth DnD experience.

As written, the summary and report do not describe the commonly desired
behavior for DnD. What's needed is not for a program to "steal focus",
merely for its window to be raised at the right time.

Removing the duplicate marker and leaving as invalid.

** This bug is no longer a duplicate of bug 29560
   drag & drop improvement: delay bringing window to front until mouse released

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.
https://bugs.launchpad.net/bugs/388247

Title:
  Nautilus windows don't steal focus when files are dragged into them

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

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 811921] Re: Clicking on icons in Nautilus changes focus

2012-03-10 Thread Greg Merchan
This bug is not a duplicate of a similar bug in either compiz or
metacity. This is a bug in Nautilus.

The solution of the problem the user sees requires changes to both
regular applications and window managers.

** This bug is no longer a duplicate of bug 29560
   drag & drop improvement: delay bringing window to front until mouse released

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

Title:
  Clicking on icons in Nautilus changes focus

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

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 880962] Re: dnd pointer lock when dragging tab between two gedit instances

2012-02-04 Thread Greg Merchan
I added comments on GNOME bugzilla, but I have more comments relevant to
just Ubuntu.

When this locks up, there is almost no way out for me.
Ctrl+Alt+Backspace hasn't worked in a long time, so that's not an
option. Ctrl+Alt+1 (or 2-6) works, but because of some other bug
(NVIDIA, perhaps) the VT is invisible. (I also get a sort of "backlight
bleed" effect sometimes.) The VT is present so I can log in and `killall
gedit`, but I have to do it blindly. There's also no sshd by default, so
I couldn't even log in remotely to kill the process.

There needs to be a way for a user who doesn't know these tricks to get
back to working system without pulling the power.

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

Title:
  dnd pointer lock when dragging tab between two gedit instances

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

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 882856] [NEW] Text is misleading in Universal Access settings panel

2011-10-27 Thread Greg Merchan
Public bug reported:

On the Pointing and Clicking page of the Universal Access settings panel
there is a toggle for a "Simulated Secondary Click". By conventional
American English, a "secondary" click would perhaps be the second click
of a double-click, but really it just doesn't make any sense. What is
meant is a click of the second button on a pointing device, or what is
most commonly known as a "right-click". If the word "secondary" must be
kept, it would be better to say "secondary button click".

The effect described in the text does not match what happens. It says,
"Trigger a secondary click by holding down the primary button". When
this is enabled, the effect is that the right-click happens when the
button is released, not when it is held down. The text should perhaps
read "Trigger a right-click by holding down then after a delay releasing
the primary button."

Perhaps the text is correct and the behavior is not?

** Affects: gnome-control-center (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  Text is misleading in Universal Access settings panel

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/882856/+subscriptions

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 721554] Re: EOG does not render SVG elements from other files at 100% zoom.

2011-02-18 Thread Greg Merchan
** Attachment added: "Demonstration of the bug."
   
https://bugs.launchpad.net/bugs/721554/+attachment/1858767/+files/bugfiles.zip

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to eog in ubuntu.
https://bugs.launchpad.net/bugs/721554

Title:
  EOG does not render SVG elements from other files at 100% zoom.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 721554] [NEW] EOG does not render SVG elements from other files at 100% zoom.

2011-02-18 Thread Greg Merchan
Public bug reported:

Binary package hint: eog

When an SVG 'use' tag links to an element in another file and the zoom
is 100%, EOG does not render that element. Change the zoom higher or
lower and the element is rendered. Go back to 100% and the element goes
away. Also, if a gradient is defined in another file, EOG will not
render it at 100% zoom, but will at other zoom values.

The attached zip file contains two SVGs, one of which, 'parent.svg',
uses elements from the other, 'child.svg'. Both problems are
demonstrated. In the file 'parent.svg', a red rectangle with a blue
border will appear on the left and a gradient will appear in the
rectangle on the right at non-100% zoom values.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: eog 2.32.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-25.44-generic 2.6.35.10
Uname: Linux 2.6.35-25-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Fri Feb 18 15:48:42 2011
ExecutablePath: /usr/bin/eog
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: eog
XsessionErrors:
 (polkit-gnome-authentication-agent-1:1756): GLib-CRITICAL **: 
g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:1753): GConf-CRITICAL **: gconf_value_free: assertion `value != 
NULL' failed
 (nautilus:1753): GConf-CRITICAL **: gconf_value_free: assertion `value != 
NULL' failed
 (nautilus:1753): GConf-CRITICAL **: gconf_value_free: assertion `value != 
NULL' failed

** Affects: eog (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug maverick

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to eog in ubuntu.
https://bugs.launchpad.net/bugs/721554

Title:
  EOG does not render SVG elements from other files at 100% zoom.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 294182] Re: GNOME's Help Slow to Load

2010-04-26 Thread Greg Merchan
Two of the bugs marked as duplicates of this bug should be reopened and
reassigned to the package responsible for the System menu which contains
the item About Ubuntu, because that item does not need to open the help
browser. It could instead open an About dialog - like every other About
menu item.

Those bugs are: bug #49 and bug #474923 .

-- 
GNOME's Help Slow to Load
https://bugs.launchpad.net/bugs/294182
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 555549] Re: About Ubuntu and Help take a very long time to start

2010-04-26 Thread Greg Merchan
*** This bug is a duplicate of bug 294182 ***
https://bugs.launchpad.net/bugs/294182

I'm sorry. It seems there's just one other bug #474923 that has been
marked as a duplicate but shouldn't be. I thought I'd seen more.

-- 
About Ubuntu and Help take a very long time to start
https://bugs.launchpad.net/bugs/49
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to yelp in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 555549] Re: About Ubuntu and Help take a very long time to start

2010-04-26 Thread Greg Merchan
*** This bug is a duplicate of bug 294182 ***
https://bugs.launchpad.net/bugs/294182

Duplicate status is wrong.

One of the problems here, and in some other bugs marked as duplicates,
is that Yelp is being used for About Ubuntu, not that Yelp is slow.

These need to be marked as WONTFIX if the intent is that About Ubuntu
will always use Yelp. I say that is a bad choice.

Don't complain that your screwdriver won't hammer nails, get a hammer
instead.

-- 
About Ubuntu and Help take a very long time to start
https://bugs.launchpad.net/bugs/49
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to yelp in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 70951] Re: double click in file from my desktop folder open the application, but focus is not in new application.

2010-04-02 Thread Greg Merchan
I have this problem with at least GIMP, Metacity or Mutter, and Nautilus
or Nautilus Elementary.

When I first double-click an XCF file and GIMP is not running, then GIMP
starts and its windows are raised and focused. If I then go to a folder
and open another XCF file - with GIMP still running - the XCF file is
opened in an unfocused window underneath the folder window and its task
bar button pulses. Between the second click of the double-click and a
few moments after the new window appears, I neither type nor click.

This happens with applications other than GIMP, but I don't recall which
ones. I've not exhausted the combinations of apps, Metacity or Mutter,
and Nautilus or Nautilus Elementary. I've tried both "smart" and
"strict" as options for "focus_new_windows" and the behavior is the
same.

As I recall, and it's been more than 5 years, the file manager should
pass the timestamp of the second click in the double-click to the
application with which the file will be opened. The application should
either call XSetInputFocus using that timestamp or use some EWMH request
with the timestamp or both to have the window raised and focused. Focus
should only change if no button presses or key presses have occurred
since the double-click.

Because this bug could be a failure on the part of any of the three
applications involved (launcher, new window maker, window manager), I'm
not sure it's actually a Metacity bug.

-- 
double click in file from my desktop folder open the application, but focus is 
not in new application.
https://bugs.launchpad.net/bugs/70951
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 532633] Re: [Master] Window Control buttons: position/order/alignment

2010-03-30 Thread Greg Merchan
Thank you, Ludwik, for recognizing that students are supposed to be
learning new things. This is too often forgotten and in fact there are
university classes in the US devoted to slavish memorization of
Microsoft applications. I would say that teachers and administrators
should be even more adaptable than the students and that computers are
tools of their professions which they should learn to use well. I've
observed many of my colleagues treat computers as annoying conveniences
(an oxymoron, eh?) instead of tools - or perhaps they like to blame
their tools?

-- 
[Master] Window Control buttons: position/order/alignment
https://bugs.launchpad.net/bugs/532633
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to metacity in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 532633] Re: [Master] Window Control buttons: position/order/alignment

2010-03-26 Thread Greg Merchan
@Pako
Until 2005, I ran Debian GNOME or jhbuild GNOME (on Debian) with only 96MB RAM. 
That was a Toshiba Portege 3010, you can look up the rest of the specs.

-- 
[Master] Window Control buttons: position/order/alignment
https://bugs.launchpad.net/bugs/532633
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to metacity in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 532633] Re: [Master] Window Control buttons: position/order/alignment

2010-03-23 Thread Greg Merchan
I've noticed only one mention of the disappearance of the system menu,
also called the window menu or the application menu. It's the one that
shows when you click the application icon in the frame, right-click the
frame, or press Alt+Space. To maximize a window, I usually use
Alt+Space-X. That may be a habit formed to avoid missing Maximize and
clicking Close.

I mentioned this bug to a Mac user I know and she knew the buttons were
in the frame but didn't recall, without looking, which did what. She
confessed she almost never uses the frame controls. A thousand anecdotes
don't make a data point, but there you go.

-- 
[Master] Window Control buttons: position/order/alignment
https://bugs.launchpad.net/bugs/532633
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to metacity in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 532633] Re: [Master] Window Control buttons: position/order/alignment

2010-03-22 Thread Greg Merchan
I've made comments on blogs about this and I hope it will be helpful to
add them here.

The layout I've seen in screenshots has already shown flaws, because
whatever draws the window frames hasn't been made to adjust rounded
outlines when buttons are missing. That's an "easy" fix, barely worth
noting. Same goes for other complaints about broken themes.

But also apparent in those screen shots is that with the new button
arrangement the buttons will either be in different places on different
windows, or there will be gaps, or we will need frame controls that for
some windows are always disabled. This was already a problem because of
the order of Minimize and Maximize; no maximizable window is not
minimizable, but some minimizable windows are not maximizable.

It was always advisable to put Close in the top-right corner because we
have left-aligned menu bars in the windows. In fact, in the early days
of GNOME it was decided that the Help menu item must not be right-
aligned because that would place it too close to the Close button (among
other reasons).

There has always been a good reason to keep Close away from Minimize and
Maximize - it's too easy to miss your intended target.

Put these together and an order like Min-MaxTitleClose seems
best.

But the danger of accidentally clicking Close can be mitigated by other
changes. The Close button can be disabled when there are unsaved changes
in a document. You still have to reopen your document, but at least
nothing should be lost. In lieu of that, the application can prompt the
user to save changes. Annoying, but alas.

If these things are done, then Close can be safely put next to Minimize
and Maximize and it can be put on either side.

If missing-button gaps are to be avoided, disabled window frame controls
will not be used, and the buttons will be grouped together, then there
is one button order which is suitable for the frames; from outside to
inside that is: Close, Minimize, Maximize. Change those conditions, and
anything goes. (Well, almost.)

I favor getting rid of all three buttons and replacing them with . . .
well, that another topic, eh?

-- 
[Master] Window Control buttons: position/order/alignment
https://bugs.launchpad.net/bugs/532633
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to metacity in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 474923] Re: help/about ubuntu applet takes too long to load

2010-03-02 Thread Greg Merchan
*** This bug is a duplicate of bug 294182 ***
https://bugs.launchpad.net/bugs/294182

I think this bug should be reopened and reassigned, perhaps to the
package responsible for the System menu.

The problem initially reported is not that Yelp is slow, but that the
"About Ubuntu" action is slow. It would be much faster if it loaded an
About window like "About GNOME" does. That window could have a link to
further documentation.

I'd wager that most of the time people use "About" menu items, they are
looking for version numbers. That's what I was doing a moment ago when I
encountered this problem.

-- 
help/about ubuntu applet takes too long to load
https://bugs.launchpad.net/bugs/474923
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to yelp in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs