Quote:
If i understood things correctly, i would probably go for option 1.

But that indeed leaves some things problematic, as already described by o1i. What do to with already running programs ?

fwiw: when pressing use, i would expect that the settings i have chosen are 'used' (not stored permanently and be confronted with these settings on a reboot). hence for me to favor option 1.

Possible 3th (incompatible) solution ? when an option is changed and causes you problems in starting/disabling current running app, make the use button grey out so that the use button can't be pressed at all (e.g. circumvent the difficult parts for the time being) ?

Quote:

To be consistent with AmigaOS you would have to display a requester saying: "In order to apply the changes you must restart the following programs..". Like Workbench does, when you try to change the screen resolution and it asks you to close programs, when you click "Use".

And yes, might be difficult to find out, which programs are running. For j-uae it should not be difficult ;). Search for a port or check, if the commodity is running..

Another update. I sent the program to Icaros beta testers ML for further testing. I have fixed some grammar mistakes here and there, recovered the 'USE' option and let AmiBridge settings be saved as well.

I have, however, two possible choices now for the 'USE' option and I'd need your suggestions as well.

There are settings that can be 'used' like AmiBridge ones, and other where the 'USE' button simply made not so much sense. How can something be saved on RAM and used, if it needed a reboot to apply? So here are the two roads I can take:

1) USE button applies the in-session applicable new settings and does not save them, BUT does nothing to changes that can be applied only at next startup. User can change options such as FTP and VNC at next startup, but these changes won't be applied

2) USE buttion applies the in-session applicable new settings and saves them, AND applies also the changes that can be applicable only at next startup. It wouldn't be coherent with Amiga habits, but how could a new setting like "run this at startup" be used otherwise?

Then, there would be the PERFECT solution, which would be stopping current programs like AmiStart or re-launching it when the user changes the option, saves or uses them, but, frankly speaking, I'm afraid it would be quite overkill (I'd have to check wether the program is running or not, and then act as the user likes), at least for now.

So, in your opinion, what option should I go for? 1 or 2?

Quote:

This is all your fault. Without one of your comments, I would have never touched e-uae in the first place ... I'll never forgive you that ;).

No need to be sorry coolcat... nine out of ten time it's me who read over things and misinterpret things

Your answer made me think though... it would be even ultimate if the 'program' could keep track of userchanges and 'know' (by keeping track of a variable named need_reboot, and changed accordingly) when a reboot is needed.

Then, on a save or exit, the program could query that variable to see if there was an option changed that needs rebooting and then ask the user:
"you have made changes that can only be applied on a reboot, do you like to reboot right now, yes/no ?"

But, i/we am/are getting a little ahead of things, i think. We have to keep in mind that all of what is planned is probably already a bit of a struggle for paolone, and as such paolone might have other priorities atm

magorium, sorry, i didnt read "right" (misunderstood) your post properly!
yes, i +1 the checkbox! :)

Quote:
That's why i wrote _add_ a button, as in _add_itional

But it was merely a suggestion. a checkbox saying "reboot when saved" might perhaps also be an option.

Reason to mention is that it is always nice to write something, but in practice nine out of ten times text was not read or 'forgotten' and then complain arise about why things not work

Quote:
it would be optional for the enduser, so with my suggestion you would still have that choice

Quote:
It really is, albeit some things are missing. it is not really my language, but mazze also added sqlite database support , which make amilua a very powerful tool. if only it could create/add api functions calls dynamically, it would make a near perfect scripting tool.

Quote:
i can only add +1 to that

first i would like to congrats for the nice work! :)
second, i dont think save and rebot is the best option, sometimes you want to make the change, do small stuff, and expect the changes in the next reboot.
but maybe that is a personal preference of mine.
well, have i said i loved it? the amibridge stuff is what i imagined years ago and it materialized. really cool!
infact, for some time now aros had impressed me a lot as it envolved.
i dunno how we dont got the fuse project done, but erverything really got an awesome overall fit, namelly:
-68k port
-68k emulation support
-the awesome gallium support (i think we could have more composite effects like compiz, but gallium was really an awesome step)

otoh, i think once kal was working on a qpart app, i suspect for replace hdtoolbox that didnt came to reality :/

i think now it uses a regular grub(2), and look all this back, i blamed myself for didnt noticed how handy amilua was.

abi1 isnt in the road yet, but for this about 15(?!?!) years, its really nice look the results. (from the michal smile face booting a x86 to a full featured OS, with tons of settings and details)

i couldnt find a better place for learn (a lot), and find the coolest group in the net.

congrats you all!

Unukily??? (in the tip box!)

Looking very good paolone :thumsbup:

If you have some time left, might i propose another request ?

In the dialog is writen "needs a reboot". why not add a button at the bottom saying "save and reboot".

If everything else fails (e.g. lua does not support reboot api) you could always use your normal 'save' routine and use "reboot cold" commandline program to do a reboot.

For the startupsound i would suggest an editbox (non-editable ?) with a ... (three dot) button (at the end of the box... does zune has such thing?) for calling the file selection requester ? e.g. you would avoid creating your own file selection dialog for that. Or did you meant to say something else with "add a requester for startup sound"


red:
drats, this picture is the only one i could come up with so quickly (instead of the image i meant an elipse button e.g. tripple dots):


And perhaps a checkbox in front to 'enable'/'disbale' the startup sound.

red2:
file selection ?

red3:
mui fileselection