No more right click terminal

Jeff Spaleta jspaleta at gmail.com
Fri Jul 15 16:03:59 UTC 2005


On 7/15/05, Andy Green <andy at warmcat.com> wrote:
> They understand that RHAT has some flexibility
> in terms of overrides (patches) of upstream providers.

And when they bring it up with regard to gnome desktop functionality,
they are repeatedly told to move discussion upstream. The issue isn't
that people, start the discussion here.. the issue is people (people
who know better) refuse to move the discussion upstream once they are
told it would be more effective to discuss this upstream.  As the move
from bluecurve to clearlooks illustrates there appears to be a
concerted effort by the gnome maintainers to move closer to upstream
not to further pull away from it.

> Although I don't use Gnome as a desktop, I use enough Gnome apps to be
> constantly reminded of the ineffective choices (Ctrl-L... if you can
> magically find out about it -- it's not on the dialog -- then make
> coffee while it tries to populate /usr/bin) foisted on folks via File
> Open dialogs for example.  It seems to me there is a genuine problem
> with the trend of Gnome development and the use of changing defaults to
> try to program their users. They could be more modest and provide
> compatability with conventional expectations as the default, and a
> simple choice into the new methods.  If the new methods rock, they will
> be taken up by word of mouth and become default by demand.

All of this, are comments on gnome's process for introducing and
laying out features. Without  making a judgement as to whether or not
your concerns are valid, these would be more effectively expressed as
part of upstream gnome discussions or in the case of the keyboard
shortcuts, rfes into upstream bugzilla.

> Well despite taking your point that upstream has more power over the
> direction of upstream, some care needs to be taken not to blow off
> genuine observations.  The power of RHAT to patch its desires into
> reality is real, as we see in the kernel.

No one has blown off the observations with regard to the specific
issue of terminal menu item. Clark chimed in very early on with
upstream information concerning how the terminal menu item is being
re-implemented as an addon. People took that information and are now
starting the packaging of that addon for Extras.
 
But this thread degraded into general comments about how gnome is
making upstream decisions, about how gnome has become a "social
experiement" on users. Even YOU just now decided it was worthwhile to
make a comment about how upstream gnome is changing defaults and how
you think they should be doing it.  These sorts of comments don't need
to be discussed here.. in fact they will get lost in the noise and
never make it back to gnome.
To quote you again:
"It seems to me there is a genuine problem with the trend of Gnome
development and the use of changing defaults to try to program their
users."

In no way shape or form is a comment about the "trend of gnome
development" worthwhile to discuss in fedora-devel. Comments like
these only serve to frustrate list participants, because comments
about the general trends in gnome development made in this list are
not going to lead to any changes into how gnome does things.   If you
want to make a comment about "general trends" of ANY upstream
project.. take it to the upstream project.

> Well despite taking your point that upstream has more power over the
> direction of upstream, some care needs to be taken not to blow off
> genuine observations.  The power of RHAT to patch its desires into
> reality is real, as we see in the kernel.

Its a huge logical fallacy to hold up what goes on with kernel
development as an example of whats going on with desktop application
development... inside redhat or even upstream.
What the fedora kernel people think is appropriate in terms of
patching the kernel.. is immaterial to what the desktop people think
is appropriate in terms of patching gnome functionality. There are no
parallels nor conclusions worth drawing in that comparison.


-jef




More information about the fedora-devel-list mailing list