From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dvvm1-0003pd-LV for qemu-devel@nongnu.org; Fri, 22 Jul 2005 07:33:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dvvlx-0003nj-BR for qemu-devel@nongnu.org; Fri, 22 Jul 2005 07:32:58 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dvvlw-0003jO-76 for qemu-devel@nongnu.org; Fri, 22 Jul 2005 07:32:56 -0400 Received: from [195.129.94.187] (helo=srv94-187.ip-tech.ch) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DvvrL-0002S5-8X for qemu-devel@nongnu.org; Fri, 22 Jul 2005 07:38:31 -0400 Message-ID: <42E0D84E.9050706@kberg.ch> Date: Fri, 22 Jul 2005 13:28:14 +0200 From: Mike Kronenberg MIME-Version: 1.0 Subject: Re: [Qemu-devel] news on the OS X cocoa port References: <42DF6E93.3010705@kberg.ch> <41e41e7a0507210312259ae3d5@mail.gmail.com> <42DF9604.2090503@kberg.ch> <41e41e7a05072106462bf1d20f@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Pierre d'Herbemont wrote: > > On 21 juil. 05, at 15:46, Hetz Ben Hamo wrote: > >> On 7/21/05, Mike Kronenberg wrote: >> >>> Hetz Ben Hamo wrote: >>> >>> >>>> I just looked at the screenshots, and if you don't mind, I want to >>>> offer few suggestions for your GUI: >>>> >>>> 1. RAM size - how about adding up/down arrows (in addition to what >>>> you >>>> have right now) to increase RAM? >>>> >>>> >>>> >>> Good Idea. How should they id/decrement the value? One by one or >>> doubling the Value? >>> >> >> My suggestion - by 8MB incrememental steps, but allow the user to type >> a number in case someone wants type a specific number. > > > Why a slider, or arrow? A simple text box is far more simpler, > quicker. Don't tell me that you'll click on the arrow button to get > 256, when you are at 128! :) >> >>>> 2. Instead of Radio buttons in the Floppy/CDROM/Hard drive, I would >>>> suggest to replace it with Check Boxes, so the ones that are not >>>> needed by the user, will be grayed out until the check boxes will be >>>> marked. >>>> >>>> >>>> >>> I look into that. Have You an Idea how we could optimize the >>> choosing of >>> cd-rom and cd-rom-image. >>> >> >> Sure. A simple pull down menu instead of the ... circle button, where >> you have 2 options: >> * Physical Media >> * Other (ISO) .... >> >> If the user selects Other (ISO) - a sile selection could appear to >> select an ISO and then appears. If the user selects "Physical Media" - >> the device name appear in the selection. > > > For the button title why "other". Something like "File" or "CD-ROM > image" sounds better, more explicit. > And why don't we have an intermediate window that allow the user to > choose a file or a device, or in the selector you specify if you want > a device or a file. It may simplify the interface. Like an NSPopupButon with the options -CD Rom -/path/to/file/if/one/was/selected Separator -choose an imagefile... >>> I'd like to keep the Panel as easy as possible, so "normal" Users >>> won't >>> be destracted by to much options. >>> Probably I'm gonna ad '-localtime', '-smb', and >>> '-user-net'/'-dummy-net', since I activate them by default. >>> >> >> I think Localtime, should also be a checkbox item (in a seperate >> line), and user-net / dummy net should be a radio button selection, >> but all of them should be hidden until the user press the "Advanced.." >> button. > > > Sounds like a Windows App to me :P No need for Advanced mode, the > advanced mode sounds scary to me. Keep it simple. > Something like a "Network & File Sharing" section for -smb and -user- > net. "Time" section for -localtime. If the interface is sufficiently > explicit and simple no need to hide them, if the names are > sufficiently user friendly. > > This must be discussed a bit, so feel free to reply if you are not > agree. > > BTW, what does Fabrice thinks of having nib files and png in CVS? well that would be something I'd like to know, too. Aktually the nibs are saved as xml. (they are easyer to use until we have a form of UI that corresponds to our needs, that could be coded directly) PNGs are not really necessary, the toolbars can be switched to text-only mode. There is another matter, I'd like to discuss: I've now integrated the controller in the qemu binary, but I dont feel happy with that: 1. One can't choose different architectures 2. It's a "oneshot" now (there are things in QEMU that are tied to the PID, and there is also a problem with cleaning up with atexit() ) I would preffer a qemu-control (or whatever) that exec()s qemu, qemu-x86_64, qemu-ppc as child processes, so they can run in there own memory-space. > Mike, thanks for the work. > > Pierre. Thanks for Your Input. Mike