| |||||||||||||
Reitter: Answering the question: "How do I develop an app for GNOME?"Reitter: Answering the question: "How do I develop an app for GNOME?"Posted Feb 6, 2013 11:39 UTC (Wed) by drago01 (subscriber, #50715)In reply to: Reitter: Answering the question: "How do I develop an app for GNOME?" by lkundrak Parent article: Reitter: Answering the question: "How do I develop an app for GNOME?"
gnome-shell (ins't really an application in the classical sense). gnome-documents would be the other one.
(Log in to post comments)
Reitter: Answering the question: "How do I develop an app for GNOME?" Posted Feb 6, 2013 18:19 UTC (Wed) by droundy (subscriber, #4559) [Link]
This is a pretty sad example of apps written in javascript. I don't know about gnome-documents, but in my experience gnome-shell makes fast computers seem slow, and slow computers unbearable. While it might not be the language at fault, it would be nice to have an example of a good gnome program written in javascript before committing the future of gnome to it.
Reitter: Answering the question: "How do I develop an app for GNOME?" Posted Feb 7, 2013 9:22 UTC (Thu) by ovitters (subscriber, #27950) [Link]
GNOME shell does not make fast computers slow. Secondly, Javascript will be the preferred language. As such, committing the future of GNOME to it? There will still be Vala, C, Python, etc.
Reitter: Answering the question: "How do I develop an app for GNOME?" Posted Feb 7, 2013 15:03 UTC (Thu) by paulj (subscriber, #341) [Link]
GNOME shell definitely has significantly higher resource needs than the previous Metacity/Compiz environments. Worse, it seems to leak memory. It's RSS expands and expands with time, until it starts causing the machine to have to swap. At which point you have to kill gnome-shell to have it restarted and get a useable desktop back.
Reitter: Answering the question: "How do I develop an app for GNOME?" Posted Feb 7, 2013 15:14 UTC (Thu) by ovitters (subscriber, #27950) [Link]
I responded to making fast computers slow.
You bring up something different, higher resource usage compared to metacity/compiz. GNOME shell is based on clutter, etc. Totally different than metacity.
The higher usage vs metacity is partly because of compositing and at the moment there is a binding bug with clutter (IIRC). Not much to do with Javascript. It would have been exposed in any binding. That bug was unfortunately only fixed in unstable, not in 3.6.x. In any case, you would've seen the same in Python, etc.
Of course, you can judge a Javascript decision on whether or not that bug is fixed at the moment. But actually we also fix memory leaks in other programs. Be it C (lots), Python, etc.
Reitter: Answering the question: "How do I develop an app for GNOME?" Posted Feb 7, 2013 15:43 UTC (Thu) by paulj (subscriber, #341) [Link]
Well, my laptop has fast enough CPUs (pretty much any x86 CPU made in the last 5 odd years is "fast"). Unfortunately, it doesn't have that much memory (1.5GB). This was sufficient prior to GNOME shell, except that I couldn't keep as many browser tabs open as on my desktop, and it was better to minimise swapping between LibreOffice and my browser, when using the former. GNOME shell's memory usage, its tendency to expand quite quickly, has put an additional pressure on memory, such that it's regularly much slower than before, as it's using swap much more heavily than before.
If bugs relating to leaks have been fixed, and things are due to improve in future releases, that's great.
I didn't place any blame on Javascript. ;) Though, for whatever it's worth, my experience is that it can be even harder to avoid or fix leaks in GCed languages than in ones with explicit semantics for managing ownership of memory.
Reitter: Answering the question: "How do I develop an app for GNOME?" Posted Feb 11, 2013 15:25 UTC (Mon) by droundy (subscriber, #4559) [Link]
Interestingly, I didn't say it made fast computers slow, I said it made fast computers <i>seem</i> slow, which is quite a different statement. I also didn't say that javascript was to blame, more likely it was javascript developers who were to blame. But the correlation is not encouraging.
Reitter: Answering the question: "How do I develop an app for GNOME?" Posted Feb 11, 2013 15:42 UTC (Mon) by ovitters (subscriber, #27950) [Link]
Not sure how you see the correlation. Why pick javascript and not the compositing? Or maybe gtk+3.x, dconf, etc?
In practice the slowness is often combination of compositing and drivers btw (aside from just outright gnome-shell bugs :P). Use gnome-shell on another system or with another driver and you'll see a huge difference.
Reitter: Answering the question: "How do I develop an app for GNOME?" Posted Feb 7, 2013 10:05 UTC (Thu) by ncm (subscriber, #165) [Link]
It depends on your goals. Switching your "emphasis" to an untried language makes exactly as much sense as eliminating everything people liked about your product. When the goal is to become irrelevant, every choice gets easy. Likewise, when the goal is to make every choice easy, each easy choice makes you less relevant.
Staying relevant is the exception. Linux still is. C++ and even C still are. Intel, astonishingly, still is. TCP/IP is. Things don't look too good for Java or for habeas corpus. One of those will be missed even by people who say we never really had it.
Reitter: Answering the question: "How do I develop an app for GNOME?" Posted Feb 7, 2013 12:22 UTC (Thu) by kigurai (guest, #85475) [Link]
I don't remember noticing that Gnome-Shell would be slower than any other *composited* desktop environment.
I have a netbook that runs it quite well.
gnome-documents is pretty fast. Try it.
|
|||||||||||||