Sean Middleditch

10 Comments

• 1. Mart Raudsepp replies at 28th September 2007, 7:35 pm :

  You will be happy to hear that:

  * EOG actually starts quicker thanks to the rewrite of core in 2.20
  * Evolution doesn’t load (at least if it still behaves as intended) the tasks, memos, whatnot components until you actually click to them
  * I use gedit and to ever actually do that the features it has are crucial. Why would I want to look at a HTML or whatever file in monochrome text without any syntax highlighting? Never.

  Also, how can firefox be considered better by having its own HTML viewer? I call THAT bloat. Epiphany uses what is already there without shipping its own things - gedit, with HTML syntax highlighting.

  The load problems from GDM to desktop have zero to do with Gedit, EOG or evolutions “bloat” that some call essential and some still call “stripping of features in the name of usability” even though you are saying there is too much features and they that too few :P
  They have everything to do with disk seeks, interdependent waiting on eachother, loading of things that can wait quite a bit (nautilus desktop loading its extensions that are necessary due to the menu - one that isn’t even shown on the desktop) and so on - all of which are solvable and being worked on without stripping any features whatsoever. Want to help in that?

• 2. Sean Middleditch replies at 28th September 2007, 10:23 pm :

  “Also, how can firefox be considered better by having its own HTML viewer? I call THAT bloat. Epiphany uses what is already there without shipping its own things - gedit, with HTML syntax highlighting.”

  I would buy that argument if gedit were solely an HTML viewer, and not a useless text editor (by comparison to vim or emacs or what have you) that is horrendously large, slow, and buggy (compared to other “quick-n-dirty” text editors like Notepad). I have to open Firefox to view source for many pages because gedit bogs down to a crawl or even locks up on some large pages. The one thing I would actually use gedit for, and it can’t even do that. I have to open the “bloated” browser because the text editor can’t manage to handle what it was made to do - handle text.

  What would be far nicer in my opinion would be a fast inline view of the source in the browser window. No popup, no loading time, just an instant switch between “render’ view and “source” view, controllable by a single keypress or menu selection, with the browser remembering the state and viewport of each between switches. Even better would be a mode to selectively switch between virgin source mode and post-Javascript-modified source mode. Some which would require two gedit tabs (tabs!? ugh.) on top of the loading, and complete loss of easy key bindings to switch between the views and all the extra cruft gedit brings with it that I don’t need to just view source to look for the cause of layout bugs.

  Firefox doesn’t do that, but at least the view source feature in Firefox is instant, never locks up, never crashes, doesn’t include a ton of useless menu items irrelevant to the viewing of source, or use tabs for viewing multiple documents. (stupidest idea ever - it works ina browser only because many of us have dozens of pages open at once - when I have two text documents, opening the second one in a tab is “teh dum.”)

  I’ve followed the GNOME performance work. I know it’s gotten better in some areas, but for every step forward made there some other developer makes two steps back with each release. My desktop as a whole is getting progressively slower, not faster.

  I’ve no interest in helping other than the filing of bugs, which I do whenever the situation warrants. The gigantic mess that resulted from trying to graft OO functionality onto C without a higher language layer makes me about as frustrated as gedit does. :p
  (And the fact that the gobject model can’t even map cleanly into a higher language level like Vala without gross losses in efficiency frustrates me even more, like the recent thread regarding property string ownership issues on gtk-devel-list - a combination of glib not having a string data type combined with weakly defined ownership semantics for property getters.)

• 3. Mart Raudsepp replies at 2nd October 2007, 10:55 pm :

  We obviously need more people to work on the performance. Me included - I did a lot of research, but once it got to using that gathered knowledge I got too busy with work and other matters to actually use them in practice.
  I do think filing performance bugs is important, and also important is marking them with the “perf” keyword in gnome’s bugzilla. I at least often look at just keyword:perf search results. Sometimes also the memory keyword search results, as that’s also important (unlimited caches growing memory usage too large over time and such).

  Regarding the view source, I must agree. It would be nice, but while that functionality doesn’t exist, I think it’s good as is for now. Btw, it turns me nuts how firefox now seems to reload the page for the view source window now, while failing to use the session credentials from cookies. So I just use epiphany. Might be from some firebug and co extension caused though.

• 4. kiss replies at 27th November 2007, 3:04 pm :

  the main forgotten rule - keep it simple, stupid (kiss)
  best samurai sword isn’t the most decorated one - true, but it still has a handle, a ring to protect the hand and a blade. they all must be in balance. now if u have technically superior sword ready, then maybe should you do some decorations. some. if you make too many, too elaborate - you ruin the sword and it’s useless. that’s how it is with everything. to topic - too many young programmers that want to ‘tune up’ their programs in features or visuals before the code is ‘tuned up’. crappy swords covered in feathers, ribbons and colors. it’s pretty (for most people) too look at, but if you start to use it you discover the truth, and you start ranting and then you start looking eighter a new sword or look up your old rusted one…

• 5. Stuart Langridge replies at 28th November 2007, 5:07 pm :

  If you’d like a “show source” button in Epiphany, which shows the source in the browser window (not in a separate window, and not in Gedit either), then add a bookmarklet called “Toggle Source” with the following URL:

  javascript:(function(){if (location.href.substr(0,12)==”view-source:”){location.href=location.href.substr(12)}else{location.href=”view-source:”+location.href}})()

  clicking it will exchange this page for its source, and clicking it again will go back to the page.

  I use Gedit for all my hacking, incidentally; vim and emacs and so on are hugely annoying. Takes all sorts to make a world, I suppose. :)

