Well, this was a couple of years ago, I guess it's better now.
The thing that bit me was the form widget: the Sun Motif let you have circular dependencies if you kept horizontal and vertical links separate. The HP-UX one didn't, as I discovered when HP-UX people started complaining:-(
I did Motif devel for 6 years, I switched to GTK about 3 years ago. Here's why:
API -- GTK has a much, much nicer programmer interface; if you're coding stuff by hand, it's about 1/2 the number of lines (guess)
speed -- Motif pays a huge price for Xt. One of my apps makes a whole bunch of widgets when it loads a file... a very simple rewrite for GTK brought load times down by a factor of 10 (ten... TEN)
open source -- developing for a widget set which you have the source to is just lovely. With Motif, if something didn't work the way you expected, you had to spend hours trying different stuff at random. With GTK, you can see what's wrong, and how to fix it.
simplicity -- GTK is much simpler than Motif, and it's much easier to write your own widgets. The object model is much better. Signals rock. Within a few hours of starting GTK, I subclassed one of the standard GTK widgets and modified its behaviour; fantastic. Xt makes subclassing widgets difficult.
range of widgets -- GTK has a much better range of standard widgets. At the end of the interview, Fountain says he's updated his new edition to cover the latest widgets, such as the ComboBox and the Notebook. Good grief!
portability -- amazingly, not all Motifs are equal. If you want to write an app which can run on most versions of IRIX, HP-UX, Solaris, etc. you can only rely on quite a small part of Motif. This is an incredible and enormous pain. With GTK, you can just say "needs 1.2.10 or better", and if the user doesn't have that, they can download and build. They don't need to go through their vendor to get the toolkit. This is less of a problem now that Motif has opened up a bit, to be fair.
portability -- because GTK wraps Xlib, I can recompile my app, and it'll run on Winders.
Fountain is right on i18n being a current lag point for GTK. GTK2.0 (due out fairly soon (less than six months? not sure)) will include stuff like pango. This will jump GTK quite a way ahead of Motif on i18n.
On introspection, GTK has had this for years, I'm not sure what Fountain is talking about here.
I've not used Qt, no doubt similar stuff can be said.
>GNOME widget themes are color fixed. They are
>completely pixmap based. They are incredibly slow
Hi Denis, this isn't quite true. gtk+ has pluggable theme engines, one of the (many) available engines is the pixmap one, that's the one you are complaining about. There are lots of others.
>it is not uncommon to see GTK apps redraw
>themselves
gtk1.2 is not double buffered (qt is), so you sometimes see redraw. This leads ppl to think gtk is slow.. it isn't. Try timing some apps.
gtk2 has a nice double-buffer system and looks smoother.
This isn't my experience: I've just moved my app (a spreadsheety thing) from Motif to gtk, and seen about a factor of 10 speed up. Plus the API is much, much nicer to work with.
(GUI toolkit speed is hard to quantify... the factor of 10 is the time taken to load a large workspace and create all the widgets to display it)
10mpixels is a little generous, much beyond 6 and you're mostly scanning film grain. Plus that's the film resolution, which is not the same as the resolution of your camera system seen as a whole. Any imprefections in your optics (eg focussing problems, lens MTF etc) will knock this right down.
Something that's not been mentioned is colour quality. Film has fundamental problems here, as the light for the blue-sensitive layer has to pass through two other filters first. These inter-image effects are very bad for colour fidelity. Digital generally uses mosaic sensors, and can give much lower colour errors as a result. jnd (just noticable difference) colour errors drop by about a factor of 5.
I think the clearest way to think about it is to compare camera systems in different market sectors: sub-$50, film wins. Around $500, digital wins. $1000 - $10000, film wins. $10000+, digital wins again (for still subjects).
Unfortunately, some (char*)gtk_get*() functions return a pointer to an internal widget thing (which you must not free), and some gtk_get*() functions return a fresh string. Which you must free.
Policy for new code is that (char*) returns must always be freed. There are still a buch of legacy functions which don't work this way though.
It should be quite a bit quicker (bigger busses, more bandwidth, less legacy idiocy), and you'll be able to handle bigger objects easily.
It's not just how much RAM you have, it's the size of the files on your disc too. You have a 40GB hard disc, but the largest file you can mmap() is 2GB? That sux0rs. What if you're trying to edit a movie? Or open lots of large images in Gimp? The 2GB limit is becoming painful already.
I'm sure most people do this, but I'll say it anyway.
My projects always have 500 line todo lists which mix awful architectural problems with 'polishing' (eg. nasty flash when new image dialog pops up/class browser should link lazily). If I get stuck on one, fixing a few easy todos often frees the mind (and brings back confidence), making the solution to the tougher problem 'obvious' when I come back to it.
So: anytime you notice something wrong/broken, however trivial, always add it to the todo. It'll make great work-avoidance material when you're blocked.
I guess this doesn't work so well at the drawing board phase, which is maybe what the poster was saying:/
I did my PhD thesis with David Turner (designer of Miranda, which was the main starting point for Haskell). I wrote a baby operating system in Miranda. It was quite cool (I think): it had an editor, a shell, a "date" command, a file system, job control, you could have several people "logged" on at once and... the kernel had a formal semantics, so you could prove simple properties of sets of prorams running on it. I think (1989) I held the world record for the largest hand-made Miranda program:-) 14k lines as I recall. It did have some speed issues.
Anyway: my current spare-time project is an image processing package, and I've done a little lazy, pure, O-O functional language as the scripting tool (it's GPL... http://www.vips.ecs.soton.ac.uk, if you're interested).
I think this is an area where functional languages work really well:
- concise: duh, this is what you want in a scripting language
- speed: not at all important for an image processing scripting tool, since the primitive operations you are combining are so amazingly expensive
- formal: if you're trying to write a little script to implement a particular operation, it's great if you can prove that you have actually implemented what you thought you had:-)
- simple and easy to learn: the manual for the scripting language does the complete syntax and semantics (assumes no programming background, in a tutorial style, with many examples) in 10 pages
Conclusion: functional languages are great in niches, not so great for Big Jobs.
John
Re:We Have X Because Sun Wanted to Keep Da Goodies
on
X Windows Must Die!
·
· Score: 1
As I remember, the key thing was that X was much faster than NeWS. Having lots of the window system in interpreted PostScript made my uni's sun 3/50s *crawl*. X seemed like a real pleasure in comparision.
Slashdot Mirror
kdevelop pretty much does do everything you're asking for, check it out:
t ur es.html
http://www.kdevelop.org/index.html?filename=fea
If you install a recent-ish linux, check the "kdevelop" box and you won't even have to download anything.
qt is much nicer than mfc (imo).
I was being more sarcastic than you ... you lose :)
pango does ligatures and other compound characters very nicely, and it's the thing that does text rendering in gtk2:
http://www.pango.org
ie. every gnome2 application will automatically do this in most places
You use a vac cleaner on your lawn??
Do you also object public libraries? After all libraries allow people to read your book without "compensating" you.
Ahh, no. Authors get paid when their books are borrowed from libraries. Some popular writers would find it hard to survive without this.
The 'stripped down PC' uses a shared memory architecture that you won't find on a modern PC.
In this case that's a function of the operating system kernel.
AFAIK it's hardware. GPU and CPU share the memory. Not like a PC at all.
Eh? The UK is the 6th largest economy in the world, hard to believe I know. There's plenty of money, it's just not shared out very fairly :-)
What you did was optimise for a particular memory/fp architecture, not for a programming language.
The "naive" matmul.c you started with is probably the best implementation if what you are interested in is a sensible portability/performance balance.
And I ran X on a Sun 3 in 1987 in 4 MB of RAM. It was fine. You must have been running huge apps :-) They filled mem, not X.
Well, this was a couple of years ago, I guess it's better now.
:-(
The thing that bit me was the form widget: the Sun Motif let you have circular dependencies if you kept horizontal and vertical links separate. The HP-UX one didn't, as I discovered when HP-UX people started complaining
I did Motif devel for 6 years, I switched to GTK about 3 years ago. Here's why:
... a very simple rewrite for GTK brought load times down by a factor of 10 (ten ... TEN)
API -- GTK has a much, much nicer programmer interface; if you're coding stuff by hand, it's about 1/2 the number of lines (guess)
speed -- Motif pays a huge price for Xt. One of my apps makes a whole bunch of widgets when it loads a file
open source -- developing for a widget set which you have the source to is just lovely. With Motif, if something didn't work the way you expected, you had to spend hours trying different stuff at random. With GTK, you can see what's wrong, and how to fix it.
simplicity -- GTK is much simpler than Motif, and it's much easier to write your own widgets. The object model is much better. Signals rock. Within a few hours of starting GTK, I subclassed one of the standard GTK widgets and modified its behaviour; fantastic. Xt makes subclassing widgets difficult.
range of widgets -- GTK has a much better range of standard widgets. At the end of the interview, Fountain says he's updated his new edition to cover the latest widgets, such as the ComboBox and the Notebook. Good grief!
portability -- amazingly, not all Motifs are equal. If you want to write an app which can run on most versions of IRIX, HP-UX, Solaris, etc. you can only rely on quite a small part of Motif. This is an incredible and enormous pain. With GTK, you can just say "needs 1.2.10 or better", and if the user doesn't have that, they can download and build. They don't need to go through their vendor to get the toolkit. This is less of a problem now that Motif has opened up a bit, to be fair.
portability -- because GTK wraps Xlib, I can recompile my app, and it'll run on Winders.
Fountain is right on i18n being a current lag point for GTK. GTK2.0 (due out fairly soon (less than six months? not sure)) will include stuff like pango. This will jump GTK quite a way ahead of Motif on i18n.
On introspection, GTK has had this for years, I'm not sure what Fountain is talking about here.
I've not used Qt, no doubt similar stuff can be said.
It's not clear from the BBC piece, but it looks like they're proposing to log *connections*, not content.
/ st ory/0,7369,406484,00.html
http://www.guardianunlimited.co.uk/internetnews
(not much better from a freedom point of view, but at least technically possible)
:-) True, but the poster was just saying that you will not be paying for services you are not able to use.
>GNOME widget themes are color fixed. They are
.. it isn't. Try timing some apps.
>completely pixmap based. They are incredibly slow
Hi Denis, this isn't quite true. gtk+ has pluggable theme engines, one of the (many) available engines is the pixmap one, that's the one you are complaining about. There are lots of others.
>it is not uncommon to see GTK apps redraw
>themselves
gtk1.2 is not double buffered (qt is), so you sometimes see redraw. This leads ppl to think gtk is slow
gtk2 has a nice double-buffer system and looks smoother.
This isn't my experience: I've just moved my app (a spreadsheety thing) from Motif to gtk, and seen about a factor of 10 speed up. Plus the API is much, much nicer to work with.
... the factor of 10 is the time taken to load a large workspace and create all the widgets to display it)
(GUI toolkit speed is hard to quantify
10mpixels is a little generous, much beyond 6 and you're mostly scanning film grain. Plus that's the film resolution, which is not the same as the resolution of your camera system seen as a whole. Any imprefections in your optics (eg focussing problems, lens MTF etc) will knock this right down.
Something that's not been mentioned is colour quality. Film has fundamental problems here, as the light for the blue-sensitive layer has to pass through two other filters first. These inter-image effects are very bad for colour fidelity. Digital generally uses mosaic sensors, and can give much lower colour errors as a result. jnd (just noticable difference) colour errors drop by about a factor of 5.
I think the clearest way to think about it is to compare camera systems in different market sectors: sub-$50, film wins. Around $500, digital wins. $1000 - $10000, film wins. $10000+, digital wins again (for still subjects).
Unfortunately, some (char*)gtk_get*() functions return a pointer to an internal widget thing (which you must not free), and some gtk_get*() functions return a fresh string. Which you must free.
Policy for new code is that (char*) returns must always be freed. There are still a buch of legacy functions which don't work this way though.
For multiresolution image viewers, check out the turing archive:
http://www.turingarchive.org/
It's got a little GPL java client/server for image viewing (which I did part of).
It should be quite a bit quicker (bigger busses, more bandwidth, less legacy idiocy), and you'll be able to handle bigger objects easily.
It's not just how much RAM you have, it's the size of the files on your disc too. You have a 40GB hard disc, but the largest file you can mmap() is 2GB? That sux0rs. What if you're trying to edit a movie? Or open lots of large images in Gimp? The 2GB limit is becoming painful already.
I'm sure most people do this, but I'll say it anyway.
:/
My projects always have 500 line todo lists which mix awful architectural problems with 'polishing' (eg. nasty flash when new image dialog pops up/class browser should link lazily). If I get stuck on one, fixing a few easy todos often frees the mind (and brings back confidence), making the solution to the tougher problem 'obvious' when I come back to it.
So: anytime you notice something wrong/broken, however trivial, always add it to the todo. It'll make great work-avoidance material when you're blocked.
I guess this doesn't work so well at the drawing board phase, which is maybe what the poster was saying
It's a MIPS core, with a couple of nice vector units. arstechnica have a couple of overview articles:
2 /ee-1.html
http://arstechnica.com/reviews/1q00/playstation
SO mostly reads most MS office files, so you can read stuff other people have done (which is something).
:-)
If you change anything and post it back to them though, they'll be very cross
SO 5.2 has much better import filters, you might want to try that.
I did my PhD thesis with David Turner (designer of Miranda, which was the main starting point for Haskell). I wrote a baby operating system in Miranda. It was quite cool (I think): it had an editor, a shell, a "date" command, a file system, job control, you could have several people "logged" on at once and ... the kernel had a formal semantics, so you could prove simple properties of sets of prorams running on it. I think (1989) I held the world record for the largest hand-made Miranda program :-) 14k lines as I recall. It did have some speed issues.
... http://www.vips.ecs.soton.ac.uk, if you're interested).
:-)
Anyway: my current spare-time project is an image processing package, and I've done a little lazy, pure, O-O functional language as the scripting tool (it's GPL
I think this is an area where functional languages work really well:
- concise: duh, this is what you want in a scripting language
- speed: not at all important for an image processing scripting tool, since the primitive operations you are combining are so amazingly expensive
- formal: if you're trying to write a little script to implement a particular operation, it's great if you can prove that you have actually implemented what you thought you had
- simple and easy to learn: the manual for the scripting language does the complete syntax and semantics (assumes no programming background, in a tutorial style, with many examples) in 10 pages
Conclusion: functional languages are great in niches, not so great for Big Jobs.
John
As I remember, the key thing was that X was much faster than NeWS. Having lots of the window system in interpreted PostScript made my uni's sun 3/50s *crawl*. X seemed like a real pleasure in comparision.
I use IE5 on my Sun (*cough* for compatibility testing), and it's fine. Much faster then nutscrape 4.72 anyway. And it doesn't crash.
I think an office port should be pretty easy, they've obviously got the display stuff done.