From: Kevin & M. O. <kev...@th...> - 2004-05-22 21:38:18
|
Hi all, 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: http://kevino.theolliviers.com/colinux/pub/coManager.htm 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. VMConfig) 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 think we could have a release where we can put a fully-functional GUI into the start menu. =) Thanks, Kevin |
From: Bjorn S. <sw...@in...> - 2004-05-23 05:44:02
|
I get this when highlighting a VM and hitting configure, C:\CoLinux>python comanager.py <colinux.VMConfig instance at 0x013339B8> Traceback (most recent call last): File "comanager.py", line 87, in OnEdit editor = configurator.MainFrame(self.vmListBox.GetStringSelection() + ".coli nux.xml", self) File "C:\CoLinux\configurator.py", line 181, in __init__ self.new() File "C:\CoLinux\configurator.py", line 238, in new self.SetAutoLayout(wx.true) AttributeError: 'module' object has no attribute 'true' > -----Original Message----- > From: col...@li... > [mailto:col...@li...] On Behalf > Of Kevin & Masako Ollivier > Sent: Saturday, May 22, 2004 4:38 PM > To: col...@li... > Subject: [coLinux-devel] New coManager+configurator GUI prototype > > > Hi all, > > 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: > > http://kevino.theolliviers.com/colinux/pub/coManager.htm > > 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. > VMConfig) > 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 think > we could have a release where we can put a fully-functional GUI into > the start menu. =) > > Thanks, > > Kevin > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... > Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam > FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Kevin & M. O. <kev...@th...> - 2004-05-23 05:52:49
|
Hi, Thanks for pointing this out. Changing wx.true to "True" should resolve the problem. Very strange that this doesn't cause problems on my machine though... Are you using wxPython 2.4 or 2.5? Kevin On May 22, 2004, at 10:43 PM, Bjorn Sodergren wrote: > I get this when highlighting a VM and hitting configure, > > C:\CoLinux>python comanager.py > <colinux.VMConfig instance at 0x013339B8> > Traceback (most recent call last): > File "comanager.py", line 87, in OnEdit > editor = > configurator.MainFrame(self.vmListBox.GetStringSelection() + > ".coli > nux.xml", self) > File "C:\CoLinux\configurator.py", line 181, in __init__ > self.new() > File "C:\CoLinux\configurator.py", line 238, in new > self.SetAutoLayout(wx.true) > AttributeError: 'module' object has no attribute 'true' > >> -----Original Message----- >> From: col...@li... >> [mailto:col...@li...] On Behalf >> Of Kevin & Masako Ollivier >> Sent: Saturday, May 22, 2004 4:38 PM >> To: col...@li... >> Subject: [coLinux-devel] New coManager+configurator GUI prototype >> >> >> Hi all, >> >> 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: >> >> http://kevino.theolliviers.com/colinux/pub/coManager.htm >> >> 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. >> VMConfig) >> 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 think >> we could have a release where we can put a fully-functional GUI into >> the start menu. =) >> >> Thanks, >> >> Kevin >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: Oracle 10g >> Get certified on the hottest thing ever to hit the market... >> Oracle 10g. >> Take an Oracle 10g class now, and we'll give you the exam >> FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click >> _______________________________________________ >> coLinux-devel mailing list >> coL...@li... >> https://lists.sourceforge.net/lists/listinfo/colinux-devel >> > > > |
From: Bjorn S. <sw...@in...> - 2004-05-23 05:44:00
|
I get this when highlighting a VM and hitting configure, > -----Original Message----- > From: col...@li... > [mailto:col...@li...] On Behalf > Of Kevin & Masako Ollivier > Sent: Saturday, May 22, 2004 4:38 PM > To: col...@li... > Subject: [coLinux-devel] New coManager+configurator GUI prototype > > > Hi all, > > 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: > > http://kevino.theolliviers.com/colinux/pub/coManager.htm > > 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. > VMConfig) > 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 think > we could have a release where we can put a fully-functional GUI into > the start menu. =) > > Thanks, > > Kevin > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... > Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam > FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Bjorn S. <sw...@in...> - 2004-05-23 05:46:31
|
So, what python libraries are needed, I'm getting C:\CoLinux>python comanager.py Traceback (most recent call last): File "comanager.py", line 9, in ? import wx ImportError: No module named wx > -----Original Message----- > From: col...@li... > [mailto:col...@li...] On Behalf > Of Kevin & Masako Ollivier > Sent: Saturday, May 22, 2004 4:38 PM > To: col...@li... > Subject: [coLinux-devel] New coManager+configurator GUI prototype > > > Hi all, > > 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: > > http://kevino.theolliviers.com/colinux/pub/coManager.htm > > 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. > VMConfig) > 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 think > we could have a release where we can put a fully-functional GUI into > the start menu. =) > > Thanks, > > Kevin > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... > Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam > FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Bjorn S. <sw...@in...> - 2004-05-23 05:50:45
|
Sorry about the triple post :|, damned outlook |
From: Kevin & M. O. <kev...@th...> - 2004-05-23 05:53:54
|
Hi, You need wxPython 2.4 or 2.5 installed (tested with 2.4), but how did you get the error you listed in your previous message without having them installed? Kevin On May 22, 2004, at 10:46 PM, Bjorn Sodergren wrote: > So, what python libraries are needed, > I'm getting > > C:\CoLinux>python comanager.py > Traceback (most recent call last): > File "comanager.py", line 9, in ? > import wx > ImportError: No module named wx > >> -----Original Message----- >> From: col...@li... >> [mailto:col...@li...] On Behalf >> Of Kevin & Masako Ollivier >> Sent: Saturday, May 22, 2004 4:38 PM >> To: col...@li... >> Subject: [coLinux-devel] New coManager+configurator GUI prototype >> >> >> Hi all, >> >> 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: >> >> http://kevino.theolliviers.com/colinux/pub/coManager.htm >> >> 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. >> VMConfig) >> 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 think >> we could have a release where we can put a fully-functional GUI into >> the start menu. =) >> >> Thanks, >> >> Kevin >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: Oracle 10g >> Get certified on the hottest thing ever to hit the market... >> Oracle 10g. >> Take an Oracle 10g class now, and we'll give you the exam >> FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click >> _______________________________________________ >> coLinux-devel mailing list >> coL...@li... >> https://lists.sourceforge.net/lists/listinfo/colinux-devel >> > > > |
From: Bjorn S. <sw...@in...> - 2004-05-23 06:02:03
|
> > You need wxPython 2.4 or 2.5 installed (tested with 2.4), but how did > you get the error you listed in your previous message without having > them installed? Yahoo :) Python wx returned wxPython as the firt link. 2.5 im using |
From: Jaroslaw K. <ja...@zd...> - 2004-05-23 20:27:20
|
Some random UI ideas which sit in my head. 1. "Devices" panel should parse the paths and output the results in two columns instead of one: a) \DosDevices\x:\path\to\file is displayed as: "Partition Image | x:\path\to\file" b) \DosDevices\x: is displayed as: "Hard Disk Partition | x:" c) \Device\CDRom0 is displayed as: "CD ROM | 0" d) other devices are displayed as "Custom" 2. When adding a new device user should be presented with a choice: a) Partition - followed by a partition selector b) Image - followed by a file browser/selector c) CD ROM - followed by CD ROM selector d) Custom - followed by an edit box to input file name 3) Memory sizes should be pre-defined as a combo-box containing "32", "64", "128", "192", "256", "Custom" Megabytes. Alternatively there should be a horizontal slider instead. Up/Down control is not very well suited for the task of choosing among a list of typical values. 4) Kernel Image Path should come with a "Browse..." button. There should be a warning saying that the use of non-standard kernel is discouraged. Browse button should run a standard OS file selector. 5) Boot params could be specified in a graphical manner. For example "root=" could be specified by placing a checkmark next to one of the configured devices. "ro" option for "mount root readonly" can be specified using a checkbox. More parameters can be specified in a similar way. Any extra parameters can be specified manually via an edit box. There should be a preview of the entire commandline passed to the kernel. 6) Main window should include options for "Install as a service", "Remove service", "Start service", "Stop service". I think that we may need to keep the name of the service in the XML config file for this purpose. Option "Start VM" should be renamed as "Start VM Interactively". 7) There should be a visual hint about which machines are running/stopped. This can be implemented with small icons (started, stopped, paused). 8) Network configuration screen should include a selection of installed network cards. It should allow the user to configure the IP address, netmask and routing information for TAP connections. Maybe an automated bridging configuration can be implemented here. 9) There should be an easy way to import/export virtual machines along with all configuration files and disk images. Features like "burn VM to CD" or "import VM from CD" can be a bonus. Some smart handling of portable devices (like USB memory sticks, CompactFlash adapters or ZIP drives) would make the integration even more convenient. For example the VM would automatically be started whenever the appropriate device is plugged in. 10) There should be an option to create partitions / swap space automatically from the host OS. We can use preexisting *.bz2 files for that and unpack them or use the Windows port of e2fs (and other filesystems) utilities. 11) There should be a GUI option to resize the partition images (maybe even partitions ;-) 12) VM config file should have a distinguished file extension (not just XML). Assuming it's *.colinux we could implement a file handler for starting/stopping/pausing/context-sensitive editing from the windows shell without spawning the configurator. This would be similar to what WinZIP does with zip files. 13) There should be an option to minimize the configurator to a tray application leaving only some traffic-light-style indicator of its state (running, paused, stopped) with a context menu for performing most common actions and restoring the full GUI. My general impression is that the configurator can be really useful only if it provides very tight integration with the host OS. Configurator that's just a specialized XML editor is less useful IMO. I'm not sure if Python can deliver the required level of OS integration. For Windows I would use a lightweight toolkit like WTL (recently opensourced by MS at http://sourceforge.net/projects/wtl). WTL applications depend on no external DLLs (beside the common core) and are very small in size (even <100 KB for quite a capable applications). The toolkit is definitely not portable, but the tight host OS integration is not very "compatible" with portability requirement. Awaiting your opinion, Jarek P.S. Sorry, I just had to... ;-) I did some windows GUIs in my career and I'm willing to help with the design. ----- Original Message ----- From: "Bjorn Sodergren" <sw...@in...> To: "'Kevin & Masako Ollivier'" <kev...@th...> Cc: <col...@li...> Sent: Sunday, May 23, 2004 8:01 AM Subject: RE: [coLinux-devel] New coManager+configurator GUI prototype > > > > > You need wxPython 2.4 or 2.5 installed (tested with 2.4), but how did > > you get the error you listed in your previous message without having > > them installed? > > Yahoo :) > > Python wx returned wxPython as the firt link. > 2.5 im using > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Kevin O. <ke...@tu...> - 2004-05-23 21:57:56
|
Hi Jaroslaw, On May 23, 2004, at 1:27 PM, Jaroslaw Kowalski wrote: > Some random UI ideas which sit in my head. Wow, thanks! Note that these things will take time to implement, but I do like a lot of these suggestions! My comments below. > 1. "Devices" panel should parse the paths and output the results in two > columns instead of one: > > a) \DosDevices\x:\path\to\file is displayed as: "Partition Image | > x:\path\to\file" > b) \DosDevices\x: is displayed as: "Hard Disk Partition | x:" > c) \Device\CDRom0 is displayed as: "CD ROM | 0" > d) other devices are displayed as "Custom" Yes, I think there should be some sort of "Type" specifier as well, and this is on the todo list. > 2. When adding a new device user should be presented with a choice: > > a) Partition - followed by a partition selector > b) Image - followed by a file browser/selector > c) CD ROM - followed by CD ROM selector > d) Custom - followed by an edit box to input file name Agreed, I consider this pretty high priority once the core editing functionality is in place. > 3) Memory sizes should be pre-defined as a combo-box containing "32", > "64", > "128", "192", "256", "Custom" Megabytes. Alternatively there should be > a > horizontal slider instead. Up/Down control is not very well suited for > the > task of choosing among a list of typical values. Agreed. > 4) Kernel Image Path should come with a "Browse..." button. There > should be > a warning saying that the use of non-standard kernel is discouraged. > Browse > button should run a standard OS file selector. Agreed. > 5) Boot params could be specified in a graphical manner. For example > "root=" > could be specified by placing a checkmark next to one of the configured > devices. "ro" option for "mount root readonly" can be specified using a > checkbox. More parameters can be specified in a similar way. Any extra > parameters can be specified manually via an edit box. There should be a > preview of the entire commandline passed to the kernel. Yes, I'll need to look more closely at what the params are. This is low priority, IMHO, as most people won't want to change these anyways. > 6) Main window should include options for "Install as a service", > "Remove > service", "Start service", "Stop service". I think that we may need to > keep > the name of the service in the XML config file for this purpose. Option > "Start VM" should be renamed as "Start VM Interactively". I actually think that the service options should be a separate tool. I think there is a service manager GUI being worked on (or even finished already) and I think it should be separate from this. It creates a tray icon and does other goodies for people wanting to use coLinux as a service, but I think that mixing up service and interactive use in one big dialog would be confusing to newbies. > 7) There should be a visual hint about which machines are > running/stopped. > This can be implemented with small icons (started, stopped, paused). Yes, I'll need to learn how to do this one though. =) I spawn a separate process, so one can have more than one VM running at a time. I guess a decision needs to be made as to whether this is a good or a bad thing. ;-) > 8) Network configuration screen should include a selection of installed > network cards. It should allow the user to configure the IP address, > netmask > and routing information for TAP connections. Maybe an automated > bridging > configuration can be implemented here. This would be very cool but I have to admit I don't know how I'd go about doing this in any language. ;-) Do you have any suggestions on what APIs to look at, etc? > 9) There should be an easy way to import/export virtual machines along > with > all configuration files and disk images. Features like "burn VM to CD" > or > "import VM from CD" can be a bonus. Some smart handling of portable > devices > (like USB memory sticks, CompactFlash adapters or ZIP drives) would > make the > integration even more convenient. For example the VM would > automatically be > started whenever the appropriate device is plugged in. Yes, this is also highly on my todo list. But to make this really useful, we'd need to think about how to handle removable devices - i.e. CDs, floppies. Moving the VM from one machine to another would mean that it would need to be reconfigured for removable devices. Maybe a sort of "auto-detect removable devices" type of support. > 10) There should be an option to create partitions / swap space > automatically from the host OS. We can use preexisting *.bz2 files for > that > and unpack them or use the Windows port of e2fs (and other filesystems) > utilities. Yes, my thoughts were actually that coLinux come with a base images for the root partition and swap, and in the "New VM" wizard, it asks them to specify partition and swap size, etc. There are command line tools already that can do the grunt work here, we'd just need to design a front end. > 11) There should be a GUI option to resize the partition images (maybe > even > partitions ;-) I personally do not want to touch real partition resizing with a 10-foot pole. ;-) > 12) VM config file should have a distinguished file extension (not just > XML). Assuming it's *.colinux we could implement a file handler for > starting/stopping/pausing/context-sensitive editing from the windows > shell > without spawning the configurator. This would be similar to what > WinZIP does > with zip files. But if one creates a coLinux service, it would seem to me that the natural behavior is to manage it via Windows' own service manager. > 13) There should be an option to minimize the configurator to a tray > application leaving only some traffic-light-style indicator of its > state > (running, paused, stopped) with a context menu for performing most > common > actions and restoring the full GUI. I believe the coLinux service GUI does this already. > My general impression is that the configurator can be really useful > only if > it provides very tight integration with the host OS. Configurator > that's > just a specialized XML editor is less useful IMO. I'm not sure if > Python > can deliver the required level of OS integration. For Windows I would > use a > lightweight toolkit like WTL (recently opensourced by MS at > http://sourceforge.net/projects/wtl). WTL applications depend on no > external > DLLs (beside the common core) and are very small in size (even <100 KB > for > quite a capable applications). The toolkit is definitely not portable, > but > the tight host OS integration is not very "compatible" with portability > requirement. Well, Python can integrate with the host OS (in this case Windows) pretty well. Many Win32 APIs are already accessible via Python (including registry access, process management, etc.), and wxPython is actually just a thin-wrapper around the Win32 GUI classes. wxPython is basically a (IMHO) simpler and more straightforward API for the Win32 classes, and in that sense, it serves much the same purpose as WTL. We can easily add any platform specific bits inside of a "if os.platform == 'nt':" block. And we can wrap any C/C++ class that we need to make it accessible from Python. Python is about options - it doesn't force portability, it just makes it an option. At the same time, there is "coLinux on Linux" too - so all the Python/wxPython work could be easily re-used there rather than re-invented. Thanks, Kevin > Awaiting your opinion, > > Jarek > > P.S. Sorry, I just had to... ;-) I did some windows GUIs in my career > and > I'm willing to help with the design. > > ----- Original Message ----- > From: "Bjorn Sodergren" <sw...@in...> > To: "'Kevin & Masako Ollivier'" <kev...@th...> > Cc: <col...@li...> > Sent: Sunday, May 23, 2004 8:01 AM > Subject: RE: [coLinux-devel] New coManager+configurator GUI prototype > > >> >>> >>> You need wxPython 2.4 or 2.5 installed (tested with 2.4), but how did >>> you get the error you listed in your previous message without having >>> them installed? >> >> Yahoo :) >> >> Python wx returned wxPython as the firt link. >> 2.5 im using >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: Oracle 10g >> Get certified on the hottest thing ever to hit the market... Oracle >> 10g. >> Take an Oracle 10g class now, and we'll give you the exam FREE. >> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click >> _______________________________________________ >> coLinux-devel mailing list >> coL...@li... >> https://lists.sourceforge.net/lists/listinfo/colinux-devel >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle > 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Samuel L. <sa...@li...> - 2004-05-24 11:14:00
|
"Jaroslaw Kowalski" <ja...@zd...> wrote in message news:006e01c44104$5d74d930$2000a8c0@jarekxp... > Some random UI ideas which sit in my head. > 3) Memory sizes should be pre-defined as a combo-box containing "32", "64", > "128", "192", "256", "Custom" Megabytes. Alternatively there should be a > horizontal slider instead. Up/Down control is not very well suited for the > task of choosing among a list of typical values. Please make this a combo-editbox-listbox so custom values can still be typed. Don't use a stinkin slider, please! > 8) Network configuration screen should include a selection of installed > network cards. It should allow the user to configure the IP address, netmask > and routing information for TAP connections. Maybe an automated bridging > configuration can be implemented here. And the ability to add extra TAP interfaces so machines dont have to share the same subnet. Sam |
From: Dan A. <da...@co...> - 2004-05-23 21:35:02
|
On Sat, May 22, 2004 at 02:38:13PM -0700, Kevin & Masako Ollivier wrote: > 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: > > http://kevino.theolliviers.com/colinux/pub/coManager.htm > > 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. VMConfig) > 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 think > 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'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. * Rename 'Network' to 'Networking', and add a tree node per virtual adapter. 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 now. It should also allow to configure various Win32-TAP bells and whistles such as DHCP, MAC addresses, IP addresses, etc. * 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. * 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. 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. 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 configurator.py. 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. -- Dan Aloni da...@co... |
From: Kevin & M. O. <kev...@th...> - 2004-05-24 00:10:01
|
Hi Dan, On May 23, 2004, at 2:36 PM, Dan Aloni wrote: > On Sat, May 22, 2004 at 02:38:13PM -0700, Kevin & Masako Ollivier > wrote: > >> 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: >> >> http://kevino.theolliviers.com/colinux/pub/coManager.htm >> >> 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. >> VMConfig) >> 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 >> think >> 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 > adapter. > > 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 > now. > > 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 model. > * 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 files) 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 > configurator.py. > > 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. Kevin |
From: Dan A. <da...@co...> - 2004-05-24 04:35:33
|
On Sun, May 23, 2004 at 05:09:49PM -0700, Kevin & Masako Ollivier wrote: > Hi Dan, > > On May 23, 2004, at 2:36 PM, Dan Aloni wrote: > > >On Sat, May 22, 2004 at 02:38:13PM -0700, Kevin & Masako Ollivier > >wrote: > > > >>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: > >> > >>http://kevino.theolliviers.com/colinux/pub/coManager.htm > >> > >>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. > >>VMConfig) > >>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 > >>think > >>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. Looking at KDE's Control Panel I must say it does make more sense this way, plus I think a small icon added to each node can make some appeal. But anyway, I insist that each block device gets its own configuration window or panel. > 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. There's a difference between a Block Device and a plain Device. A plain Device is too ambiguous to be used to describe block devices. I'll rather stick to either Disk or Virtual Disk. > >* Rename 'Network' to 'Networking', and add a tree node per virtual > > adapter. > > > > 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 > > now. > > > > 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 > model. I'll check it out. > >* 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. Perhaps a radio option between a 'default setting' and a 'custom setting' + text box. > >* 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 > files) > > 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. It can be good if coManager could serve as an *optional* item from the start menu, for people who would like to manage their VMs *that way*. I don't aim for the clueless users first. I don't know about you, but the absense of the ability to just go about and open an XML configuration from a file that lays around somewhere on the HD, doesn't have any appeal in it, *even* for a CLI-inclined person such as myself. That said, I suggest that you modify the current design, to separate between the functionality of configuration editing, and the functionality of managing several VMs, in manner that will still let you transparently pick up / add / remove / configure / run / stop VMs from that coManger list of VMs, *but* will let people such as myself, using another link from the start menu, to go and edit, load and save VMs configuration files regardless of coManager. I think that level of modularity can be achieved to satisfy both needs. -- Dan Aloni da...@co... |
From: Kevin & M. O. <kev...@th...> - 2004-05-24 06:17:04
|
On May 23, 2004, at 9:36 PM, Dan Aloni wrote: [snip] > Looking at KDE's Control Panel I must say it does make more sense this > way, plus I think a small icon added to each node can make some appeal. > But anyway, I insist that each block device gets its own configuration > window or panel. Everyone is entitled to their own opinions, but I prefer not to make design decisions just by looking at other programs. In any case, if we're comparing, I much prefer configuration dialogs such as FireFox's and the Windows XP and Mac system configuration applets, as I find them easier to navigate and more intuitive than KDE's. If you insist, however, you are free to develop the program in any way that you choose. >> 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. > > Perhaps a radio option between a 'default setting' and a 'custom > setting' + text box. You could do that, but why? If a user changes to the defaults, they no longer can use their custom setting anyways, and it will in fact be wiped out when they save. [snip] > It can be good if coManager could serve as an *optional* item from the > start menu, for people who would like to manage their VMs *that way*. > I don't aim for the clueless users first. I don't know about you, but > the absense of the ability to just go about and open an XML > configuration > from a file that lays around somewhere on the HD, doesn't have any > appeal in it, *even* for a CLI-inclined person such as myself. > > That said, I suggest that you modify the current design, to separate > between the functionality of configuration editing, and the > functionality > of managing several VMs, in manner that will still let you > transparently > pick up / add / remove / configure / run / stop VMs from that coManger > list of VMs, *but* will let people such as myself, using another link > from the start menu, to go and edit, load and save VMs configuration > files regardless of coManager. I think that level of modularity can be > achieved to satisfy both needs. If you want to build it that way, you're free to do so. However, I would like to say that insisting that a volunteer do things your way isn't a good way to solicit help, particularly when you don't even bother to explain how your way is better interface design. You have in most cases not even discussed the merits of my (or your) ideas, you typically just point out that you don't like the way that I did it and "suggest" (or insist, of course) that I change it. In any case, as this is work done in my spare time, I really am not going to work on a program that I don't see myself using. I wish it did appeal to you, but even if it does not, it will be quite useful to me. I will continue working on the program where I can improve it to make my life easier, and if others are still interested, I can make it available. Kevin |