Re: Future capability: Package management via gui?

[Mike Miller]

On Thu, Nov 12, 2015 at 12:58:33 -0500, Nicholas Jankowski wrote:
> On Thu, Nov 12, 2015 at 12:44 PM, Carnë Draug <address@hidden> wrote:
> > On 4 November 2015 at 14:03, Nicholas Jankowski <address@hidden> wrote:
> >> [...]
> >> Along with this is a question (stemming from an admitted ignorance of
> >> how the package install mechanics work) of why we need the
> >> auto-loading function to be set up along with a full package
> >> install/rebuild?  Does that provide something that a simple pkg load
> >> XX in a global startup script would not?

Do you mean the "pkg rebuild -auto foo" command? This does not actually
rebuild or reinstall the package contents, it only rebuilds the cache
that says what packages are installed and sets the auto-load flag.

> > The only difference by setting autoload is that if you start Octave
> > without reading the initialization file, then packages will still be
> > loaded.  But I'd argue that's actually a bad thing and not desired.
> >
> > I'm all in favour of completely removing the -auto flag from packages
> > and require users to place them in the octaverc file instead.
> >
> > Carnë
> 
> I think that would make it easier to incorporate in a gui based
> package interface, where checking the 'auto' box could effectively be
> removing or adding a comment character.  I guess the question then
> would be: is it ok to have a 'system managed' config file (does one
> exist now?). That could get very messy if the user is modifying the
> same file, or conflicts could develop with separate 'system managed'
> and user config file. I notice the GUI 'Preferences' mentions
> specifically that "These preferences are applied after any .octaverc
> startup files', but those settings seem pretty GUI specific. What
> would be the best way for pkg preferences to get stored and applied by
> the gui?

Yes, I think it would be a worthwhile project to look at a set of
functions for enabling and disabling certain settings that are currently
done by adding or deleting executable code in ~/.octaverc. I think it's
important that it's not something specific to the GUI, but a set of
function calls that the GUI will issue to the interpreter, and that a
command-line user could also use if they wanted.

The settings could either be added to ~/.octaverc or could be written to
a separate not-yet-defined file that would be loaded by ~/.octaverc,
etc. Lots of possibilities to look at where these actions are stored.

For comparison, there is already the function savepath, as well as the
addpref/getpref/setpref set of functions.

-- 
mike