Ars has reviewed GNOME 2.20. “GNOME 2.20 was officially released last week after six months of development. The new version includes strong incremental improvements that contribute to a better user experience and provide more flexibility and integration opportunities for third-party software developers.”
http://arstechnica.com/reviews/os/gnome-2-20-review.ars
For instance, the file dialogs still do not support even basic file management tasks like renaming and deletion.
I can’t help it, I totally agree with him about it. It wastes my time to go to terminal or open file manager to do this task. Do anyone know if there is much of patch exists for this? I would love to use it for myself.
Well, I for one think that having file managing functions inside the file selector is bad and wrong.
I’ve seen so many times people screw up their files making non undoable changes inside a file selector.
Besides, it’s contrary to the principles of the gnome hig: a selection dialog should not be able to influence things outside of its scope.
Having a way to quickly open nautilus on the current directory, I think, would be a good compromise.
I’ve seen so many times people screw up their files making non undoable changes inside a file selector.
I don’t think it is a good reason. It is no difference with the file manager. Any users can screw up in file manager either.
Besides, it’s contrary to the principles of the gnome hig: a selection dialog should not be able to influence things outside of its scope.
What is the difference with ‘Create Folder’? Isn’t it influence outside? or something that I don’t understand?
Having a way to quickly open nautilus on the current directory
Not all users (include me) are using Nauitlus or file manager. When he creates a new file and somehow he wants to rename old file and use that old name for new file. It is wasting time to open and jump in file manager.
I know I have borked my system before using a terminal and forgetting where I was in the file hierarchy and deleting a file that I didn’t mean to. No matter what the system, some of us can still screw it up.
I would mod you up, if OS News was not coming back with errors
It could be an hidden option tho…in GConf or something like that.
Well, I for one think that having file managing functions inside the file selector is bad and wrong.
Oh please. What on earth do you think you’re doing when you open or save a file? This is just silly.
I’ve seen so many times people screw up their files making non undoable changes inside a file selector.
Like what? This is just sensationalist, ‘users are stupid’, BS. If you have reusable components in your integrated desktop then you’re going to be able to get consistent and familiar file operations wherever you are.
It’s certainly not uncommon for someone to try and save a file, open the save dialogue and think “Oh dear, I want to put this in a separate folder” or open an open dialogue and think “Oh dear, I made a typo saving the file, so I’ll change it”. You shouldn’t need to open another application to do what you want. If your main file manager is able to do that then you should get that functionality for free without anyone needing to code it in or complain about it. It should just happen.
Same for thumbnail support. If your file managers do it then your file dialogues should get it for free.
Besides, it’s contrary to the principles of the gnome hig: a selection dialog should not be able to influence things outside of its scope.
What says that this sort of functionality is out of the scope of a file dialogue?
Having a way to quickly open nautilus on the current directory, I think, would be a good compromise.
How on Earth would having an extra step and having to deal with another application make things any better?
I’m sorry, but this is just lunacy.
Edited 2007-09-25 22:15
I don’t get it either. Why can’t they just embed the view from Nautilus in there… It just makes sense. It would have file previews etc, and as such improve usability.
Or is it that they just CAN’T do that?
It’s a matter of not having GTK+ depend on Nautilus. The GTK+ filechooser needs to function regardless of whether Nautilus is installed or not.
Well, that makes sense. Though, wouldn’t it be possible to extract the view code from Nautilus and get it in GTK, instead of this duplication?
well, lucky for us your book is not the last word.
Even Trolltech is providing Qt bindings for Mono, that would mean KDE apps. based on Mono, you like it or not.
No, Trolltech is providing Java Bindings calles Qt Jambi.
The C# Bindings are (mostly) the work of Richard Dale and Arno Rhen.
Are they Trolltech employes or KDE developers?
Aside from the fact that a person can be both a KDE developer as well as a Trolltech employee, the two mentioned ones are “just” KDE developers.
Oh please. What on earth do you think you’re doing when you open or save a file? This is just silly.
When you open or save a file, you’re not renaming or deleting a file.
An open or save dialog is not a dialog for doing all kinds of file managing operations, which is what the original poster intended to say I think. Stop playing dumb.
And this is not a “user is stupid” problem, this is a user hazard that can happen to anyone, stupid or not.
Like what? This is just sensationalist, ‘users are stupid’, BS. If you have reusable components in your integrated desktop then you’re going to be able to get consistent and familiar file operations wherever you are.
Exactly, but “being able to” doesn’t mean “have to”. There’s an HIG for that. This is a power against usability problem again.
It’s certainly not uncommon for someone to try and save a file, open the save dialogue and think “Oh dear, I want to put this in a separate folder” or open an open dialogue and think “Oh dear, I made a typo saving the file, so I’ll change it”. You shouldn’t need to open another application to do what you want.
And why you shouldn’t?
Why shouldn’t you run a file managing application to manage your files?
Why should a “file open dialog” or a “file save dialog” transform into a “file renaming dialog” or “file deleting dialog” (with all the user error this will create)? Just because you can?
Now that’s silly!
For years, you could do everything with everything in FOSS desktops, and they were deemed unusable and bashed for that.
Now Gnome tries to go away from that, has even a HIG, and you bash it again? Besides, I’m pretty sure you’re aware of the reasons behind that design decision, but it’s just a case of you not agreeing with it.
But if you want it to change, I agree your best way to change this behaviour is to bash the current one.
If your main file manager is able to do that then you should get that functionality for free without anyone needing to code it in or complain about it. It should just happen.
That’s nonsense. Why it should? And that is no justification for it to happen.
Same for thumbnail support. If your file managers do it then your file dialogues should get it for free.
This I agree more with, but that still doesn’t mean it’s a desirable behaviour. I can see the point in a image manipulation application, I can’t see the point when you’re dealing with text documents. IIRC, recent GTK+ filechooser API allows you to implement it in your app if you want, but doesn’t force it.
Which is much better than your resource hogging solution. If you mean they should implement it in Nautilus and put a checkbox configuration to have this or not in your file dialogs, then I agree it would be a good thing.
What says that this sort of functionality is out of the scope of a file dialogue?
The answer was in the sentence: the HIG.
How on Earth would having an extra step and having to deal with another application make things any better?
Because it’s a validation step that you really know what you’re doing, as renaming a file in a open or save dialog should be a hidden functionality, right?
These are file operation dialogs, not file managers.
What says that this sort of functionality is out of the scope of a file dialogue?
The answer was in the sentence: the HIG.
That’s a bad excuse for not doing something. Just having a HIG doesn’t magically make your apps of DE more user friendly. Bindly following a bad HIG is a lot worse than having no HIG at all. A HIG should be a set of guidelines not a set of commandments. You should refuse to implement a feature because you can show it’s a bad idea, not just because it goes against some arbitrary set of rules set down by some arbitrary groupd of people.
Even the much worshiped Apple knows when to ignore their own HIG.
[i]Even the much worshiped Apple knows when to ignore their own HIG.<&u>
True, especially if the functionality, like in this case, is well tested and seam to work well in other OS:es.
I agree with you as long as we are talking about file selection dialogs. But not if you are talking about save dialogs, here it is already possible to create new folders. If you can create them you certainly should be able to rename them, e.g. if you make a typo.
If you can rename folders, why shouldn’t you be able to rename files. E.g imagine you are downloading an image from the net, you name it house.jpg, then you find a similar image and want to give both images descriptive names. E.g. house-south-side.jpg and house-west-side.jpg or you may want to create a folder named house, and move the images into it. You shouldn’t need to open Nautilus for this.
As for messing things up, opening Nautilus gives the user even more possibilities to mess things up.
Actually the problem is that thumbnail support in the filechooser isn’t inside of gtk and is left up to the individual application writers to implement. There are a few functions to implement it that make it pretty easy.
Yes this is _totally friggin lame_, but until someone puts this support into gtk, it won’t happen.
In the meantime about all you can do is file bugs or send patches to software you want screenshots in the filechooser for.
In the meantime about all you can do is file bugs or send patches to software you want screenshots in the filechooser for.
No need to, there are already two of that in bugzilla. As for the patches, sadly, I will have to learn C to do that.
Alexander Larsson (Nautilus maintainer) is doing the heavy lifting and working on a gnome-vfs replacement called GVfs that will be put in the right place of the stack, i.e. GLib/GTK+.
Thumbnails in the filechooser will be a cake walk when that’s done.
It might land sooner than you think. He’s even proposed it for GNOME 2.22.
http://mail.gnome.org/archives/desktop-devel-list/2007-September/ms…
Edited 2007-09-25 20:49
I don’t get why there aren’t filepreviews and such in the filechooser. Doesn’t the filechooser just reuse code from Nautilus? Or is it something totally different? Of course, I’m looking at this from a KDE view, where I know Dolphin offers it’s fileview to Konqueror and every filedialog in KDE – so they all have filepreviews, several basic viewing capabilities like list/icons/details and some basic editing like ‘new folder’. That approach just makes sense to me – can’t you guys do that in Gnome? Or is code reuse evil, or is it impossible due to architecture, or???
“Doesn’t the filechooser just reuse code from Nautilus?”
It doesn’t. They want GTK to be independent and don’t want it to depend on Nautilus, so they don’t use Nautilus code and thus it doesn’t support file previews natively.
The VFS (GNOME-VFS) has traditionally been higher in the stack than the toolkit (GTK+/GLib). This made using GNOME-VFS in the lower parts of the stack hard (interfaces and abstractions had to be used).
GVfs/GIO will be put in the right place of the stack, namely in the toolkit itself. (And hence, no more abstractions are needed… on that level at least.)
Reusing too much stuff (some might be reasonable…) from the filemanager would just lead to another bunch of abstractions.
I guess KDE is a bit different since it builds a layer on top of the toolkit so abstractions are the rule rather than the exception? (Note: I haven’t looked on any KDE code in a looong time…)
Yeah Alex Larson is the gnome-vfs maintainer who decided to write gvfs. gvfs doesn’t solve the problem that is needed for thumbnails in filechoosers.
The thumbnail code (parts of poppler) need to be in gtk which won’t happen anytime soon. Can’t find the bug right now where the maintainers flat rejected it.
The thumbnail code (parts of poppler) need to be in gtk which won’t happen anytime soon. Can’t find the bug right now where the maintainers flat rejected it.
Couldn’t find it either.
I find the attitude of the Gnome developers flat out offensive.
Seriously, both KDE and Windows have previews/thumbnails for all apps. This is 2007, not 1997, for gods sake!
Poppler is a PDF rendering library and doesn’t have to be in GTK+ proper to be used to render the thumbnails for PDF files. The thumbnail mechanism will be extensible, just as it is now. So there can still be thumbnails in every app.
The problem up until now has been that the VFS layer has been too high in the stack so it was tedious to integrate in the lower parts.
Edited 2007-09-26 20:06
I think the thumbnail of a file will be available in the File class.
Poppler itself is a PDF rendering library. It doesn’t have to be included in GTK+ in order for the thumbnail mechanism to call out to it (be it a .so loaded module or an executable) to render the thumbnail.
I don’t see your point, really.
Not trying to start a flamewar, but the fact that Gnome requires Mono (since 2.16, tomboy) is a real turnoff for me.
so what are you trying to do?
Trying to bring attention to the fact that the dependency on mono is a bad thing.
It’s not. Move on.
Just because you say it is a bad thing doesn’t make it so. Give a good valid reason why something like this, which can be removed easily if you so choose, is so horrible.
False, Gnome does not depend on Mono which can be easily removed. Only applications like Beagle, Fspot, Tomboy, Banshee require it. On Fedora you can do
yum remove mono and Debian/Ubuntu, apt-get remove Mono* (Thanks Apoclypse) to get Gnome running without Mono at all.
* Wrote the right apt-get command
Edited 2007-09-25 20:23
It’s apt-get remove mono*
to be anal:
$sudo apt-get purge mono
purge is identical to remove except that packages are removed and purged.
afaik, Gnome includes Tomboy by default since 2.16, thereby requiring Mono to install.
That I can remove it afterwards, doesn’t change the fact that it initially depends on it.
“Only applications like Beagle, Fspot, Tomboy, Banshee require it.”
…and as time goes by, more and more “Gnome” applications will be using mono, so simply removing it won’t leave much in the way of functionality will it?
I feel about as much at ease with any MS tech being in Gnome as I do with a single ebola strand inhabiting my sandwich. Initially it all seems quite harmless…but oh my, doesn’t it turn nasty later on…
This is too true. I’m tired of people saying that “Mono is required for Gnome” It isn’t. It’s optional.
Why is Mono such a bad thing anyhow? It’s faster than Python, which nobody complains about being tied to Gnome.
It’s released under an open-source license, so it’s free software.
What exactly is the problem here?
Yeah it is true its optional but some distros are *bad* at packaging these optional things. For example this happened to me once:
Removing Mono wants to remove
– Tomboy (understand this)
– Gnome Applets (because tomboy is one!?..)
– Gnome Panel (because applets sit on it..)
etc etc and break the gnome desktop as a result. I am not going to name the distro for needless flaming but merely pointing out that it is usually the packagers fault when removing mono breaks the gnome desktop as it works flawlessly on other distros as others have mentioned.
So first place to complain about such problem would be the bug tracker for your distro.
Removing Mono wants to remove
– Tomboy (understand this)
– Gnome Applets (because tomboy is one!?..)
– Gnome Panel (because applets sit on it..)
Gnome Applets is almost certainly a metapackage, depending on all the applets. Remove one and the metapackage is removed, but the rest remain. Gnome Panel probably is too (it would be pretty dumb to have it removed otherwise). Likewise, Gnome-Desktop is a metapackage. Its removal means nothing other than that you no longer have every single piece installed (which is what you want, since you wish to be rid of Tomboy).
I see this all the time in Debian with KDE. Someone complains about having multiple multimedia players or multiple text editors. When told to remove the ones they don’t want, (s)he says (s)he can’t because it “would remove KDE.” Yes, the KDE metapackage that draws in all parts including many text editors. If you don’t need all of it, you don’t need the metapackage.
Similarly, if you don’t need all of the Gnome Applets (say, you don’t want Tomboy), you don’t need the metapackage. That’s assuming it is a metapackage, which I don’t know for sure since I don’t use Gnome and you didn’t mention which distro you are using, though I am assuming Ubuntu.
While it is technically true that you don’t need the metapackage, it is not quite as simple to remove it as you say. The problem is that when you install the equivalent of kde-desktop, it pulls in a bunch of other packages, and marks those packages as having been automatically installed. This is usually a good thing, because when you remove that metapackage you want all the dependencies to be removed as well. Now the problem is when you want to remove one of those packages because you don’t need it. The metapackage must be uninstalled because it no longer has all of its dependencies installed. Unfortunately when you uninstall it, it wants to uninstall all the other packages as well. Then you have to manually fix all the packages it wants to uninstall.
It’s not hard, but it certainly is disconcerting to see the package manager wanting to uninstall half the system just because you want to uninstall one app.
Still assuming Ubuntu (or Debian derivative).
The problem is that when you install the equivalent of kde-desktop, it pulls in a bunch of other packages, and marks those packages as having been automatically installed. … Unfortunately when you uninstall it, it wants to uninstall all the other packages as well. Then you have to manually fix all the packages it wants to uninstall.
That’s pretty much how aptitude behaves. I’m not a big fan of that behavior, so I tend to use apt-get. Last I checked, Ubuntu was using Synaptic and last I checked, Synaptic used apt-get. Has something changed? Adept certainly doesn’t do that on Debian.
Aptitude’s way of automatically removing dependencies when the package that pulled them in is removed leaves fewer orphans around (though deborphan helps with that) but would indeed present some problems with metapackages
Ah ok. Yeah I use aptitude for my system. I like it much better than synaptic or adept, mostly because it’s faster and I’m used to all the keyboard shortcuts…
Personally, I dont like Mono because of the tie-in with Microsoft. Just because Mono is OSS doesn’t mean it’s exempt from any leverages MS may – or may not – have. At any rate, I want to avoid it.
You are the type of person that just wants to complain about mono, you have no basis for not liking it, it doesnt matter to you. Hell you will never even use gnome. But you like to start the same old tired idiotic flame wars over and over.
Get back to class.
You may be surprised at this little piece of news, but not all objections to software technology have to be technical. The guy expressed a legitimate concern, namely that in an unprecised future MS might be using Mono to strongarm or stop (or simply FUD about: see their stance on patent FUD) Gnome development.
So it doesn’t matter how good Mono is on purely technical grounds, if it’s a poisoned pill having it go down your throat nice and sweet can only make things worse for you.
Rehdon
Indeed. PPL fell all over Novell for the MS deal, but they love Silverlight and Mono. Well, in my book, Mono is NOT Free Software, as it’s patent-ridden and it’s future and development are controlled by Microsoft
Because it’s patent-encumbered and uses gobs of memory.
How it it patent encumbered? Name some patents that it infringes.
It may indeed infringe some patents. Some say that most free software projects infringe patents. I guarantee you that you’re running software that could be claimed to “infringe patents”. Note Microsoft’s claim about the kernel. This is because of a broken system that allows broadly-defined patents, and is not the fault of software.
So then don’t use Tomboy? Just what exactly is the problem?
So then don’t use Tomboy? Just what exactly is the problem?
Read the article. It will become increasingly difficult to avoid Tomboy and Mono with distributions shipping with it, and if the integration with lots of third party applications happens then it will be impossible to avoid. However, like everything in the open source world, if enough people to decide to use it then that’s par for the course.
Although I’m personally not keen on Mono and I think there are far better ways of creating a great looking framework, considering that I’ve complained about a lack of integration, I think this is no bad thing. Gnome needs a good, straightforward development framework and environment to develop and integrate applications.
Personally, I think when Ximian initially thought about cloning .Net I just wished they’d looked at it practically and took what was good about it, ditched what wasn’t going to be practical, looked at what was happening and what was wrong with Java in the enterprise arena, looked at up and coming languages like Python and Ruby and created something new and original.
However, if no one steps up to the plate and creates something good for Gnome developers to get hold of then I’m not sure what the alternatives are. Red Hat (and Sun) could do something with Java now being open sourced and Eclipse, but it’s not happening.
No, that’s not going to happen. Apps are included in GNOME because they’re good, not because they use Mono. There is no evil conspiracy to take over the world with Mono, get over it.
If you don’t like Mono, then don’t load Tomboy. That way Mono will never be loaded into memory. It’s as simple as that. If you don’t like Mono app $FOO, then load use $FOO.
Agreed. I find it ironic that they celebrate 10 years of freedom by going into the devil’s hand.
Mono might be “free software” by definition of the term, but it’s certainly not so by the spirit. It’s a trap, and very well made one at that. The fact the most people don’t see it doesn’t make it go away tho…
On the other hand, none of the core stuff depends on Mono [yet] so it’s possible to go without mono (as I do now for example). But I’m fairly sure someone will make some core part of GNOME in Mono one day and that’s when we’re screwed.
that’s what forking and competing projects are for
“But I’m fairly sure someone will make some core part of GNOME in Mono one day and that’s when we’re screwed.”
Please, take off the tinfoil hat and relax. Mono is not patent encumbered, it’s a clean reimplementation, and free software. Just because you don’t like MS does not make the technology bad.
Actually there are patents on mono; the issue isn’t whether they exist; no one is denying that (except you), the concern is whether Microsoft will exercise their rights as the patent holder. Given one doesn’t have to act immediately with patent violations, Microsoft allow this to simmer for quite some time and exercise when it can inflict maximum damage.
With that being said, however, they have an agreement with Novell for a patent sharing agreement, which will give them the ability to clone technologies, including the patented ones within .NET. Sun is in a similar situation. All things being equal, the issue then shouldn’t be so much whether Microsoft will exercise those rights but where those distributors who haven’t signed patent sharing agreements, sit into the bigger equation. Will we see Microsoft sue Red Hat and Conical for not playing ball? its all wait and see for now.
“no one is denying that (except you)”
Actually, I wasn’t really denying that the patents exist, I just wasn’t very clear. I guess the problem I have is the word “encumbered” as I also believe that the deal with Novell protects Mono and Linux users from any legal problems with MS. So I guess I look at it as a non issue. So while there is patents on .NET technology, I think were all safe in this case.
Actually, to clarify, the patent covenant between MS and Novell explicitly excludes applications and technologies that are “cloned” to duplicate existing Microsoft products. So OpenOffice and Wine, for instance, are excluded from the covenant, and that would likely also exclude the non-ECMA .Net stuff, which exists only to clone the Windows application environment.
Having said that, I don’t see why people feel that the non-ECMA stuff is any more at risk of patent threats from MS than any of the other various components that Ballmer has mumbled incoherent threats against. OIN and Novell’s own patent portfolio are more of a threat to MS than MS is to the community.
I agree with the sentiment that chasing an MS controlled standard is foolhardy at best, and they should just chart mono to be it’s own framework. And I think some of the details behind the linux implementation of Silverlight in mono, particularly Microsoft’s intent to control the way the community is permitted to use it, should give people the willies, at least until we know more and see how it fleshes out. But personally I think the risk of patent encumberrance is overstated relative to everything else.
I dislike mono simply because it sucked enough resources to dim the lights in my neighbourhood every time beagle or zmd fired up, so I’m hardly endorsing it, but I think if people are opposed the opposition should at least be on technical or practical merit.
edit:typo
Edited 2007-09-26 19:30 UTC
Mono might be “free software” by definition of the term, but it’s certainly not so by the spirit. It’s a trap, and very well made one at that. The fact the most people don’t see it doesn’t make it go away tho…
Your comments and others like it are indicative of a lack of knowledge about the subject. Mono is an implementation of a standarized language. Mono has its own classes and bindings. There are reimplentations of things like WindowsForms but they are unneeded in GNOME and on Linux in general. Those are the only things that Microsoft would even have a shot at taking away from FLOSS and they don’t matter to Linux. When is the last time anyone created a programming language they didn’t want anyone using anyway?
You are aware of the fact, that it is only CLR/IL + C# that has been standardized?
The copying of .NET features, is the part that can hit Mono distributors, that hasn’t made a deal with Micorsoft, yet.
Indeed. These technologies are royalty-free, and the GNOME stack is built on top of that free base. GNOME doesn’t use the Mono/Winforms or Mono/ASP.NET implementations.
I have yet to see any info on GNOME not including anything else but C# and CLR/IL? I am not sure its actually possible to get a Mono distribution without any of the parts that have “issues”.
Fedora packages the winforms and asp.net parts in separate packages (mono-winforms and mono-web). Tomboy doesn’t depend on these packages (however F-spot, Beagle and Banshee do).
Tomboy is the only Mono application that’s included in GNOME, so GNOME proper has no dependencies on winforms or asp.net, and only the Tomboy dependency on C# and CLR/CIL.
ah, ok – that makes a bit more sense then, thanks for the info. Were do mortals get those packages without using a package manager?
I do, however, still feel its a bad direction to take – next Gnome will depend on Java too (thos less bad after they GPL’ed it)…
I am all for using a “higher” level language, but I would have thought that python was high enough :/
You are aware of the fact, that it is only CLR/IL + C# that has been standardized?
The copying of .NET features, is the part that can hit Mono distributors, that hasn’t made a deal with Micorsoft, yet.
Like I said before the only thing MS could possibley stop is the Microsoft compatibility stuff and it doesn’t seem likely that they will try to stop it. After all how long has WINE beeen around without issue from Microsoft? Even if they did stop the Microsoft compatibilty code it isn’t needed for Linux applications like Tomboy, Banshee, Beagle, and F-Spot.
You’re a fool if you think that microsoft would ignore wine, if it ever hurt their bottom-line.
The fact remains, Microsoft has defacto control over the direction of C# and .NET. Mono is playing catchup to Microsoft. This is bad – no matter how you churn it, imo. Mono should stick with what they’ve got in ECMA, and then do their own things!
The fact that novell/mono has signed patent deals with microsoft should set off ALL alarm clocks, yet it hasn’t…
You’re a fool if you think that microsoft would ignore wine, if it ever hurt their bottom-line.
Will an OS that is playing catch up to an already existing OS really affect Microsoft? It hasn’t in the many years that WINE has been in existance and in those many years a lot of tin-foil-hat-wearers have predicted WINE’s demise by way of Microsft, yet it hasn’t happened. Microsoft no longer has the power to destroy OSS anyway. OSS has many allies with many patents, much more than Microsoft. A patent war with OSS is the last thing Microsoft needs.
The fact remains, Microsoft has defacto control over the direction of C# and .NET.
True, but they don’t have control over Mono. Mono doesn’t need to stay compatible with Microsoft’s .NET. Just because they are attempting to now doesn’t mean that they cannot change course in the future if Microsoft f–ks up the standard royally. After ALL Mono is open source.
Mono should stick with what they’ve got in ECMA, and then do their own things!
Holy shit have you read one thing I’ve said? Essentially that is what Mono is doing.
The fact that novell/mono has signed patent deals with microsoft should set off ALL alarm clocks, yet it hasn’t…
It only sets off alarm clock in toil-foil-hat-wearers heads. The rest of the sane world knows that Novell and Microsoft have a long history of business together and this particular agreement allows Novell much more freedom to accomplish their goals of creating software that is interoperable with Microsoft’s software.
A lot of people saw the Novell deal as bad because it doesn’t offer explicit protections to everyone who uses the software, just Novell customers. I would love for Novell to force something like this on Microsoft but it’s just not going to happen and Novell did what was best for Novell. That’s what businesses do.
Why?
Not only Gnome doesn’t require Mono, but there’s now even less chance it happens.
Remember that people were saying that C was not practical anymore for desktop dev, and that we needed a higher level language, like Java or Mono (C#).
Well, it seems like some devs found an easier solution, which is Vala (http://live.gnome.org/Vala).
Well, it’s not well documented, but if all goes right (I’m sure there’ll be lot of bitching), it could prevent the use of resource hogging (compared to C) Java or Mono on our desktop, without having to go the “harder” C++ way.
Vala is tailored for GObject, which is GTK+ specific, so in my eyes that’s the best solution for Gnome main dev language.
In my opinion, the last thing GNOME needs is a new language. I understand the advantages that Vala would bring, but it could deter the occasional contributor from submitting bug fixes or improvement patches. Even though it’s close to C#, it’s not quite C# and I’m not sure casual developers would bother to learn its quirks. Furthermore, even though Vala generates C code, it’s still an additional layer of code interpretation, bringing various bugs, issues, etc.
It wouldn’t be so bad if Vala was meant as a general purpose language, but it really looks like “by GNOME, for GNOME”, bringing the NIH syndrome to a new level. Without a large userbase, its development could slow down GNOME.
Combined with the new web-oriented direction proposed by Havoc, it looks like the core developers are having fun with a pissing contest or something like that… 😉
Anyway, my 2¢.
For those who are interested, Sun has released JDS/GNOME 2.20 B75 out on their servers, its ready to download from:
http://dlc.sun.com/osol/jds/downloads/current/
I’m running it right now, and it works beautifully; there are no known issues – but if you do find bugs, please report them 🙂
Just an update; you’ll need to upgrade libexpat to at least 2.0.1 as dbus (and other components) rely on the updated version.
I can see from this comment:
http://www.osnews.com/comment.php?news_id=5746&offset=75&rows=90#19…
that they want to split it into two components – an ECMA and the rest. I just can’t see anywhere I can download either?
Gnome does not depend on Mono.
There are some Gnome applications that depend on Mono, but they are not part of the OFFICIAL Gnome project.
Gnome includes Tomboy:
from their news section:
Tomboy: Stable version 0.6.1 released! This will be the version included by GNOME 2.18.0.
If Gnome includes tomboy, then gnome becomes dependent on any of its sub packages, and thus its dependent on mono.
Edited 2007-09-26 09:20
GNOME would only depend on Mono if it fails to build without Tomboy but AFAIk you dont *have* to build and install Tomboy. I could be wrong though.
All this pointless talk against Mono…
How about Samba? Wine? Fat32 that used to be a problem until recently? NTFS drivers? OpenOffice.org .doc filters? And so on?
How about Samba? Wine? Fat32 that used to be a problem until recently? NTFS drivers? OpenOffice.org .doc filters? And so on?
Because Mono is a little bit different in how patents have, and can be, applied to it. With stuff such as Samba, Wine, Fat32, NTFS and OpenOffice filters these are all independently produced code for interoperability purposes that you could never nail down anything common with. Microsoft prefers shifting technical goalposts anyway, which is far cheaper.
The line that many people, including the Mono project itself, have come up with is that the ECMA stuff is OK whereas the Microsoft specific APIs may not be. I really don’t know how anyone can say that. Microsoft have stated that they have a patent or two on things such as the CLR, and the ECMA provides implementers no real patent protection whatsoever. The ECMA does not state that people submitting standards can’t hold patents, but merely states that they must give some kind of RAND agreement. However, that still doesn’t stop companies from using their patents, and in that event all that can happen is that the ECMA standard in question will be dropped:
http://www.ecma-international.org/memento/codeofconduct.htm
This is why we had some discussion about the Mono people supposedly having a letter from HP and Microsoft that the common .Net underpinnings such as the CLR would be available under RAND terms forever. No such letter ever materialised, and presumably, only Novell’s customers can be sure that
The clincher is that in all of Microsoft’s patents regarding .Net related stuff that I’ve seen, they have clearly stated that the patent only applies to code run with a CLR (Common Language Runtime). It’s not a general thing as you see with most of them.
However, the the acid test is whether anyone will use Mono in the open source world (and they are), and in the absence of anything better currently that’s the way things are. Certainly from a Gnome development perspective, Mono is just a big step forward.
http://www.mono-project.com/FAQ:_Licensing