[dundee] Linux on the desktop

[Mark Harrigan]

On Sat, Jan 10, 2004 at 01:30:59PM +0000, Jonathan Riddell wrote: 
> On Sat, Jan 10, 2004 at 08:54:06AM +0000, Mark Harrigan wrote: 
> > Although the following article is about Mac OS X it does make some 
> > points relating to Linux on the desktop that I think are very 
> > important for the Linux community to think about when trying to 
> > compete with Windows.  
> > 
> > http://www.kernelthread.com/mac/osx/conclusion.html 
> > and 
> > http://www.kernelthread.com/mac/osx/conclusion_trap.html 
> He seems to argue that choice is bad because you would have to spend a 
> long time deciding which libraries to use if you were writing a 
> (presumably proprietry) application.  
I don't agree that it'd be fair to assume that, I'd also say it's
irrelevant to assume it too.  
> "Which toolkit(s) would you use? Which desktop environment would you 
> integrate it with? Which distribution would you target it for? How do
> you know what you "like" is "right"? Which all libraries would you 
> leverage so that you don't reinvent the wheel? How would you ensure it
> works seamlessly on a random installation? " 
> Well you either use GTK, if you think object orientation in C is a 
> nice idea, or Qt, if you want to make life easy.  Or for more 
> integration and less operating system portability you use GNOME libs 
> or KDE libs.

You're thinking on a different plane from the author and perhaps
you've also stumbled into the answer as well.  The author is not
thinking in the limited expanse of the gui, he's thinking about the
problems of finding all the appropriate libraries that are inevitably
required when developing a gui application.

When you develop on Windows and Mac OS X you have certain definite
starting points, WIN32/MFC/.NET, Carbon/Cocoa/Java. When you compare
this with Gnome you start to see his point (We're really talking about
a rival to MFC and Cocoa). Gnome is made up of many different and
disparate parts, themselves made up of many more different libraries
which may do similar things to each other. The view of the author is
that there needs to be a central framework which does most things well
and is accepted by the majority of the community as common basis. This
idea allows people to use their own choices but also reduces the
dilema of where to start learning/developing on a platform to an
obvious choice unless you have a specific reason to use something
else. In essence, a good starting point.

There is however a framework for linux that does slot in with this
idea of a wide variety of functionality in one easy to use place,
QT. I would still agree with him as QT isn't ubiquitous enough to
compare with the closed platform's guaranteed availablity of
frameworks, but glibc/QT/and one of dotgnu or mono or java sounds like
where we should be aiming to compete properly.
(Yeah I know you know I don't like KDE but this changes nothing, QT is
not KDE. I've never said I didn't like the QT libraries. ner ner ;) )

* For comparison
* http://doc.trolltech.com/3.2/index.html
* http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_mfc_class_library_reference_introduction.asp
* http://developer.apple.com/documentation/Cocoa/Cocoa.html  

>  On the other page he moans about how you have to endlessly tinker
> to get things working which is probably entirly true but he gives
> the example of a camera that wasn't supported by the Linux module so
> he had to edit the source to get it working.  But in a similar
> situation on Mac OS if your camera isn't supported there's nothing
> you can do about it because it's proprietry software and you arn't
> allowed to change it (apart from some of the very low level Darwin
> bits).  Just seemed like a strange example, being able to fix a
> problem.  Other Mac restrictions include not being able to play DVD
> videos out of your local region and not being able to burn DVDs
> using the drive of your choice.  Plus their rediculous interface
> patents listed somewhere on http://jriddell.org/patents.html 

I agree it wasn't the best example he could have used but also I agree
with him that there is too much damn tinkering, though that's only a
problem because it tends to be way more fun than working. I would put
a smilie there but I probably do loose more time to tinkering than is 
reasonable.

>  Somewhere along the way he makes the point of it being hard to
> configure and of course it is a shame that there are two different
> desktop environments with much the same goals (one day those GNOME
> people will see sence :).  

Yeah if they ported it to QT it'd be
perfect and we wouldn't have this annoying to develop for but nice
gui Vs nice to develop for but annoying gui thing going on. ;)

>  There are loads of things which Mac OS does better than GNU/Linux
> distributions but surprisingly my mum, who has had both forced upon
> her, asks just as many difficult problems with Mac OS X as she did
> with SuSE (only some of which are due to the lack of features in
> AppleWorks).  

New version coming soon I believe, about time too. Or
you could try KOffice on it. Mind you that's only been possible
since the 27th December so maybe a wee wait for the last bits of
polish might be an idea.

> 
> Jonathan Riddell
> 

Mark Harrigan

-- 
Debugging is twice as hard as writing the code in the first place. 
Therefore, if you write the code as cleverly as possible, you are, 
by definition, not smart enough to debug it. -- Brian W. Kernighan