All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kronenberg <mike.kronenberg@kberg.ch>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] news on the OS X cocoa port
Date: Fri, 22 Jul 2005 13:28:14 +0200	[thread overview]
Message-ID: <42E0D84E.9050706@kberg.ch> (raw)
In-Reply-To: <D96E4691-B29E-4B58-A375-94D5D5FB7CF1@free.fr>

Pierre d'Herbemont wrote:

>
> On 21 juil. 05, at 15:46, Hetz Ben Hamo wrote:
>
>> On 7/21/05, Mike Kronenberg <mike.kronenberg@kberg.ch> 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

  reply	other threads:[~2005-07-22 11:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-21  9:44 [Qemu-devel] news on the OS X cocoa port Mike Kronenberg
2005-07-21 10:12 ` Hetz Ben Hamo
2005-07-21 12:33   ` Mike Kronenberg
2005-07-21 13:46     ` Hetz Ben Hamo
2005-07-21 17:33       ` Stealth Dave
2005-07-21 18:21         ` Natalia Portillo
2005-07-22  9:58       ` Pierre d'Herbemont
2005-07-22 11:28         ` Mike Kronenberg [this message]
2005-07-21 14:00     ` René Korthaus
2005-07-21 15:20       ` Jim C. Brown
2005-07-22  7:51         ` Mike Kronenberg
2005-07-22  8:44           ` René Korthaus
2005-07-22  9:42             ` Mike Kronenberg
2005-08-04  7:36     ` Mike Kronenberg
2005-08-04 18:39       ` Natalia Portillo
2005-08-05 11:45         ` Mike Kronenberg
2005-08-14 19:18       ` Mike Kronenberg
  -- strict thread matches above, loose matches on Subject: below --
2005-07-22  2:05 Joshua Root
2005-07-22  7:28 ` Mike Kronenberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42E0D84E.9050706@kberg.ch \
    --to=mike.kronenberg@kberg.ch \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.