On Mon, 4 Apr 2011, Pedro Lopes wrote:

p.s.: Mathieu: The last image gave me a wrong link.

I've had problems too. I don't understand what's going on : http://code.goto10.org/ redirects to http://lists.goto10.org/cgi-bin/mailman/listinfo/

Yet I did access the correct page and copy the link into my email. Weird stuff is happening for sure.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

Le 2011-04-04 à 22:40:00, yvan volochine a écrit :

hi no I never tried it (when I discovered it back in the years, my linux knowledge was close to null and I thought that the project was dropped (for some reasons..)) it always looked amazing to me, congrats ! (as well as gridflow)

En effet, le projet a été abandonné. Je pense parfois à le redémarrer, mais après le 2ième congrès de PureData, j'ai pas fait grand chose à part essayer de fusionner DesireData avec les diffs 39-40, 40-41 et 41-42.

I'll give a try at desiredata and let you know.

J'ai bien peur que ça marche seulement juste assez pour pouvoir voir de quoi ont l'air certaines features, et encore... il y en a plusieurs qui sont brisées.

Je sais pas ce que ça me prendrait pour me donner le goût de tout remettre ça en marche. Jonathan essaye de me le faire faire, de temps en temps.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

salut Mathieu

replying on the list because I think it's of general interest ;)

...

I'll give a try at desiredata and let you know.

J'ai bien peur que ça marche seulement juste assez pour pouvoir voir de quoi ont l'air certaines features, et encore... il y en a plusieurs qui sont brisées.

I did try DD and it worked ok (for my simple test patches at least).

the killer feature I'd *love* to see ported to pd is select object|pathchord with keyboard. (using the mouse to connect objects or open help patch is really bad IMHO)

I had a take at it. alas, there are still a lot of GUI things happening on the pd side and at the time I didn't find an easy way to just get the currently selected object(s) in tcl. (any hint on this is welcome).

right now I'm very busy but I might try this one again one day...

nice work auf jeden Fall =)

cheers, _y

-- yvan.volochine@gmail.com http://yvanvolochine.com

On Wed, 6 Apr 2011, Hans-Christoph Steiner wrote:

It would be great if as many of those desiredata improvements as possible were available as GUI plugins, I think I a lot of people would use them.

Yeah. It would be great if they were. But they aren't.

That's why I mention some of them, once in a while.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

On Apr 6, 2011, at 3:27 PM, yvan volochine wrote:

On 04/06/2011 09:23 PM, Mathieu Bouchard wrote:

...

On Wed, 6 Apr 2011, Hans-Christoph Steiner wrote:

...

It would be great if as many of those desiredata improvements as possible were available as GUI plugins, I think I a lot of people would use them.

Yeah. It would be great if they were. But they aren't.

That's why I mention some of them, once in a while.

BTW I gave a quick try to DesireData CTRL + arrows to select surrounding objects is amazing ! (although a
bit buggy here)

This should be doable in a GUI plugin, but the easy way to do it would
be basically making a keyboard controlled selection box.

this + connect via keyboard shortcuts would be insanely cool :P

This is probably not doable without C modifications.

cheers, _y

ps: and stick to grid !!!

This could be doable in a GUI plugin, but it might be a bit odd.

.hc

"We have nothing to fear from love and commitment." - New York Senator
Diane Savino, trying to convince the NY Senate to pass a gay marriage
bill

On Wed, 6 Apr 2011, yvan volochine wrote:

BTW I gave a quick try to DesireData CTRL + arrows to select surrounding objects is amazing ! (although a bit buggy here) this + connect via keyboard shortcuts would be insanely cool :P

btw, here's the article on keyboard-only interface, from 2nd Pd Convention (Montréal 2007) :

http://artengine.ca/~catalogue-pd/18-Lee-Bouchard.pdf

And there's also a guy who lives in my neighbourhood who wrote something called MAX Toolkit (before 2007). I think someone redid that in Pd in 2009 or so, I don't remember when. But those are not keyboard-only interfaces.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

hey,

I found the time to refine autocompletion-plugin so I ended up kinda rewriting it (screenshot below).

