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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
er, sorry, forgot to cc list
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
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
On Nov 5, 2007, at 12:46 PM, Luke Iannini (pd) wrote:
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
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
Hi, this is not necesserarily more readable with it, but how one can
change font color in a patch?
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
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
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
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
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 (
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
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
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-list@iem.at mailing list
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
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 ;-)
1) providing style options for
programmers who want to make use of it and 2) the possibility to
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
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
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
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
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
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.
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
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
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
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
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
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? :}
_ _ __ ___ _ _
Hans-Christoph Steiner a écrit :
I added variables in pd.tk so you can edit that if you want to make
your own theme.
.hc
hi, is there a way for having a different font color?
I'd like to patch with a black background and white fonts.
___
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.
.hc
hi, is there a way for having a different font color?
I'd like to patch with a black background and white fonts.
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.
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:
1) 1px border looks better. 2px or more looks like drawn with a clumsy
pencil
2)
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
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
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
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
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
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
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
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
57 matches
Mail list logo