• 6. S.F. replies at 28th November 2007, 5:56 pm :

  1. You’re not required to load *any* plugin in gedit, nautilus, eog and whatnot. In gedit we took care to only load a few useful C plugins by default, because python ones slow down the startup quite a bit… And yeah, there are quite a few third party plugins, some of them are listed on http://live.gnome.org/Gedit/Plugins. This might be bloat, but eh, it’s optional bloat.

  2. gedit’s goal has never been to be a replacement for notepad. It’s meant to be a featureful text *editor* with syntax highlighting.

  3. It has gained a new highlighting engine recently, which would explain a consequent slowdown (hopefully it will get better as gtksourceview gets fixed). Also, it has suffered a (slowing) gtktextview bug with long lines for ages (this is probably what you might experience with some generated web pages)… and gtktextview and pango are not particularly optimized for display of fixed-width fonts (which slows things when you use line wrapping). Those are known bugs that just wait for someone to fix them. And, as usual, you’re free to disable the syntax highlighting if you don’t like it.

  4. Most of the times it takes to start gedit comes from… libgnome’s useless library initializations and gnomevfs startup (one is needed for bug buddy, help and such, the other for remote files opening).

  5. Usually, gedit isn’t started on boot so it should not have any influence on the time it takes for your computer to become usable.

• 7. Sean Middleditch replies at 28th November 2007, 9:36 pm :

  First, looking back at this vitrol-filled post, I’m a bit embarrassed. My biggest beef having done Open Source work are ungrateful users who yell at volunteers demanding they bow to the user’s whims, and here this blog post is really just that. I’m a bad user. Sorry!

  Stuart, thanks man! And I guess some people do use gedit (you weirdo, you!). I stand corrected. :)

  S.F., how do you turn off gedits syntax highlighting? I see no way to do that.

  gedit’s goal is less my concern than the goal of what GNOME is going to ship. Shipping an app like gedit when it clearly DOES NOT WORK for simple use-cases depended on by other desktop apps is a problem, no matter which library/app is at fault.

  Hopefully both libgnome’s and libgnomevfs’s replacements fix that particular problem, though. I admit that I always thought the 10-billion-libraries approach of GNOME was a little off base. I mean, what’s the point of a bunch of separate libraries for individual application use-cases when, out in reality land, users have more than one app running and all those little libraries are going to be loaded into memory together anyway? The modularization has almost no practical benefit, and now people have found that it actually had an unintended consequence.

  I wasn’t implying gedit was part of the startup process, by the way. That was a more general complaint at GNOME (it really does take longer to start GNOME after GDM than my whole XP VM takes to start, which confuses me greatly). While gedit was the big example, I’ve found that almost all of GNOME is generally slow to load and memory intensive. And then there’s this Python obsession that Ubuntu and Fedora both have, with default setups involving at least two or three python applets running that consume twice as much memory as any other app save epiphany and eat up CPU time like you wouldn’t believe. (No, not GNOME’s fault, I’m being generic again.) I haven’t printed anything since I booted this computer this morning, so why do I have an “applet.py” process from system-config-printer that’s manged to eat up multiple full seconds of CPU time as well as using… 15m of memory? Jesus. Hey, mixer_applet2 has claimed 14m. 10m of each of those are shared, but… 4-5 megs of overhead for… nothing. Man, I sure am glad this box has two gigabytes. Let’s see, I have a grand total of… 160 megabytes of free memory (including file caches and buffers). And I’m running nothing but the core desktop, a handful of utilitarian applets, epiphany, and a gnome-terminal. Srslywtfbbqsauce?

• 8. S.F. replies at 29th November 2007, 3:54 am :

  You can disable the highlighting by turning off /apps/gedit-2/preferences/syntax_highlighting/enable in gconf. I’m pretty sure there used to be a checkbox in the pref dialog but it doesn’t seem to be there anymore (you could report a bug to get it back if you care, anyway)

  Speaking of memory, I wonder how you manage to get your 2 gigs filled with a freshly started Gnome: I use 768M right now with quite a few apps running, including a gitk view of the kernel repository (which according to gnome-system-monitor uses 380M), several instances of epiphany and gedit (which I use for development), etc. That said, I don’t use any python applet that I know of, and I still agree more than 128M is still too much for a clean system.

• 9. Sean Middleditch replies at 29th November 2007, 11:33 am :

  Ah, thank you! I now have syntax highlighting off. For a normal text editor I’d say that gconf is the right place to hide keys like that, buf it gedit is supposed to be a power-user editor, it probably should have a checkbox in prefs added back.

  I’m not sure what’s up with the memory on this machine. I am using 64-bits, so memory usage is expected to be a bit higher than most people… but not this much. I don’t recall it ever being this high before, either. Time to start learning some of those cool memory profiling tools and submit bugs, I guess. :)

• 10. Andrew Conkling replies at 30th November 2007, 11:14 am :

  Sean: Came across this post about the Javascript bookmarklet for toggling the view. Interesting post and, I’m predicting, I’ll find the blog interesting as well. Cheers.

  Your second comment kept me reading (I almost decided I was done with the vitriol). I’m with you about only being able (or maybe, for you, it’s more about being willing) to submit bugs, and I’m glad you do that too.

  I think you were talking more about GNOME/Ubuntu/etc. default policy/etc. but you have commenting enabled so maybe a little unsolicited ideas would be welcome?… I was just thinking that maybe you’d be interested in Leafpad, a GTK+ text editor that came out of Xfce-land. Sorta like a GTK+ equivalent to Windows’ Notepad, but actually useful. ;) Certainly no development editor, but handy for quick one-off editing.

  Also, I’m assuming you’ve changed your default editor–if such is your desire–so that you can get where you want to go from Epiphany?

Leave a comment