there are lots of changes, it would be nice if some of you could test it and tell me what's wrong or what is weird etc...

latest is here: http://github.com/gusano/pd_stuffs/tree/master/gui-plugins/autocompletion

I tested it only on linux and pd-0.43.1-test2 (vanilla).

list of changes:

• new GUI (à la DesireData)
• added support for osx and win32 (untested)
• added bash-completion-mode behavior (more or less)
• added *.cfg file for options
• completions update while typing
• added 'All' mode (requested: completions popup as soon as you type)
• hiting 'Enter' without the popup unedits and select the object

...

I'd like to track down bugs before releasing it this time ;)

thanks for the help.

cheers, _y

On 05/06/2011 08:16 PM, Patrice Colet wrote:

thank you for this plugin, is it possible to have a 8.4 compatible code? then it would be possible to load it within pd-vanilla

no sorry I won't support tcl-8.4 (and its ugly fonts)

note that gui-plugins work only in pd >= 0.43 (vanilla or not) if you use pd-0.43 you should update tcl/tk to 8.5 anyway.

cheers, _y

...

I found the time to refine autocompletion-plugin so I ended up kinda rewriting it (screenshot below).

there are lots of changes, it would be nice if some of you could test it and tell me what's wrong or what is weird etc...

latest is here: http://github.com/gusano/pd_stuffs/tree/master/gui-plugins/autocompletion

I tested it only on linux and pd-0.43.1-test2 (vanilla).

list of changes:

• new GUI (à la DesireData)
• added support for osx and win32 (untested)
• added bash-completion-mode behavior (more or less)
• added *.cfg file for options
• completions update while typing
• added 'All' mode (requested: completions popup as soon as you type)
• hiting 'Enter' without the popup unedits and select the object

...

I'd like to track down bugs before releasing it this time ;)

thanks for the help.

hi hans, thanks for testing

On Mac OS X, I can't select the

the ??

Why did you need to override ::dialog_font::ok? Perhaps something needs to be fixed so you don't need to do that.

to be able to change the completion fontsize on the fly when changing the fontsize via ::dialog_font instead of editing *.cfg, restarting, etc I forgot to use the config(font_size) there btw, will fix that

little bugs:

• type a letter in the box, highlight the letter with the mouse, then

hit Tab, and I get a Tcl error

• arrow keys or typing doesn't work in pop-up menu

on which OS ? I can't reproduce any of those neither on linux nor osx (tcl-8.5).

there seem to be weird focus thingz going on on os x. I'll try to simplify the whole focus behavior.

A couple little suggestions:

• for simplicity's sake, the namespace should be named the same as the

plugin, perhaps the plugin could also be called 'completion'.

makes sense, I'll do that

• pd will automatically post which plugins its loaded if you switch the

Pd window to the debug level, so you probably don't need the pdtk_post at the end.

