This was probably due to a poor understanding by the authors of XUL.
Because if they understood they would surely find it a superb idea?
I understand XUL and I think it's a terrible idea, much like Swing. Sure it's nice for programmers but users suffer a lesser experience due to XUL/Swing programs not fitting in the environment.
But in north america and europe where the working week is 60 hours a week, the father (or mother) can actually watch the child and maybe offer a helping hand.
An Anonymous Coward replied to that with:
Actually, in most of Europe, it's under 50 (40 in some countries).
How the heck do you work 60 hours per week? Concidering a 5-day work week that would mean working 12 hours a day.
For the record, here in Belgium people work only 39 hours a week.
Scan the dialog as follows: default action, cancel and then the alternative actions. Supposedly the eye/brain is fastest when scanning the dialog buttons in that order.
You see the Cancel and Default Action buttons first because they're nearest to the edge of the window. Those are the buttons you'll need most of the time and are certain to be there. In the rare case that you need an alternative action you can still read the rest of the dialog, being the alternative actions. I don't think the Cancel and Default Action button order is that important though.
I figure that having the allignment and button order realligned to the left, this would be OK too. It's just that there is a tradition of alligning to the right (except for Windows who allign to the center, causing it to be hard to find the most important buttons first). I bet the GNOME UI team probably came up with more reasons:).
[Save] [Don't Save] [Cancel]
When alligned to the left, this makes it slower to find Cancel because it's at a variable distance from the borders. When alligned to the right, the opposite is true.
Default Button and Cancel are the most frequently chosen options and are the only ones that are always there (except for a one-buttoned dialog but those are pretty easy:p), thus they should be the first ones scanned (knowing from Apple research that the eye is trained to jump to things such as the border of a window).
There are three problems that have caused me problems when upgrading or installing a package:
Broken (un)install/upgrade or configuration scripts.
An ideal package management system would have no install/uninstall/upgrade scripts.
Files should be copied and a number of update programs should be run (such as ldconfig) and that should be it. No per-package scripts would be involved. This would reduce the package maintainer's work too.
There should also be no configuration scripts (like in Debian) too. Other packages containing configuration tools should exist instead, these packages would have a configuration relation that is queryable from a package server.
The requirement of and old package, that has since been upgraded (with the new package being incompatible).
This problem exist soley because binary compatibility isn't taken seriously. If a new version of a program or library breaks binary compatibility or an API (command line options in case of a program), then it should be possible to install these different versions in parallel.
The requirement of a package, which files are already provided by a different package.
If two packages want to install the same file, let them. Assume it won't break binary compatibility because that's evil anyway (see 2). A timestamp (based on CVS checkin for example) for each file in the package would solve the problem of having the old version of a file installed.
An additional advantage of this would be that you could ship monolithic RPMs that contained all required files. No more dependency hunting!
Oh, and pray there are no namespace clashes. This wouldn't be a problem if third-party apps were installed in/opt and only had LSB as a requirement, distribution files were installed in/usr and programs or libraries compiled by the administrator were installed in/usr/local. Then again, if people actually listened to this LSB convention, RPM would work perfectly already.
A 120T HDD is perfect for distributed file systems, or systems similar to Freenet.
Think about it, you'd upload a file to Freenet and it would never disappear, every Freenet node that would have ever received the file could keep it cached for a long time.
With such capacity Freenet or distributed file systems would become the ultime backup tool, you'd never have to loose data again. All movies, music and books could be stored online and would be readily available from a nearby Freenet node.
But bigger HDDs will be needed so that even if most of the world is destroyed, the most important data online is preserved on single nodes.
A more optimist use for having all of the world's data on a single computer, is for sending the data along on space ships to far away galaxy's. Perhaps for humons on the ship to enjoy themselves during a trip that would take years (or generations), or for exchanging our culture with alian civilisations in outer galaxies.
Whatever happened to porting OpenOffice to GTK? Was this ever seriously considered or did I just imagine it?
I've wondered about that myself too. The nice thing is that Michael Meeks talked about doing that at FOSDEM, also he has mentioned the same thing on one of the GNOME mailing lists (can't be bothered to look this up).
Miguel de Icaza too has said that time is better spent on improving OpenOffice rather than working on say Gnumeric (which he wrote part of too).
So, nothing concrete but who knows, maybe Michael wil work on integrating OpenOffice with GNOME some day. Another possibility is that Sun will do the integration after they switch to GNOME (perhaps they could pay Ximian to do this for them?).
Slashdot Mirror
Are you saying it's a subliminal message telling you to stay off drugs?
I don't think I can have respect for this nut.
I understand XUL and I think it's a terrible idea, much like Swing. Sure it's nice for programmers but users suffer a lesser experience due to XUL/Swing programs not fitting in the environment.
A stupid question was asked and posted by an editor. Everyone (at this moment) giving the correct answer is moderated down as Flamebait.
Is this an all-time low for /.?
For the record, here in Belgium people work only 39 hours a week.
Scan the dialog as follows: default action, cancel and then the alternative actions. Supposedly the eye/brain is fastest when scanning the dialog buttons in that order.
You see the Cancel and Default Action buttons first because they're nearest to the edge of the window. Those are the buttons you'll need most of the time and are certain to be there. In the rare case that you need an alternative action you can still read the rest of the dialog, being the alternative actions. I don't think the Cancel and Default Action button order is that important though. I figure that having the allignment and button order realligned to the left, this would be OK too. It's just that there is a tradition of alligning to the right (except for Windows who allign to the center, causing it to be hard to find the most important buttons first). I bet the GNOME UI team probably came up with more reasons :).
When alligned to the left, this makes it slower to find Cancel because it's at a variable distance from the borders. When alligned to the right, the opposite is true.Default Button and Cancel are the most frequently chosen options and are the only ones that are always there (except for a one-buttoned dialog but those are pretty easy :p), thus they should be the first ones scanned (knowing from Apple research that the eye is trained to jump to things such as the border of a window).
The correct way for such a dialog, by the way, is to have [Cancel] [Ok]. Not [No] [Yes].
- Broken (un)install/upgrade or configuration scripts.
- The requirement of and old package, that has since been upgraded (with the new package being incompatible).
- The requirement of a package, which files are already provided by a different package.
Oh, and pray there are no namespace clashes. This wouldn't be a problem if third-party apps were installed inAn ideal package management system would have no install/uninstall/upgrade scripts.
Files should be copied and a number of update programs should be run (such as ldconfig) and that should be it. No per-package scripts would be involved. This would reduce the package maintainer's work too.
There should also be no configuration scripts (like in Debian) too. Other packages containing configuration tools should exist instead, these packages would have a configuration relation that is queryable from a package server.
This problem exist soley because binary compatibility isn't taken seriously. If a new version of a program or library breaks binary compatibility or an API (command line options in case of a program), then it should be possible to install these different versions in parallel.
If two packages want to install the same file, let them. Assume it won't break binary compatibility because that's evil anyway (see 2). A timestamp (based on CVS checkin for example) for each file in the package would solve the problem of having the old version of a file installed.
An additional advantage of this would be that you could ship monolithic RPMs that contained all required files. No more dependency hunting!
Think about it, you'd upload a file to Freenet and it would never disappear, every Freenet node that would have ever received the file could keep it cached for a long time.
With such capacity Freenet or distributed file systems would become the ultime backup tool, you'd never have to loose data again. All movies, music and books could be stored online and would be readily available from a nearby Freenet node.
But bigger HDDs will be needed so that even if most of the world is destroyed, the most important data online is preserved on single nodes.
A more optimist use for having all of the world's data on a single computer, is for sending the data along on space ships to far away galaxy's. Perhaps for humons on the ship to enjoy themselves during a trip that would take years (or generations), or for exchanging our culture with alian civilisations in outer galaxies.
Miguel de Icaza too has said that time is better spent on improving OpenOffice rather than working on say Gnumeric (which he wrote part of too).
So, nothing concrete but who knows, maybe Michael wil work on integrating OpenOffice with GNOME some day. Another possibility is that Sun will do the integration after they switch to GNOME (perhaps they could pay Ximian to do this for them?).
Just dreaming out loud here.