On Sun, Jun 09, 2002 at 08:13:25AM +0100, Bastien Nocera wrote:
> > If I'm going to be flamed for not upgrading to a fixed version of a thing
> > which was just uploaded before I complain that there is a problem, at the
> > very leas the new version should actually fix that problem, I would hope.
> > Either way, the important thing is that the problem be identified and
> > corrected. It also helps if several people happen to know what the
> > problem is so the next person who comes along with the problem has a
> > chance of getting help with it.
>
> You could at the very least check that the latest version of the
> software still has the bug. Or read the ChangeLogs. And if in doubt file
> a bug. People on #gnome are not know-it-alls.
My point is that I had no reason to believe that this was actually a bug,
until today. I learned of the new package and the fact that I had a real
honest bug within an hour of eachother, and the very first thing I did was
start a download of the latest version to verify whether it was still a
bug or not.
Note, as of this writing, http.us.debian.org still has 1.1.17-2, now
that's what I call frequent updates! ftp.debian.org has 1.1.19-1, but not
its dependencies. Those are in pool, but not in any package lists. I
think the archive is confused (or in the middle of a mirror pulse..)
I don't expect #gnome to magically be able to solve any problem. But I do
expect that they've got a better chance of solving any Gnome problem than
most other irc channels, and if a problem is reproducable, they're likely
to be the crew which can most easily verify this once a trigger is found.
In short, the channel is a resource to help prevent false positive bug
reports, though if it is a good resource for this may be debatable. ;)
> > Okay, I can tell you I don't have this key. I added it, gconf-editor
> > crashed, I reran it and added .../preferences/desktop_font_size as well,
> > it crashed again. Time to grab the source and build this thing for
> > debugging, Gnome's registry editor ;) should not die when you add keys
> > like that, and this looks reproducable enough to buttonhole the actual
> > cause for a change!
>
> No shit. Filing a bug with reproducible steps is good enough for a bug
> report. The key should be there, or that means that nautilus isn't
> properly installed.
Reproducable by whom? In this case, all I had to do in order to reproduce
it was look at my screen. Two other people seemed to have the problem,
but they were no more sure of what was happening or why than I was. A bug
report with the information I had would have been somewhat irresponsible.
As I said, it was only today I could confirm it was in fact a bug. I
immediately set out to get the latest package.
By the time I could have reasonably filed a bug report with any real
information at all, I had been told once that the bug was already fixed in
1.1.19 and then told in your message that the bug was not in nautilus at
all, but would be fixed in the next version of gnome-control-center2 with
the patch to do so already in CVS. Since it included a workaround and
changelog snippet, and the workaround did, a bug report now would be
silliness.
I do not believe I was wrong to hold off on filing a bug while there were
doubts whether or not the bug was in Nautilus or in my system config. By
the time I knew for sure, it was really too late to file a bug until I'd
installed a new version.
> > And BTW... THANK YOU! Adding the first key fixed the problem. The
> > second was an experiment on my part, but the key seems not to be
> > recognized. If you happen to know the name of the key for changing the
> > size of the font, I'd greatly appreciate knowing. (If you do not know, it
> > is not strictly necessary as the chosen default size is readable at this
> > resolution/size..)
>
> Same key. Something like "Sans 12". Or any other Pango font description.
> It's what appears in the Fonts Prefs, even though applying doesn't work.
Okay, the default_font and default_font_size keys seem unused now. I did
not see anything in the changelog to indicate what key replaces them,
changing it didn't affect anything.
Tabs also seem to use their own fontspec, though since I only use two of
them, I can use word-shape to identify them until I find out if they can
be changed. If I can't find a reasonable way to do so, I'll file a bug.
I figured I'd check the help to see what it has to say, but yelp comes up
with a microscopic font and bright white backgrounds. I can't use either,
and saw no configuration options. Once again, if I can't find a way to
make it work, I'll file a bug.
These latter two I haven't even tried to fix yet, it's late here and I've
had a long day. There's no sense filing bugs about these things until I
know there's something wrong and that I've not just overlooked some
setting documented in a README which I haven't yet. Is this not how I
should react to these things? It's how I'd hope users react when they
find things wrong with my stuff.
--
Joseph Carter <knghtbrd@bluecherry.net> Hey, that's MY freak show!
Technology is a constand battle between manufacturers producing bigger and
more idiot-proof systems and nature producing bigger and better idiots.
-- Slashdot signature
Attachment:
pgpd0BfMoCodH.pgp
Description: PGP signature