With gedit moving from gnome-print to gtk-print there is probably only one gnome-print user left, namely abiword.
This is amazing progress in the sense that instead of using gnome-print which is basically unmaintained and doesn’t work on Win32, we can now simply use gtk-print which is basically unmaintained and doesn’t work on Win32.
(By blog and email.)
Murray, a retraction of that post is in order.
Here is why: I do not think, and you have certainly offered no evidence, that you are competent to diagnose the mental state and ditto ailments of other people. If you in fact do have such credentials from a respectable medical school, now would be a good time to display them. (And to inspect an inquiry from the relevant ethics committee.)
The truth or falsity of the rest of your post is utterly irrelevant. I do not know if it is true or false; I do not care. You have evinced seriously bad judgment and deep character flaws.
I have noticed that main-menu on my system is a bit of a pig. It takes up something like 30 cpu minutes per day. That is kind of crazy considering I don’t really use it much. Certainly not every day. So what does it do?
And it does all of those every few seconds.
…although I am willing to entertain the idea that they are a necessary
evil.
Themes in GTK+ land are, simplified, arbitrary pieces of dynamically
loaded code that is hooked into the drawing layers of widgets. There
is no fault isolation, so when (not if) a theme does something naughty,
the application crashes. Then the user curses a few times and blames
the usual suspects: the screen/keyboard and the application.
Have a look at bug 438456. Theme code used in, for example, the industrial theme released various
kind of memory allocated by GTK+ using the wrong function, in this case g_free. Result: instant memory corruption in all GTK+ applications! Not good.
I do not think it is realistic to redesign the theming of GTK+ at
this point in time, but we really need to do something about
stability.
G_SLICE=debug-blocks during some kind of theme torture test is a bare minimum. For every release.I realize that I am asking other people to do some work. I do not feel too bad about that, though, because it is theme code that is causing my application to crash, causing people to lose data, and the blame is sent my way.
Ok, go ahead and tell me how wrong I am.
I wanted to know when a certain identifier was introduced in goffice.
It turned out that it was fairly simple:
git grep -w GO_FORMAT_MARKUP `git tag -l 'GOFFICE*'` -- '*.h'
That commands searches all .h files from all Goffice releases.
It is very fast: about 0.5s (cpu time) on a fairly slow machine.
How do I do that with SVN?
I’ll happily add myself to the chorus: switching to SVN? Someone must
have been drinking out of the potty.
If we are going to suffer the pain of a conversion, then we have better get a lot out of it.
These apply to all systems (except cvs). The trouble with SVN
is that it is hard to see it as more than a stepping stone.
Dave, if the only argument that people have against it is that “everyone knows that distributed’s better” is what you believe, then you have not been listening. Start with KeithP’s write-up saying, in part, that (1) SVN lacks corruption detection,
(2) Git is a whole lot faster than SVN, and (3) SVN is a space pig compared to Git.
By the way, why is it relevant whether most distributions include the system by default? We expect, from time to time, that developers have HEAD versions of various off-site libraries, so surely we can get the same developers to obtain a recent copy of Git (etc.), right?
So can we please have git and gitweb running somewhere on gnome.org
with access to, say, ~user/public_git/ directories? I promise that I will not complain too much about SVN if that happens.
I have been trying out f-spot recently and I must say that using
it gives me one of those rare warm fuzzy feelings inside.
It has well designed interface with relatively little clutter.
It by and large does what I want it to.
And it does not crash or hang for me.
It does not even spew a lot of scary warnings in my session log file.
I can find nits, sure I can. In fact I just filed a pile of them, but we are talking the would-be-nice department here.
Nice job on this, guys!
Until recently I have been using xterm and twm. Call me a stone-age
throw-back if you like, but those two are fast and lean.
But I am giving gnome-terminal and metacity a spin now. Metacity
suffers somewhat from click-to-focus, even if you set
it to focus-follows-mouse, but that is a story for another day.
Today it is gnome-terminal gripe time. Ok, so it is actually not
too bad, but it feels slow. Starting the first terminal window,
for example, takes a few seconds. Seconds! I want my window to
show up in less than .2 seconds.
A bit of stracing reveals the cause. It is dlopen-ing a zillion modules related to character support.
That is used to populate a, I estimate, rarely used menu. In my humble opinion, the penalty for this kind of thing should not be taken on startup, but when the rarely-used feature is activated. Or in the background while I type away happily. Luckily this does not seem
too hard to fix.
On top of this, Fontconfig is doing a whole lot of work on startup.
It does that for other GTK+ based programs too, so I doubt the
applications are to blame. So what does it do?
access("/etc/fonts/suse-hinting.conf", R_OK) = 0
stat64("/etc/fonts/suse-hinting.conf", {st_mode=S_IFREG|0644, st_size=6575, ...}) = 0
open("/etc/fonts/suse-hinting.conf", O_RDONLY) = 18
Are you there? Are you there? Please open! This kind of behaviour
is fairly cheap on a local file system, but not necessarily so on
a remote one. And it is wrong: the file could have changed twice between the three calls.
read(17, " fd9 78563412 1 4 4"..., 255) = 255 lseek(17, -136, SEEK_CUR) = 158 read(17, "/usr/X11R6/lib/X11/fonts/CID/us"..., 4109) = 3938 lseek(17, -3909, SEEK_CUR) = 187 read(17, "/usr/X11R6/lib/X11/fonts/URW/us"..., 4109) = 3909 lseek(17, -3880, SEEK_CUR) = 216 read(17, "/usr/X11R6/lib/X11/fonts/uni/us"..., 4109) = 3880 lseek(17, -3851, SEEK_CUR) = 245
Back-and-forth over the same area again and again. Short of timing
system call overhead I do not see what it is doing.
I am also having problems with focus in the terminal. I am not entirely sure how I manage, but
somehow the focus ends up on one of the tabs where it has no business being.
If you click on the column header of a regular treeview, the
entries will get sorted by the values in that column.
That works fine for the file chooser, at least if you sort by
filename.
It works horribly for programs like Banshee that display a long
list of (artist,album,song) entries. Sort by artist, according
to the treeview, means something like “sort by artist, and insofar
two entries’ artist values agree, pick a random ordering”.
That is useless! (It is a different matter whether Banshee has
the right interface for its song list. Add a few thousand songs
and I have the feeling the UI will suffer.)
To be useful, one ought to have the option of telling the treeview
that sorting by artist really means to sort by the (artist,album,song)
tuple.
So what am I not seeing?
I have noticed some trends in how the “severity” field in Gnome’s Bugzilla is being
used at the initial bug reporting time. Basically, “enhancement” is being used mostly right (although it has little to do with severity) and the others can be interpreted
in the following way:
Blocker: It happened to me.
Critical: I do not know how I can go on living if
you do not drop everything in your hands and fix the cosmetic problem
I believe I am seeing. Right now.
Major: This might become a problem for me
at some point in the future.
Normal: I did not see the option when I filed the bug.
Minor: Rarely used.
Trivial: I saw it happen to someone else.
Now, if someone could please tell me why we let non-maintainers
set the “priority” field…