discuss: consistency in KDE GUI

[Big O]

On 12/22/06, Friedrich W. H. Kossebau <friedrich.w.h at kossebau.de> wrote:
> Am Freitag, 22. Dezember 2006 15:10, schrieb Orville Bennett:
> > On Dec 22, 2006, at 8:57 AM, Friedrich W. H. Kossebau wrote:
> > > Hi,
> > >
> > > Am Freitag, 22. Dezember 2006 14:47, schrieb Orville Bennett:
> > >> On Dec 22, 2006, at 1:12 AM, subbukk wrote:
> > >>> Should KDE core libs be engineered to encourage (or enforce) this
> > >>> consistency?
> > >>
> > >> How do you encourage consistency with a set of libraries? I can see
> > >> how you could enforce this, but "therein lies the path to destruction
> > >> my son."
> > >
> > > Oh. What do you mean by this?
> >
> > By forcing someone to conform to your standards of what is best, you
> > encourage them to go elsewhere.
>
(WARNING: The following statements are based on nothing more than
supposition and wild speculation.)
Now that that's taken care of...
> Unless you give good arguments for the standard :)
I think even when you give good arguments for the standard someone
will still want/need to change them because a) Your "standard" has
become outdated. b) someone just doesn't like it. Your standard, while
appropriate for you may not be appropriate for everyone else. Now if
you're saying KDE should just focus on itself and isn't a platform for
developing independent apps, then this discussion is moot.

> And giving the developer a default implementation in terms of a lib also helps
> things to be done more quickly.
> E.g. noone is forced to use a QPushButton. But don't we all use it?
> Because it get's us a button that does nearly all in the way that makes sense?
>
> > Some applications violate certain
> > aspects of the HIG as it stands, and will probably continue to do so
> > in the future.
>
> Are you sure they all violate by decision? Perhaps some developers simply
> concetrated on other things, those which were the itch they want to scratch.
> And just made a quick'n'dirty implementation for the things that had to be
> done, too. Because there was no default (implementation).
Let's look at amarok. The menubar, as of 1.4 has no File entry. It
says Engage. WTH does that means w/ respect to audio playback?
Nothing. Not one single, solitary thing. Now I look at that, chuckle,
say "Cool". And go on playing my music. Another user may groan, say
"Ugh." in disgust and continue playing music. Inevitably, we both
eventually will want to find out what the heck is up there. And so
slowly, but surely, we reach. And we may find something we've never
seen before. I believe that's when I noticed last.fm radio
integration.

So in this case, and we'll say it was intentional, the developers have
found a sly way to introduce new functionality to both new and
experienced users. "But Orville" you say, "surely you read the release
anouncement on the dot." Yes, I did. And promptly forgot everything
therein soon after. I mean, sure I know the amarok devs have a
penchant for the flashy, and that this was probably some gimmicky way
of announcing the "launching" of 1.4, in tune with the release
codenames.
But what about those who don't read the dot. or the release
announcements, or just installed a distro and want to play some music.
The windows users trying out the amarok live CD or their first linux
distro won't necessarily see the codename tie in. He sees the file
menu and may go there or not. But "Engage", it piques an interest. It
draws you. It interacts with you. Well, you get the idea. And before
you know it, you've discovered something. Maybe you'll use it, maybe
not, but it's permanently etched in your mind.
It also looks far better than File in big red letters. That's just annoying :-)

>
> > If compliance were forced upon them they could choose
> > in the begin, they could easily have chosen another platform to
> > develop on, if it's forced after, they could choose to spend valuable
> > time trying to undo this instead of contributing to their respective
> > apps. And that, that would be a shame.
>
> Sure. :) But I don't see your point here. If they don't want to feel forced by
> using the convenience libs (which "enforce" the standard), they would have to
> implement the things anyway on their own. So what would they loose?
Freedom? Convenience libs can provide convenience while still offering
the choice to deviate from the norm if desired. KDE can still dictate
policy (and enforce with avengeance) in it's own apps, as well it
should.  But to enforce this _in the libs_ is to unnecessarily
restrict those who may seek to use the platform.

>
> So thanks for explaning. But I disagree :)
I hope my enhanced explanation has changed your mind :-)
And we really need a kde-offtopic ML for stuff like this :-D

>
> Friedrich
> _______________________________________________
> kde-quality mailing list
> kde-quality at kde.org
> https://mail.kde.org/mailman/listinfo/kde-quality
>


-- 
All your gmail are belong to us.