On May 23, 2004, at 2:36 PM, Dan Aloni wrote:
> On Sat, May 22, 2004 at 02:38:13PM -0700, Kevin & Masako Ollivier
>> As promised, I have created a prototype of how I see coManager and
>> configurator fitting together. Also, I've GPLed coManager.py to avoid
>> any nasty licensing issues. Screenshots and a downloadable prototype
>> are available from here:
>> Also, I have created a third .py file which I am calling colinux.py.
>> This is where I think all the core coLinux data objects (i.e.
>> and helper functions should go, so that they can be used by the
>> manager, the configurator, and any other utilities that get created
>> along the way.
>> Any comments and suggestions are greatly appreciated! If people agree
>> that this GUI is not in need of any major modifications, I'll start
>> implementing the configuration editing. In a week or two, I would
>> we could have a release where we can put a fully-functional GUI into
>> the start menu. =)
> This is good, but I have a few suggestions.
> * Rename 'Devices' to 'Disks', and add a tree node per disk.
I disagree with this, as from an user interface perspective it is
inconsistent. This would mean that the treeview contains both
categories and user data. The treeview will not, however, contain all
user data, only ones we selectively place there. So is the treeview a
list of categories? Sort of. Is it a list of settings? Sort of.
Consistency is key. A category list should only be a category list. All
making each device a tree-node does is make editing one less click, but
it makes adding a device more complex. (Right-click menu? Or the Disks
panel only has an "add" button?) The Disks "node" in the tree is now
basically an empty screen, meaning that from a user interface
perspective, it's useless. Its only purpose is to group sub-nodes.
As for Devices to Disks, I typically am not a stickler for terminology
but I chose devices for a reason - because the list will contain images
and partitions, the former of which are not "physical" as a disk is,
and the latter of which are commonly part of a disk, not the whole
disk. So I felt that while Devices was a bit more abstract, it was more
accurate in describing what would go in there. Not to mention, you
later use the Device terminology yourself, so we should be consistent
on the name.
> I'd like
> the disk configuration to be presented more nicely to the user. In
> each disk configuration panel, the user should be presented with 2
> options (using a radio switch widget or something similar):
> * File image - Clicking the Browse button should allow the user
> to choose a file and \DosDevices\ should automatically be
> prepended to the choosen pathname.
> * Device image - Choosing this, the script should enumerate all
> the block devices under \Device\* and present the user with
> a detailed and friendly list of his/her disk paratitions,
> CDROMs, USB storage devices, etc.
> With any path written, the configurator should alert the user if
> it doesn't exist (by making it appear red, perhaps).
> Another feature we can add here is for resizing file systems /
> block devices and creating swap block devices after incorporating
> some sources from mkswap.
Yes, I agree with these changes and they are on the TODO list. =)
> * Rename 'Network' to 'Networking', and add a tree node per virtual
> Whether the user selects TAP or Bridged, he/her should be presented
> with the list of available adapters to choose from, not to be
> concerned about specifying the right name= attribute like it is
> It should also allow to configure various Win32-TAP bells and
> whistles such as DHCP, MAC addresses, IP addresses, etc.
Yes, if someone knows the right APIs or registry keys for me to look at
for this, I would really appreciate it. I checked "ipconfig /all" but
it doesn't list the "name" that should be used - just the actual device
> * Each of the options under 'Settings' needs to have an enabling
> check box next to it. When unchecked, it should be obvious to the
> user what is the default in that case.
Checkboxes are for settings which can be enabled/disabled. The settings
options cannot be disabled (they are all necessary), so what we want
instead is some way of reverting to the default values for these
settings. I think a "Use Default Settings" button would serve the same
purpose just as well.
> * Like I noted before, I don't see any reason for that 'CoLinux
> Manager' window. If the user would like to manage his/her list
> of VMs, he/she can do that with shortcuts/scripts and/or other
> non-specific methods. I prefer modularity over the compulsory
> All-In-One strategy.
Those users can still manage things with scripts or shortcuts if they
like - but the point of the GUI is so that they don't have to do this.
This is for people who don't want to deal with shortcuts or scripts,
they just want the GUI to put things in the right place, manage things
for them, and make it so that they have to think less and do less to
get a coLinux VM up and running.
People who prefer modularity typically want to take the time out to
configure their environment to their liking. They don't like programs
making decisions for them. These are typically not people who want or
need GUIs, as they prefer complete control and flexibility over ease of
use. (i.e. the Linux philosophy of working with text-based config
That doesn't describe me. I personally could care less about where
coLinux/coManager puts my files - I just want it to let me click "New
VM", specify any necessary data, and just be up and running quickly.
The more coManager handles, the less I have to think/worry about. This
is the primary purpose of a GUI - to isolate the user as much as
possible from the technical details of the program, thus reducing the
learning curve and making the program seem more polished and less
intimidating/complex. That is also typically why users of GUI programs
like integration - integration means less effort on their part.
> BTW, I'd like to take this opportunity to let everyone know
> that the first letter of the coLinux short-name is not capital
> *on purpose*. i.e, coLinux, not CoLinux, and not Colinux.
Thanks, I was planning on asking about that. =) I will be sure to
standardize it in the sources.
> I'd like the configurator to have the common and most recognized
> GUI standard menubar that contains the File submenu, and allows
> to pick an XML file with a File Browser dialog box. See
> Yes, I know designing GUI is hard, I'd rather mess more with kernel
> programming, but I also had my fair share of GUI experience in the
> years, so consider what I envision for this.
I've had my fair share of GUI experience over the years too, and just
as importantly, I've done a decent amount of research on user interface
design as well. So don't think I'm pulling these ideas out from
nowhere. Standards like menus should, of course, be followed - when
menus are indeed necessary. If menus are not necessary (and so far they
are not, in the current design) then adding them is basically adding
complexity for no reason. There's no reason to have two ways to do the
same thing if one way is intuitive, simple, and works correctly. That's
not to say that I'd always be adverse to menus, but I just don't see a
situation that warrants them at this point in time.