Slashdot Mirror

Seriously, it's probably like 40 lines of code to have a config option

And how many lines to test the interactions of that option with other options? Moving functionality out to an extension allows defects due to unintended interactions to be reported against that particular extension rather than against the browser in general.

And how many lines of documentation to describe that option? And how many lines of code to run a tutorial lightbox to make sure the user finds that option among all the options?

It's because they treat their users like moron. Literally. Here is the article that started the whole "let's remove preferences" movement that began with GNOME and spread to many other formerly great apps: http://ometer.com/preferences....

Take the famous âoetoo many clocksâ example (2015 note - this doesnâ(TM)t seem to be online anymore, but it was a usability study Sun did in 2001). A significant number of test subjects were so surprised to have 5 choices of clock they couldnâ(TM)t figure out how to add a clock to their panel. This cost of preferences is invariably underestimated by us technical types.

In other words, design your UI for people so dumb they are surprised by choice and can't comprehend having to make a trivial, cosmetic decision.

If a product ships broken but has an "unbreak" checkbox, it still ships broken.

However the player wants it to be displayed.

How does a player who lacks the time to specify how it shall be displayed want it to be displayed?

square pixels (even if the system would never display them as such, like the Master System or SNES)

Incidentally, the exact pixel aspect ratio for Master System, NES, Genesis H32 mode, and Super NES is 8:7. This can be calculated from their pixel clock rate (945/176 MHz), the nominal scanline width of Rec. 601 (704 cycles of a 13.5 MHz clock), and the 240-pixel height and 4:3 shape of the visible portion of an NTSC field. I've been collecting other platforms' pixel clock rates and PARs as well.

You really can please all the people all the time, if your software is capable of supplying the things they want.

For most people, a reasonable default is high on the list of "the things they want". Out-of-box experience is very important with the short-form games common on mobile. I imagine that most short-form reviewers of a mobile app will not want to touch every combination of settings. As Havoc Pennington pointed out, an "unbreak my application please" checkbox buried in a huge settings list is not acceptable. This means a game has to look good without explicit configuration. Some people will complain if there are massive borders by default to ensure lack of blur; others will complain if there is blur by default to ensure lack of massive borders. So given the problem of scaling art intended to be viewed at 256x208 with 8:7 pixel aspect ratio to multiple modern devices, what are the "good defaults that Just Work" as Havoc put it?

All Ican figure is that either the author either believes that it's not classic if we can customize a GUI to the point that it's no longer "classic" looking

In my opinion, a desktop that can be easily customized to act "classic" is classic enough, so long as users are made aware of this customizability. But there's a practical problem with presenting too many options for customizability. See the section "The Question of Preferences" in this article.

or is judging it based on the first few releases when it wasn't fully functional as a 'classic' desktop yet

A not-yet-fully-functional GUI shouldn't be shipped as the default GUI of a GUI-oriented operating system until such time as it becomes fully functional.

The movement against excessive options started with an article by Havoc Pennington that describes why Linux desktops had such bad user interfaces back in the 90s and early 2000s:

http://ometer.com/free-software-ui.html

You have to read it with the proper historical context in mind. Some examples he gives of the state of the desktop at the time are:

* Emacs having a broken-by-default cut and paste feature, and you had to go into the preferences dialog to make it standards-compliaint
* Gnome 1.x used to have 5 different clock applets, and during usability testing people would asking why are there 5 clocks to choose? More of a problem was that they assumed that there was a good reason for having 5 clocks, and would then spend a lot of time thinking about which of the 5 clocks was right for them.

It wasn't so much an idea that "options are bad" but rather that "options have a cost", and so excessive options are bad and that the default option should be something reasonable. There should never be an option to "unbreak" something like clipboard standards.

