<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 05/16/2014 01:37 AM, Crístian Viana
      wrote:<br>
    </div>
    <blockquote cite="mid:5374FB49.20103@linux.vnet.ibm.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      On 15-05-2014 00:30, Hongliang Wang wrote:<br>
      <blockquote cite="mid:537434D5.4040105@linux.vnet.ibm.com"
        type="cite">
        <meta content="text/html; charset=UTF-8"
          http-equiv="Content-Type">
        It's an interesting topic here.</blockquote>
      I agree :-) I wish we had more discussions like this here.<br>
      <blockquote cite="mid:537434D5.4040105@linux.vnet.ibm.com"
        type="cite">Take edit template for example. The flow is:<br>
        List templates =&gt;<br>
        Select a template to edit by clicking the "<b>Edit</b>" Button
        =&gt;<br>
        Edit template window is open, and user changes some fields.
        =&gt;<br>
        Click the "<b>Save</b>" (Or "Submit") Button to save (or submit)
        changes.<br>
        <br>
        Notice that "Edit" means the user is about to edit the template,
        so "Edit'" Button should trigger a pop-up window to allow user
        to change some fields.<br>
        And "Save" Button is for saving user's changes to server. So I
        think it's reasonable to use these 2 labels for these 2
        different purposes.<br>
      </blockquote>
      You're right, that's another way of labeling the buttons. But this
      is also not used in throughout Kimchi and that's what concerns me.
      Some windows have the "Save" button, some windows have the same
      label as the button which triggered it; we need a consistency.
      Whichever way is fine for me, as long as it looks consistent. I
      don't like the idea of having each dialog of the same application
      designed differently, even if subtly, which is how I feel it is
      now.<br>
      I also thought about always using "Save" as the buttons' labels,
      as you said, and that sounds totally fine for me. If we think this
      approach is better, I'll use this approach on the next version of
      this patchset.<br>
    </blockquote>
    Go ahead! Either "Save" or "Submit" is fine for me.<br>
    <blockquote cite="mid:5374FB49.20103@linux.vnet.ibm.com" type="cite">
      <blockquote cite="mid:537434D5.4040105@linux.vnet.ibm.com"
        type="cite">Let me explain the naming rule of
        #guest-edit-button-save. It follows name space style like Java
        package mechanism.<br>
        guest-: It's within the scope of guest page<br>
        edit-: It's within the scope of guest edit window<br>
        button-: It's a button within the scope of guest edit window<br>
        save: It's a button named save<br>
        <br>
        So please remain the original ID string of the button. If we
        will introduce another button in the future, we can simply name
        it "#guest-edit-button-newid".<br>
      </blockquote>
      Thanks for the explanation, it makes total sense. I just blindly
      removed the "save" string from the variable name, I should have
      left "edit" instead, which is the new label I'm using.<br>
      But, again, this variable naming rule is also not consistent
      throughout thel Kimchi code. For example, the submit button of the
      dialog "Create Storage Pool" has an id="pool-doAdd". According to
      this naming rule, it should be something like
      "storage-add-button-create". In this patch, I was just trying to
      remove the reference to "save", which was the label I removed. I
      agree I should have left the new label on the ID, "edit". But I
      think this is a different discussion, regarding coding
      consistency, which [definitely] needs to be addressed in future
      patches. I'll use "guest-edit-button-edit" in the next version of
      this patch to keep the style you mentioned.<br>
    </blockquote>
    Agree. The naming rules is totally not consistent because we didn't
    propose one unified. I also think we need have a unified naming rule
    (as well as same user experience through out Kimchi, including
    windows, dialog s, buttons, operation behaviors, etc.). Maybe we
    need propose a coding/designing guideline documentation for future
    code. If we are planning to, I'm glad to be involved in.<br>
    <br>
  </body>
</html>