IMHO it would be better to see what kind of extra libs/plugins are loaded without debug level (it's easy to forget that you have this maybe-buggy thing in your path). I'd vote for posting those by default.

cheers, _y

On May 7, 2011, at 10:05 AM, IOhannes m zmölnig wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 05/07/2011 01:58 PM, yvan volochine wrote:

...

IMHO it would be better to see what kind of extra libs/plugins are loaded without debug level (it's easy to forget that you have this maybe-buggy thing in your path). I'd vote for posting those by default.

i'd do a gui-plugin that raises the debug-level.

That's always a possibility, you can set the default debug level with
a one liner like:

set ::loglevel 4

As for what should be the default behavior, that's a tough question.
I've heard from a lot of newbies that having lots of text in the Pd
window at startup is quite intimidating, so I think its good to really
only show errors and strong warnings by default. More advanced users
can hopefully figure out how to set the log level.

.hc

Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 05/07/2011 08:02 PM, yvan volochine wrote:

from a noob pov it could easily lead to problems such as:

• why is pd behaving strangely suddenly ?
• remove all your gui-plugins and try again ?
• ooh, I forgot that I used xxx-plugin which is breaking pd !

if xxx-plugin was breaking Pd, then you probably don't have a chance to see the verbose messages either.

anyhow, i think the default behaviour should not be targetted at the worst case but at the normal case, which i hope is the none-broken one.

if things do break, the user (and that's not only the noob) ought to be given an easy way to inspect the problem (that is why i pushed hard to replace the numeric log-levels with symbolic ones)

mfgtasdr IOhannes

On May 7, 2011, at 2:02 PM, yvan volochine wrote:

...

...

...

IMHO it would be better to see what kind of extra libs/plugins are loaded without debug level (it's easy to forget that you have this maybe-buggy thing in your path). I'd vote for posting those by default.

i'd do a gui-plugin that raises the debug-level.

That's always a possibility, you can set the default debug level
with a one liner like:

set ::loglevel 4

As for what should be the default behavior, that's a tough question. I've heard from a lot of newbies that having lots of text in the Pd window at startup is quite intimidating, so I think its good to
really only show errors and strong warnings by default. More advanced
users can hopefully figure out how to set the log level.

I see gui-plugins more like "add-ons" and seeing that some of them
behave strangely, I think it's a good habit to have infos about
external libs being loaded in default debug level.

from a noob pov it could easily lead to problems such as:

• why is pd behaving strangely suddenly ?
• remove all your gui-plugins and try again ?
• ooh, I forgot that I used xxx-plugin which is breaking pd !

this kind of infos posted at startup would make sense to me: Gem version x Gridflow version x xxx-plugin version x ...

but maybe that's just me ;) I understand your point though and I'll remove it from my code.

Those Gem, etc version reports are just the thing that the people I
talked to were complaining about. If you are totally new, then being
hit with a wall of mystery text can be intimidating.

From my perspective, I also don't want to see anything but errors by
default, because I can always easily switch to see the debug log. I
think in this case, the interests of newbies and advanced users align
nicely.

Also, I think Pd-extended should include a number of plugins by
default, like perhaps your completion plugin. So that would mean that
the plugin reports would be shown by default.

.hc

I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-05-08 18:40, Hans-Christoph Steiner wrote:

Also, I think Pd-extended should include a number of plugins by default, like perhaps your completion plugin. So that would mean that the plugin reports would be shown by default.

though it's a bit annoying that the user cannot chose to _not_ use a certain plugin. (moving the foo-plugins folder into a "disabled/" folder is probably a not such a good idea either, as in this case this would be a global operation that effects all users on the machine)

(right, there is the plugins-plugin which might solve this; i don't know about it's persistency though)

maybe it would be nice if the GUI repsonded to the "-nostdlib" flag (or something equivalent)

fgasdm,r IOhannes

On May 10, 2011, at 2:55 PM, András Murányi wrote:

On Tue, May 10, 2011 at 12:19, IOhannes m zmoelnig zmoelnig@iem.at
wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-05-08 18:40, Hans-Christoph Steiner wrote:

...

Also, I think Pd-extended should include a number of plugins by

default,

...

like perhaps your completion plugin. So that would mean that the

plugin

...

reports would be shown by default.

though it's a bit annoying that the user cannot chose to _not_ use a certain plugin. (moving the foo-plugins folder into a "disabled/"
folder is probably a not such a good idea either, as in this case this
would be a global operation that effects all users on the machine)

(right, there is the plugins-plugin which might solve this; i don't
know about it's persistency though)

If I'm getting right what you mean by persistence, plugins-plugin
uses the "move to /disabled" method too. Actually, I don't really
sympathise with that method, and I was trying to advocate something
else (also because you may not have write access to every folder)
and I'll be happy to update the plugin as soon as a cleaner method
is agreed on.

Andras

I think its also something that needs to be addressed, but I'm not
sure there is a clear idea of how it should be done. I agree there
should be some kind of -noprefs/-nostdlib type flag that disables the
loading of plugins, perhaps just -noplugins?

The plugins-plugin might be able to override the current plugins
loading logic by being loaded first, then breaking out of the loop
that loads the rest. That'd be a big hack, but could be an easy way
to test out different ideas of handling the loading of plugins.

.hc

"A cellphone to me is just an opportunity to be irritated wherever you
are." - Linus Torvalds