[Qemu-devel] news on the OS X cocoa port

[Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Based on experiences with Q, I rewrote the cocoa port.

It features now:
- Keyboard
- Mouse
- Full screen
- Hardware CD-Rom support
- Possibility to create/save guest PC profiles
- Toolbar to load images for fd/cd and save/shutdown/reset guest PC
- graphic interface to create/change/delete/start guest PCs
- new command line options (only for the cocoa port)

At the moment it lacks:
- Sound
- possibility to start multiple guest PCs

The diff is rather large (~800kb). You find diff and binaries at:
http://www.kberg.ch/q

It compiles on 10.2.x (search this list for questions on poll.h) and 10.3.x
The binaries provided should run on 10.3.x and 10.4.x


At the moment I got stuck with cleaning up after a guest PC, so I can 
start a new one or even multiple guest PCs. (this is still perfectly 
possible with multiple instances of QEMU)

I create a new Object (cocoaQemu.m) for the guest PC, then I start the 
guest PC with a new NSThread. After completion, I can create a new 
Object, but  the guest PC won't start. (I called/rewrote the functions 
in atexit but there must be some more things to be cleaned up before)

There are some Problems with multiple guest PCs at the same time, too. 
For Example: '-smb' creates a temp directory with the PID. This makes 
multiple smb configurations impossible. It might be better to use a 
timestamp.

I'm not sure whether that was ever intended.
So if you have an Idea, please drop a note.



Mike

Re: [Qemu-devel] news on the OS X cocoa port

[Hetz Ben Hamo]

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?
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.
3. I would also suggest to add a "Boot from" pull down menu - to
select from which device to boot (useful for CD installation etc..)

Thanks,
Hetz

On 7/21/05, Mike Kronenberg <mike.kronenberg@kberg.ch> wrote:
> Based on experiences with Q, I rewrote the cocoa port.
> 
> It features now:
> - Keyboard
> - Mouse
> - Full screen
> - Hardware CD-Rom support
> - Possibility to create/save guest PC profiles
> - Toolbar to load images for fd/cd and save/shutdown/reset guest PC
> - graphic interface to create/change/delete/start guest PCs
> - new command line options (only for the cocoa port)
> 
> At the moment it lacks:
> - Sound
> - possibility to start multiple guest PCs
> 
> The diff is rather large (~800kb). You find diff and binaries at:
> http://www.kberg.ch/q
> 
> It compiles on 10.2.x (search this list for questions on poll.h) and 10.3.x
> The binaries provided should run on 10.3.x and 10.4.x
> 
> 
> At the moment I got stuck with cleaning up after a guest PC, so I can
> start a new one or even multiple guest PCs. (this is still perfectly
> possible with multiple instances of QEMU)
> 
> I create a new Object (cocoaQemu.m) for the guest PC, then I start the
> guest PC with a new NSThread. After completion, I can create a new
> Object, but  the guest PC won't start. (I called/rewrote the functions
> in atexit but there must be some more things to be cleaned up before)
> 
> There are some Problems with multiple guest PCs at the same time, too.
> For Example: '-smb' creates a temp directory with the PID. This makes
> multiple smb configurations impossible. It might be better to use a
> timestamp.
> 
> I'm not sure whether that was ever intended.
> So if you have an Idea, please drop a note.
> 
> 
> 
> Mike
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

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?

>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.

>3. I would also suggest to add a "Boot from" pull down menu - to
>select from which device to boot (useful for CD installation etc..)
>  
>
On the list.

>Thanks,
>Hetz
>
>  
>
Thanks.

[snip]

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'm thinking of a new way to store the images and saved VMs, too.
Maybe we could make something like vpc: A package with the config, 
disk-images and saved VMs, located in ~/Documents/QEMU PCs/

any Ideas?

Mike

Re: [Qemu-devel] news on the OS X cocoa port

[Hetz Ben Hamo]

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.

> >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.
 
> [snip]
> 
> 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.
 
> I'm thinking of a new way to store the images and saved VMs, too.
> Maybe we could make something like vpc: A package with the config,
> disk-images and saved VMs, located in ~/Documents/QEMU PCs/

Nice idea.

Hetz

Re: [Qemu-devel] news on the OS X cocoa port

[Stealth Dave]

On Jul 21, 2005, at 6:46 AM, Hetz Ben Hamo wrote:

> On 7/21/05, Mike Kronenberg <mike.kronenberg@kberg.ch> wrote:
>> Hetz Ben Hamo wrote:
>>
>> I'm thinking of a new way to store the images and saved VMs, too.
>> Maybe we could make something like vpc: A package with the config,
>> disk-images and saved VMs, located in ~/Documents/QEMU PCs/
>
> Nice idea.

I would recommend ~/Library/QEMU/PCs as an alternative.  OS X tends to 
store all of its program specific configuration information in the 
Library folder, which separates it from actual Documents such as disk 
images, word processor files, images, etc.

