I think there is a lot that could be done to the look and feel of Pd
that would make it much more efficient and usable. I think it is
crucial to avoid flashiness, one of Pd's strengths is its lack of
flashiness (no segmented patch cords! ;) But small things can make a
big difference.
For example, I think the inlet you're about to drop a connection onto
should highlight itself, that would make life a lot easier. You can
just drag to the middle of the box to connect to and see which inlet
is selected instead of having to aim for the tiny inlet.
Another thing is having the inlets and outlets look slightly
different based on whether they are audio, message, or both.
Another thing would be to automatically shape a cord when it is used
to feedback to the top of a patch. This is the only time when I
think that segmented patch cords are useful.
Some of these ideas already exist, maybe in DesireData, maybe in Max/
MSP, maybe jMax, wherever. I'd like to try to come up with a
coherent idea of the whole look. Another thing is choosing the line
colors, weights, shapes, etc.
I've been thinking a bit of how to make a patch more readable.
Color, shape, and weight should be used to highlight what is
important in the patch. I think that the shapes of the object box
vs. the message vs. the atom box are a nice feature. I think that
having them drawn in sharp, black lines draws too much attention to
the boxes themselves, rather than the text, which is more important.
Here are a couple of quick sketches I did, while talking with Roman,
vade, and others:
http://eds.org/~hans/pdsketch/
I'd like to see other sketches along these ideas.
.hc
Mistrust authority - promote decentralization. - the hacker ethic
hi all
i like the idea of optimizing pd's appearance, although i think it's only details, that should be improved. personally, i'd prefer boxes like that:
http://romanhaefeli.net/ramsch/nu_peedee_stuyl.png
because:
pencil 2) a border is still needed, otherwise the boxes seem to disappear and the strong presence of connections with very light boxes looks strange and makes it hard to follow a patch. 3) borders are grey not black in order to emphasize the text. 4) light grey filled boxes in order to better distinguish patch from canvas
why i like in the examples from: http://eds.org/~hans/pdsketch/
roman
On Sat, 2007-11-03 at 14:24 -0400, Hans-Christoph Steiner wrote:
I think there is a lot that could be done to the look and feel of Pd
that would make it much more efficient and usable. I think it is
crucial to avoid flashiness, one of Pd's strengths is its lack of
flashiness (no segmented patch cords! ;) But small things can make a
big difference.For example, I think the inlet you're about to drop a connection onto
should highlight itself, that would make life a lot easier. You can
just drag to the middle of the box to connect to and see which inlet
is selected instead of having to aim for the tiny inlet.Another thing is having the inlets and outlets look slightly
different based on whether they are audio, message, or both.Another thing would be to automatically shape a cord when it is used
to feedback to the top of a patch. This is the only time when I
think that segmented patch cords are useful.Some of these ideas already exist, maybe in DesireData, maybe in Max/ MSP, maybe jMax, wherever. I'd like to try to come up with a
coherent idea of the whole look. Another thing is choosing the line
colors, weights, shapes, etc.I've been thinking a bit of how to make a patch more readable.
Color, shape, and weight should be used to highlight what is
important in the patch. I think that the shapes of the object box
vs. the message vs. the atom box are a nice feature. I think that
having them drawn in sharp, black lines draws too much attention to
the boxes themselves, rather than the text, which is more important.Here are a couple of quick sketches I did, while talking with Roman,
vade, and others:http://eds.org/~hans/pdsketch/
I'd like to see other sketches along these ideas.
.hc
Mistrust authority - promote decentralization. - the hacker ethic
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
I agree, 1px looks better, and I very much like the versions with the
colored patch coords. I think the gray sans border ones are too
diffuse, and do not catch your eye fast enough, so you have to work
MUCH harder to make out the patch structure.
If it is possible to add user preference for these options, at least
things like -
control rate patch coord color audio rate patch coord color
optional arrows (I notice you have them in there subtly)
object box border color message box border color
object box interior color message box interior color
font color
background canvas color.
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 (not saying you HAVE to have it, but
it might be a nice addition.
I think the overall goal should be to increase visual differentiation
between graphic representation of different objects on screen, like
objects, abstractions, externals, patchcoord types, inles and outlets.
This is *really* important, as many people learn through their eyes,
and being able to visually identify components of a patch will ease in
learning, ease in patch flow understanding, and lower common error
rates and disambiguate LOTs of things.
Great work. Im all for it. These are the kind of quality of life
issues so few open source projects attempt to tackle, and what keep
many people from actively using some software.
Awesome.
On Nov 3, 2007, at 3:11 PM, Roman Haefeli wrote:
hi all
i like the idea of optimizing pd's appearance, although i think it's only details, that should be improved. personally, i'd prefer boxes
like that:http://romanhaefeli.net/ramsch/nu_peedee_stuyl.png
because:
- 1px border looks better. 2px or more looks like drawn with a clumsy
pencil 2) a border is still needed, otherwise the boxes seem to disappear and the strong presence of connections with very light boxes looks strange and makes it hard to follow a patch. 3) borders are grey not black in order to emphasize the text. 4) light grey filled boxes in order to better distinguish patch from canvas
why i like in the examples from: http://eds.org/~hans/pdsketch/
- the inlets and outlets.
- anti-aliased connections
roman
On Sat, 2007-11-03 at 14:24 -0400, Hans-Christoph Steiner wrote:
I think there is a lot that could be done to the look and feel of Pd that would make it much more efficient and usable. I think it is crucial to avoid flashiness, one of Pd's strengths is its lack of flashiness (no segmented patch cords! ;) But small things can make a big difference.
For example, I think the inlet you're about to drop a connection onto should highlight itself, that would make life a lot easier. You can just drag to the middle of the box to connect to and see which inlet is selected instead of having to aim for the tiny inlet.
Another thing is having the inlets and outlets look slightly different based on whether they are audio, message, or both.
Another thing would be to automatically shape a cord when it is used to feedback to the top of a patch. This is the only time when I think that segmented patch cords are useful.
Some of these ideas already exist, maybe in DesireData, maybe in Max/ MSP, maybe jMax, wherever. I'd like to try to come up with a coherent idea of the whole look. Another thing is choosing the line colors, weights, shapes, etc.
I've been thinking a bit of how to make a patch more readable. Color, shape, and weight should be used to highlight what is important in the patch. I think that the shapes of the object box vs. the message vs. the atom box are a nice feature. I think that having them drawn in sharp, black lines draws too much attention to the boxes themselves, rather than the text, which is more important.
Here are a couple of quick sketches I did, while talking with Roman, vade, and others:
http://eds.org/~hans/pdsketch/
I'd like to see other sketches along these ideas.
.hc
Mistrust authority - promote decentralization. - the hacker ethic
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 (not saying you HAVE to have it, but it might be a nice addition.
something important might be the possibility of using other colors except
white for the background. Not because of looks but because of eye health.
It's taken for granted that the standard background must be white, which
is maybe quite damaging to the eyes. I know of no studies about this, but
I set as many of my programs as I can to have a greyish background, that
goes softer on my eyes. (I usually also do my patches with graphics in
grayscale) I would second to even make the standard color a "safe" color.
Although looks might not be considered so relevant, it is an important
step in pd to improve also these subjects. I also second Vade's idea of a
properties saved in the patch file (and alterable on the fly through the
pd engine, please). That opens up lots of possibilities for more
rrrradical patching.
By the way, are all these new elements going to be improved only in
pd-ext, or also in vanilla? I guess it would make sense to have both at
the same level.
i think all in pd gui canvas part is just right.
there is also DesireData, why wouldn't you use it to have coloured stuff?
different stuff is already in the externals (which i personally dont use (almost, apart from a few objects)).
you can even have a three-dimensional gui made in GEM, if you really want to.
all gui colouring related stuff obviously seems to be in pd.tk script .. for example we could have a variabel instead of the string "white" write "$canvas_background" : canvas $name.c -width $width -height $height -background white
i'm just still wondering if we eventually increase the number of variables by say a 100 (which can easily happened, might even go to 200 or something like that), that will take more memory, isn't it ? so i think even if modern computers have a great figure of RAM, still this should be taken care of.
look, actually , having pd just black and white one can use a monochrome video card, and tweak the modern one to do the DSP. there ongoing developments , that most of you are aware of, i reckon. (that can happened only in theory, the two cards like that and a mother board which can accommodate both and communicate with them all together is very _hard_to_find_) but still, something a bit more normal can be done.
after all, who is not happy with tk, might like Tcl-GTK or i suppose, a brand new shiny pdgui can be rewritten in anything else if someone really wants to.
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 (not saying you HAVE to have it, but it might be a nice addition.
I look at this as the equivalent of properly indented code; a feature I'd really appreciate is the equivalent of auto-indenting since I obsessively line up my Pd patches.
Secondly, maybe consider making message boxes, object boxes and subpatch boxes each a different color? I'd consider this the equivalent of syntax highlighting, and though I'm sure choice of default colors will be contentious, I think it would be a boon for busy patches (especially the subpatch/objectbox differentiation; I am always searching for subpatches).
And finally, it pains me that much of this work we're discussing has already been done by Mathieu and Chun : (! I have a dream, where DD and PD and PD-E are one.
Cheers Luke
On Nov 3, 2007, at 8:40 PM, Luke Iannini (pd) wrote:
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 (not saying you HAVE to have it, but it might be a nice addition.
I look at this as the equivalent of properly indented code; a
feature I'd really appreciate is the equivalent of auto-indenting
since I obsessively line up my Pd patches.Secondly, maybe consider making message boxes, object boxes and
subpatch boxes each a different color? I'd consider this the
equivalent of syntax highlighting, and though I'm sure choice of
default colors will be contentious, I think it would be a boon for
busy patches (especially the subpatch/objectbox differentiation; I
am always searching for subpatches).And finally, it pains me that much of this work we're discussing
has already been done by Mathieu and Chun : (! I have a dream,
where DD and PD and PD-E are one.
DesireData has much more substantial and interesting changes than the
colors and backgrounds. it is also, unfortunately, not at a fully
usable state yet. Since there were 50,000+ downloads of the previous
version of Pd-extended (0.38.4), I think it's worthwhile to spend a
couple days to make Pd-extended work better while we are waiting for
DesireData.
.hc
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
DesireData has much more substantial and interesting changes than the colors and backgrounds. it is also, unfortunately, not at a fully usable state yet. Since there were 50,000+ downloads of the previous version of Pd-extended ( 0.38.4), I think it's worthwhile to spend a couple days to make Pd-extended work better while we are waiting for DesireData.
.hc
Sorry, I hope my tone was not discouraging; I most certainly support this.
It would be cool if you could document your changes, since I'd be interested in helping out. http://puredata.info/dev/GuiIdeas/ (I added some of the things from this thread just now)
By the way, Monaco on Leopard is rendering anti-aliased at 10pt again, so Pd-e looks great there out of the box.
Hi, this is not necesserarily more readable with it, but how one can change font color in a patch?
On Nov 4, 2007, at 12:25 AM, Luke Iannini (pd) wrote:
DesireData has much more substantial and interesting changes than
the colors and backgrounds. it is also, unfortunately, not at a
fully usable state yet. Since there were 50,000+ downloads of the
previous version of Pd-extended ( 0.38.4), I think it's worthwhile
to spend a couple days to make Pd-extended work better while we are
waiting for DesireData..hc
Sorry, I hope my tone was not discouraging; I most certainly
support this.It would be cool if you could document your changes, since I'd be
interested in helping out. http://puredata.info/dev/GuiIdeas/ (I added some of the things from this thread just now)By the way, Monaco on Leopard is rendering anti-aliased at 10pt
again, so Pd-e looks great there out of the box.
Here's the patch with the changes that I made, there is a section in
u_main.tk (aka pd.tk) that lists the colors that you can configure:
http://pure-data.cvs.sourceforge.net/pure-data/packages/patches/ color_scheme_support-0.40.3.patch
If anyone is interested in working on the Pd GUI, a good place to
start is the various panels. I played a bit with this GUI builder
thing, it's quite handy. It's a bit buggy, but useful, and available
on GNU/Linux, Windows, and Mac OS X.
http://sourceforge.net/project/showfiles.php? group_id=24918&package_id=219784
The app is a little weird to run on Mac. First download this file,
Then if you add ".command" to the end of it, you can run it by
doubleclicking. You also have to set it as executable.
http://downloads.sourceforge.net/spectcl/guibuilder-macosx- universal-20070129
Basically, if you are interest in improving the GUI, you could use it
to remake some of the panels. The IEMGUI panels are quite hard to
modify, but the Pd ones are easy, so try some of these:
find panel send panel text editor array panel canvas/GOP panel Pd window all four preferences panes
Avoid BWidget and Iwidgets since those aren't currently included in
Pd's Tcl/Tk.
.hc
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
On Sun, Nov 04, 2007 at 07:20:47PM +0100, Steffen Juul wrote:
On 04/11/2007, at 17.21, Hans-Christoph Steiner wrote:
Avoid BWidget and Iwidgets since those aren't currently included in
Pd's Tcl/Tk.Does anyone know of alternative "tricks" wrt. building tab'ed windows?
just use fluxbox WM.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 4 Nov 2007, Steffen Juul wrote:
On 04/11/2007, at 17.21, Hans-Christoph Steiner wrote:
Avoid BWidget and Iwidgets since those aren't currently included in Pd's Tcl/Tk.
Does anyone know of alternative "tricks" wrt. building tab'ed windows?
Pd-extended's build system could also bundle some Tk extensions and auto-compile them like the rest. Then you need two lines of code to load those Tk libraries from lib/pd/lib/tk, for example.
Apart from that, DesireData has a tabbed dialog component, though it's not exactly as nice as I would like it to be (a bit tricky to get right).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Nov 4, 2007, at 1:20 PM, Steffen Juul wrote:
On 04/11/2007, at 17.21, Hans-Christoph Steiner wrote:
Avoid BWidget and Iwidgets since those aren't currently included
in Pd's Tcl/Tk.Does anyone know of alternative "tricks" wrt. building tab'ed windows?
Maybe it's worth it to work on getting iwidgets as part of Pd-
extended, then there would be a bunch of full-featured widgets
available. Then it would also be not too hard to make an "iwidgets"
library that wraps all of those for use directly in Pd.
Then the pref panes could be Pd patches :D
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
And finally, it pains me that much of this work we're discussing has already been done by Mathieu and Chun : (! I have a dream, where DD and PD and PD-E are one.
Oh yes, we are dreaming the same dream - but DesireData isn't there in terms of usability yet. I couldn't use it for anything dsp-related actually. The only thing I was able to get out of it was just to see what Chun and Mathieu have been up to. From what I understand (admittedly, not much) they have undertaken something much more extensive than color changes, and their work is likely not easily integrated with pd's vanilla ui. I had a conversation with Miller at the pd-conv where he said he was interested in implementing some of dd's features at a point in the future.
Kevin
On Sat, 3 Nov 2007, Luke Iannini (pd) wrote:
I look at this as the equivalent of properly indented code; a feature I'd really appreciate is the equivalent of auto-indenting since I obsessively line up my Pd patches.
I thought about auto-positioning of objects and figured out that a way to conciliate many potentially conflicting rules about placement of objects, each rule could be defined as a force that pull objects towards their ideal spot relative to that rule. The object will then tend towards an intersection of the ideal spots, or if there is none, it will tend towards somewhere between several ideal spots.
So, for example, there would be a first force to ensure that objects don't overlap. It would repulse objects from other objects, though not in a way usually seen in physics. A second rule would tend to align a box with the boxes it is connected to, with priority on left inlet connections, and a third rule would tend towards the previous object in the chain. More rules can be added and all rules can be weighted in order to adjust the priority of the rules. By making rules combine in different ways (variable weighting), different systems of priorities can be made.
This could take an external and a patch, or some tcl code in desiredata.
And finally, it pains me that much of this work we're discussing has already been done by Mathieu and Chun : (! I have a dream, where DD and PD and PD-E are one.
DD-E is "coming soon", that is, almost as soon as the rest of DD that is not really coming closer at this point...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
hey mathieu, in case you have not seen this yet.. (max toolbox) http://video.google.com/videoplay?docid=9064204491926904985 marius.
Mathieu Bouchard wrote:
On Sat, 3 Nov 2007, Luke Iannini (pd) wrote:
I look at this as the equivalent of properly indented code; a feature I'd really appreciate is the equivalent of auto-indenting since I obsessively line up my Pd patches.
I thought about auto-positioning of objects and figured out that a way to conciliate many potentially conflicting rules about placement of objects, each rule could be defined as a force that pull objects towards their ideal spot relative to that rule. The object will then tend towards an intersection of the ideal spots, or if there is none, it will tend towards somewhere between several ideal spots.
So, for example, there would be a first force to ensure that objects don't overlap. It would repulse objects from other objects, though not in a way usually seen in physics. A second rule would tend to align a box with the boxes it is connected to, with priority on left inlet connections, and a third rule would tend towards the previous object in the chain. More rules can be added and all rules can be weighted in order to adjust the priority of the rules. By making rules combine in different ways (variable weighting), different systems of priorities can be made.
This could take an external and a patch, or some tcl code in desiredata.
And finally, it pains me that much of this work we're discussing has already been done by Mathieu and Chun : (! I have a dream, where DD and PD and PD-E are one.
DD-E is "coming soon", that is, almost as soon as the rest of DD that is not really coming closer at this point...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 4 Nov 2007, marius schebella wrote:
in case you have not seen this yet.. (max toolbox) http://video.google.com/videoplay?docid=9064204491926904985
Yes, there was a talk about a Pd version of this, at PdConvention2007. Were you there? :}
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Nov 4, 2007, at 11:59 PM, Mathieu Bouchard wrote:
On Sun, 4 Nov 2007, marius schebella wrote:
in case you have not seen this yet.. (max toolbox) http://video.google.com/videoplay?docid=9064204491926904985
Yes, there was a talk about a Pd version of this, at
PdConvention2007. Were you there? :}
I think it would be possible to do something like that in Pd and the
iemguis, since you can move them with messages.
There is an alpha version of [cursor] in today's build which will
give you the mouse cursor position. I just got some ideas of how to
do it better, so it should be better tomorrow. :)
If someone wants to try to do this, I am willing to do the work to
fill in the gaps in Pd so that it's possible.
.hc
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
On Sat, 2007-11-03 at 14:24 -0400, Hans-Christoph Steiner wrote:
I think there is a lot that could be done to the look and feel of Pd
that would make it much more efficient and usable. I think it is
crucial to avoid flashiness, one of Pd's strengths is its lack of
flashiness (no segmented patch cords! ;) But small things can make a
big difference.
I really like some of these ideas, and I do agree that a few subtle visual nuances would bring Pd's UI into the 21st century! I always thought that om/ingen (http://wiki.drobilla.net/Ingen) had a a really nice UI - just the right combination of minimalist simplicity and graphical niceness (anti-aliased splines!). Maybe we can steal some ideas from that.
Can I put a vote in for _not_ putting arrows on the end of patch chords. This is one of the features of Desire Data that I really don't like since it adds no additional information to the patch (it isn't possible to connect from inlets to outlets), and it adds visual noise.
Jamie
On Nov 3, 2007, at 7:28 PM, Jamie Bullock wrote:
On Sat, 2007-11-03 at 14:24 -0400, Hans-Christoph Steiner wrote:
I think there is a lot that could be done to the look and feel of Pd that would make it much more efficient and usable. I think it is crucial to avoid flashiness, one of Pd's strengths is its lack of flashiness (no segmented patch cords! ;) But small things can make a big difference.
I really like some of these ideas, and I do agree that a few subtle visual nuances would bring Pd's UI into the 21st century! I always thought that om/ingen (http://wiki.drobilla.net/Ingen) had a a really nice UI - just the right combination of minimalist simplicity and graphical niceness (anti-aliased splines!). Maybe we can steal some ideas from that.
Can I put a vote in for _not_ putting arrows on the end of patch
chords. This is one of the features of Desire Data that I really don't like since it adds no additional information to the patch (it isn't
possible to connect from inlets to outlets), and it adds visual noise.Jamie
-- www.postlude.co.uk
I'm going to try to get a version of this into the Pd-extended auto- build for tonight:
http://eds.org/~hans/pdsketch/solidboxes+color.png
I'll made the colors settable in the pd.tk so people can make it look
the "old way" without too much trouble. Perhaps it could be a
command line flag, something like: -orthodox ;)
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Hi Hans, I saw that you filled the boxes now with grey. actually I do not agree with roman, that this looks better, I think the contrast is smaller and therefore text is less readable for me. I would prefer white object background. marius.
Hans-Christoph Steiner wrote:
On Nov 3, 2007, at 7:28 PM, Jamie Bullock wrote:
On Sat, 2007-11-03 at 14:24 -0400, Hans-Christoph Steiner wrote:
I think there is a lot that could be done to the look and feel of Pd that would make it much more efficient and usable. I think it is crucial to avoid flashiness, one of Pd's strengths is its lack of flashiness (no segmented patch cords! ;) But small things can make a big difference.
I really like some of these ideas, and I do agree that a few subtle visual nuances would bring Pd's UI into the 21st century! I always thought that om/ingen (http://wiki.drobilla.net/Ingen) had a a really nice UI - just the right combination of minimalist simplicity and graphical niceness (anti-aliased splines!). Maybe we can steal some ideas from that.
Can I put a vote in for _not_ putting arrows on the end of patch
chords. This is one of the features of Desire Data that I really don't like since it adds no additional information to the patch (it isn't
possible to connect from inlets to outlets), and it adds visual noise.Jamie
-- www.postlude.co.uk
I'm going to try to get a version of this into the Pd-extended auto- build for tonight:
http://eds.org/~hans/pdsketch/solidboxes+color.png
I'll made the colors settable in the pd.tk so people can make it look
the "old way" without too much trouble. Perhaps it could be a
command line flag, something like: -orthodox ;).hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, 2007-11-03 at 20:08 -0400, marius schebella wrote:
Hi Hans, I saw that you filled the boxes now with grey. actually I do not agree with roman, that this looks better, I think the contrast is smaller and therefore text is less readable for me.
though it probably slightly minimizes the contrast a bit, i don't think, that this is basically true with the _very_ light grey hans has chosen. turn the brightness level of your screen down by one level and you have the very same contrast in old pd style as well. does it really make a difference in readibility?
I would prefer white object background.
the idea came up, because hans proposed to use grey for the borders and with grey borders, the objects seemed to kind of disappear. it was a way to separate the objects better from the canvas background.
what would you actually prefer? grey borders and white filled objects? or just status quo? (i want to add: i do not dislike pd's actual appearance at all, but i am interested to see, if it could be improved )
roman
Hans-Christoph Steiner wrote:
On Nov 3, 2007, at 7:28 PM, Jamie Bullock wrote:
On Sat, 2007-11-03 at 14:24 -0400, Hans-Christoph Steiner wrote:
I think there is a lot that could be done to the look and feel of Pd that would make it much more efficient and usable. I think it is crucial to avoid flashiness, one of Pd's strengths is its lack of flashiness (no segmented patch cords! ;) But small things can make a big difference.
I really like some of these ideas, and I do agree that a few subtle visual nuances would bring Pd's UI into the 21st century! I always thought that om/ingen (http://wiki.drobilla.net/Ingen) had a a really nice UI - just the right combination of minimalist simplicity and graphical niceness (anti-aliased splines!). Maybe we can steal some ideas from that.
Can I put a vote in for _not_ putting arrows on the end of patch
chords. This is one of the features of Desire Data that I really don't like since it adds no additional information to the patch (it isn't
possible to connect from inlets to outlets), and it adds visual noise.Jamie
-- www.postlude.co.uk
I'm going to try to get a version of this into the Pd-extended auto- build for tonight:
http://eds.org/~hans/pdsketch/solidboxes+color.png
I'll made the colors settable in the pd.tk so people can make it look
the "old way" without too much trouble. Perhaps it could be a
command line flag, something like: -orthodox ;).hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Sun, Nov 04, 2007 at 01:32:08AM +0100, Roman Haefeli wrote:
what would you actually prefer? grey borders and white filled objects? or just status quo? (i want to add: i do not dislike pd's actual appearance at all, but i am interested to see, if it could be improved )
Almost all visual improvements are going to be subjective. That is to say, for every suggestion someone makes along the lines of visual changes to Pd, there will be many people for the change and many people against. For that reason, please put in the time to make all changes configurable, so that those who like the current look of Pd can easily put in command line flags or .pdrc settings to make it looks the way it does now. Ideally this would be something like "-originalgui". As for the default look, that could be decided by majority vote I guess.
Best,
Chris.
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
Almost all visual improvements are going to be subjective. That is to say, for every suggestion someone makes along the lines of visual changes to Pd, there will be many people for the change and many people against. For that reason, please put in the time to make all changes configurable, so that those who like the current look of Pd can easily put in command line flags or .pdrc settings to make it looks the way it does now. Ideally this would be something like "-originalgui". As for the default look, that could be decided by majority vote I guess.
I very much support that approach. What looks good or is helpful is a very personal decision. We already had a heated discussion about which fonts to choose and I'd rather not repeat this for every other aspect of Pd, this would be counter-productive and bind too many resources better wasted elsewhere. ;)
The only way a GUI overhaul can work in the long run IMO is to make a configuration system. This actually probably should not be a command line flag like "-originalgui" or "-newgui", but a new configuration file for themes that can be loaded with "-theme" or so. This is the approach that works for most other applications as well (Firefox, Gtk, etc.) All that Pd would need to supply is some hooks for setting various things like colors for canvas-BG, thickness of signal/msg-cords, (or even fonts, though this may be tricky) etc. Then the config file would just list the values for these variables, maybe in simple Tcl-syntax (no XML!). But please don't enforce huge GUI choices on all users.
Frank Barknecht _ ______footils.org__
On 04/11/2007, at 12.03, Frank Barknecht wrote:
I very much support that approach.
I also think preferences/themes are a good ide. This could quickly
become the bike shred colouring story over again.
The only way a GUI overhaul can work in the long run IMO is to make a configuration system. This actually probably should not be a command line flag like "-originalgui" or "-newgui", but a new configuration file for themes that can be loaded with "-theme" or so.
I like the idea of separating it, but i think it would be good to
consider the possibilities to get "it" into vanilla Pd as well. I
don't know if there is any strategy with that goal that works better
then others wrt. that?
In some sense such custom GUI options would support the goal of being
cultural natural.
"The computer music community is similar to the Linux community in
that it can grow among small groups with only occasional need for
outside contact beyond what a modem can provide. To empower this, it
is important that the software not come with its own cultural freight
but that it adapt to whatever realities exist where the users live.
This is exactly what typifies good software development in general."
26, No 4, p. 41.
Hallo, Steffen Juul hat gesagt: // Steffen Juul wrote:
On 04/11/2007, at 12.03, Frank Barknecht wrote:
I very much support that approach.
I also think preferences/themes are a good ide. This could quickly
become the bike shred colouring story over again.The only way a GUI overhaul can work in the long run IMO is to make a configuration system. This actually probably should not be a command line flag like "-originalgui" or "-newgui", but a new configuration file for themes that can be loaded with "-theme" or so.
I like the idea of separating it, but i think it would be good to
consider the possibilities to get "it" into vanilla Pd as well.
I don't think it would be too hard to get it into vanilla Pd. The idea would be to first replace the hardcoded stuff in pd.tk with variable. There's a lot of "-background white" or "-borderwidth 1" there, which would become: "-background $theme_bgcolor" or "-borderwidth $theme_bwidth" etc. The theme config file then would just need to be included from pd.tk with something like (pseudocode):
# set defaults:
set theme_bgcolor white
set theme_bwidth 1
# ...
# source theme as provided from command line to overwrite
# defaults:
source $theme_from_commandline
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey
set theme_bwidth 2
...
People then could write lots of funky themes and distribute them on websites and everybody would be happy couples.
The only thing to write would be some variables in pd.tk and a loader which fills the $theme_from_commandline variable. And maybe think about if simply sourcing the file is a security hole.
Frank Barknecht _ ______footils.org__
On Sun, Nov 04, 2007 at 07:12:40PM +0100, Frank Barknecht wrote:
There's a lot of "-background white" or "-borderwidth 1" there, which would become: "-background $theme_bgcolor" or "-borderwidth $theme_bwidth" etc. The theme config file then would just need to be included from pd.tk with something like (pseudocode):
# set defaults: set theme_bgcolor white set theme_bwidth 1 # ... # source theme as provided from command line to overwrite # defaults: source $theme_from_commandline
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
that's what i was just meaning at the top of the thread somewhere .
People then could write lots of funky themes and distribute them on websites and everybody would be happy couples.
The only thing to write would be some variables in pd.tk and a loader which fills the $theme_from_commandline variable. And maybe think about if simply sourcing the file is a security hole.
why do you think it could be ? there so many files sources in different apps, as i know ..
i heard pd is generaly not as secure as some openbsd system apps...
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, ilya .?? hat gesagt: // ilya .?? wrote:
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
that's what i was just meaning at the top of the thread somewhere .
Yes, sorry, I missed that. Anyway my main point is the hook to load a complete theme file from a user option, instead of hardcoded themes.
Frank Barknecht _ ______footils.org__
On Sun, Nov 04, 2007 at 09:47:08PM +0100, Frank Barknecht wrote:
Hallo, ilya .?? hat gesagt: // ilya .?? wrote:
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
that's what i was just meaning at the top of the thread somewhere .
Yes, sorry, I missed that. Anyway my main point is the hook to load a complete theme file from a user option, instead of hardcoded themes.
sure. i 'm probably not very good at delivering my ideas to public anyway ;)
do you think massively increasing the amount of variables won't cause ANY interpreter slowdown ? .. may be some 'unset' procedure should be done after new canvas was created with '-background $theme_canvbg' - do 'unset theme_canvbg' ..it's a common practice in the shell scripts, regardless of the general sizeof it.
i reckon it has to be embedded into the pd.tk script.
there are may variables which are used many times, but many are still just used once.
On Nov 4, 2007, at 3:12 PM, ilya .д wrote:
On Sun, Nov 04, 2007 at 07:12:40PM +0100, Frank Barknecht wrote:
There's a lot of "-background white" or "-borderwidth 1" there, which would become: "-background $theme_bgcolor" or "-borderwidth $theme_bwidth" etc. The theme config file then would just need to be included from pd.tk with something like (pseudocode):
# set defaults: set theme_bgcolor white set theme_bwidth 1 # ... # source theme as provided from command line to overwrite # defaults: source $theme_from_commandline
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
I added variables in pd.tk so you can edit that if you want to make
your own theme.
.hc
that's what i was just meaning at the top of the thread somewhere .
People then could write lots of funky themes and distribute them on websites and everybody would be happy couples.
The only thing to write would be some variables in pd.tk and a loader which fills the $theme_from_commandline variable. And maybe think about if simply sourcing the file is a security hole.
why do you think it could be ? there so many files sources in different apps, as i know ..
i heard pd is generaly not as secure as some openbsd system apps...
Ciao
Frank Barknecht _
______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
On Nov 5, 2007, at 12:36 AM, Patrice Colet wrote:
Hans-Christoph Steiner a écrit :
I added variables in pd.tk so you can edit that if you want to
make your own theme. .hchi, is there a way for having a different font color? I'd like to patch with a black background and white fonts.
Yup, that should be possible, I'll try to put out a "theming" patch
soon.
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Hans-Christoph Steiner a écrit :
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
One ideal feature would be to make a distinction between normal objects and subpatch / abstraction, for example with a bolder font or heavier borderline. I'm sure this is more difficult, but as a subpatch or an abstraction is in itself more important than its text, it should be really useful... Is this conceivable?
Greetings,
On Mon, 2007-11-05 at 16:12 +0100, Nicolas Montgermont wrote:
Hans-Christoph Steiner a écrit :
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
One ideal feature would be to make a distinction between normal objects and subpatch / abstraction, for example with a bolder font or heavier borderline. I'm sure this is more difficult, but as a subpatch or an abstraction is in itself more important than its text, it should be really useful... Is this conceivable?
isn't it the idea of the abstraction, that they behave as any other object? if so, why do they need a distinction from other objects?
yo, but i think, that some additional info could be useful in general. what about another entry, when right-clicking an object/abstraction, that shows, where the abs/objects is coming from?
right-click on [dirac~] would show:
zexy.pd_linux (in pd-vanilla)
or
zexy/dirac~.pd_linux (in pd-extended)
or
my_zexy_replacement_lib/dirac~.pd
or
dirac~.pd_linux (if dirac~.pd is directly in <...>/extra)
is this possible at all?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
FYI, this should be possible now using [textfile] and [sys_gui]. See
my "themer" example I posted last night, then add [textfile] and some
basic parsing.
.hc
kill your television
On 05/11/2007, at 18.23, Hans-Christoph Steiner wrote:
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
FYI, this should be possible now using [textfile] and [sys_gui]. See my "themer" example I posted last night, then add [textfile] and some basic parsing.
I think the/your [sys_gui] is interesting from a GUI slash custom
patch layout per patch point of view. But another interface for
setting the general patch layout (~theme) would be great, I think.
One reason, as I spoke of earlier, is the possibility of getting it
into vanilla Pd too. For that to make sense there need a non-external
interface. - As I see it.
Related: What does the changes to the *.c files in
color_scheme_support-0.40.3.patch do? I read c not good.
But to put it another way: Would it be troublesome to add another
interface fx via a "theme file with tcl syntax"? At a later point it
could get it's own tab in a tab-ified preference window as a bonus.
In this discussion i think it's good to keep the distinction between
the general layout/theme and the per patch ditto.
Technically [sys_gui] and friends can do both. It can by it self do
the general themes by (re)setting the vars in pd.tk. With friends it
can therefor also reset it to default, where default is the the
default theme the given user has specified - right?
On Nov 5, 2007, at 1:17 PM, Steffen Juul wrote:
On 05/11/2007, at 18.23, Hans-Christoph Steiner wrote:
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
FYI, this should be possible now using [textfile] and [sys_gui]. See my "themer" example I posted last night, then add [textfile] and some basic parsing.
I think the/your [sys_gui] is interesting from a GUI slash custom
patch layout per patch point of view. But another interface for
setting the general patch layout (~theme) would be great, I think.One reason, as I spoke of earlier, is the possibility of getting it
into vanilla Pd too. For that to make sense there need a non- external interface. - As I see it.Related: What does the changes to the *.c files in
color_scheme_support-0.40.3.patch do? I read c not good.But to put it another way: Would it be troublesome to add another
interface fx via a "theme file with tcl syntax"? At a later point
it could get it's own tab in a tab-ified preference window as a bonus.
That theme file can be loaded by a Pd patch using [textfile] and
[sys_gui]. I am thinking of making a "startup.pd" patch which is run
after startup completes. This could then load the theme file.
In this discussion i think it's good to keep the distinction
between the general layout/theme and the per patch ditto.
A theme could be loaded in a patch by using [initbang] so that it's
run before the patch is done drawing (I think, I could be wrong).
.hc
Technically [sys_gui] and friends can do both. It can by it self do
the general themes by (re)setting the vars in pd.tk. With friends
it can therefor also reset it to default, where default is the the
default theme the given user has specified - right?
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
Nicolas Montgermont wrote:
Hans-Christoph Steiner a écrit :
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
One ideal feature would be to make a distinction between normal objects and subpatch / abstraction, for example with a bolder font or heavier borderline.
hmm, why do you want to differentiate between a "normal" object and an abstraction? i always considered abstractions to be equal to internals and externals. (they are not from an API point-of-view; but i think that this is a bug rather than a feature)
I'm sure this is more difficult, but as a subpatch or an abstraction is in itself more important than its text, it should be really useful...
otoh, i understand that subpatches might be visually distinct from objects.
fmga.dsr IOhannes
hmm, why do you want to differentiate between a "normal" object and an abstraction? i always considered abstractions to be equal to internals and externals. (they are not from an API point-of-view; but i think that this is a bug rather than a feature)
Distinguishing between externals and abstractions would be great since it would give you an at-a-glance understanding of what has "more inside". Sure externals and abstractions are capable of congruent behavior, but one cannot open an external, edit it and save it under a new name all within Pd. I'd see this feature as more of a "toggle-switch" rather than something I'd turn on or off permanently, though.
Speaking of the "more inside" concept: I strongly support subpatch differentiation, since personally I use subpatches primarily for patch organization rather than as impromptu abstractions, but you are already convinced : ).
It might be a good time to look at doing a "grammar" style identification of objects to choose their style; this would get a lot closer to syntax highlighting. It would be cool to see all iemmatrix objects, or all list processing objects highlighted in a different style. And this would of course solve the subpatch styling, since one could just look for "^pd .*".
And not to push my luck, but is it possible for the theme changes to live-update rather than only applying to new windows? I only ask because it would open some fun patch-UI hacks.
Cheers Luke
On Mon, 5 Nov 2007, Luke Iannini (pd) wrote:
Speaking of the "more inside" concept: I strongly support subpatch differentiation, since personally I use subpatches primarily for patch organization rather than as impromptu abstractions, but you are already convinced : ).
in jMax, subpatch boxes had a special look (the box was all teal instead of white with a teal outline), but abstraction instances looked just like any other kind of object. I think that there was a good reason for this.
It might be a good time to look at doing a "grammar" style identification of objects to choose their style; this would get a lot closer to syntax highlighting. It would be cool to see all iemmatrix objects, or all list processing objects highlighted in a different style. And this would of course solve the subpatch styling, since one could just look for "^pd .*".
I agree that there could be options for this. I don't think that distinguishing abstraction instances from other boxes should be done by default or encouraged, but it could deserve to be turned on temporarily on some occasions.
And not to push my luck, but is it possible for the theme changes to live-update rather than only applying to new windows? I only ask because it would open some fun patch-UI hacks.
it's possible, I've done it, but it does not extend to the choice of translation. If e.g. I open a patch in Japanese and I switch the language to Russian, the already existing windows would continue to be in Japanese, while the new ones will be in Russian. (at this point, I delay the loading of translations to the next run of pd, so that the program continues to be in one language. Updating every gui element is hard)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Nov 7, 2007, at 8:57 AM, Mathieu Bouchard wrote:
On Mon, 5 Nov 2007, Luke Iannini (pd) wrote:
Speaking of the "more inside" concept: I strongly support subpatch differentiation, since personally I use subpatches primarily for
patch organization rather than as impromptu abstractions, but you are
already convinced : ).in jMax, subpatch boxes had a special look (the box was all teal
instead of white with a teal outline), but abstraction instances
looked just like any other kind of object. I think that there was a
good reason for this.It might be a good time to look at doing a "grammar" style
identification of objects to choose their style; this would get a lot closer to syntax highlighting. It would be cool to see all iemmatrix objects, or
all list processing objects highlighted in a different style. And this
would of course solve the subpatch styling, since one could just look for
"^pd .*".I agree that there could be options for this. I don't think that
distinguishing abstraction instances from other boxes should be
done by default or encouraged, but it could deserve to be turned on
temporarily on some occasions.
I agree with this except for the fact that there should be some
visual marker that you can open an abstraction. So abstractions and
binary objects look the same, except abstractions have a little
marker to mark it as openable. This could then also apply to objects
written in scripting languages.
.hc
And not to push my luck, but is it possible for the theme changes
to live-update rather than only applying to new windows? I only
ask because it would open some fun patch-UI hacks.it's possible, I've done it, but it does not extend to the choice
of translation. If e.g. I open a patch in Japanese and I switch the
language to Russian, the already existing windows would continue to
be in Japanese, while the new ones will be in Russian. (at this
point, I delay the loading of translations to the next run of pd,
so that the program continues to be in one language. Updating every
gui element is hard)_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC
Canada_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I agree with this except for the fact that there should be some
visual marker that you can open an abstraction. So abstractions and
binary objects look the same, except abstractions have a little
marker to mark it as openable. This could then also apply to objects
written in scripting languages.
Lua objects aren't openable.
Frank Barknecht _ ______footils.org__
On Nov 5, 2007, at 10:45 AM, IOhannes m zmoelnig wrote:
Nicolas Montgermont wrote:
Hans-Christoph Steiner a écrit :
The file "theme_from_commandline" would just need to specify variables in tcl-syntax:
set theme_bgcolor grey set theme_bwidth 2 ...
One ideal feature would be to make a distinction between normal
objects and subpatch / abstraction, for example with a bolder font or heavier borderline.hmm, why do you want to differentiate between a "normal" object and an abstraction? i always considered abstractions to be equal to internals and
externals. (they are not from an API point-of-view; but i think that this is a
bug rather than a feature)I'm sure this is more difficult, but as a subpatch or an
abstraction is in itself more important than its text, it should be really useful...otoh, i understand that subpatches might be visually distinct from
objects.
Yeah, I think having subpatches visually distinct would definitely be
useful, since they are really a hidden chunk of the current patch
rather than an object.
Keep the ideas flowing and add them here so we have a record of them:
http://puredata.info/dev/GuiIdeas
.hc
If you are not part of the solution, you are part of the problem.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yeah, I think having subpatches visually distinct would definitely be
useful, since they are really a hidden chunk of the current patch
rather than an object.
Personally I wouldn't care. To me it's enough that they have a special name with "pd" and a funky argument. [pd THE_SCORE] is visually different enough to me, and often I don't care that a subpatch is a subpatch (e.g. in [pd count-to-10] or so).
[textfile] also is different from [osc~], but do they necessarily need to look different? And everywhere? When using data structures to just hold data, a subpatch is very similar to [textfile]. Should these two be similar then? If you enable GOP in your subpatch, it already can be made to look very different from other objects.
So in the end I think, making objects look different automatically is a hairy issue. Some more ways to make individual objetcs look different on a one-by-one base could be interesting, though.
Frank Barknecht _ ______footils.org__
On Nov 6, 2007, at 3:42 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Yeah, I think having subpatches visually distinct would definitely be useful, since they are really a hidden chunk of the current patch rather than an object.
Personally I wouldn't care. To me it's enough that they have a special name with "pd" and a funky argument. [pd THE_SCORE] is visually different enough to me, and often I don't care that a subpatch is a subpatch (e.g. in [pd count-to-10] or so).
[textfile] also is different from [osc~], but do they necessarily need to look different? And everywhere? When using data structures to just hold data, a subpatch is very similar to [textfile]. Should these two be similar then? If you enable GOP in your subpatch, it already can be made to look very different from other objects.
It's a visual language, so I think it's very important to find ways
of clearly representing things visually. black on white with 1px
boxes, doesn't say much. The ends of the message boxes and atom
boxes are nice, I think they work well.
So in the end I think, making objects look different automatically is a hairy issue. Some more ways to make individual objetcs look different on a one-by-one base could be interesting, though.
You can write GUI objects. I'd like to see a jMax [trigger] in Pd,
it's quite nice.
.hc
Ciao
Frank Barknecht _
______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
May I make one humble suggestion?
Is it possible to remove the GIANT 3 PIXEL BLACK BORDER around the
edges of a selected patcher window on OS X? Its highly distracting and
really ruins the improved aesthetic (and work) of the newer PD
extended nightlies.
Thank you,
On Tue, 2007-11-06 at 20:45 -0500, vade wrote:
May I make one humble suggestion?
Is it possible to remove the GIANT 3 PIXEL BLACK BORDER around the
edges of a selected patcher window on OS X? Its highly distracting and
really ruins the improved aesthetic (and work) of the newer PD
extended nightlies.
personally i would like to have also the 1px border in linux removed. there is already a border from the wm, i don't see a need for another one.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Nov 6, 2007, at 9:01 PM, Roman Haefeli wrote:
On Tue, 2007-11-06 at 20:45 -0500, vade wrote:
May I make one humble suggestion?
Is it possible to remove the GIANT 3 PIXEL BLACK BORDER around the edges of a selected patcher window on OS X? Its highly distracting
and really ruins the improved aesthetic (and work) of the newer PD extended nightlies.personally i would like to have also the 1px border in linux removed. there is already a border from the wm, i don't see a need for another one.
roman
Hmm, would be worth trying. I looked around quickly, it's not obvious
what is drawing it...
.hc
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
On Nov 6, 2007, at 11:54 PM, ilya .d wrote:
On Tue, Nov 06, 2007 at 09:34:46PM -0500, Hans-Christoph Steiner
wrote:Hmm, would be worth trying. I looked around quickly, it's not obvious what is drawing it...
.hc
not it is obvious actually, that's just form Tk.
I don't think Tk puts that border there since windoes in the Wish.app
don't have it.
.hc
-- ilya .d
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
and one other detail: in windows, everytime you open up a window
(subpatch, abstraction, whatever), the window opens up a tiny bit bigger
as before. I didn't notice it happening in linux. So after someone has
saved a very nicely proportioned and pretty patch with the windows just
the right size etc., after those windows have been open a few times the
proportions are messed up.
this is only a detail that many people don't notice, but in my "good"
patches I put some effort on the gui building, also making windows that
have the explanatory text, etc (look at jmmmp/gui-edit, for example). and
I guess that if someone if producing something pretty (specially for a
client or to be distributed) it can be a bother. not to speak that in a
limit case, the windows can go off screen.
On Nov 6, 2007, at 11:54 PM, ilya .d wrote:
On Tue, Nov 06, 2007 at 09:34:46PM -0500, Hans-Christoph Steiner wrote:
Hmm, would be worth trying. I looked around quickly, it's not obvious what is drawing it...
.hc
not it is obvious actually, that's just form Tk.
I don't think Tk puts that border there since windoes in the Wish.app don't have it.
The creeping window size problem exists in OS X as well. I posted about
it earlier this year under the thread "minor but persistent annoyances"
(see: http://lists.puredata.info/pipermail/pd-list/2007-02/047450.html ).
It's still persists, and it's still very annoying.
Phil Stone pkstonemusic.com
João Miguel Pais wrote:
and one other detail: in windows, everytime you open up a window
(subpatch, abstraction, whatever), the window opens up a tiny bit bigger
as before. I didn't notice it happening in linux. So after someone has
saved a very nicely proportioned and pretty patch with the windows just
the right size etc., after those windows have been open a few times the
proportions are messed up. this is only a detail that many people don't notice, but in my "good"
patches I put some effort on the gui building, also making windows that
have the explanatory text, etc (look at jmmmp/gui-edit, for example). and
I guess that if someone if producing something pretty (specially for a
client or to be distributed) it can be a bother. not to speak that in a
limit case, the windows can go off screen.On Nov 6, 2007, at 11:54 PM, ilya .d wrote:
On Tue, Nov 06, 2007 at 09:34:46PM -0500, Hans-Christoph Steiner wrote:
Hmm, would be worth trying. I looked around quickly, it's not obvious what is drawing it...
.hc
not it is obvious actually, that's just form Tk.
I don't think Tk puts that border there since windoes in the Wish.app don't have it.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If there isn't a bug report for this, please file one and I'll take a
look when I get a chance.
.hc
On Nov 7, 2007, at 6:51 AM, João Miguel Pais wrote:
and one other detail: in windows, everytime you open up a window
(subpatch, abstraction, whatever), the window opens up a tiny bit
bigger as before. I didn't notice it happening in linux. So after
someone has saved a very nicely proportioned and pretty patch with
the windows just the right size etc., after those windows have been
open a few times the proportions are messed up. this is only a detail that many people don't notice, but in my
"good" patches I put some effort on the gui building, also making
windows that have the explanatory text, etc (look at jmmmp/gui- edit, for example). and I guess that if someone if producing
something pretty (specially for a client or to be distributed) it
can be a bother. not to speak that in a limit case, the windows can
go off screen.On Nov 6, 2007, at 11:54 PM, ilya .d wrote:
On Tue, Nov 06, 2007 at 09:34:46PM -0500, Hans-Christoph Steiner wrote:
Hmm, would be worth trying. I looked around quickly, it's not
obvious what is drawing it....hc
not it is obvious actually, that's just form Tk.
I don't think Tk puts that border there since windoes in the Wish.app don't have it.
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
you can start searching in 2002. m.
Hans-Christoph Steiner wrote:
If there isn't a bug report for this, please file one and I'll take a
look when I get a chance..hc
On Nov 7, 2007, at 6:51 AM, João Miguel Pais wrote:
and one other detail: in windows, everytime you open up a window
(subpatch, abstraction, whatever), the window opens up a tiny bit
bigger as before. I didn't notice it happening in linux. So after
someone has saved a very nicely proportioned and pretty patch with
the windows just the right size etc., after those windows have been
open a few times the proportions are messed up. this is only a detail that many people don't notice, but in my
"good" patches I put some effort on the gui building, also making
windows that have the explanatory text, etc (look at jmmmp/gui- edit, for example). and I guess that if someone if producing
something pretty (specially for a client or to be distributed) it
can be a bother. not to speak that in a limit case, the windows can
go off screen.On Nov 6, 2007, at 11:54 PM, ilya .d wrote:
On Tue, Nov 06, 2007 at 09:34:46PM -0500, Hans-Christoph Steiner wrote:
Hmm, would be worth trying. I looked around quickly, it's not
obvious what is drawing it....hc
not it is obvious actually, that's just form Tk.
I don't think Tk puts that border there since windoes in the Wish.app don't have it.
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 07/11/2007, at 19.07, marius schebella wrote:
you can start searching in 2002.
Now i don't know if i repeat anyone from the past. I apologize
beforehand.
Hans-Christoph Steiner wrote:
If there isn't a bug report for this, please file one and I'll take a look when I get a chance.
Maybe we can keep it on list for a few bits more.
I made a patch to test the behavior. This is the test:
text editor or with 'head -1' or. 2) Open the attached patch. Click the [10( on one of the sides. 3) Note that the patch has grown to 504x304
Now the weird bit.
So it seams it grows 4px per run with a reload.
More weirdness. Or observations.
Now try the above but clicking the [100( on either side.
Note that it still only increases by 4px.
Close and reopen the patch.
Just save it as you normally would.
Note that only one save increases the size 4px.
Note that using either the [until] method or the [delay] method
doesn't make a difference.
On Nov 8, 2007, at 10:59 AM, Steffen Juul wrote:
On 07/11/2007, at 19.07, marius schebella wrote:
you can start searching in 2002.
Now i don't know if i repeat anyone from the past. I apologize
beforehand.Hans-Christoph Steiner wrote:
If there isn't a bug report for this, please file one and I'll
take a look when I get a chance.Maybe we can keep it on list for a few bits more.
I made a patch to test the behavior. This is the test:
- Note that the patch is 500x300 initially. Either by opening in a
text editor or with 'head -1' or. 2) Open the attached patch. Click the [10( on one of the sides. 3) Note that the patch has grown to 504x304
Now the weird bit.
- with out closing the patch, click the [10( again.
- Note that it has _not_ grown to 508x308.
- Close the patch
- Reopen the patch
- Click the [bang(
- Note that it has now grown to 508x308
So it seams it grows 4px per run with a reload.
More weirdness. Or observations.
Now try the above but clicking the [100( on either side.
Note that it still only increases by 4px.
Close and reopen the patch.
Just save it as you normally would.
Note that only one save increases the size 4px.
Note that using either the [until] method or the [delay] method
doesn't make a difference.
<grow.pd>
This is a very helpful illustration of the bug. I think that it's
probably happening when opening the patch. Could you add this info
to the bug tracker, I believe there is already a bug report for this
one, and I'll try to look at it tomororw.
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
On Nov 9, 2007 8:41 AM, Hans-Christoph Steiner hans@eds.org wrote:
On Nov 8, 2007, at 10:59 AM, Steffen Juul wrote:
Now i don't know if i repeat anyone from the past. I apologize beforehand.
So it seams it grows 4px per run with a reload.
This is a very helpful illustration of the bug. I think that it's probably happening when opening the patch. Could you add this info to the bug tracker, I believe there is already a bug report for this one, and I'll try to look at it tomororw.
I believe this is a very old bug, no? I had similar behavior for a long time with vanilla Pd on Windows and Mac. Haven't noticed it lately, though, so maybe that was fixed already. I'm also mostly using Linux now.
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
I think this is the single best quote in your sig collection, Hans.
-Chuckk
I believe this is a very old bug, no? I had similar behavior for a long time with vanilla Pd on Windows and Mac. Haven't noticed it lately,
though, so maybe that was fixed already. I'm also mostly using Linux now.
It's been always there, in both dists. but I noticed that it doesn't
happen in linux.
On Nov 9, 2007 1:33 PM, João Miguel Pais jmmmpais@googlemail.com wrote:
I believe this is a very old bug, no? I had similar behavior for a long time with vanilla Pd on Windows and Mac. Haven't noticed it lately, though, so maybe that was fixed already. I'm also mostly using Linux now.
It's been always there, in both dists. but I noticed that it doesn't happen in linux.
Methinks that hints at a perfect solution.
-Chuckk
On 09/11/2007, at 7.41, Hans-Christoph Steiner wrote:
This is a very helpful illustration of the bug. I think that it's
probably happening when opening the patch.
That sounds reasonable. Maybe your new cursor position object can
help answer that question.
Could you add this info to the bug tracker, I believe there is
already a bug report for this one, and I'll try to look at it
tomororw.
I submitted a new report, since i couldn't find a matching report
already (despite people claims it's been there for ages).
On 9 Nov 2007, at 2:59 AM, Steffen Juul wrote:
I made a patch to test the behavior. This is the test:
- Note that the patch is 500x300 initially. Either by opening in a
text editor or with 'head -1' or. 2) Open the attached patch. Click the [10( on one of the sides. 3) Note that the patch has grown to 504x304
Now the weird bit.
- with out closing the patch, click the [10( again.
- Note that it has _not_ grown to 508x308.
- Close the patch
- Reopen the patch
- Click the [bang(
- Note that it has now grown to 508x308
So it seams it grows 4px per run with a reload.
This growing on each save/open cycle seems to have changed in the
latest autobuilds:
Pd-0.40.3-extended-20071109 for PPC (on OSX 10.4.8)
Now I get a 2 pixel SHRINKING of the window on each of these cycles,
and the part of the patch shown when the window opens isn't exactly
the top left part anymore.
IIRC the 3 pixel border around the active window has just been
removed - that could account for the 6 pixel difference in the
shrinkage/growth ... maybe if the border was made 1 pixel the size of
the window would be stable????
Playing around and testing it seems something (possibly in the new
visuals) is slowwwing down displaying/opening patches
problems resizing, with much lower CPU usage, in autobuild Pd-0.40.2-
extended-2007-05-01 on the same system) which will have consequences
(dropouts etc) and is extremely noticeable on my ageing powerbook
the time (when only a small part of a big patch is showing the
problem is less). Large patches take an age to open.
The new visuals are nice - I'll find out soon how much it helps my
problems swapping patches with intricate layouts and GOP between mac,
linux and windows (certainly old patches for mac layout cleanly, no
overlaps etc). The live update for the font bomb is great.
Thanks for all the hard work, especially the documentation ... lots
of nice touches ... the improved help menu works well, the web
references will great for newcomers finding their way around and make
the locations for web documentation more consistent (are there local
settings needed for the IRC item to work?) ... now midi and Gem
help work properly! ... the [pddplink] GUI deserves a place in the
'put' menu! (I guess its been around for a while but I've only just
noticed it) ... the 'text window' checkbox is good - does it save
cpu if it is off, eg does it mean [print] uses less cpu? ... the
cursor changing in click-able areas is nice, and I'm sure I'll find a
use for [cursor] in setting up nicer user interfaces.
simon
On Nov 6, 2007, at 9:01 PM, Roman Haefeli wrote:
On Tue, 2007-11-06 at 20:45 -0500, vade wrote:
May I make one humble suggestion?
Is it possible to remove the GIANT 3 PIXEL BLACK BORDER around the edges of a selected patcher window on OS X? Its highly distracting
and really ruins the improved aesthetic (and work) of the newer PD extended nightlies.personally i would like to have also the 1px border in linux removed. there is already a border from the wm, i don't see a need for another one.
I think that is a good idea. It turns out that it seems be a default
in Tk, but you can turn it off. So I did... and figured out how to
can mess with it for each patch:
http://eds.org/~hans/pdsketch/bordermadness.png
.hc
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
On Nov 4, 2007, at 6:03 AM, Frank Barknecht wrote:
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
Almost all visual improvements are going to be subjective. That is to say, for every suggestion someone makes along the lines of visual changes to Pd, there will be many people for the change and many
people against. For that reason, please put in the time to make all changes configurable, so that those who like the current look of Pd can
easily put in command line flags or .pdrc settings to make it looks the
way it does now. Ideally this would be something like "-originalgui". As for the default look, that could be decided by majority vote I guess.I very much support that approach. What looks good or is helpful is a very personal decision. We already had a heated discussion about which fonts to choose and I'd rather not repeat this for every other aspect of Pd, this would be counter-productive and bind too many resources better wasted elsewhere. ;)
The only way a GUI overhaul can work in the long run IMO is to make a configuration system. This actually probably should not be a command line flag like "-originalgui" or "-newgui", but a new configuration file for themes that can be loaded with "-theme" or so. This is the approach that works for most other applications as well (Firefox, Gtk, etc.) All that Pd would need to supply is some hooks for setting various things like colors for canvas-BG, thickness of signal/msg-cords, (or even fonts, though this may be tricky) etc. Then the config file would just list the values for these variables, maybe in simple Tcl-syntax (no XML!). But please don't enforce huge GUI choices on all users.
I'll add -vanillagui to set the old colors. Plus I am working on a
hack so you'll be able to set those colors from within Pd.
Pd is sorely in need of a good preferences API, then this could
easily be added to that... any volunteers? :D
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I'll add -vanillagui to set the old colors.
As I wrote in my mail, I don't think using command line options in this fashion is a good idea. It's not maintainable. It forces people to choose either A or B, when they actually want 1.2635 or 9.3463
Frank Barknecht _ ______footils.org__
The gui has to be a mixture of both, 1) providing style options for programmers who want to make use of it and 2) the possibility to view patches also in old "text-only" black and white style for users that are distracted by too much new technology and design. I think it is similar to web browsing. If you don't want style-sheets you always can use lynx. For Pd to finally become a tool that can be used to create instruments that will be shared, I see no other possibilty than to go with some enhancements. I don't see any movement from Miller into that direction (to conjure up style features), I simply think, there is no possibilty to get additional style information into patches. that given, the "enhancements" are limited anyway. Maybe someone has to come up with an alternative objectbox-style that provides all the style settings. (like number2 or comment from cyclone). or maybe it is possible to create a wrapper object that does the same like any objectclass itself, but with additional layout-information. But, who is willing and able to do the work? ... So all that talk is going 'poof'. You want to create a patch to share? Use something different for the interface and run pd -nogui. marius.
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I'll add -vanillagui to set the old colors.
As I wrote in my mail, I don't think using command line options in this fashion is a good idea. It's not maintainable. It forces people to choose either A or B, when they actually want 1.2635 or 9.3463
Ciao
On Sun, 2007-11-04 at 13:36 -0500, marius schebella wrote:
The gui has to be a mixture of both,
"bamm.. here i am and i know _exactly_, what needs to be done... "
i like your diplomatic way ;-)
- providing style options for
programmers who want to make use of it and 2) the possibility to view patches also in old "text-only" black and white style for users that are distracted by too much new technology and design. I think it is similar to web browsing. If you don't want style-sheets you always can use lynx. For Pd to finally become a tool that can be used to create instruments that will be shared, I see no other possibilty than to go with some enhancements. I don't see any movement from Miller into that direction (to conjure up style features), I simply think, there is no possibilty to get additional style information into patches. that given, the "enhancements" are limited anyway. Maybe someone has to come up with an alternative objectbox-style that provides all the style settings. (like number2 or comment from cyclone). or maybe it is possible to create a wrapper object that does the same like any objectclass itself, but with additional layout-information. But, who is willing and able to do the work? ... So all that talk is going 'poof'. You want to create a patch to share?
now you are changing the topic. as far as i understood, hc initial efforts were going into finding ways to improve pd's appearance from a programmers perspective. the ideas wasn't to change the appearance for fancy guis for fancy patches.
Use something different for the interface and run pd -nogui.
here i think you are _very_ wrong by saying this. have you ever used datastructures? have you ever had a look at netpd? especially at syntax_the_nerd's bon-* patches? have you ever had a look at the gop abstractions of pdmtl? not to mentionen all the stuff that i forgot to list here?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
On Sun, 2007-11-04 at 13:36 -0500, marius schebella wrote:
The gui has to be a mixture of both,
"bamm.. here i am and i know _exactly_, what needs to be done... " i like your diplomatic way ;-)
you think I am diplomatic? I take that as a compliment...
Use something different for the interface and run pd -nogui.
here i think you are _very_ wrong by saying this. have you ever used datastructures? have you ever had a look at netpd? especially at syntax_the_nerd's bon-* patches? have you ever had a look at the gop abstractions of pdmtl? not to mentionen all the stuff that i forgot to list here?
I think it is amazing how much you and pdmtl are able to get out of pd, but (and sorry I don't know how to put this diplomaticly) I think these interfaces are at least 2 generations away from what a good interface could look like. hey, I love pd, and I will do my best to work on all that stuff that I am permanently complaining about. but think! - and don't get me wrong, because I know that your work is not recognized and valued enough - given the hours that you put into netpd and given the accessability of Pd in general I would assume this application to be about 1000 times more successful. And the reason why it is not, is, I think the lack of a better interface. I am talking about at least 1000 kids permanently using it, making music with their friends.
I think I lose my diplomacy, because I am angry when I see the waste of time that people put into patching using an unsatisfying software and not having the success they should have.
best, marius.
On Sun, Nov 04, 2007 at 03:25:38PM -0500, marius schebella wrote:
but think! - and don't get me wrong, because I know that your work is not recognized and valued enough - given the hours that you put into netpd and given the accessability of Pd in general I would assume this application to be about 1000 times more successful. And the reason why it is not, is, I think the lack of a better interface. I am talking about at least 1000 kids permanently using it, making music with their friends.
I think I lose my diplomacy, because I am angry when I see the waste of time that people put into patching using an unsatisfying software and not having the success they should have.
i can understand what do you guys have a trouble with ?
do you think things like .. some basic easy-to-use apps are good examples? which application do you find closer to ideal by it's user interface?
best, marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 2007-11-04 at 15:25 -0500, marius schebella wrote:
I think it is amazing how much you and pdmtl are able to get out of pd, but (and sorry I don't know how to put this diplomaticly) I think these interfaces are at least 2 generations away from what a good interface could look like.
though i basically agree with you, i am not quite sure, what needs to be done to change that. what makes a interface a good interface? are you talking only about the appearance? or also about the functionality?
hey, I love pd, and I will do my best to work on all that stuff that I am permanently complaining about. but think! - and don't get me wrong, because I know that your work is not recognized and valued enough -
you said that, not me... (i don't feel like my work should be valued 'more'. though, of course, i am happy seeing people using my stuff)
given the hours that you put into netpd
and, more important, all the people who contributed with patches and hours of testing....
and given the accessability of Pd in general
just because it is free doesn't automatically mean that it is accessible to everyone. i would even say, that pd in general is one of the lesser accessible softwares i know (probably just because it is such an interesting and versatile software)
I would assume this application to be about 1000 times more successful. And the reason why it is not, is, I think the lack of a better interface. I am talking about at least 1000 kids permanently using it, making music with their friends.
maybe you are right, maybe not. i am not sure about this. however, this is not the point of the discussion. the initial discussion was only about changing the appearance of pd in order make patches more readable, not about having more and fancier guis for - i call them now - 'end product' patches. but i totally agree with you, that in this area of the 'end product' patches a _lot_ could still be achieved.
I think I lose my diplomacy, because I am angry when I see the waste of time that people put into patching using an unsatisfying software and not having the success they should have.
i totally agree.
cheers roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, marius schebella hat gesagt: // marius schebella wrote:
The gui has to be a mixture of both, 1) providing style options for programmers who want to make use of it and 2) the possibility to view patches also in old "text-only" black and white style for users that are distracted by too much new technology and design. I think it is similar to web browsing. If you don't want style-sheets you always can use lynx. For Pd to finally become a tool that can be used to create instruments that will be shared, I see no other possibilty than to go with some enhancements. I don't see any movement from Miller into that direction (to conjure up style features), I simply think, there is no possibilty to get additional style information into patches. that given, the "enhancements" are limited anyway. Maybe someone has to come up with an alternative objectbox-style that provides all the style settings. (like number2 or comment from cyclone). or maybe it is possible to create a wrapper object that does the same like any objectclass itself, but with additional layout-information. But, who is willing and able to do the work? ... So all that talk is going 'poof'. You want to create a patch to share? Use something different for the interface and run pd -nogui.
Maybe I'm missing something fundamental but I don't see how what you just wrote is related to my previous mail where I wrote:
As I wrote in my mail, I don't think using command line options in this fashion is a good idea. It's not maintainable. It forces people to choose either A or B, when they actually want 1.2635 or 9.3463
If you read this: I only proposed to not hardcode enhancements, but leave room for more enhancements by managing the enhancements in a more flexible way (which isn't even a very advanced way. For an advanced way see DesireData.)
Frank Barknecht _ ______footils.org__
Hi, I did not disagree with you. I just wanted to add some thoughts. let me explain again. one of the thoughts is, that I think there is a difference between the "programmer" (the one that writes a patch) and the "user". these two types need different features of gui improvement. the programmer wants to work in a nice environment, where she can set colors and fontsizes of the workspace. but to create better user interfaces she maybe wants to have the possibility to hide cords, color specific objects, make them bigger. the one style (for the workspace) only needs to be set once. but the style for a specific patch may change from patch to patch (according to how the programmer wants the patch to look like. and still, there probably should be the possibility to override another programmers layout with your own -nofancyfirlefanz setting... marius.
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
The gui has to be a mixture of both, 1) providing style options for programmers who want to make use of it and 2) the possibility to view patches also in old "text-only" black and white style for users that are distracted by too much new technology and design. I think it is similar to web browsing. If you don't want style-sheets you always can use lynx. For Pd to finally become a tool that can be used to create instruments that will be shared, I see no other possibilty than to go with some enhancements. I don't see any movement from Miller into that direction (to conjure up style features), I simply think, there is no possibilty to get additional style information into patches. that given, the "enhancements" are limited anyway. Maybe someone has to come up with an alternative objectbox-style that provides all the style settings. (like number2 or comment from cyclone). or maybe it is possible to create a wrapper object that does the same like any objectclass itself, but with additional layout-information. But, who is willing and able to do the work? ... So all that talk is going 'poof'. You want to create a patch to share? Use something different for the interface and run pd -nogui.
Maybe I'm missing something fundamental but I don't see how what you just wrote is related to my previous mail where I wrote:
As I wrote in my mail, I don't think using command line options in this fashion is a good idea. It's not maintainable. It forces people to choose either A or B, when they actually want 1.2635 or 9.3463
If you read this: I only proposed to not hardcode enhancements, but leave room for more enhancements by managing the enhancements in a more flexible way (which isn't even a very advanced way. For an advanced way see DesireData.)
Ciao
Hallo, marius schebella hat gesagt: // marius schebella wrote:
one of the thoughts is, that I think there is a difference between the "programmer" (the one that writes a patch) and the "user". these two types need different features of gui improvement. the programmer wants to work in a nice environment, where she can set colors and fontsizes of the workspace. but to create better user interfaces she maybe wants to have the possibility to hide cords, color specific objects, make them bigger. the one style (for the workspace) only needs to be set once. but the style for a specific patch may change from patch to patch (according to how the programmer wants the patch to look like. and still, there probably should be the possibility to override another programmers layout with your own -nofancyfirlefanz setting...
I like that option name! ;)
Thanks for clarifying, I think, our opions are quite close.
Frank Barknecht _ ______footils.org__
Hi, there is no macintel autobuild from today. marius.
Hans-Christoph Steiner wrote:
On Nov 3, 2007, at 7:28 PM, Jamie Bullock wrote:
On Sat, 2007-11-03 at 14:24 -0400, Hans-Christoph Steiner wrote:
I think there is a lot that could be done to the look and feel of Pd that would make it much more efficient and usable. I think it is crucial to avoid flashiness, one of Pd's strengths is its lack of flashiness (no segmented patch cords! ;) But small things can make a big difference.
I really like some of these ideas, and I do agree that a few subtle visual nuances would bring Pd's UI into the 21st century! I always thought that om/ingen (http://wiki.drobilla.net/Ingen) had a a really nice UI - just the right combination of minimalist simplicity and graphical niceness (anti-aliased splines!). Maybe we can steal some ideas from that.
Can I put a vote in for _not_ putting arrows on the end of patch
chords. This is one of the features of Desire Data that I really don't like since it adds no additional information to the patch (it isn't
possible to connect from inlets to outlets), and it adds visual noise.Jamie
-- www.postlude.co.uk
I'm going to try to get a version of this into the Pd-extended auto- build for tonight:
http://eds.org/~hans/pdsketch/solidboxes+color.png
I'll made the colors settable in the pd.tk so people can make it look
the "old way" without too much trouble. Perhaps it could be a
command line flag, something like: -orthodox ;).hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list