Posted Apr 23, 2008 21:05 UTC (Wed) by corbet (editor, #1)
[Link]
If I turn off the file manager, I expect not to have a file manager. I was surprised to find that it breaks seemingly unrelated functionality, especially given that things did work in previous releases. The breaking of something which once worked is called a "regression," normally.
So be it, this one is not that big of a deal. I can't see my background anyway (which is why I see no point in having nautilus cluttering it up), and xsetroot is sufficient to clear away the obnoxious default color scheme.
Changing backgrounds
Posted Apr 23, 2008 22:45 UTC (Wed) by russell (subscriber, #10458)
[Link]
Is is still a regression if the GNOME developers never intended old releases to work that way?
I would have thought nautilus was something GNOME developers could have counted on being
around as a fundamental piece of infrastructure on which they can build on.
Any GNOME developers out there?
Changing backgrounds
Posted Apr 23, 2008 23:19 UTC (Wed) by NCunningham (guest, #6457)
[Link]
(Not a Gnome developer, but I am a developer)
It doesn't matter how the developer intends the software to be used. Users will always come up
with ways of using it that you never imagined.
What counts is whether the knobs you provide for tuning your software work as advertised,
regardless of which combination of settings the user tries. If they find a combination where
something doesn't work as intended, you have a bug. If they find a combination where something
works as intended, but not as desired, well... that's a feature request.
In this case, it's a bug because the advertised functionality doesn't work as advertised in
these circumstances.
Changing backgrounds
Posted Apr 24, 2008 1:20 UTC (Thu) by drag (subscriber, #31333)
[Link]
Well the guy that was asking the question asked 'If it was a regression', not 'if was a bug'.
It may be a bug, but it's not a regression. It's always been like this as far as I know.
It shouldn't be hard to fix, so file a bug report and let it go. They fix it or they don't.
nautilus =? infrastructure
Posted Apr 23, 2008 23:25 UTC (Wed) by ncm (subscriber, #165)
[Link]
I don't run nautilus either. I don't want unrelated features built on it as "infrastructure".
By all means put desktop file management features there. That's what it's for.
Me, I use "mv", and prefer it.
So, yes, this *is* a regression. Any core dependency on nautilus is a regression, just as
would be any core dependency on tomboy or beagle. They're programs I don't happen to use, and
that I see no reason to have installed. There are other programs that do behind-the-scenes
work. Gnome-session seems like a not unreasonable place for this bit.
Changing backgrounds
Posted Apr 28, 2008 12:54 UTC (Mon) by ekj (subscriber, #1524)
[Link]
Yes. Plain and simple yes.
If doing that USED to work, but doesn't work TODAY, then it is a regression.
It matters not how the developers, or anyone else, INTENDED it to work, what matters is actual
behaviour.
Actual behaviour is that right-clicking the desktop and setting the wallpaper USED to work,
even for people without Nautilus running. Today it no longer works. That is a regression.
It's not a major issue or anything, not as if this makes the computer unusable, but a
regression nevertheless.
Changing backgrounds
Posted Apr 28, 2008 19:40 UTC (Mon) by jospoortvliet (subscriber, #33164)
[Link]
Hehe, talking of regressions, you'd like KDE 4.0 ;-)
More serious, this is a weird thing. I would personally say it's good to
reuse code (use Nautilus code to paint the background) but it was done
wrong (needs Nautilus running somehow). Should be factored out in a common
library, I would presume.
Imho despite all it's shortcomings, KDE does things better in this
regard - the infrastructure is in order. Let's see if our Grumpy friend
will get acquainted with KDE again when 4.1 is out - see if he likes it.
Changing backgrounds
Posted Apr 29, 2008 6:09 UTC (Tue) by ekj (subscriber, #1524)
[Link]
I personally don't mind minor regressions much. I deal, and like our grumpy editor I like
living on the edge, and I'm fully aware that that means suffering bruises and cuts every now
and then.
I was just responding to the (imho!) very misguided idea that something that stops working
somehow isn't a regression if the developer never "intended" it to work in the first place.
I do indeed like KDE4, bugs and all.
Changing backgrounds
Posted Apr 24, 2008 15:54 UTC (Thu) by proski (subscriber, #104)
[Link]
I don't know how it is in Ubuntu, but in Fedora 9, removing bluetooth support removes nautilus:
yum remove '*bluez*'
...
--> Processing Dependency: libbluetooth.so.2 for package: gvfs
...
--> Processing Dependency: gvfs for package: nautilus
You don't make one of the most basic components depend on libraries for optional hardware. And if you do, don't be surprised that users will remove it.
Changing backgrounds
Posted Apr 24, 2008 19:26 UTC (Thu) by oak (guest, #2786)
[Link]
> You don't make one of the most basic components depend on libraries for
optional hardware.
By most basic components I guess you mean gvfs?
Nautilus is not the only dependency for that (at least not in the future)
as it replaces gnome-vfs...
Changing backgrounds
Posted Apr 24, 2008 21:49 UTC (Thu) by proski (subscriber, #104)
[Link]
"one of the most basic components" referred to nautilus. I should have used quotes.
Hmm... Why?
Posted May 12, 2008 14:25 UTC (Mon) by khim (subscriber, #9252)
[Link]
You don't make one of the most basic components depend on libraries for optional hardware.
Interesting. Why it's Ok for optional software (like kerberos) but not Ok for optional hardware (like bluez)? And if you'll say that you should make everything optional removable then the only sane answer is Gentoo...
Ubuntu, Fedora and other popular distributions are NOT Gentoo and are NOT designed to allow mix-and-match use. They are designed to WORK. Out of the box. They are doing it quite well - unless you are trying to change them too much.
Hmm... Why?
Posted May 15, 2008 12:24 UTC (Thu) by Duncan (guest, #6647)
[Link]
Interesting you mention Gentoo. That's in fact what I was going to
mention as well. Binary distributions often have compile-time support
choices that force library dependencies if enabled. It was apparently
judged worthwhile to enable bluetooth support for those that had it, even
at the cost of forcing the library dependency. The option would be
disabling bluetooth support even for those that needed it.
This is the kind of choices binary distributions make all the time. Among
other things, it's why most binary distributions favor one desktop
environment (KDE, GNOME, XFCE, whatever) over another, even if they have
binaries for both. Inevitably there will be packages with compile-time
enabled options to better integrate with more than one, and a binary
distribution will, by working policy borne of necessity, tend to enable
the support for their "default" desktop while disabling the other, thus
not forcing the installation of their non-default desktops, while forcing
the installation of at least major components of their default choice due
to the build-time linking they enabled.
The only way around this sort of thing for a binary distro is shipping
multiple choices, either as different distribution flavors,
ubuntu/kubuntu, etc, or by shipping multiple versions of the same package
(say vim and vim-minimal, to cite one example I'm familiar with from my
time a few years ago on Mandrake). Either way that's a limited
workaround, because it doesn't deal with the more obscure choices, which
will tend to be enabled or disabled based on individual distribution
policy for that sort of dependency and the functionality hit taken when
disabling it.
While they certainly have their own faults, source-based distributions
shouldn't have this one, at least not to anywhere near the same extent,
because being source based, the choice of whether to support the extra
functionality and take the extra dependencies is made at the user end, at
compile and install time. That's what Gentoo's USE flags are all about.
If you're using a binary distribution, you're choosing a package set where
untold hundreds, more like thousands, of these choices have been already
made for you. If you choose one more or less compatible with your usage,
purposes and preferences, a good share of them will be the same choices
you would have made anyway and you've saved yourself the hassle of
compiling everything from source at the cost of, probably, a handful of
packages that get installed as dependencies that you'd not need had you
compiled each package with just the support you needed. Hopefully, you
find one fairly close to what you want and you have just those few extra
packages and interdependencies. But, you WILL get those few. It comes
with the territory. It's a tradeoff you choose to take when you choose a
binary distribution. If you don't like it, choose a from source
distribution that allows you to control such things... at the cost of
compiling everything yourself. Your choice.
When it comes to my computer, I'm definitely and admittedly a control
freak, and I had decent hardware, so I chose the extra control. Others
don't mind the loss of functionality and customizability, as long as
it "just works". For them, from all I read, GNOME based Ubuntu tends to
be a pretty good solution, as are (in a different way) various
proprietaryware solutions, where you pay your money and get a more or less
turnkey solution they expect you you to take more or less as is and not be
too interested in poking away at the internals of (indeed, it tends to be
against the EULA to do so). If they are lucky, it'll meet their needs and
wants as well as my Gentoo with KDE has for me, and they'll be as happy
with the results as I've been. =8^)
Duncan