Just $0.02 from the Peanut Gallery! :)

- Dave

Re: [Qemu-devel] news on the OS X cocoa port

[Natalia Portillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yeah but the Library is a obscure place, and VirtualPC for example  
uses Documents with packages inside and I think that is an elegant  
way and also will help deal with old users.
Also VPC uses XML for hardware description and should be easy to make  
a XML<->XML virtual machine converter, with along qemu-img will allow  
people to convert old VPC machines to QEMU ones (will be very useful  
for me).

El 21/07/2005, a las 18:33, Stealth Dave escribió:

> On Jul 21, 2005, at 6:46 AM, Hetz Ben Hamo wrote:
>
>
>> On 7/21/05, Mike Kronenberg <mike.kronenberg@kberg.ch> wrote:
>>
>>> Hetz Ben Hamo wrote:
>>>
>>> I'm thinking of a new way to store the images and saved VMs, too.
>>> Maybe we could make something like vpc: A package with the config,
>>> disk-images and saved VMs, located in ~/Documents/QEMU PCs/
>>>
>>
>> Nice idea.
>>
>
> I would recommend ~/Library/QEMU/PCs as an alternative.  OS X tends  
> to store all of its program specific configuration information in  
> the Library folder, which separates it from actual Documents such  
> as disk images, word processor files, images, etc.
>
> Just $0.02 from the Peanut Gallery! :)
>
> - Dave
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC3+eUSOHwOb87puQRAsQ1AKCvabMrHhtFDXQo4kC9sMaR9YuX5ACeOL/j
M5Q9/DIRv4Ksn2S5xXWGUkA=
=Jdc+
-----END PGP SIGNATURE-----

Re: [Qemu-devel] news on the OS X cocoa port

[Pierre d'Herbemont]

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.


>> 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?

Mike, thanks for the work.

Pierre.

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

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

Re: [Qemu-devel] news on the OS X cocoa port

[René Korthaus]

Am 21.07.2005 um 14:33 schrieb Mike Kronenberg:

> 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?
>
>
>> 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.
>
>
>> 3. I would also suggest to add a "Boot from" pull down menu - to
>> select from which device to boot (useful for CD installation etc..)
>>
>>
> On the list.
>
>
>> Thanks,
>> Hetz
>>
>>
>>
> Thanks.
>
> [snip]
>
> 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'm thinking of a new way to store the images and saved VMs, too.
> Maybe we could make something like vpc: A package with the config,  
> disk-images and saved VMs, located in ~/Documents/QEMU PCs/
>
> any Ideas?


That is what I was also thinking about for some time, but first we  
should then agree on an universal way of saving configurations (this  
was already been touched by the list some time ago, couldnt find the  
mails by now). As I am pretty much satisfied with saving the data in  
an xml file, I would suggest this way, but we shouldnt only focus on  
Mac OS X part, but also on other platforms.

I really like the idea of sharing Qemu VirtualMachines with others  
including configs, vm states a.s.o. over several platforms. That  
would also mainly feature the idea of the FreeOSZoo.

Greets. cordney*
>
> Mike
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>

Re: [Qemu-devel] news on the OS X cocoa port

[Jim C. Brown]

On Thu, Jul 21, 2005 at 04:00:12PM +0200, Ren? Korthaus wrote:
> That is what I was also thinking about for some time, but first we  
> should then agree on an universal way of saving configurations (this  
> was already been touched by the list some time ago, couldnt find the  
> mails by now). As I am pretty much satisfied with saving the data in  
> an xml file, I would suggest this way, but we shouldnt only focus on  
> Mac OS X part, but also on other platforms.
> 

I have a shell script that provides config file support for qemu called vqemu.
Basicly the format is a simple "option=value", the shell script sources the
config file in and then passes certain command line options to qemu based on
the options given.

The script should be easy to modify to use on OS X. To make it more portable
(e.g. usable on Windows), converting it to C is not terribly difficult.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Jim C. Brown wrote:

>On Thu, Jul 21, 2005 at 04:00:12PM +0200, Ren? Korthaus wrote:
>  
>
>>That is what I was also thinking about for some time, but first we  
>>should then agree on an universal way of saving configurations (this  
>>was already been touched by the list some time ago, couldnt find the  
>>mails by now). As I am pretty much satisfied with saving the data in  
>>an xml file, I would suggest this way, but we shouldnt only focus on  
>>Mac OS X part, but also on other platforms.
>>
>>    
>>
>
>I have a shell script that provides config file support for qemu called vqemu.
>Basicly the format is a simple "option=value", the shell script sources the
>config file in and then passes certain command line options to qemu based on
>the options given.
>
>The script should be easy to modify to use on OS X. To make it more portable
>(e.g. usable on Windows), converting it to C is not terribly difficult.
>
>  
>
Right now I'm using .plist(property lists), which is very common in OS 
X, because you can read them back directly in to an Array or a 
Dictionaty. It's a standardized XML File.
I'm a big fan of XML, but I'm also very much Intrested in having a 
compatible package over all platforms.
I see advantage in XML, because it's a lot more flexible and accurat in 
storing your Data - well it was defined exactly for that pourpose :)

