[PD-dev] removing path and libs from Pd-extended preferences GUI

[András Murányi]

Just a silly idea... (attached)

Andras

On Mon, Sep 19, 2011 at 19:32, Hans-Christoph Steiner <hans at at.or.at> wrote:

>
> Hey Miller,
>
> I actually think this would make switching between vanilla and extended
> easier because it would make people use [import] or [declare] to load libs,
> then when using vanilla, you'll know which libraries the patch needs.  Can
> you think of examples where it would make things more difficult?
>
> To see which libraries Pd-extended is loading at startup, you can switch to
> the 'debug' view in the log, and you'll see:
>
> libdir loader 1.9
>        compiled on Sep 19 2011 at 03:25:20
>        compiled against Pd version 0.43.1.extended-20110919
> libdir_loader: added 'vanilla' to the global objectclass path
> libdir_loader: added 'extra' to the global objectclass path
> GEM: Graphics Environment for Multimedia
> GEM: ver: 0.93.SVN rev4516
> GEM: compiled: Sep 19 2011
> GEM: maintained by IOhannes m zmoelnig
> GEM: Authors :  Mark Danks (original version)
> GEM:            Chris Clepper
> GEM:            Cyrille Henry
> GEM:            IOhannes m zmoelnig
> GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle,
> Hans-Christoph Steiner, et al.
> GEM: found a bug? miss a feature? please report it:
> GEM:    homepage http://gem.iem.at/
> GEM:    bug-tracker http://sourceforge.net/**projects/pd-gem/<http://sourceforge.net/projects/pd-gem/>
> GEM:    mailing-list http://lists.puredata.info/**listinfo/gem-dev/<http://lists.puredata.info/listinfo/gem-dev/>
> GEM: compiled for SIMD architecture: SSE2 MMX
> GEM: using SSE2 optimization
> libdir_loader: added 'cyclone' to the global objectclass path
> libdir_loader: added 'zexy' to the global objectclass path
>
>
> .hc
>
>
> On Sep 19, 2011, at 1:26 PM, Miller Puckette wrote:
>
>  Hi Hans -
>>
>> Perhaps better would be to make it read-only so one can query it.
>>
>> I'm not sure, but there still might be complications for people switching
>> back and forth between vanilla and extended, for example, which would be
>> easiest to resolve if the GUI tools were there :)
>>
>> M
>>
>> On Sun, Sep 18, 2011 at 03:31:41PM -0400, Hans-Christoph Steiner wrote:
>>
>>>
>>> For next Pd-extended release, the same set of libraries that have been
>>> loading automatically at start-up would continue to be loaded as usual.
>>> It is just that there wouldn't be a GUI for people to modify that list
>>> of libraries that are loaded at startup.  I think most Pd-extended users
>>> don't use the startup libs preference already, so I am guessing most
>>> people wouldn't notice.
>>>
>>> .hc
>>>
>>>
>>> On Sunday, September 18, 2011 8:09 PM, "João Pais"
>>> <jmmmpais at googlemail.com> wrote:
>>>
>>>> you'll have lots of newbies complaining that their objects don't load?
>>>> (it's a good way to force everyone to use namespaces)
>>>>
>>>>
>>>>> I am thinking for the next release of Pd-extended, that the preferences
>>>>> panels for loading libs and adding paths should be removed.  [import]
>>>>> and [declare] cover all it can do in a better way, and people who
>>>>> really
>>>>> want to have libs and paths loaded globally on start-up can use either
>>>>> a
>>>>> manually written preferences file or the command line flags.
>>>>>
>>>>> I could see maybe keeping the paths GUI, but I don't see any good
>>>>> reasons to keep the startup libs GUI.  Anyone have objections?
>>>>>
>>>>> .hc
>>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110920/3868530f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Startup...disable-plugin.tcl
Type: application/x-tcl
Size: 550 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110920/3868530f/attachment.tcl>