<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.