*Desktop should run PinSetup/Pinboard

Currently !Boot runs PinSetup and Pinboard after the desktop starts, to set the backdrop and add the desktop icons.

It would be nice if *Desktop ran them itself, so the desktop is correct after manually starting it from the commandline.

Wouldn’t that reduce flexibility?

That said, it should probably run all the post Desktop tasks if *Desktop is to be anything like what you get after a reboot.

*Desktop would need to accept parameters for flexibility, ie “-noRunTasks”

Modules have the ability to run themselves when the Wimp starts up (Service_StartWimp). Perhaps it would be better for those modules to take care of it themselves, and they can be initialised or not, as desired?

I think the default setting should be the other way round:
*Desktop – starts the GUI but doesn’t run anything else from !Boot
*Desktop -RunPreDesk – runs !Boot.Choices.Boot.PreDesk after starting the GUI
and so on.

My reasoning is that some people may be relying on *Desktop doing nothing other than starting the GUI. I can’t think of a solid use-case (apart from the obvious “when something goes horribly wrong during boot it’s easier to dig around in !Boot.Choices.Boot from a GUI”) but it somehow “feels wrong” to make a drastic change to the default behaviour of a long-existing command/function.

I’m with Stuart.

*Desktop should start the desktop, only.

*Obey !Boot.!Boot (or just boot) should do all the fancy stuff.

In no case should there be an only pinboard option because the list of exceptions is about as long as the list of users (I for example, would like the option to have Internet set up but nothing else).

If you really must have pin icons with a basic booted system, write a little Obey file to run the stuff, drop it in $, and then you can F12 MyPins [Enter] [Enter] to bring them up.

It sounds like overall you’re looking to be able to exit and re-enter the desktop cleanly. I think that’s a good idea.

It sounds like overall you’re looking to be able to exit and re-enter the desktop cleanly. I think that’s a good idea.

Exactly that.

Having thought about it some more, it doesn’t need a parameter to load to a blank desktop, holding the SHIFT key should mirror current behaviour and not run anything from PostDesk/Look at/Run etc

What is the use case for leaving and re-entering the desktop, as opposed to rebooting?

What is the use case for leaving and re-entering the desktop, as opposed to rebooting?

I presume you’re querying that on the basis that anything you can do between the two, could be done equally well in a task window? Is that actually 100% true?

I presume you’re querying that on the basis that anything you can do between the two, could be done equally well in a task window?

I think you may have meant ShellCLI (i.e. F12) rather than a task window, as a task window imposes significant restrictions on what you can do.

As for the original question, “Exit desktop” would allow you to perform certain actions in the knowledge that no other applications or tasks are running/suspended, so the chances of you encountering (e.g.) open files on a filesystem are much reduced. Rebooting may not be an option if you want to make use of (e.g.) the current contents of system variables.

Is this even really possible? I’m not sure the desktop environment is intended to be quite and restarted…

perform certain actions in the knowledge that no other applications or tasks are running/suspended, so the chances of you encountering (e.g.) open files on a filesystem are much reduced.

As this not a bit of a red herring? Whether or not you’re in the desktop doesn’t guarantee anything about background processing. Think ShareFS, or Econet (if anybody still uses that). My server’s back end is implemented as a module, accepting the connection and handing over to a (multitasking) front end.
Unlike all of those things, that likely run of events and tickers, you can easily suspend all regular tasks by simply not polling.

As for the open files, these can be queried, though well behaved apps won’t keep files lingering without good reason.

But note that these days devices can also have file handles, so CLOSE#0 is not an option, lest something inadvertently fail.

I presume you’re querying that on the basis that anything you can do between the two, could be done equally well in a task window? Is that actually 100% true?

No, there are reasons for exiting the desktop. I’m asking what purpose is there to re-entering the desktop in minimal state via *desktop, instead of the more usual method of rebooting and having everything set up via the boot sequence.

in minimal state

Ah. I think that’s the point I’d missed!