[HST] Plans for coming week - please read

[Hans Petter Jansson <hpj helixcode com>]

I'm not sure who's on this list (I'd appreciate the admin password), so I'm
keeping the Cc list I've seen Miguel using.

Okay, so we released 0.2.0 this weekend, but we still have pretty urgent
things to fix. I'm calling for a 0.2.1 release on sunday evening or monday
morning next week. That's the 12th or 13th. I notified gnome-i18n, so they'll
have the translations in a non-broken state before the release.

Before that release we'll fix as many technical problems as possible. I have
a list here, based on our own observations of the snapsnot released as 0.2.0.
I haven't gotten any actual bug reports from users yet, apart from the fact
that it doesn't work with the old control-center (it's not supposed to, but a
workaround for the system menu is in the list anyway).

Assigned tasks are marked with the name of whoever they're assigned to. In
this list, I've tentatively assigned some to myself. You should pick the
tasks that you think you can handle efficiently within the time frame.

After the 0.2.1 release, I'd like to see some serious interface action, and
we'll be helping out with the code necessary to implement the improvements
you have. Taylor and Anna, you can think about the interfaces in the
meantime. Get the package from

ftp://ftp.helixcode.com/pub/setuptools/helix-setup-tools-0.2.0.tar.gz

I'd be very happy to see some Glade mockups. Also, what I'm thinking on the
interface issue is that we need a complete refactoring of all the tools, with
global style enforcement.

The following lists contain technical issues only, that should be fixed by
myself, Arturo or Tambet. If you're not doing code on the tools, you don't
have to read them.


Things to fix
-------------

- When EMap zooms out, the visible area doesn't center on the old centered
  position, but instead keeps the old adjustment offset, scaled to the new
  map size. [Hans Petter]

- When EMap zooms in, it doesn't scroll to show as much as possible around
  the area that's zoomed to, before it starts zooming. It does so afterwards,
  which sometimes makes the view jump (ugly). I'd like to see a smooth scroll
  here, possibly using an acceleration-plateau-deceleration approach, so it's
  consistent with the smooth-zoom hack. [Hans Petter]

- Shares and Disks need to check if a specified mount point exists, and if it
  doesn't, ask the user if she wants it created, then create it if she
  confirms. This should happen right after the point in question is
  specified, i.e. before the mount information dialog closes. It could have
  three buttons - a) Create (default), b) Don't create, c) Back to dialog.
  Of course, the naming can be different.

- Buttons that don't complete an action immediately, but starts an interface
  procedure, like a dialog, should have "..." tacked to the end of their
  names.

- Shares-admin always sets a comment of "0" in exported shares. Probably a
  Perl oddity that popped up during the move to be.pl. [Hans Petter]

- Enable the tools to su themselves, while we wait for a release of
  root-manager and/or console-helper. This is the biggest gripe people have
  now, and I've heard it three or four times already. We might use the hack
  from the Stormix distribution (?), that talks to su through a pty (I'll try
  to find the message that mentions that). If that fails, we can just chop
  our own heads off and make the tools +s, using a crypt() check.

  Particulary important because it keeps novice users from trying out the
  tools, and we really need them to.

- Users can't change passwords yet.

- Progress indicators should be set to 100% and stay visible for one second
  of time before they go away. Windows that flicker in and out of existence
  too quickly to see what they are, make users uneasy.


Middle term fixes
-----------------

If any of this could be done within a week, it would be great. If you think
not, don't touch it until after we release 0.2.1.

- Multi-interfaces handling in Networking. There's no way around it - right
  now it's just too confusing and people break their network settings.

- Make an error reporting protocol for the backends. This protocol will be
  employed when the --set method is invoked, if the --report flag is also
  specified.

  The protocol has some similarities to existing Internet protocols. Every
  reported condition is one a single line, consisting of a three-digit
  decimal value followed by a space and a free-form string. The first digit
  is globally defined, and specifies what kind of report message it carries.

  1xx: Informational.
  2xx: Success.
  3xx: Warning.
  4xx: Error.
  5xx: Fatal error - new configuration will not appear to work, at all.

  The second and third digits are defined by the individual backend, and
  carry extra information that allows the frontend to know what happened
  without parsing the text string. Examples:

  149 Restarting Samba.
  210 Samba restarted successfully.
  305 Mounted share "/mnt/human_rights/" appears empty.
  405 Samba not installed.
  513 Could not locate tools needed for config manipulation.

  All messages would be written to stdout while the backend works. We keep
  the stderr reporting system invoked by "-v", as it serves a different
  purpose (communicating with shell users).

  I'd also like to integrate the progress reporting in this protocol. All
  message numbers under 100 could be assigned to it, and the number would
  represent % done. Then we add progress reporting to the --set operation as
  well, and make --report work with --get.
  
  A blank line indicates that the tool is finished. In the case of --get, the
  produced XML follows directly after the blank line.

  Then we can have, for both get and set, a) a progress meter and b) a small
  text display showing what the backend is doing.


--
Hans Petter