You could argue that Gnome 3.x takes it too far (I disagree, but that's just my opinion), but there are good reasons to remove the fallback mode. The fact is, no one uses it. The people who the fallback mode is targetted towards have already (very vocally!) moved to KDE/XFCE. So why bother developing something for users who aren't going to use it anyway?

Some of the things they've left out boggle the mind, since it must have been a conscious decision.

I'm pretty sure it was a conscious decision. Search this page for "The Question of Preferences". Try installing CompizConfig to get a lot of the settings back.

This looks a bit like the OS used on the litl webbooks. It's an interesting idea, to choose a specific niche with specific constraints, and really target it. I'm still unsure whether this precise niche (almost-always online, only apps that can be delivered via the browser) is a large enough niche to be useful.

Yes, because that is without costs...

Read, for example, http://ometer.com/features.html

See Havoc Pennington's blog entry on this

excerpt:
<quote>I would define an "embedded" language as one that doesn't come with a platform. It's small and easy to glue together with an app written in C or C++. It uses the same platform as the app. If the platform has an introspection capability like XPCOM or GObject-Introspection, then the platform can be exported to the embedded language in an automated way.</quote>

"By that rationelle, in my case neither KDE, GNOME, XFCE, Windows, OSX, BeOS, OS/2, Fluxbox or indeed any other windowing system I have ever seen has "got it right" out of the box."

Correct. Some of them just try harder than others.

While some kinds of preferences make total sense, some do not and too many are generally a bad thing. To paraphrase a wise hacker, those extra preferences are just way for lazy developers to avoid making hard decisions.

Just scroll bit down to GNOME Online Desktop. Open Source desktop guys are talking about this idea for a long time. They want to build interface with contacts list as central place. People (online presences) are to become major pivot point. Telepathy, Galago, Decibel, KIMProxy gave application access to uniform online connectivity and presence information.
Additionally, projects like Stateless Linux break ties between user's documents and his computer. User's desktop moves with him when changing laptops etc.
They even built ,,aggregator for popular online sites and social notworking websites'' -- check Mugshot.

My standard advice: http://ometer.com/hacking.html

Anyway, you don't join a project - there's no membership list, and there's nobody who will tell you do this or do that or whatever.

What you do is get on the forums (usually mailing lists, IRC, and bug tracker), start following the discussions, and help out where help appears to be needed. That's it.

If you wait for hand-holding or permission you won't get anything done. You have to be persistent and just start doing stuff.

I think Linus's point was that certain GNOME developers refuse features not because they're too hard to do but because UI is some cathedral that requires perfection. Take the first question in the FAQ from the metacity README : "Will you add my feature?"

The guy basically says "Only if everyone would like it to be there." And lets take the article linked to after that explanation: http://ometer.com/free-software-ui.html The contradiction of "Not enough UI designers" and "Too many cooks" might not be obvious, especially if you feel that designers aren't programmers. But open source software doesn't make that distinction. I actually find it nice in this regard: it avoids situations in which some volunteers tell other volunteers what to do, and more importantly, what not to do. There's a fairly recent parable of the mice and the bell. It can easy to propose and vote that something should be done, but sometimes doing it is another thing. Open source projects focused on patch sets eliminate this.

GNOME is not a platform for programmers. GNOME developers should not be surprised then, when programmers notice this and either avoid it or complain in some fashion.

Redhat still trying to figure out how to lure the opensource community back.

Are you talking about the open source community that includes people like Alan Cox, Ingo Molnar, Havoc Pennington, and Owen Taylor? It never left.

Are you part of a new, anti-RedHat OSS community? What have you written?

"My full real name found on my official government documents is "Robert Sanford Havoc Pennington." Everyone calls me Havoc, and always has. I didn't make it up. There isn't a cool story about it, my parents are just weird. It is not a nickname. No, I do not wreak havoc, usually. Yes, I have heard any and all jokes you can think of about this." -- Havoc Pennington's Home Page

HP continue to be involved in the GNOME Foundation, to great effect.


HP also involved in FreeDesktop.org too.

No.. there is no formal connection between Mono and Evolution, although both are products of Ximian.

A very good read is this piece by Havoc Pennington, of GNOME fame.

Basically he says that there are ideas that integrating some high-level, sandboxed platforms like Mono/.NET and/or Java into the Linux desktop. (or more specifically, GNOME)

He also says that they're not going to use Mono or Java in Gnome (and where Gnome goes, Evolution goes) until there is some kind of road-map on which technology should be used and how.

Personally, I find Java more compelling. C# may be a nicer language, but there is no control over which direction the class libraries will take. The Java Community Process is at least a somewhat open alternative.

You are awesome. He always has something cool to say. I would recommend anyone to read blogs.redhat.com daily and see whats going on over at redhat. In particular, you can read Havoc's log and other cool stuff here. My favorite is his editorial on "Why free software maintainers are so stuborn".
Regards,
Steve

Havoc Pennington recently stated that he also sees legal issues by using MONO technology in GNOME read here and here.

There are another few comments made by Havoc Pennington this year but I wasn't able to find the links. So you people should better be sceptical by using MONO technology because MONO is moving in the gray area here and is probably becomming a big legal issue.

Though Java and Mono are both free as in beer, they are not free in the way Gnome would need them to be. Check out this for a detailed explanation.

Look dude... you are acting like it's the responsibility of the Gnome developers to produce a desktop that you like. It sounds to me that you like the design choices of KDE over the design choices of Gnome. Personally, I find the KDE applications and general desktop environment ugly and cluttered, while I enjoy the simple and sleek elegance of Gnome. So it should be apparent to you that I prefer the design choices of Gnome over the design choices of KDE.

Two desktop environments for X11, each optimized for users with different preferences for user interfaces. And the best part is that they all interoperate, so I have no problem running KWorldClock in my Gnome environment, and you can run Evolution or whatever you want in your KDE. Check out what Havoc had to say about how modern DEs can interoperate these days.

So by my definitions, Gnome is progressing rapidly. I'm enjoying version 2.6 over 2.4 after using it for only a few days. Do I consider KDE to be regressing because it is getting more cluttered and ugly by my standards? That would hardly be fair... it's progressing in it's own way, and the same is true for the Gnome project. Mr. Rodney King, we _can_ all get along, just don't let slashdot know.

• include a complete implementation of the current version of this specification without subsetting or supersetting;
• implement all the interfaces and functionality of the required packages of the Java 2 Platform, Standard Edition, as defined by SUN, without subsetting or supersetting;
• pass all test suites relating to the most recent published version of the specification of the Java 2 Platform, Standard Edition, that are available from SUN six (6) months prior to any beta release of the clean room implementation or upgrade thereto;

Well, let me put it this way:

Yes, there are existing efforts at making a Free Software JVM/Java implementation - notably GCJ and Kaffe - and it is perfectly legal to do so. However, the big problem is reimplementing the whole Java API. Java has probably one of the biggest unified API's ever. Creating a compatible and stable implementation is not only a massive job, but also such an effort will be forever playing catch up! GNU Classpath is an admirable effort, relied upon by pretty much every GPL Java implementation, but just look at all the core stuff missing from the API!

If Sun GPL'd all its API, we could have a functional 100% free Java implementation right now, and they could still keep their own JVM tech proprietary, maybe sell it as a high performance option or something. Also, think of the improvements and bugfixes you'd get with thousands of people hacking on the class libraries?

As for forking the language, I think Sun could use its existing Community infrastructure to help tie development together and prevent this. Perl, PHP, Python, Ruby, etc are all open languages, yet forking is not a problem with them! As for Microsoft somehow doing evil stuff with Java - they have C# doing a good enough job at eroding Java already!

Another advantage to opening Java would be that distributions could include it in the base install. As it stands, if you want to run Sun's JVM, you have to go to their website seperately and download it. Even their download procedure itself can be a pain (especially on a server)!

Other people have blamed distros themselves for "religious" attitudes, but the fact is they simply aren't allowed to distribute JVMs, without at least adding all kinds of EULAs etc to the installer.

In my opinion Sun should:

• Preferably GPL the API
• At very least allow binary distribution by distros

If Sun opened it up, Java could become the base language of GNOME as detailed here. Think of how cool it would be to use a well established, modern language to write GNOME apps? And Sun would get even more of a foothold with their language.

The Future of OSS Desktop Development, Part II is a current discussion of the blog debate between Havoc Pennington and Miguel de Icaza regarding Havoc's initial essay on Mono, Java, and the Linux desktop.

also worth a read is Rasterman's (lead developer of the Enlightenment project) comment.

educate yourself.

peace

Thankfully people are working on this, or at least part of the problem.

AIUI in response to this article by Havoc Pennington a project called HAL was started. This will hopefully form the userspace part of stack for convenient automounting behaviour. It's worth looking at the current (0.2) spec for the detail, but essentially you should be able to plug in an iPod and have RhythmBox detect that (via HAL, communicating using dbus).

Dia has a windows version. Like many (if not most) free software it's a little rough around the UI edges, but it works and it's free.

-Adam

...who'd never heard of this IDE before, and always want screenshots to quickly judge for themselves if something is worth a further look:
screenshot 1, screenshot 2, screenshot 3. (They're kinda old, so undoubtedly this thing has evolved quite a bit further since then.)

...who'd never heard of this IDE before, and always want screenshots to quickly judge for themselves if something is worth a further look:
screenshot 1, screenshot 2, screenshot 3. (They're kinda old, so undoubtedly this thing has evolved quite a bit further since then.)

...who'd never heard of this IDE before, and always want screenshots to quickly judge for themselves if something is worth a further look:
screenshot 1, screenshot 2, screenshot 3. (They're kinda old, so undoubtedly this thing has evolved quite a bit further since then.)