My packages look like this:
~/Documents/QEMU/Freedos.qemu/configuration.plist
~/Documents/QEMU/Freedos.qemu/hda.img
~/Documents/QEMU/Freedos.qemu/saved.vm
~/Documents/QEMU/Freedos.qemu/thumbnail.png
or:
~/Documents/QEMU/ReactOS 15412.qemu/configuration.plist
~/Documents/QEMU/ReactOS 15412.qemu/hda.img
~/Documents/QEMU/ReactOS 15412.qemu/saved.vm
~/Documents/QEMU/ReactOS 15412.qemu/thumbnail.png

They can nicely be ziped.

A sample configuration .plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>-boot</key>
        <string>1</string>
        <key>-cdrom</key>
        <string></string>
        <key>-fda</key>
        <string></string>
        <key>-hda</key>
        <string>/Users/mike/Documents/qemu/images/2gb_win2k.img</string>
        <key>-m</key>
        <string>128</string>
        <key>cpu</key>
        <string>0</string>
        <key>custom</key>
        <string></string>
        <key>name</key>
        <string>win2ksp4</string>
        <key>status</key>
        <string>shutdown</string>
    </dict>
</plist>

I'm also looking into writing a converter for vpc packages, which are 
very similar :)

Mike

Re: [Qemu-devel] news on the OS X cocoa port

[René Korthaus]

[-- Attachment #1: Type: text/plain, Size: 4192 bytes --]


Am 22.07.2005 um 09:51 schrieb Mike Kronenberg:

> Jim C. Brown wrote:
>
>
>> On Thu, Jul 21, 2005 at 04:00:12PM +0200, Ren? Korthaus wrote:
>>
>>
>>> That is what I was also thinking about for some time, but first  
>>> we  should then agree on an universal way of saving  
>>> configurations (this  was already been touched by the list some  
>>> time ago, couldnt find the  mails by now). As I am pretty much  
>>> satisfied with saving the data in  an xml file, I would suggest  
>>> this way, but we shouldnt only focus on  Mac OS X part, but also  
>>> on other platforms.
>>>
>>>
>>>
>>
>> I have a shell script that provides config file support for qemu  
>> called vqemu.
>> Basicly the format is a simple "option=value", the shell script  
>> sources the
>> config file in and then passes certain command line options to  
>> qemu based on
>> the options given.
>>
>> The script should be easy to modify to use on OS X. To make it  
>> more portable
>> (e.g. usable on Windows), converting it to C is not terribly  
>> difficult.
>>
>>
>>
> Right now I'm using .plist(property lists), which is very common in  
> OS X, because you can read them back directly in to an Array or a  
> Dictionaty. It's a standardized XML File.
> I'm a big fan of XML, but I'm also very much Intrested in having a  
> compatible package over all platforms.
> I see advantage in XML, because it's a lot more flexible and  
> accurat in storing your Data - well it was defined exactly for that  
> pourpose :)

Fully agree.

>
> My packages look like this:
> ~/Documents/QEMU/Freedos.qemu/configuration.plist
> ~/Documents/QEMU/Freedos.qemu/hda.img
> ~/Documents/QEMU/Freedos.qemu/saved.vm
> ~/Documents/QEMU/Freedos.qemu/thumbnail.png
> or:
> ~/Documents/QEMU/ReactOS 15412.qemu/configuration.plist
> ~/Documents/QEMU/ReactOS 15412.qemu/hda.img
> ~/Documents/QEMU/ReactOS 15412.qemu/saved.vm
> ~/Documents/QEMU/ReactOS 15412.qemu/thumbnail.png

What about .qvm instead of .qemu ?

>
> They can nicely be ziped.
>
> A sample configuration .plist:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"  
> "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
> <plist version="1.0">
>    <dict>
>        <key>-boot</key>
>        <string>1</string>
>        <key>-cdrom</key>
>        <string></string>
>        <key>-fda</key>
>        <string></string>
>        <key>-hda</key>
>        <string>/Users/mike/Documents/qemu/images/2gb_win2k.img</ 
> string>
>        <key>-m</key>
>        <string>128</string>
>        <key>cpu</key>
>        <string>0</string>
>        <key>custom</key>
>        <string></string>
>        <key>name</key>
>        <string>win2ksp4</string>
>        <key>status</key>
>        <string>shutdown</string>
>    </dict>
> </plist>

