Slashdot Log In
BBC on Gnome & Interview Miguel
Posted by
Hemos
on Wed May 19, 1999 10:06 AM
from the checkin-in-with-the-man dept.
from the checkin-in-with-the-man dept.
Evil Greeb writes "The BBC have written a fairly pro-Linux article, citing Gnome as "the operating system which could loosen Microsoft's stranglehold on the market". I thought it was a desktop environment myself, but that's not the issue: Linux promotion is! The page includes an audio snippet of Miguel de Icaza on Gnome. " Excellent-now if my Gnome-session would just run properly.
This discussion has been archived.
No new comments can be posted.
BBC on Gnome & Interview Miguel
|
Log In/Create an Account
| Top
| 128 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
I thought they were friends now, but..... (Score:3)
Has he been horribly misquoted, or did he _really_ mean this?? Since when has Gnome been accessible through Fortran? Each system is authored in one core language (C or C++) with bindings at various levels for other languages (Perl, Python, etc). Geez.. Maybe more of the Gnome API is available to more languages, but that hardly makes the above comment accurate.
What a desktop environment is (Score:5)
There are two big pieces to a desktop environment, that distinguish it from a window manager.
It has a set of UI guidelines that conformant programs follow as closely as possible.
For example, on Win95, hitting Alt-F4 will kill just about any Windows applictation, and every menu bar has to have a File option -- these are the sorts of things that Windows applications are (theoretically) required to follow.
It has a set of guidlines for exposing component interfaces that conformant programs follow as closely as possible.
The advantage of having a component architecture is that it makes it *much* easier to script programs (because the scripting language bindings become simple to implement), and because it makes it easier for programmers to allow different programs to interact. For example, a programmer writing a word-processor could let users put charts into a document whose appearance is dynamically calculated from the spreadsheet, without knowing how the spreadsheet is implemented -- all he needs are the component interfaces. Think of it as Unix pipes on steroids and growth hormones, and you'll have some idea of why component models are so cool.
Also, a DE usually contains a set of libraries and applications to make adhering to the first two much easier.
For example, KDE uses the QT widget library to expose a set of UI elements to make it easier for programs to look and behave like KDE apps. Gnome uses GTK. Likewise, KOM/OpenParts (for KDE) and Baboon (for GNOME) are the component APIs that programs have to honor to be well-behaved KDE or GNOME apps.
That's all there is to it, really. A window manager doesn't do these two things; all it does is manage the decorations on the windows. (Well, there's ICCCM, but it is at once hideously overengineered and utterly inadequate for specifying UI behaviors....)
However, note that the big interoperability problem between GNOME and KDE isn't the UI; Unix users have been dealing with wildly different-looking GUI programs for years.
Instead, the problem is that the component specs are different, which means it will be a lot harder to write programs that mix components from the two environments. For example, it will be unneccesarily messy to (say) write a script that uses KIllustrator to draw a chart from data in a Gnumeric spreadsheet unless the KDE and GNOME teams figure out a clean way of bridging their two component models.
Fortunately, both of these are free software, so if they don't want, someone else will be able to. (It would have *legendary* hack value, if that someone is reading and needs encouragement. :)
dammit dammit dammit! (Score:5)
>it's not completely free yet and it's bound to a
>single programming language in Unix. Gnome from
>the very beginning has been accessible through >any language. We are providing the GUI for
>all the languages and programmers can choose
>the language they like the most," says Miguel.
At least on
KDE and GNOME are both very nice( I use pieces
from both ) and there is no need for either team
to make inflammatory statements like this. Let
the kiddies fight this psuedo-debate out in the
middle school lunch room. GNOME rocks! KDE rocks!
But having a choice rocks even more!
OK, here's the deal: (Score:4)
Both of these are, at heart, suites of applications and libraries. The applications are there to make the user experience easier; examples are the file managers and the panels of each. The libraries are there for two purposes: to provide a consistent look and feel, and to help applications written for a given desktop environment to interact with one another, thereby providing a more seamless experience.
My choice: Gnome, with KDE's libs also installed.
Hmmm ... unsure about levity of the KDE comment (Score:4)
Chris Wareham
Linux on C vs. C++ (Score:4)
> Author: Linus Torvalds
> Email: torvalds@transmeta.com
> Date: 1998/11/22
> Forums: comp.os.linux.advocacy, comp.os.linux.x
>
> Peter A. Koren wrote:
>>
>> If I read the GNOME folks correctly, KDE essentially locks
>> you in to C++, while GNOME is architected to easily allow
>> other languages to be used for development under GNOME/GTK.
>> Is this really true? If so, the case favoring GNOME over KDE
>> would be compelling.
>
> I don't see why language is an issue at all.
>
> The kernel is coded in C, and I don't export any scheme or perl bindings
> for it. You have to code in C (or in assembly if you really really feel
> like it and want to punish yourself for some bad deed you have done) in
> order to write kernel code.
>
> Having one primary language has advantages: less confusion, and less
> overhead to maintain language-level abstractions.
>
> Haviung one primary langauge has it's disadvantages too: you have to use
> that language.
>
> I'm not saying that C++ is the only language to use, I'm just saying
> that you have to balance the advantages against the disadvantages. It
> all depends on what you want to do - saying that the language issue is
> "compelling" just doesn't make sense at all. It could be compelling in
> either way, and as such the compulsion isn't very real, is it?
[demands lean programing in both projects]
> Being too generic (in languages or features or design) often has its own
> set of serious downsides. Never _ever_ forget that.
>
> Linus