GuiIdeas

Ideas for Improving Pd's GUI

The a ground up rewrite of Pd's GUI is underway, you can track the progress here: PdGuiRewrite. (Please note that there are small differences across platforms which can be found or added to the GUIPlatformDifferences wiki page.)

General

"Find" enhancement

• "Find" should work with symbol-text strings. Pd has the great feature of naming local variables with $0-xxx. But if I'm looking for all objects with $0-xx, or all ocurrences of $4 in a patch, that won't work with "find". Also using the specific-assigned number (e.g. 1024-xxx instead of $0-xxx) won't do the trick.

• "Find" doesn't work with partial strings. If I'm looking for all ocurrences of INIT (which might be in several objects like sends, receives, table~, etc.), it only looks for complete objects. I would have to look for "s INIT", "r INIT", etc. etc. (as of Pd 0.42, find works with partial strings)

Custom Object Contextual Menus

• An object, [contextitem 1 Edit...]? would add an "Edit..." item to either the current canvas, the parent of the object (when the object was right clicked), or both depending on the first argument (0, 1, or 2 respectively). The remaining arguments would specify the name of the context item (to allow for spaces), and the [contextitem]? object would have a single outlet which would [bang( when the context item was clicked.

• This (combined with a state-saving solution) would allow emulation of "Properties" dialogs, and would be generally useful for embedding functionality in tight spaces.

Display

• Currently, the font size and box sizes in Pd vary on each platform, causing layouts designed on one platform to be off on other platforms.

• Fixing the cross-platform size differences: GuiSizeDifferences

Comments with line breaks

Or, making a comment block a full-powered text block. What sense is it in making 5 diferent text strings for a list with 5 items, that is anyway supposed to look like one object?

Edit Mode

Snap-to-Grid

Especially useful for placing GUI objects, but also helpful for keeping patches tidy and clean: snap objects to grid while editing. Kind of "Edit->Tidy up" on the fly.

Ideally, it would be resizable and togglable via a preference, or even better, via Pd messages.

Possibly combine this with "magnetic edges", which lets (GUI) objects snap to each other when close.

From Vade: It might also be useful to have a very subtle background grid drawn on the canvas at certain intervals to help patch organization. Quartz Composer has this, as does Max 5.

Avoid Disconnections with Route, Trigger, Select

Changing a [trigger bang float]? to a [trigger bang anything float]? will make previous connections connect to the wrong outlet. It would be nice if old connections could be preserved even on such recreate-edits.

More Ways to Create Connections

• Keyboard shortcuts

• Multi-connections

• "Insert connections": drag an object over an existing connection and it magically inserts itself there.

• Holding shift while holding a patchcord would allow to connect several inlets

• Holding shift while clicking and dragging a patch cord would allow to deconnect it to the inlet it is connected in and then one could connect it to something else.

• the priority order of operation could be automatically right-to-left and bottom to up (instead of using the creation order). Therefore, the position of objects would matter. (is this good design?)

• shift(or control)-drag could duplicate an object. (as Alt already drags windows in Linux)

• one could not need to keep the mouse button down in order to connect a patch cord

Objects Z-axis Ordering

As in vector graphics software, the following commands would be essential for serious patching: send to back, bring to front, move one layer back/forward, etc.

Inlets and Outlets

Inlets and outlets could be improved in many ways:

• A slightly different look based on whether they are audio, message, or both

• The inlet you're about to drop a connection onto should highlight itself

• For small object boxes, a number showing the inlet/outlet that is under the mouse

• An ability to resize inlets and outlets (currently, chaging the font size doesn't affect the inlets size).

• Changable object width such that we can see all outlets or inlets. Could be a property of the boxes.

Size of objects automatically set + horizontal stretching

If you have an object with more than 4 outputs you'll need to make some garbage text or something in order to work with it. since it is quite logical that when the user needs outputs they should be acessible, an elegant solution would be to assign a minimal value to the gap between outputs. if the standard space of the object isn't big enough, the object will make itself bigger automatically. Although the stretching possibility in max is quite useful as well.

Connections

• Automatically shape a cord when it is used to feedback to the top of a patch

• Cords could be covered with a pattern like >>>>>>> so it is clearer when they were pointing upwards

• * This could alternatively be implemented by gradating between two colors (e.g. red at start of cord, blue at end), or by varying the thickness to form a "lance" shape (e.g. thick to thin).

Displaying Status Info

• Change the color of an object argument if its been overridden by data from an inlet or message (debug mode).

• Flash a cord in a specific color when data is sent (debug mode).

• Display inlet/outlet descriptions in a status bar.

Object Numbering

See: Objects should have optional visible numbers to assist dynamic patching. These could also help with the keyboard shortcuts discussed above - e.g. "22o0-5>27i0-5" would connect object 22's outlets 0,1,2,3,4,5 to object 27's inlets 0,1,2,3,4,5, or "14-25o0>50-59i4" would connect outlet 0 of objects 14 through 25 to inlet 4 of objects 50 through 59. Perhaps this syntax is awful :); any implementation that can accomplish what's described would be wonderful, though.

New style preferences

• patch cords:

• control rate color + thickness

• audio rate color + thickness

• optional arrows

• object box:

• border color + thickness

• interior color

• inlet/outlet style: filled or not

• message box:

• border color + thickness

• interior color

• inlet/outlet style: filled or not

• font color + size

• background canvas color

---

Colours based on data type --CpILL?, Mon, 05 Nov 2007 18:58:59 +0100

I was thinking that the connectors and inlets/outlets could be colored to show what data type they are. i.e. blue for float, red for bang etc. There is no visual representation of that information at the moment and I think it would help to ease the learning curve. Perhaps the colours could changed in the preferences or turned on/off.

What also might be good, and inspired from web pages, it the ability to increase the font size or better a sort of zoom in or out. Perhaps subpatched could have their own zoom level remembered?

send-architecture shortcut

All objects based on "invisible cords" (sends- and receive-based objects) could have a shortcut to its counterparts, like in max. By right-clicking on these objects, a list with their counterparts is shown, and selecting any element in that list takes us to the relevant patch window. (check Max for how it exactly works)

Solution to disastrously slow visualization of graphic arrays --jleben, Thu, 10 Apr 2008 12:32:13 +0200

Current problems because of slow drawing of graphic arrays: - Writing large amount of data into a graphic array causes fault of audio engine sync at the moment when the graphic array is being redrawn. - Moving a graphic array with big amount of data around a pd patch is hard/unusable.

I found out that it is possible to make visualization of graphic arrays much faster and usable: - by implementing a better visualization algorithm: drawing a vertical line for each column of pixels, the line ranges from minimum to maximum value of data window "covered" by the screen's column of pixels - instead of a line segment for each array data -> This results in much less Tk line segments being drawn. - by drawing the array data onto a separate Tk canvas

Solution to disastrously slow visualization of graphic arrays -

• second part (sorry) --jleben, Thu, 10 Apr 2008 12:39:15 +0200

...

• by drawing the array data onto a separate Tk canvas. -> this results in faster moving, because only the special canvas is translated instead of all the Tk line's coordinates being changed.

I have already made Pd externals that implement these two ideas, but I think this should be solved at the Pd core level. I would do it if someone introduced me into the depths of how (where in the code) pd's native graphic arrays are drawn.