I assume <key>cpu</key> is the system the image is designed for, f.e.  
x86? What about some additional keys like author, date of creation,  
email if someone f.e. downloaded the image from the web and has  
problems getting it to run?!

Hey, FreeOSZoo'ers, what do you think would be also nice to save in  
the xml regarding distribution on your platform?
According to your site:

ToDO List:
[...]
Create a FreeOSZoo hotdelivery XML format, gathering all information  
needed to download and install FreeOSZoo images. We hope that the  
FreeOSZoo hotdelivery XML format will allow the next generation of  
QEMU GUIs to connect to a distribution site and download the needed  
files automatically. We plan the XML file to deliver the following  
information:
Available mirrors for download
Bittorent trackers
Host operating systems requirements
Guest operating systems requirements
List of free software bundled
Upgrading facilities over the Internet
Targeted audience (home use, ...)
Links to a gallery of screenshots
Links to tutorials and help systems
Links to live video presentations

>
> I'm also looking into writing a converter for vpc packages, which  
> are very similar :)

Very nice! Looking forward to it.

>
> Mike
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>


[-- Attachment #2: Type: text/html, Size: 15788 bytes --]

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

[snip]

>> Right now I'm using .plist(property lists), which is very common in 
>> OS X, because you can read them back directly in to an Array or a 
>> Dictionaty. It's a standardized XML File.
>> I'm a big fan of XML, but I'm also very much Intrested in having a 
>> compatible package over all platforms.
>> I see advantage in XML, because it's a lot more flexible and accurat 
>> in storing your Data - well it was defined exactly for that pourpose :)
>
>
> Fully agree.
>
>>
>> My packages look like this:
>> ~/Documents/QEMU/Freedos.qemu/configuration.plist
>> ~/Documents/QEMU/Freedos.qemu/hda.img
>> ~/Documents/QEMU/Freedos.qemu/saved.vm
>> ~/Documents/QEMU/Freedos.qemu/thumbnail.png
>> or:
>> ~/Documents/QEMU/ReactOS 15412.qemu/configuration.plist
>> ~/Documents/QEMU/ReactOS 15412.qemu/hda.img
>> ~/Documents/QEMU/ReactOS 15412.qemu/saved.vm
>> ~/Documents/QEMU/ReactOS 15412.qemu/thumbnail.png
>
>
> What about .qvm instead of .qemu ?

Ok for me.

>>
>> They can nicely be ziped.
>>
>> A sample configuration .plist:
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
>> "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
>> <plist version="1.0">
>>    <dict>
>>        <key>-boot</key>
>>        <string>1</string>
>>        <key>-cdrom</key>
>>        <string></string>
>>        <key>-fda</key>
>>        <string></string>
>>        <key>-hda</key>
>>        <string>/Users/mike/Documents/qemu/images/2gb_win2k.img</string>
>>        <key>-m</key>
>>        <string>128</string>
>>        <key>cpu</key>
>>        <string>0</string>
>>        <key>custom</key>
>>        <string></string>
>>        <key>name</key>
>>        <string>win2ksp4</string>
>>        <key>status</key>
>>        <string>shutdown</string>
>>    </dict>
>> </plist>
>
>
> I assume <key>cpu</key> is the system the image is designed for, f.e. 
> x86? What about some additional keys like author, date of creation, 
> email if someone f.e. downloaded the image from the web and has 
> problems getting it to run?!

This is right from Q, so its no real proposal, just to show the 
advantages of xml. cpu stands for the guest PC architekture.

I would propose 4 dicts in a containing dict:
- Description (PC Name, Platform)
- Arguments (with the real qemu arguments)
- Author (FreeOSZoo go go go!)
- Temp (to store temporary "nice to have" hints for a specific port)

> Hey, FreeOSZoo'ers, what do you think would be also nice to save in 
> the xml regarding distribution on your platform?
> According to your site:
>
> ToDO List:
> [...]
>
>    1. Create a FreeOSZoo hotdelivery XML format, gathering all
>       information needed to download and install FreeOSZoo images. We
>       hope that the FreeOSZoo hotdelivery XML format will allow the
>       next generation of QEMU GUIs to connect to a distribution site
>       and download the needed files automatically. We plan the XML
>       file to deliver the following information:
>           * Available mirrors for download
>           * Bittorent <http://bitconjurer.org/BitTorrent> trackers
>           * Host operating systems requirements
>           * Guest operating systems requirements
>           * List of free software bundled
>           * Upgrading facilities over the Internet
>           * Targeted audience (home use, ...)
>           * Links to a gallery of screenshots
>           * Links to tutorials and help systems
>           * Links to live video presentations
>
[snip]

Mike

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Mike Kronenberg wrote:

> I'm thinking of a new way to store the images and saved VMs, too.
> Maybe we could make something like vpc: A package with the config, 
> disk-images and saved VMs, located in ~/Documents/QEMU PCs/

QEMU guest PC Format, a Proposal

This should serve as a base for the discussion on a Structure/Format to 
save preconfigured/saved guest PCs.


Structure:
all the Files needed by the VM are stored in a folder. The folder has an 
ending of .qvm (QEMU Virtual Machine).

Mandatory Files:
- Harddiskimages
Configuration File (configuration.plist)

Other Files:
FDImages
CDImages
Thumbnail (thumbnail.png)
VM State File (saved.vm)

Host dependent Files:
PkgInfo (OS X)
info.plist (OS X)


Format:
As a general format, I propose XML. To be more exact: PropertyLists. You 
find the definition for PropertyLists at: 
http://www.apple.com/DTDs/PropertyList-1.0.dtd

Why XML?
We live in a small world, the QEMU community started out from France and 
has now it's followers all over the world. The developers and (hard)core 
users may stick to ASCII characters. But this is not the case for a 
broader community. Localized Operating Systems and less 
interested/educated users will fast break compatibility of simple 
text/ini files. (There might even arise difficulties with 
ASCII/MacRoman) So XML is the choice in the long run.

Why PropertyList?
Because they are easy to handle. Datatypes/Values and Variable Names are 
stored as pairs:
<dict>
<key>author</key>
<string>Mike Kronenberg</string>
<key>date</key>
<date>2005-07-27T22:00:00Z</date>
</dict>

What should be covered by “configuration.plist”?
Version
About
Arguments
PC Data
Temporary

There is no particular Order, Data is accessed by key.


1.Version
Simple String to define the version of this configurations.plist file. 
Format: 1.0.0

2.About
Author name, Date, Copyright/left. Place for further Descriptions.

3.Arguments
To have the highest compatibility, we should stick to a simple 
option/value Scheme here, with boolean YES/NO for arguments with no 
value, like -enable-audio. There should be no host dependent switches here.

4.PC Data
PC Name, PC Description, PC Status, emulated CPU and other guest PC 
related “Meta” Information.

5.Temporary
“Nice to have” data, host dependent switches – shortly everything that 
is NOT needed to guarantee the operation of QEMU.

Sample configuration.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>About</key>
<dict>
<key>author</key>
<string>Mike Kronenberg</string>
<key>copyright</key>
<string>© 2005, Mike Kronenberg</string>
<key>date</key>
<date>2005-07-27T22:00:00Z</date>
<key>description</key>
<string>This is a sample PC configuration.</string>
</dict>
<key>Arguments</key>
<dict>
<key>-boot</key>
<string>c</string>
<key>-cdrom</key>
<string>/dev/cdrom</string>
<key>-hda</key>
<string>Harddisk1.raw</string>
</dict>
<key>PC Data</key>
<dict>
<key>name</key>
<string>My new PC</string>
<key>state</key>
<string>saved</string>
<key>system</key>
<string>qemu-system-x86_64</string>
</dict>
<key>Temporary</key>
<dict/>
<key>Version</key>
<string>0.1.0</string>
</dict>
</plist>




Waiting for Your Suggestions...

Mike

Re: [Qemu-devel] news on the OS X cocoa port

[Natalia Portillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Better to have a architecture/machine pair.

Architecture: x86-64
Machine: PC

Architecture: PowerPC
Machine: Core99

To be coincident with the -M flag and having the possibility of  
changing the qemu executable name (that should be in the GUI  
configuration)

El 04/08/2005, a las 8:36, Mike Kronenberg escribió:

> Mike Kronenberg wrote:
>
>
>> I'm thinking of a new way to store the images and saved VMs, too.
>> Maybe we could make something like vpc: A package with the config,  
>> disk-images and saved VMs, located in ~/Documents/QEMU PCs/
>>
>
> QEMU guest PC Format, a Proposal
>
> This should serve as a base for the discussion on a Structure/ 
> Format to save preconfigured/saved guest PCs.
>
>
> Structure:
> all the Files needed by the VM are stored in a folder. The folder  
> has an ending of .qvm (QEMU Virtual Machine).
>
> Mandatory Files:
> - Harddiskimages
> Configuration File (configuration.plist)
>
> Other Files:
> FDImages
> CDImages
> Thumbnail (thumbnail.png)
> VM State File (saved.vm)
>
> Host dependent Files:
> PkgInfo (OS X)
> info.plist (OS X)
>
>
> Format:
> As a general format, I propose XML. To be more exact:  
> PropertyLists. You find the definition for PropertyLists at: http:// 
> www.apple.com/DTDs/PropertyList-1.0.dtd
>
> Why XML?
> We live in a small world, the QEMU community started out from  
> France and has now it's followers all over the world. The  
> developers and (hard)core users may stick to ASCII characters. But  
> this is not the case for a broader community. Localized Operating  
> Systems and less interested/educated users will fast break  
> compatibility of simple text/ini files. (There might even arise  
> difficulties with ASCII/MacRoman) So XML is the choice in the long  
> run.
>
> Why PropertyList?
> Because they are easy to handle. Datatypes/Values and Variable  
> Names are stored as pairs:
> <dict>
> <key>author</key>
> <string>Mike Kronenberg</string>
> <key>date</key>
> <date>2005-07-27T22:00:00Z</date>
> </dict>
>
> What should be covered by “configuration.plist”?
> Version
> About
> Arguments
> PC Data
> Temporary
>
> There is no particular Order, Data is accessed by key.
>
>
> 1.Version
> Simple String to define the version of this configurations.plist  
> file. Format: 1.0.0
>
> 2.About
> Author name, Date, Copyright/left. Place for further Descriptions.
>
> 3.Arguments
> To have the highest compatibility, we should stick to a simple  
> option/value Scheme here, with boolean YES/NO for arguments with no  
> value, like -enable-audio. There should be no host dependent  
> switches here.
>
> 4.PC Data
> PC Name, PC Description, PC Status, emulated CPU and other guest PC  
> related “Meta” Information.
>
> 5.Temporary
> “Nice to have” data, host dependent switches – shortly everything  
> that is NOT needed to guarantee the operation of QEMU.
>
> Sample configuration.plist:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"  
> "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
> <plist version="1.0">
> <dict>
> <key>About</key>
> <dict>
> <key>author</key>
> <string>Mike Kronenberg</string>
> <key>copyright</key>
> <string>© 2005, Mike Kronenberg</string>
> <key>date</key>
> <date>2005-07-27T22:00:00Z</date>
> <key>description</key>
> <string>This is a sample PC configuration.</string>
> </dict>
> <key>Arguments</key>
> <dict>
> <key>-boot</key>
> <string>c</string>
> <key>-cdrom</key>
> <string>/dev/cdrom</string>
> <key>-hda</key>
> <string>Harddisk1.raw</string>
> </dict>
> <key>PC Data</key>
> <dict>
> <key>name</key>
> <string>My new PC</string>
> <key>state</key>
> <string>saved</string>
> <key>system</key>
> <string>qemu-system-x86_64</string>
> </dict>
> <key>Temporary</key>
> <dict/>
> <key>Version</key>
> <string>0.1.0</string>
> </dict>
> </plist>
>
>
>
>
> Waiting for Your Suggestions...
>
> Mike
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC8mDXSOHwOb87puQRApVgAJ432rq0FSwpBjRaxzmgVRcr3h/cpACg2+Cd
O8Amp84ZCvMwvkEGJieWYkE=
=npr3
-----END PGP SIGNATURE-----

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Natalia Portillo wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Better to have a architecture/machine pair.
>
> Architecture: x86-64
> Machine: PC
>
> Architecture: PowerPC
> Machine: Core99
>
> To be coincident with the -M flag and having the possibility of  
> changing the qemu executable name (that should be in the GUI  
> configuration)

I do see the logical connection of the two. But -M is a commandline 
Parameter that should remain with the other commandline arguments.

Maybe "PC Data" is not the correct name for what I had in mind: "PC 
Data" stores information, that is neccessary for a launcher app, to 
choose the correct binary and setup the right state, then apply the 
"Arguments" to this binary to start qemu.

Since binarynames could change in the future, I agree that we should use 
generic names for the Architectures. I'll list them now (please correct 
me, if I'm mistaken):
x86
x86-64 (x86_64 has more hits in google, but all the tech pages use x86-64)
PowerPC (maybe PPC will make it easyer to grep?)
SPARC
MIPS

G
Mike

>
> El 04/08/2005, a las 8:36, Mike Kronenberg escribió:
>
>> Mike Kronenberg wrote:
>>
>>
>>> I'm thinking of a new way to store the images and saved VMs, too.
>>> Maybe we could make something like vpc: A package with the config,  
>>> disk-images and saved VMs, located in ~/Documents/QEMU PCs/
>>>
>>
>> QEMU guest PC Format, a Proposal
>>
>> This should serve as a base for the discussion on a Structure/ Format 
>> to save preconfigured/saved guest PCs.
>>
>>
>> Structure:
>> all the Files needed by the VM are stored in a folder. The folder  
>> has an ending of .qvm (QEMU Virtual Machine).
>>
>> Mandatory Files:
>> - Harddiskimages
>> Configuration File (configuration.plist)
>>
>> Other Files:
>> FDImages
>> CDImages
>> Thumbnail (thumbnail.png)
>> VM State File (saved.vm)
>>
>> Host dependent Files:
>> PkgInfo (OS X)
>> info.plist (OS X)
>>
>>
>> Format:
>> As a general format, I propose XML. To be more exact:  PropertyLists. 
>> You find the definition for PropertyLists at: http:// 
>> www.apple.com/DTDs/PropertyList-1.0.dtd
>>
>> Why XML?
>> We live in a small world, the QEMU community started out from  France 
>> and has now it's followers all over the world. The  developers and 
>> (hard)core users may stick to ASCII characters. But  this is not the 
>> case for a broader community. Localized Operating  Systems and less 
>> interested/educated users will fast break  compatibility of simple 
>> text/ini files. (There might even arise  difficulties with 
>> ASCII/MacRoman) So XML is the choice in the long  run.
>>
>> Why PropertyList?
>> Because they are easy to handle. Datatypes/Values and Variable  Names 
>> are stored as pairs:
>> <dict>
>> <key>author</key>
>> <string>Mike Kronenberg</string>
>> <key>date</key>
>> <date>2005-07-27T22:00:00Z</date>
>> </dict>
>>
>> What should be covered by “configuration.plist”?
>> Version
>> About
>> Arguments
>> PC Data
>> Temporary
>>
>> There is no particular Order, Data is accessed by key.
>>
>>
>> 1.Version
>> Simple String to define the version of this configurations.plist  
>> file. Format: 1.0.0
>>
>> 2.About
>> Author name, Date, Copyright/left. Place for further Descriptions.
>>
>> 3.Arguments
>> To have the highest compatibility, we should stick to a simple  
>> option/value Scheme here, with boolean YES/NO for arguments with no  
>> value, like -enable-audio. There should be no host dependent  
>> switches here.
>>
>> 4.PC Data
>> PC Name, PC Description, PC Status, emulated CPU and other guest PC  
>> related “Meta” Information.
>>
>> 5.Temporary
>> “Nice to have” data, host dependent switches – shortly everything  
>> that is NOT needed to guarantee the operation of QEMU.
>>
>> Sample configuration.plist:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"  
>> "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
>> <plist version="1.0">
>> <dict>
>> <key>About</key>
>> <dict>
>> <key>author</key>
>> <string>Mike Kronenberg</string>
>> <key>copyright</key>
>> <string>© 2005, Mike Kronenberg</string>
>> <key>date</key>
>> <date>2005-07-27T22:00:00Z</date>
>> <key>description</key>
>> <string>This is a sample PC configuration.</string>
>> </dict>
>> <key>Arguments</key>
>> <dict>
>> <key>-boot</key>
>> <string>c</string>
>> <key>-cdrom</key>
>> <string>/dev/cdrom</string>
>> <key>-hda</key>
>> <string>Harddisk1.raw</string>
>> </dict>
>> <key>PC Data</key>
>> <dict>
>> <key>name</key>
>> <string>My new PC</string>
>> <key>state</key>
>> <string>saved</string>
>> <key>system</key>
>> <string>qemu-system-x86_64</string>
>> </dict>
>> <key>Temporary</key>
>> <dict/>
>> <key>Version</key>
>> <string>0.1.0</string>
>> </dict>
>> </plist>
>>
>>
>>
>>
>> Waiting for Your Suggestions...
>>
>> Mike
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFC8mDXSOHwOb87puQRApVgAJ432rq0FSwpBjRaxzmgVRcr3h/cpACg2+Cd
> O8Amp84ZCvMwvkEGJieWYkE=
> =npr3
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

I have implemented .qvm as a test in Q.

Here is a sample configuration.plist and some additions to my initial 
proposal:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>About</key>
    <dict>
        <key>Author</key>
        <string>Q</string>
        <key>Copyright</key>
        <string>none</string>
        <key>Date</key>
        <date>2005-08-07T19:25:41Z</date>
        <key>Description</key>
        <string>Converted guest PC from cocoaqemu.plist</string>
    </dict>
    <key>Arguments</key>
    <dict>
        <key>-boot</key>
        <string>c</string>
        <key>-cdrom</key>
        <string>/dev/cdrom</string>
        <key>-hda</key>
        <string>harddisk_1.img</string>
        <key>-localtime</key>
        <true/>
        <key>-m</key>
        <integer>16</integer>
        <key>-user-net</key>
        <true/>
    </dict>
    <key>PC Data</key>
    <dict>
        <key>architecture</key>
        <string>x86</string>
        <key>name</key>
        <string>Freedos</string>
        <key>state</key>
        <string>shutdown</string>
    </dict>
    <key>Temporary</key>
    <dict>
        <key>-cocoapath</key>
        <string>/Users/mike/Documents/QEMU/Freedos.qvm</string>
    </dict>
    <key>Version</key>
    <string>0.1.0.Q</string>
</dict>
</plist>

Changes:
    - the type <integer> for integer values:
        <key>-m</key>
        <integer>16</integer>
    - diskimages can have a relative path (to the .qvm root) or a 
absolute path, to an image outside the package:
        <key>-hda</key>
        <string>harddisk_1.img</string>
    - the key "architecture" for the used CPU
        <key>architecture</key>
        <string>x86</string>
    - the key "state" can take the following values:
        <key>state</key>
        <string>shutdown</string>
        <string>running</string>
        <string>saved</string>

On OS X, if you have Q installed, .qvm packages show as a single file 
and you can start QEMU by doubleclicking a .qvm package.
See the info.plist in Q.app/Contents for the Document definition.

Greetings
Mike

Re: [Qemu-devel] news on the OS X cocoa port

[Joshua Root]

On 21 Jul 2005, Natalia Portillo <claunia@claunia.com> wrote:
>El 21/07/2005, a las 18:33, Stealth Dave escribió:
>
>>On Jul 21, 2005, at 6:46 AM, Hetz Ben Hamo wrote:
>>
>>>On 7/21/05, Mike Kronenberg <mike.kronenberg@kberg.ch> wrote:
>>>
>>>>Hetz Ben Hamo wrote:
>>>>
>>>>I'm thinking of a new way to store the images and saved VMs, too.
>>>>Maybe we could make something like vpc: A package with the config,
>>>>disk-images and saved VMs, located in ~/Documents/QEMU PCs/
>>>>
>>>
>>>Nice idea.
>>>
>>
>>I would recommend ~/Library/QEMU/PCs as an 
>>alternative.  OS X tends  to store all of its 
>>program specific configuration information in 
>>the Library folder, which separates it from 
>>actual Documents such  as disk images, word 
>>processor files, images, etc.
>>
>>Just $0.02 from the Peanut Gallery! :)
>>
>>- Dave
>
>Yeah but the Library is a obscure place, and 
>VirtualPC for example  uses Documents with 
>packages inside and I think that is an elegant 
>way and also will help deal with old users.
>Also VPC uses XML for hardware description and 
>should be easy to make  a XML<->XML virtual 
>machine converter, with along qemu-img will 
>allow  people to convert old VPC machines to 
>QEMU ones (will be very useful  for me).

