Pandora Standards

Should the Pandora have a set of agreed standards ?

  • Yes

    Votes: 76 85.4%
  • No

    Votes: 5 5.6%
  • Not Bothered

    Votes: 8 9.0%

  • Total voters
    89

Spectralist said:
WizardStan said:
It's not like they'd be enforced.

For example lets say 100% of people support the 'A' button being confirm. 75% Support the 'B' button to be cancel with the remainder split between 'X' and 'Y'. The standard would end up saying that 'A' is confirm and 'B' is cancel. But most of the devs who don't like 'B' for cancel still probably wont use it. So what does the standard accomplish? I guess those with no opinion on the matter might look up the standard and follow it, as you say. But I can't imagine a lot of people would have no real opinion on any design aspect that is large or visible enough to be discussed in a standard.

I disagree..
People not wanting to follow standards will do their own thing either way. People who don't understand (or dont wanna mess around figuring) ergonomics would have an aid and a quick reference. I really fail to see a downside.
If I had a choice of 2 identical applications, one acted the way I expected and the other didn't then I know which I would choose.

And an example in the whole ABXY post scenario. As long as it deters one person from using "Y" as accept and "A" as cancel (because they just didn't know better), then the standards have done their job IMHO.

The HAL/abstraction idea - well, frankly, thats an even better idea (but would need the standards in place anyway), allowing remapping and such. Could be an issue when porting, but I suppose so would anything else. Even if just on the simplest level constants are used for that (in a pandora.h header or something) then somebody who doesn't like it can just remap and compile. It's not perfect but it beats every program doing completely different things.
 
Last edited by a moderator:
Looking at the Poll results so far and reading through the thread it would seem that the vast majority of Pandora users would appreciate some general standards.

My guess is that the people who don't want standards were more likely to respond with a post explaining their position so that the minority view was heard. Many thanks to those who took time to do this.

As nobody seemed to suggest a better way of proposing / debating / recording standards I'm assuming that people are generally happy with the methods proposed in the initial post.

With this in mind I'm going to be proposing a few standards, I'll wait until next week before doing this just in case anyone can think of a better way of doing it.
 
My first standards proposal is to start a wiki page for standards (proposed and accepted). Perhaps a template. Something like

Summary: one short line which explains what the standard is meant to do. "Location of scroll bars" for example
Group (probably a bad name, someone suggest something better): One (or more) words selected from an enumerated list, things like "gui" or "files" or something. We can add to the list as needed.
Status: proposed, discussed, accepted, rejected, or withdrawn. And one more that says "this sounds kind of a like a good idea but no one can really agree yet on exactly how it would best work, so we're going to keep it on the table and think about it some more" but I can't think of a single word that says that.
Description: a more complete description. "Vertical scroll bars should be on the right of the window they affect, horizontal scroll bars should be on the bottom of the window they affect"
Process: If the proposal has anything specific (possibly also non-obvious) that needs to be followed in order to achieve the desired effect. Images and better details can go here.
Submitter: signature (nick or email) of the person who made the original proposal. If any ambiguities come up or changes need to be made to the proposal, this person should probably be kept in the loop.[/code]

With the proposals on the wiki, we can use the talk pages to discuss, and they becomes easily indexed and searchable.
 
About program-related standards:
Never ever make them language specific, as the tendency seems to be here.

E.g. for controls or such: don't tell me to "use this and that header file to comply to the standard". The standard must be language agnostic or it won't be a standard (because what is a standard worth if it can't be complied to). Define a well-known config file location for controls, and that'll be it.

Same thing apples to standard libraries, like a library that tells you when the lid is closed, or a library that tells you when PNDs have been discovered (*cough* libpnd *cough*). Why a library? Using the D-Bus would be much more language-agnostic and lightweight; then, I won't have to care about linking to some obscure .a file or updating that .a file for new releases, or writing a wrapper for my language of choice. I'll just have to listen for a D-Bus message (which is possible in most languages that run on the Linux platform).

About the meta-standard proposed by WizardStan:
Good start, but I'd add some more sections (Partly taken from the Fedora project's standards management system):
Summary
Kind/Area/Topic?
Status
Description
Benefit - Why does this standard exist and how does it improve whatever it is that it improves.
Scope - How deep-going is this standard, e.g. "This standard defines where scrollbars are to be placed, which sizes they may have, and how the arrows are to be laid out. You are still free to choose which colors to use, and......"
Reference implementation - Link to projects, or source code listings, where the standard is being applied correctly.
Process
Verification - Can something be done to verify that the standard is being followed? Think of this as a unit test, or similar. Could be e.g. "Use this XML Schema" or "Try opening the file with this program" or "Use the generated executable to link to this library"
Dependencies - Does this standard assume that other standards are being followed as well?
Submitter
Owner - Whom to contact for clarifications about the standard's wording, or about specific implementation details. This is the person who maintains the standard, while the submitter came up with the standard.
 
gp32rich said:
first person to release skeleton code for the amateurs to start from gets to set the standards! :p
Code:
int main()
{
// code goes in here
    return 1;
};
I win!
 
Last edited by a moderator:
Back
Top