QEMU Launcher + 32 bit QEMU pet and sfs

Message

mikeb · #136 Post by **mikeb** » Sat 11 Oct 2014, 16:16

Thanks Gobbi for clearing that up...so add the global variable and give some sort of info box..

Well will get on with that and the other suggestion for boot device shortly.

mike

Gobbi · #137 Post by **Gobbi** » Mon 13 Oct 2014, 12:16

You are welcome mikeb ! I'm glad to help somehow ...

Also , on jamesbond's suggestion , I added -sdl parameter ( using Qemu from the terminal ) and the geometry of the guest desktop follows the window's one . A checkbox for this option would add one more feature , I think .

mikeb · #138 Post by **mikeb** » Mon 13 Oct 2014, 12:34

-sdl... i noticed the -noframe related one and others.....

Bit awkward for testing here..... makes it not in its own window?#

Ie is there a set of parameters to give a particular feature? ... what exactly does only -sdl do... match windows borders?

mike

Gobbi · #139 Post by **Gobbi** » Tue 14 Oct 2014, 10:04

mikeb wrote:what exactly does only -sdl do... match windows borders?

From what I've seen , yes .
Maybe this library should be included by default , at least for this reason .
Additional parameters come only with -display sdl option , as I read in qemu-system-x86_64 -sdl --help in terminal ...

mikeb · #140 Post by **mikeb** » Tue 14 Oct 2014, 10:15

Well I was wondering if there was a group of parameters to produce a desirable result...eg something akin to remote X where the virtual machine is transparent...in other words if we have a checkbox lets make the most of it

I also am making the assumption we would have SDL enabled when compiled which seems to be the case for what's floating around.

I will see if I can get something running to play with this myself too...even with a workable distro I don't have any kernel acceleration with the latest releases so tends to run like sludge.

mike

jamesbond · #141 Post by **jamesbond** » Tue 14 Oct 2014, 15:08

"-sdl" is to start qemu with sdl interface. In the past this was always the default, but newer qemu comes with gtk interface as default (if compiled with gtk).
- "QEMU_SOUND_DRV" tells qemu what *host* driver to use. By default it is oss unless it is compiled without oss driver, in which case it would be alsa.
- soundhw tells qemu what *guest* soundcard to emulate. For newer guest OSes the only sensible one is "ac97" or "hda".

mikeb · #142 Post by **mikeb** » Tue 14 Oct 2014, 15:32

Ok thanks for the info.... that suggests to me -sdl by itself as an option and any others be custom preferences.

Alsa for the host makes sense to me too...avoids the annoying sound grabbing ...i think the idea is again custom options for the rest to keep the gui simple.

Think I have a working picture now.....

mike

mikeb · #143 Post by **mikeb** » Sun 16 Nov 2014, 17:39

Ok finally did an update.

Visually no difference but have added boot device, VNC and forwarding to the list of options preserved... the first one should mean your preferred boot arrangement can be set and forgotten about...still has the fallback to boot cd if there is no hard drive image.

I added the export QEMU_SOUND_DRV=alsa for testing and because its not something that could be added via the advanced option. I don't believe there are any other variables needed for general use as otherwise a separate entry box would be needed.

I also changed the help button showing all the command line options AND the audio ones too..a tooltip informs this. Also means there is help even if the QEMU package lacks it and does not rely on defaultbrowser either.

I have not added anything for SDL yet...thought better to test out the above first. I believe just adding a -sdl switch is all that's needed at a basic level.

Its also hitting a point of whether advanced options should be added...this would probably mean a tabbed interface and I am concerned that it would overwhelm a new user which is the primary target of the GUI.

Another area is usb devices... though not much has been mentioned about those.

Look forward to any feedback and suggestions..

edit.......
Originally I intended to make these gui simply as a convenience to avoid long command lines and remember parameters.
Anything added to the extras box is preserved so it could sort of be a haven for any advance usage...and if so perhaps it could become larger or a multiline box IF that's feasible (wrapping or multiple entry boxes)..at least that gives the convenience of only having to set options once.

Mike

neerajkolte · #144 Post by **neerajkolte** » Tue 18 Nov 2014, 07:24

Hi Mike,

I liked the idea of having tabbed interface.
Basic tab : For new users.
Advanced tab: For those who want to tweak more.

Although you said you only intended to make this gui simply as a convenience to avoid long command lines and remember parameters,
I think a text box should be added at the bottom which would show actual command combination which will run when user clicks 'run qemu' button according to the choices he made.
This would really help new users understand command parameters.
But at the same time this might complicate matters for your coding of gui. What do you think?

Thanks.

- Neeraj.

mikeb · #145 Post by **mikeb** » Tue 18 Nov 2014, 09:49

Funny really...I hacked searchmonkey because its tabbed interface to me made it over complicated and inconvenient and managed to retain the advanced settings in just the one display.

On a simple level I thing there is only the -sdl switch left to add.
After that perhaps a tabbed interface...but what to include?...
Or what about as suggested the big hairy entry box where an advanced user can add as many options as they wish and they get saved for future runs?

I think a text box should be added at the bottom which would show actual command combination which will run when user clicks 'run qemu' button according to the choices he made.

Actually if you run from the command line you would see just that...the command line is echoed for debug purposes.... so echoing that to a text box instead would be something like..... I assume we are think in terms of the way pburn does this. A bit of a trick in real time with gtkdialog...ie it something is needed to refresh the text ...could have perhaps an optional xmessage box...hmmm

OR...like pburn...the full command string is built and can be edited before running...and saved?...(not sure how saving would work with such as quotes)

food for thought...

mike

neerajkolte · #146 Post by **neerajkolte** » Tue 18 Nov 2014, 10:02

I think new user might be overwhelmed if only single tab contains all basic and advance options as well.
How about having a checkmark box. which when enabled give you all options and if disabled will only show basic clean GUI.

Thanks.

- Neeraj.

mikeb · #147 Post by **mikeb** » Tue 18 Nov 2014, 10:38

hmmm thing is how exactly would I fit the 60-80+ options on one interface using the various widgets.... I see the list and it does not compute into a workable interface...hence the suggestion of a text box.
person A will want a different set of options to person B... and it does not look like one checkbox can realistically do one pile of options since there are so many variables.

My dilemma....

I don't want a gui thats bigger than yer average laptop screen

mike

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

QEMU Launcher + 32 bit QEMU pet and sfs