Besides which, you're not meant to go creating 
random folders at the top level of ~/Library/. If 
you have a single configuration file, it goes in 
~/Library/Preferences/, or if you have a 
collection of things, you create a subfolder in 
~/Library/Application Support/ and put them there.

I would prefer ~/Documents/QEMU/ rather than 
~/Library/Application Support/QEMU/ since the 
files stored there will not just be managed 
internally by the app; the user will know about 
them.

Cheers,
Josh

Re: [Qemu-devel] news on the OS X cocoa port

[Mike Kronenberg]

Joshua Root wrote:

> On 21 Jul 2005, Natalia Portillo <claunia@claunia.com> wrote:
>
>> El 21/07/2005, a las 18:33, Stealth Dave escribió:
>>
>>> On Jul 21, 2005, at 6:46 AM, Hetz Ben Hamo wrote:
>>>
>>>> On 7/21/05, Mike Kronenberg <mike.kronenberg@kberg.ch> wrote:
>>>>
>>>>> Hetz Ben Hamo wrote:
>>>>>
>>>>> I'm thinking of a new way to store the images and saved VMs, too.
>>>>> Maybe we could make something like vpc: A package with the config,
>>>>> disk-images and saved VMs, located in ~/Documents/QEMU PCs/
>>>>>
>>>>
>>>> Nice idea.
>>>>
>>>
>>> I would recommend ~/Library/QEMU/PCs as an alternative.  OS X tends  
>>> to store all of its program specific configuration information in 
>>> the Library folder, which separates it from actual Documents such  
>>> as disk images, word processor files, images, etc.
>>>
>>> Just $0.02 from the Peanut Gallery! :)
>>>
>>> - Dave
>>
>>
>> Yeah but the Library is a obscure place, and VirtualPC for example  
>> uses Documents with packages inside and I think that is an elegant 
>> way and also will help deal with old users.
>> Also VPC uses XML for hardware description and should be easy to 
>> make  a XML<->XML virtual machine converter, with along qemu-img will 
>> allow  people to convert old VPC machines to QEMU ones (will be very 
>> useful  for me).
>
>
> Besides which, you're not meant to go creating random folders at the 
> top level of ~/Library/. If you have a single configuration file, it 
> goes in ~/Library/Preferences/, or if you have a collection of things, 
> you create a subfolder in ~/Library/Application Support/ and put them 
> there.
>
> I would prefer ~/Documents/QEMU/ rather than ~/Library/Application 
> Support/QEMU/ since the files stored there will not just be managed 
> internally by the app; the user will know about them.
>
> Cheers,
> Josh
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

I agree. I used to store the saved VMs in ~/Library/cocoaqemu/. But this 
is no good solution, for if You want to remove qemu, you lose space on 
your HD, if you are not familiar with the library. Exchanging 
preconfigured/saved PC is also a lot easyer, if you have them in a nice 
package at the top of Your Documents Folder

Mike