[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-quality
Subject: Re: discuss: consistency in KDE GUI
From: "Big O" <illogical1 () gmail ! com>
Date: 2006-12-23 13:47:14
Message-ID: 797cc39c0612230547l4cdeef79vb0934b60f30cd46f () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 12/22/06, Aaron J. Seigo <aseigo@kde.org> wrote:
>
>
>
> i don't see what freedom a developer loses here. you know, other than
> making
> the user experience suck.
>
> > Convenience libs can provide convenience while still offering
> > the choice to deviate from the norm if desired.
>
> sure; any app is free to supply their own Configure Shortcuts dialog, for
> instance, even today.
>
> > 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.
>
> we've always enforced these things in the libs. never been a problem; in
> fact
> it's been a blessing. why?
I believe there is something not being communicated here so I'll attempt to
do so.
M. Subbu made a comment in the original mail "Should KDE core libs be
engineered to encourage (or enforce) this consistency?"
If you simply tell someone "Don't do that" and they ignore you nothing is
being enforced IMO. The only way then to truly enforce the HIG on anyone
outside of the official KDE project would be to restrict the code to reflect
only what is described in the HIG. So to use an old example, if confirmation
buttons could only be OK/Cancel, you would have your KConfigButton class
which only create OK/Cancel with no possibility for anything else.
As it stands standards are encouraged. We have classes with defaults
reflected the HIG. yay. Way to go, that's the way it was meant to be. At the
same time we're are not en"forcing" anything on anything.
a) it creates similarity between apps that our users LOVE (and that's why we
> create software: to be used, ergo for users; that includes us)
> b) it saves HUGE amounts of time, both today and down the road.
>
> e.g. when we get to reworking the application shorcuts systems we likely
> won't
> have to touch one line in any application. a recompile and every app will
> have a nicer configure shortcuts dialog that is consistent with every
> other
> one.
>
> look at other platforms where they have to invest amazing amounts of
> effort to
> keep things looking similar and still end up a soupy mess.
Soupy messes are nasty and should be avoided at all costs, I agree. I wasn't
arguing against the setup you describe (which is basically the current
system). Hopefully I've cleared that up.
--
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
>
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
>
>
> _______________________________________________
> kde-quality mailing list
> kde-quality@kde.org
> https://mail.kde.org/mailman/listinfo/kde-quality
>
>
>
>
Orville
Full time complainer supported by Hot Air Inc.
--
All your gmail are belong to us.
[Attachment #5 (text/html)]
<br><br><div><span class="gmail_quote">On 12/22/06, <b class="gmail_sendername">Aaron \
J. Seigo</b> <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> \
wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br><br>i don't see \
what freedom a developer loses here. you know, other than making<br>the user \
experience suck.<br><br>> Convenience libs can provide convenience while still \
offering<br>> the choice to deviate from the norm if desired. <br><br>sure; any \
app is free to supply their own Configure Shortcuts dialog, for<br>instance, even \
today.<br><br>> KDE can still dictate<br>> policy (and enforce with avengeance) \
in it's own apps, as well it<br> > should.<br><br>=)<br><br>> But to \
enforce this _in the libs_ is to unnecessarily<br>> restrict those who may seek to \
use the platform.<br><br>we've always enforced these things in the libs. never \
been a problem; in fact <br>it's been a blessing. why?</blockquote><div>I believe \
there is something not being communicated here so I'll attempt to do so. <br>M. \
Subbu made a comment in the original mail "Should KDE core libs be engineered to \
encourage (or enforce) this consistency?" <br><br>If you simply tell someone \
"Don't do that" and they ignore you nothing is being enforced IMO. The \
only way then to truly enforce the HIG on anyone outside of the official KDE project \
would be to restrict the code to reflect only what is described in the HIG. So to use \
an old example, if confirmation buttons could only be OK/Cancel, you would have your \
KConfigButton class which only create OK/Cancel with no possibility for anything \
else. <br>As it stands standards are encouraged. We have classes with defaults \
reflected the HIG. yay. Way to go, that's the way it was meant to be. At the same \
time we're are not en"forcing" anything on anything. \
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">a) it creates similarity \
between apps that our users LOVE (and that's why we <br>create software: to be \
used, ergo for users; that includes us)<br>b) it saves HUGE amounts of time, both \
today and down the road.<br><br>e.g. when we get to reworking the application \
shorcuts systems we likely won't <br>have to touch one line in any application. a \
recompile and every app will<br>have a nicer configure shortcuts dialog that is \
consistent with every other<br>one.<br><br>look at other platforms where they have to \
invest amazing amounts of effort to <br>keep things looking similar and still end up \
a soupy mess.</blockquote><div><br>Soupy messes are nasty and should be avoided at \
all costs, I agree. I wasn't arguing against the setup you describe (which is \
basically the current system). Hopefully I've cleared that up. \
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">--<br>Aaron J. \
Seigo<br>humru othro a kohnu se<br>GPG Fingerprint: 8B8B 2209 0C6F 7C47 \
B1EA EE75 D6B7 2EB1 A7F1 DB43 <br><br>Full time KDE developer sponsored by \
Trolltech (<a href="http://www.trolltech.com">http://www.trolltech.com</a>)<br><br><br>_______________________________________________<br>kde-quality \
mailing list<br><a href="mailto:kde-quality@kde.org"> kde-quality@kde.org</a><br><a \
href="https://mail.kde.org/mailman/listinfo/kde-quality">https://mail.kde.org/mailman/listinfo/kde-quality</a><br><br><br><br></blockquote></div><br>Orville \
<br>Full time complainer supported by Hot Air Inc. <br>-- <br>All your gmail are \
belong to us.
_______________________________________________
kde-quality mailing list
kde-quality@kde.org
https://mail.kde.org/mailman/listinfo/kde-quality
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic