changed:
-
15:42 < _hc> meetings longer than an hour are rarely productive, IMHO

15:42 < chun> ping:)

15:43 < dmotd> _hc, hello, what is the current status of the new devel branch?

15:43 < _hc> dmotd: hey

15:43 < _hc> dmotd: its done! :D

15:43 < dmotd> _hc, no need for a meeting the eh! ;)

15:44 < dmotd> _hc, s/the/then

15:44 < _hc> its a announcement party 

15:44 < dmotd> _hc, great! i love a text based party

15:44 < _hc> try it and you'll see the current state, it works, but it needs to be flushed out

15:44 < dmotd> _hc, saves me from humiliating myself in person

15:44 < _hc> its all Tcl, that's the good news

15:44 < IOhannes> hi chun 

15:45 < _hc> hey chun

15:45 < chun> IOhannes: hi there

15:45 < chun> _hc: hey

15:46 < dmotd> _hc, so it is presently feature wise identical to 0.41.4?

15:46 < dmotd> hi chun

15:46 < _hc> the 'pd' side is just 0.41.4

15:46 < _hc> the 'pd-gui' is all new

15:46 < _hc> and not done

15:46 < chun> dmotd: hi

15:47 < matju> IOhannes: Sylvain Cormier of SAT (who once wrote on gem-dev...) told me that they have gstreamer for some things. I'm not sure how they connected pd and gstreamer (whether it's direct or not...). You could ask him in case it helps you.

15:47 < chun> is there a agenda/topics to this meeting?

15:47 < dmotd> _hc, explain 'not done'?

15:48 < _hc> no pd window, "send message" panel, pref panes

15:48 < _hc> things like that

15:48 < _hc> some glitchiness in the key bindings

15:48 < _hc> dmotd: just try it and see, its not hard to build

15:48 < dmotd> _hc, okay.. sorry.. i'm running an in the background update while i'm chatting.. 

15:48 < _hc> easier than pd proper since it has no tk.h dependency

15:48 -!- vado-desktop (n=willy@212-198-207-217.rev.numericable.fr) has quit ("Leaving")

15:49 < dmotd> _hc, err.. and update sorry.. 

15:49 < _hc> dmotd: then you can tell me if I broke the build and I can fix it :)

15:50 < dmotd> _hc, is it still best to launch with 'wish pd.tk' ?

15:50  * chun update and build too

15:50 < _hc> chun: IOhannes: and anyone else: did you get a chance to run pd-devel?

15:50 < IOhannes> i'm just checking it out on this machine

15:50 < IOhannes> currently i am at: ./configure

15:51 < chun> _hc: i did, on and off in the last few weeks or so

15:51 < IOhannes> so it seems it's going to be a build party....

15:51 < _hc> well, hopefully that's only 5 minutes...

15:51 < IOhannes> _hc, i did not try again after my initial failure

15:51 < _hc> "it works on my machine" ;)

15:52 < chun> it seems to work here:)

15:52  * IOhannes grumbles: eee is so slow....

15:52 < dmotd> _hc, okay.. yes working.. but i am receiving a chain of 'pdtk_canvas_getscroll .xdXXXXX', on start and whenever i reposition the canvas

15:52 < chun> i mean, it works here, though i am still getting pd printing all the avaiable options on start up

15:52 < chun> same here

15:53 < dmotd> _hc, i'm guessing that's a hack to remove scrollbars when they are unnecessary?

15:54 < dmotd> _hc, although there are none present regardless of the size and contents of the canvas.. 

15:55 < dmotd> _hc, anyhow.. i doubt you wish th. is to be a debug meeting.. sorry.

15:55 < IOhannes> uninspiringly, i get the scroll-message too

15:55 < chun> hehe

15:55 < IOhannes> and i also get: invalid command name "pdtk_pd_dio"

15:56 < chun> _hc: re my option print error, i got "error parsing RC arguments"

15:56 < IOhannes> not surprisingly if there is no real main window

15:57 < dmotd> ooh an update, build and debug party.. it gets more exciting by the minute!

15:57 < chun> but anyhow, i guess we can talk about these error stuff on the list or soemthing, if there are other things to talk about now

15:57 < dmotd> chun, yes agreed.. 

15:57 < dmotd> so is there an agenda of some description?

15:58 < chun> dmotd: though what's your exciting update?;)

15:59 < chun> isn't code formatting/indentation/organisation mentioned on the list for the meeting?

16:00 < dmotd> chun, you are quite knowledgable in tk right?

16:00  * IOhannes wonders whether the code formatting part is meant to be the excitement?

16:01 < chun> dmotd: well, i wouldn't say that, but i did use a quite a lot of it when i was working on desiredata

16:01 < chun> dmotd: then bear in mind that the tk code in desiredata are not really like tck/tk code..

16:02 < chun> anyways, i can find my ways in it, given time;)

16:02 < dmotd> chun, ya.. i gathered that.. did you come across any tk extensions that simulated alpha or polygon overlay?

16:03 < chun> simulated alpha as in?

16:04 < dmotd> chun, as in semi-transparent fill for polygons?

16:04 -!- hans_ (n=hanschri@NYUFGA-WLESSAUTHCLIENTS-01.NATPOOL.NYU.EDU) has joined #dataflow

16:05 < chun> dmotd: i was looking at things like tkzinc towards the end of time when i was working on dd

16:05 < chun> and some tcl gtk binding stuff

16:05 < hans_> back...

16:05 < hans_> arg... I guess NYU only allows GNU/Linux machines to stay on the wifi for 15 mintues.... it wouldn't let me back on, so I had to reboot to Mac OS X.....

16:06 < hans_> the wifi security here is ridicullous, I think their idea is that if you can use the wifi, then their network will be secure

16:06 < chun> but i think they are a bit too adventuruous for pd-devel, no?

16:06 < hans_> chun: tkzinc?

16:06 < hans_> has anyone tried it?

16:06 < chun> i think i was looking at something else too, but i can't remember

16:07 < chun> hans_: i did, briefly for dd

16:07 < dmotd> chun, okay.. thanks.. that was basically where i ended up too.. 

16:07 < chun> dmotd: yep

16:07 < hans_> arg, now my _hc nick is claimed... how do I boot the old one?

16:08 < hans_> chun: and was it worth using?

16:08 -!- _hc (n=hans@NYUFGA-WLESSAUTHCLIENTS-01.NATPOOL.NYU.EDU) has quit (Read error: 110 (Connection timed out))

16:08 -!- hans_ is now known as _hc

16:09 < _hc> yee haw

16:09 < chun> hans_: mm, not sure, i don't remember it being much faster then the normal tk canvas at the time

16:09 < _hc> oh, well then, yeah, not really worth it.  I was thinking that it would be useful to make a tkzinc canvas object for Pd

16:09 < _hc> but I am not sure about using it as the basis for everything

16:10 < dmotd> chroos, isn't tkzinc potentially optimized for hardware acceleration?

16:10 < dmotd> sorry.. should be for chun

16:10 < chun> i think it would only be worth trying *after* pd-devel is more complete 

16:10 < _hc> so chun , IOhannes , etc. did pd-devel run for you?

16:11 < chun> _hc: hehe, you missed our debug report , it seems

16:11 < dmotd> chun, and it has some internal GL routines, no?

16:11 < chun> _hc: yeah, it runs here, but i got "error parsing RC arguments"

16:12 < chun> dmotd: yeah, i think so, that's why i tried it at the first place, but somehow it was not much faster, but maybe it has changed now

16:12 < dmotd> _hc, canvas_getscroll messages + no scroll bars

16:12 < chun> i remember that tk canvas became quite a lot faster in 8.5, comparing to 8.4

16:12 < chun> on linux ,atleast

16:12 < _hc> chun: hmm, error parsing RC arguments...

16:13 < _hc> chun: could you post the transcript of the load

16:13 < chun> dmotd: i think there was soemthing else that i treid, involving cairo, but i can't remmeber what it was now

16:13 < chun> maybe matju remembers it still

16:14 < dmotd> chun, the exciting thing about tkzink compared to regular tk canvas, is that there is at least *some* development for the canvas that doesn't just include bug-fixes.. 

16:15 < chun> _hc: http://pastebin.ca/1336165

16:15 < dmotd> chun, yes.. i actually asked about cairo earlier.. it seems that the best gtk is the best at implementing and interacting with cairo?

16:16 < _hc> dmotd: I think a tkzinc object could be like an accelerated data structures, or like Max's LCD

16:16 < matju> chun: i don't remember you trying cairo... did you really? thought you had tried something else, or perhaps that we only looked into possibilities without going any further than the tkzinc delegator thingie.

16:16 < dmotd> chun, and sdl may have decent performance with cairo.. 

16:16 -!- msp (n=msp@netblock-68-183-177-246.dslextreme.com) has joined #dataflow

16:16 -!- slv (n=potatofa@pool-96-237-2-165.bstnma.east.verizon.net) has joined #dataflow

16:17 < chun> matju: i didn't tried cairo, but i rmrmber we were talking over a few possiblities, and one of them involves it

16:17 < dmotd> _hc, well it certainly improves what is feasible with DS et al.. 

16:17 < _hc> dmotd: canvas_getscroll is not implemented yet, neither are scrollbars

16:17 < _hc> they are up for grabs, if anyone wanst to take them on ;)

16:17 < dmotd> msp, slv, hello

16:17 < _hc> hey msp slv 

16:18 < msp> hi all

16:18 < chun> hi

16:18 < slv> hi dmotd msp chun _hc

16:18 < dmotd> _hc, do you have a task list published anywhere?

16:18 < IOhannes> hi miller

16:18 < _hc> 0.41.4/devel_docs/TODO

16:18 < chun> dmotd: its in the TODO file

16:18 < chun> yep

16:18 < matju> chun: well i remember distinctly the tkzinc one because we got involved significantly into it, making a fake tk-canvas that fwded messages to tkzinc when they were compatible and rewrote the messages when tkzinc wasn't compatible enough with dd.

16:19 < dmotd> _hc, chun, thanks.. easy.. 

16:19 < _hc> chun: hmm, so I am a bit crippled to test this  running in Mac OS X...  but I haven't seen that on Ubuntu either.  Try loading it like this:

16:19 < matju> dmotd: tkzinc uses GL, and yes, that usually means that it's slow without specialised hardware for it.

16:19 < chun> matju: yep, that's why i rememberd it

16:19 < _hc> wish path/to/bin/pd.tk

16:19 -!- slv (n=potatofa@pool-96-237-2-165.bstnma.east.verizon.net) has quit (Read error: 104 (Connection reset by peer))

16:20 < matju> chun: but in the end, tkzinc was more trouble... but was there any other reason why we didn't push forward? was it significantly faster than tkcanvas on your computer?

16:20 < dmotd> matju, ya.. that seems to be consistent with what i've read.. 

16:21 -!- slv (n=potatofa@pool-96-237-2-165.bstnma.east.verizon.net) has joined #dataflow

16:21 < chun> matju: i think i stoped because it was much faster, if at all

16:21 < chun> oops

16:21 < chun> i mean was not

16:22 < chun> darn, i have a bit of lag here

16:22 < IOhannes> do basically the tkcanvas is not that bad, and could be still used(?)

16:22 < IOhannes> s/^do/so,/

16:22 < dmotd> chroos, matju, but faster is not really the point of tkzinc? it is what it does that a regular canvas doesn't?

16:22 < chun> IOhannes: yeah, i guess, unfortunately;)

16:23 < chun> dmotd: you are right about that, but our motivation was to look for something faster to start with

16:23 < _hc> wow, this is quite an error: Error: Font family "Courier" not found, using default: Courier

16:23 < matju> IOhannes: no, tkcanvas is that bad, but tkzinc is also somewhat bad. it's all quite negative, i know.

16:24 < _hc> the tkcanvas is bad at doing things it wasn't designed to

16:24 < dmotd> IOhannes, the only thing i am struggling with in a normal tkcanvas is alpha transparency.. this is not a problem for day to day use, but I think the logic of data structures suffers without some form of layering.. 

16:24 < chun> _hc: heh

16:24 < _hc> I don't think it was meant to be that fast....

16:24 < matju> IOhannes: i think that rather than using tkzinc, time would be better spent in hacking tkcanvas' code; but some other possibilities might be even more worth it, just don't know which.

16:24 < _hc> chun: so where are you running ./pd from?  on Ubuntu/Intrepid I don't get that error

16:25 < chun> _hc: debian testing

16:25 < _hc> chun: I mean which dir

16:25 < chun> bin

16:25 < dmotd> _hc, same 'Courier' error on ubuntu/hardy

16:25 < chun> and wish pd.tk

16:26 < matju> dmotd: oh, if you want transparency, then tkzinc suddenly makes a lot more sense.

16:26 < _hc> chun: do you have a .pdrc or .pdsettings?

16:26 < dmotd> matju, yes, and i think this makes more sense when using pd as a compositional/sequencing tool.. 

16:26 < _hc> FYI: tkzinc couldn't replace tkcanvas because it doesn't work on Mac OS X

16:27 < chun> _hc: i have .pdrc and no .pdsettings

16:27 < matju> _hc: is the Courier error because of some silly Adobe1-fonts vs TTF-fonts thing? two different font namespaces...

16:27 < _hc> matju: donno

16:27 < matju> _hc: i don't think it would be far away from working on OSX... do you think much is missing?

16:27 < _hc> its a known issue, sometimes tk doesn't find Courier

16:27 < _hc> that goes way bback

16:27 < _hc> matju: no idea, it just says its not supported

16:28 < IOhannes> it says the same for me, but it falls back to (tada:) "Courier"  and works

16:28 < matju> _hc: could you get it to compile and run on OSX while running AppleX11 ?

16:28 < _hc> yes, that works now

16:29 < _hc> but that is not a solution

16:29 < _hc> for mac os x

16:29 < _hc> I don't know about tkzinc tho, if that's what you mean

16:30 < matju> _hc: yeah, well, it's a lot better if it integrates with the rest of the GUI... and for example, another issue in picking a new canvas is whether you can put it in the same window as some Tk thing.

16:32 < _hc> chun: I missed this, does pd-devel run for you?

16:32 < chun> _hc: oui

16:32 < _hc> ah, ok

16:32 < chun> brb, making tea

16:32 -!- tim (n=tim@85-127-156-37.dynamic.xdsl-line.inode.at) has joined #dataflow

16:32 < _hc> I am assuming that's a yes.  I have no idea what's causing the "flags" screen to appear

16:33 < _hc> msp IOhannes: did you get pd-devel running?

16:33 < msp> _hc: just trying to compile it now.

16:34 < chun> _hc: yes, it runs

16:34 < _hc> in all its incomplete glory :D

16:35 < IOhannes> yes

16:36 < dmotd> _hc, "October 26 2006: Here is the new Tkzinc 3.3.4 version. It features a native port to Mac OS X,  that is, you do not need a X11 server running anymore. That said, the port is not complete. " - from tkzinc wiki.. 

16:36 < dmotd> _hc, my last mac died, so I can't test current status.. 

16:37 -!- baali (n=baali@117.96.117.118) has joined #dataflow

16:40 < dmotd> _hc, anyhow, I am quite prepared to do some research, i wouldn't suggest it as a replacement but perhaps as an optional canvas extension.. 

16:42 < dmotd> matju, was mescalinum talking about tkzinc recently? i'm sure i saw this come up at some point..

16:42 < _hc> dmotd: that would be great, I think it would be useful even if it only worked on GNU/Linux

16:42 < _hc> I think he mentioned it

16:43 < matju> dmotd: huh, not sure...

16:44 < dmotd> _hc, regardless.. it's there, and really the basic canvas support works, it is just a little restrictive in its approach (and what people expect from a graphics toolkit these days)

16:44 < IOhannes> hmm, actually i don't want to spoil the party; but i personally think that any discussion about tkzinc is a bit premature

16:44 < matju> dmotd: i think that if you aim for anything else than a canvas replacement it'll eventually have been more work for much less results.

16:45 -!- wip (n=pat@65.95.81.166) has joined #dataflow

16:45 < wip> morning!

16:45 < matju> wip wip wip, hourra!

16:45 < chun> wip: hey:)

16:45 < IOhannes> hi wip

16:45 < wip> oh it's the devel meeting right?

16:45 < dmotd> IOhannes, yes, quite true.. this is more at the forefront of my mind.. 

16:45 < IOhannes> i would like to see: Pd running as it is with a cleaned up tk-side of things

16:45 < matju> wip: well, not really "devil", just wiccan...

16:46 < IOhannes> (pd-devel seems to be almost there)

16:46 < dmotd> IOhannes, agreed.. 

16:46 < IOhannes> then i would like to see all the tcl/tk code vanish from any .c file

16:46 < dmotd> hi wip 

16:46 < IOhannes> (which might take another meeting :-))

16:46 < matju> IOhannes: oh, it can take a lifetime too.

16:46 < chun> hehe

16:47 < IOhannes> but let's first concentrate on the issues that keep pd-devel from finishing it's current task

16:47 < dmotd> IOhannes, which are in your opinion?

16:48 < IOhannes> i don't know, i haven't read the source luke yet

16:48 < matju> IOhannes: but do you just want to move the tcl code out of the c files, or also move out all C logic that is tightly bound to the tcl/tk code?

16:48 < IOhannes> so hans is probably in charge here

16:48 < IOhannes> matju, this depends on what you mean by "tightly"

16:48 < IOhannes> personally i have no problems with keystrokes being sent from gui to pd and back again

16:49 < IOhannes> i  have a problem with pd telling the gui to "draw a line from x0,y0 to x0,y1,.."

16:49 -!- slv (n=potatofa@pool-96-237-2-165.bstnma.east.verizon.net) has quit (Read error: 113 (No route to host))

16:49 < IOhannes> in order to draw an object box

16:49 < _hc> hehe

16:49 < dmotd> matju, can that same logic be easily repaced with tcl logic?

16:49 < matju> IOhannes: ok, and how do you explain to yourself why one is a problem and the other is not a problem?

16:50 < _hc> so I guess to follow up on what IOhannes started, do people think it makes sense to approach this in steps?

16:50 < IOhannes> it really should tell the gui "create an object-box of name "pack" with args "f f s" at position 100,100

16:50 < matju> dmotd: did that already... almost

16:50 < _hc> bascially, it means we'd have to do a fair amount of refactoring with each step

16:50 < _hc> i.e. first make GUI pure Tcl

16:50 < _hc> then make pd send pd messages to pd-gui

16:50 < _hc> and refactor pd-gui's Tcl to handle that in a rational way

16:50 < dmotd> matju, okay, so it is realistic to remove C logic then.. 

16:51 < msp> I think what _hc and chun are doing is quite a bit enough step already, and adding a C code cleanup would make the task unmanageable

16:51 < matju> dmotd: well, some people would say that desiredata isn't realistic.

16:51 < _hc> the incremental method works for me

16:51 < msp> ^bit^big

16:51 < IOhannes> msp, yes, that's what i meant by "that'll take another meeting" ;-)

16:52 < _hc> as long as we can still change things with each step

16:52 < _hc> I wouldn't want to see the current Tcl code calcified when the C code gets refactored since it is so intertwined

16:53 < msp> yep.  

16:53 < chun> i must admit that i have not done very much with pd-devel yet..

16:53 -!- gyokimae (n=chatzill@121-80-62-127.eonet.ne.jp) has joined #dataflow

16:53 -!- myosound (n=myosound@static-71-127-149-42.bltmmd.fios.verizon.net) has joined #dataflow

16:54 < _hc> one thing I have struggled with a bit is how to organize the code.  Some of it is easy, like the menus are a distinct item, but other things are really mixed between Tcl and C, so I don't see how to encapsulate it

16:54 < _hc> hence wheredoesthisgo.tcl

16:54 < _hc> et.c

16:56 < msp> _hc: that's the sort of thing I tend to call "misc" :)

16:56 < matju> _hc: you can also organise the code in one big file as well. that way you can use Ctrl+F instead of grep. Unless you use an editor that supports multifile search.

16:57 < _hc> iuse emacs with tags, that means it find the file for you and opens it

16:57 < _hc> I just got it working with Tcl too, that makes my life much easier

16:58 < dmotd> _hc, OT.. i just noticed that ./configure does not check for an installed tcl/tk version like 'vanilla' does.. it is falling back to 8.4 and not running 8.5 here which is also installed..

16:58 -!- chr15m (n=chrism@bb-87-80-4-177.ukonline.co.uk) has joined #dataflow

16:58 < msp> _hc: is that the "etags" business in the makefile?

16:58 < _hc> I think we can make the code a lot clearer and easier to handle by splitting it up into object-like files

16:58 < _hc> msp: yes

16:58 < _hc> that doesn't have to stay, I just put it there for convenience

16:59 < msp> _hc: it doesnt' seem to do any harm.

16:59 < _hc> dmotd: the GUI no longer needs tk.h, so there is no reason for ./configure to check for Tcl/Tk

16:59 < msp> dmotd: the old ./configure thing was totally out of control, but I agree we need a way to seek out tcl/tk versions.

17:00 < _hc> you do it like this now: wish8.4 pd.tk

17:00 < _hc> or wish8.5 pd.tk

17:00 < dmotd> _hc, msp, right, that's fine thanks.. just an observation.. 

17:00 < _hc> and bin/pd uses /usr/bin/wish

17:00 < msp> _hc, but how if you're inviking from "pd"?

17:00 < msp> _hc - oh, cancal.

17:00 < _hc> or /usr/bin/env wish

17:01 < _hc> On Mac OS X, it'll need to do the seeking still, and on Windows it'll use the included Tcl/Tk wish

17:01 < _hc> I think that makes sense, anyone beg to differ?

17:01 < msp> _hc, sounds like you have it pretty well covered.

17:02 < _hc> I think we can figure that out as we go along, its like I describe right now, and if we find issues, we can change things.  I just found that the wish seeking stuff can cause wierdness

17:02 -!- oskude (n=oskude@p54B0AE41.dip0.t-ipconnect.de) has joined #dataflow

17:04 -!- sll (n=sll@89.130.27.229) has joined #dataflow

17:05 < _hc> well, since it is the "official" start time, I'd like to throw out my agenda list, and anyone could add to it

17:05 < _hc> - everyone run pd-devel both from ./pd and wish pd.tk

17:05 < _hc> - get people up to speed on the code

17:05 < _hc> - code organization (namespaces, object style ,etc)

17:05 < _hc> - claiming chunks to work on

17:05 < _hc> I made a wiki page: http://puredata.info/dev/PdDevel

17:06 < _hc> so was everyone able to get it running both with ./pd and wish pd.tk?

17:06 < msp> _hc: worked for me.  

17:06 < dmotd> _hc, yes, fine.. 

17:06 < chun> i thought the official time was one hour ago?

17:07 < chun> anyways, continue..

17:07 < _hc> no one responded to my request to move it an hour earlier, so I kept it at the first time posted.  But whatever, we are here

17:07 < chun> sure

17:07 < _hc> well, if anyone has problems still getting it running, ping me

17:08 < _hc> so.... next item, is the code readable?  Does it make sense?  any quesytions, comments, etc/

17:08 < _hc> not much of it is cast in stone, so I am pretty open to changes

17:09 < IOhannes> the most unreadable thing is the arbitrary naming of .tcl and .tk files :-)

17:09 < chun> i can navigate in it last time i read it, which was last week

17:09 < _hc> IOhannes: yeah, the naming needs work and how to organize the code into files

17:10 < _hc> IOhannes: do any of them make sense?

17:10 < IOhannes> msp, are you still totally opposed to create a subdirectory within src/?

17:10 < IOhannes> e.g. src/tkgui/

17:10 < chr15m> can someone do `head .svn/entries` and post the exact svn checkout location for pd devel?

17:11 < _hc> chr15m https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-devel/0.41.4

17:11 < dmotd> hey chr15m 

17:11 < IOhannes> chr15m, i do "svn info" rather than fuzz with .svn/entries

17:11 < IOhannes> and come to the same result as _hc 

17:11 < chr15m> hi dmotd. IOhannes: that's a much better idea :)

17:12 < _hc> are any of these not clear? find_panel, font_panel, iemgui_panel, gatom_panel, pd_menus, pd_bindings, pd_connect. 

17:12 < msp> IOhannes, "grep" works soooo much better when things are in the same dir...

17:12 < _hc> IOhannes: I don't really see the advantage of having the .tcl files in a different dir

17:12 < chr15m> msp: rgrep :)

17:12 < _hc> but its not a big deal either way for me

17:12 < IOhannes> msp, there are really nice variants, like "rgrep"

17:12 < chr15m> or grep -r

17:13 < msp> _hc: I still think the "pd_" prefix is superfluous.

17:13 < msp> bash: rgrep: command not found

17:13 < dmotd> _hc, i find the title 'AppMain.tcl' a little confusing

17:13 < _hc> msp: I think its needed on common terms like "menus" "bindings" "connect", but otherwise, it is not needed

17:13 < _hc> AppMain.tcl is a Mac-only file, that name is determined by the Wish shell

17:14 < chr15m> msp: 'grep -r'  what OS are you running that doesn't have rgrep?

17:14 < msp> windows, max, and linux.

17:14 < msp> ^max^mac, sorry.

17:15 < chr15m> msp: oh yes, good point, maybe mac and windows won't have an rgrep by default. anyway, grep -r should work for recursive.

17:15 < _hc> it would really suck if we wanted to use some package that has a "menus" command, for example

17:16 < msp> _hc, the "it" that would suck is having put the tcl/tk in a subdir?

17:16 < IOhannes> i think this is unrelated to putting it into subdirs

17:17 < IOhannes> it's rather about "import menus" (or so)

17:17 < mescalinum> dmotd: re: tkzinc? nope.

17:17 < mescalinum> I'm back

17:17  * mescalinum reading log

17:17 < dmotd> mescalinum, sorry terrible memory.. 

17:18 < CIA-66> pure-data: eighthave * r10764 /branches/pd-devel/0.41.4/src/AppMain.tcl: added big desscription to clarify what this file is used for

17:18 < _hc> msp: no, name conflicts with common terms like "menus", hence "pd_menus"

17:19 < _hc> FYI: the messages from CIA-66 are the svn commit messages

17:19 < msp> _hc: aha.  Does this imply that filenames also have to start "pd_" (i.e. do the filenames have to agree with the tcl function name prefixes?)

17:20 -!- dpro (n=x@chello080109038101.17.14.vie.surfer.at) has joined #dataflow

17:20 < _hc> technically, the filenames do not need to match the package names, but it is a very good practice, IMHO, and standard practice in many languages

17:20 < mescalinum> dmotd: what I recently said is that I'm working on a high level Tk canvas made especially for dataflow software

17:21 < dmotd> mescalinum, right, well that must be where i drew your name from.. otherwise i'm sure it has come up.. 

17:21 < mescalinum> dmotd: so, it has NOT low-level instructions, like "draw a rectangle", but more high level instructions, like "draw a patcher object with 3 inlets and 1 outlet"

17:21 < mescalinum> how much time ago this devel meeting started?

17:21 -!- alx1 (n=alx@modemcable231.117-21-96.mc.videotron.ca) has quit (Read error: 104 (Connection reset by peer))

17:22 < dmotd> mescalinum, officially 20min.. 

17:22 -!- alx1 (n=alx@modemcable231.117-21-96.mc.videotron.ca) has joined #dataflow

17:22 < matju> _hc: in tcl/tk, there exists "menu" but not "menus"; "bind" but not "bindings"; and nothing that sounds like "connect"

17:23 < _hc> matju: sure, but in other packages, people are much more likely to define a command named "menus" rather the "pd_menus"

17:23 < chr15m> matju: but the kinds of errors that arise from nameclashes are often hard to trace. might be a good idea to prefix everything by default if tcl/tk doesn't have a good namespacing system builtin.

17:24 < _hc> chr15m: Tcl has namespacing, and I've tried to use it.  It in a lot of places in the pd-devel code, but not everywehre

17:24 < _hc> check find_panel.tcl for example

17:24 < matju> _hc: in other namespaces?...

17:25 < _hc> matju: I don't understand the qeustion

17:26 < matju> _hc: if you import a package named mumblematic and in there there's a mumblematic::menus, it doesn't clash unless you also copy its symbols to your home namespace.

17:26 < matju> _hc: and isn't that why namespaces exist?

17:26 < _hc> find_panel on needs to export one proc (the find_cancel kludge is removed)

17:26 < _hc> these are names of packages/namespaces

17:26 < _hc> sorry, I mispoke before by saying "command"

17:27 < msp> so, maybe a better filename for "find_panel" would be "pd_panel_find.tcl"?

17:27 < matju> msp: tcl doesn't enforce any naming of files... of all programming languages, almost only Java/C# do, afaik

17:27 < msp> matju, and Pd, of course :)

17:28 < matju> msp: oh yea, why did i omit that one? :)

17:29 < chr15m> _hc: maybe this is OT, but i don't seem to have scrollbars

17:29 < _hc> msp: there isn't a hierarchy of classes, so I think either "find_panel" or "pd_find_panel" works.  

17:29 < msp> reasoning behind the ugly pd_panel_find name would be, "pd" is toplevel prefox saying "hi, I'm tcl code"; then "panel" would firther organize us into the various panels.

17:29 < _hc> chr15m: not implemented yet

17:29 -!- myosound (n=myosound@static-71-127-149-42.bltmmd.fios.verizon.net) has quit ("Leaving...")

17:29 < matju> msp: actually, it doesn't always enforce it, as you can load libs that define things by any name in the global namespace, so that those names are then not looked up in the filesystem.

17:30 < chr15m> _hc: ok cool

17:30 < _hc> the .tcl says its tcl code

17:30 < msp> chr15m and _hc , BTW, the way the scrollbars reset themselves automatically when you move a Pd object off the top of the screen is the most annoying signel tcl issue I've had.

17:30 < _hc> it seems to be that doing something like tcl_find_panel.tcl is redudnant

17:30 < msp> .. except, then, why have _anything_ use "pd_" in the name?

17:31 < matju> msp: actually, you can also bypass it in Java, using ClassLoader or something, but it has to be a lot more deliberate than how it happens in pd externals. and also, Pd has t_loader (or is it loader_t ?) now, sooo...

17:31 -!- myosound (n=myosound@static-71-127-149-42.bltmmd.fios.verizon.net) has joined #dataflow

17:31 < _hc> msp: that's how most programs respond when  things are pasted off screen, but the current behavior does have issues

17:32 < msp> This might be only my own private issue - I use alphabetical listing to see how the source is organized, hence filename prefixes.

17:32 < _hc> msp: to avoid nameclashes with very common terms like "menus" 

17:32 < matju> msp: what you have to figure out in a taxonomy of parts of pd source code, is whether "panel" is a greater organising principle than "find" is.

17:33 < msp> _hc but auto-scroling is almost never what a Pd user is expecting when he/she sticks something off the top of the window.

17:33 < chr15m> maybe it would be good to decide once and for all whether to universally prefix everything

17:33 < _hc> msp: if you mean when you are dragging, yeah, it can be very annoying

17:33 < msp> matju, yes, and, I think, "panel" is higher-level than "find", yes.

17:33 < _hc> msp: except the code is not organized like that in anyway

17:33 < matju> msp: because, in reality, relationships between parts are not fitting nicely in a tree, but the naming has to fit in a tree, so you have to find a spanning tree that fits nicely, and not have to come back saying it would've been better naming things the other way around, when it's sort of too late.

17:33 < _hc> there is no "panel" class

17:34 < _hc> with a "find" subclass

17:34 < msp> _hc, right.  If you do a paste that lands offscreen, the scrolling action would be desirable, come to think of it :)

17:34 < mescalinum> _hc, msp: I think that issue also causes the contextual canvas menu to appear offset

17:34 < mescalinum> (at least on linux)

17:34 < _hc> mescalinum: that offset issue is quite old, AFAIK

17:35 < msp> mescalinum, I think that's right.  And that's also driven me crazy for years.

17:35 < chun> chr15m: i second that.. i foudn it a bit weird that some files has the prefix and some don't, imho..

17:35 < mescalinum> _hc: really? I remember seeing that recently on pd-0.42 (I need to remember how to cause that though...)

17:36 < chun> at least its a bit confusing to me 

17:36 < _hc> chun: I am fine with everything having a prefix, mostly I think we should have good, descriptive names.  And the namespace,package, and file names must match.

17:36 < matju> msp: personally i've avoided subordinating one to the other... but alphabetically, i put Panel last.

17:37 < _hc> if we want to make hierarchies, then that is possible with Tcl namespaces, but it seems unnecessary

17:37 < chun> what do others think about prefixing everything?

17:37 < matju> _hc: i'm not talking about superclass/subclass relationships, i'm talking about package relationships, which can be elaborated separately from inheritance

17:38 < matju> _hc: and then, inheritance doesn't have to be a tree either (except in Java).

17:38 < msp> matju, if it's find_panel and gatom_panel, for instance, then alphabetically listing your files puts the two together; if it's find_panel and gatom_panel they don't.  I'm not worried about alphabetization within a single name but between them. 

17:38 < msp> and yes, the filename organization is useful to suggest grouping, not class hierarchies.

17:39 < _hc> I don't really underttand why things need to be alphabetized

17:39 < _hc> I think that class hierarchies are a pretty well defined method of doing functional grouping

17:39 < matju> msp: within a single name? if i sorted within a name, it wouldn't be find_panel nor panel_find, it'd be _adefilnnp

17:39 < _hc> but mostly, I think this GUI is not that complicated, so we don't need that much organization

17:40 < matju> msp: i'm talking about how to order word categories so that sorting alphabetically puts together the names that go together the most. so i believe that we are talking about the same thing.

17:40 < msp> because that's the one organizing method that every OS offers.

17:40 < msp> matju, you found it.  Let's alphabetize all the letters within each name :)

17:40 -!- chr15m (n=chrism@bb-87-80-4-177.ukonline.co.uk) has left #dataflow ()

17:40 -!- chr15m (n=chrism@bb-87-80-4-177.ukonline.co.uk) has joined #dataflow

17:41 < chr15m> crap, wrong button :(

17:41 < matju> msp: has the side effect of finding anagrams.

17:41 < mescalinum> how that would look like?

17:41 < msp> matju, right.  My thnking is that "panels" are a good category.

17:42 < _hc> hmm, this is reminding me of m_pd.h... I still type #include "pd.h" then think, where did the header go?

17:42 < msp> yep.  "m" for "message system", the core of it all.

17:43 < matju> msp: i believe that first you think about gatom_panel and finds out that it belongs in a category of panels so you make it share code with panels and that's where your inheritance is. and then you look at what is _specific_ about gatom_panel and find out that the part of the code that isn't already in the common pool of panel code, is code that is specific to gatom, so i'd sorting-wise put it with gatom.

17:44 < msp> _hc,and also, "I'm part of the GUI code" seems to me a good toplevel group.

17:44  * mescalinum wonders about the header files... was initially meant for pd.h to be the only public header, thus did it go to /usr/include rather than /usr/include/pd/*?

17:44 < mescalinum> *err m_pd.h

17:44 < _hc> msp: would *.tcl mean part of the GUI?

17:45 < msp> _hc, yep.  So my odd insistence on using prefixes, in this case, clashes with the fact that in this one particular category -- GUI code -- everyone in the category ALSO shares the same implementation language.

17:45 < _hc> there is now a clear separation *.tcl = pd-gui, *.(ch) = pd

17:45 -!- myosound (n=myosound@static-71-127-149-42.bltmmd.fios.verizon.net) has quit ("Leaving...")

17:46 < msp> _hc - and this wasn't the case until now, now that I think of it.

17:46 < chr15m> but there will still be things called g_* (which is a good idea in my opinion)

17:46 < chr15m> g_*.(ch)

17:46 < msp> chr15m, yeah.

17:47 -!- alx1 (n=alx@modemcable231.117-21-96.mc.videotron.ca) has quit (Read error: 110 (Connection timed out))

17:47 < mescalinum> prefixes are nice imho. one question? does it have to be just one letter? like x_*

17:47 < mescalinum> or you can add a second letter, to make one more level of sorting

17:48 < msp> mescalinum, the only reason I did that was for brevity.  Back in the day, some systems still had limits on filename lengths.

17:48 < mescalinum> or you might be already saying that ... sorry I didn't follow from the very beginning

17:48 < _hc> gui_blah.tcl?

17:48 < mescalinum> gp_blah.tcl

17:48 < mescalinum> gui-panels-blah

17:48 < _hc> pd-gui_blh.tcl

17:49 < mescalinum> gc_bluh.tcl  gui-canvas-bluh

17:49 < mescalinum> maintains alphabetical sorting, and is short :)

17:49 < msp> _hc, it's unfortunate that I used "g" for the "gui" code in "c".  ONe idea might be to make

17:49 < _hc> pg_foo.tcl, g_foo.tcl, r_foo.tcl, and x_foo.tcl

17:49 < mescalinum> and it's tab_friendly (wrt bash) ;)

17:50 < msp> the canvas class and related files be "c" and move all the tcl to "g".

17:50 < _hc> don't read x_foo.tcl at work

17:50 < _hc> and watch out for xxx_foo.tcl

17:50 < _hc> ;)

17:50 < msp> _hc anyone who's studied algebra has had to confront that issue.

17:51 < chun> hey, a bit of OT, anyone has bright ideas of how to add patch appearance customability into pd-devel, without having to do anything to the c side of things?

17:52 < chun> into pd-devel-gui, i should say..

17:52  * mescalinum has

17:52 < msp> such as the background color, for instance?

17:52 < _hc> chun: I think some would be possible, but more would require C changes

17:52 < matju> _hc: that rating system is not international. where i live, it would be called foo16+.tcl and foo18+.tcl

17:53 < _hc> chun: for example, I think you could set the font without changing the C code

17:53 < chun> msp: yes, something like that

17:53 < msp> matju, and this is why Canadians are better at math than people in the US :)

17:53 < mescalinum> chun: but it's meant as a separate canvas widget. it requires more work on modifiyng pd core establishing a mor egeneric protocol between pd and the client gui.... quite a lot of work!

17:53 < chun> and fg/bg of objects, etc

17:53 < chroos> huh ?+

17:53 < matju> msp: there's not even a canadian rating system... it's a per-state jurisdiction...

17:54 < _hc> chun: as for canvas properties, you can always set them dynmically as a hack, finding the windows using (wm stackorder .)

17:54 < chun> mescalinum: yeah, that's what i figured, but thought i will bring it up, just in case i am wrong about that

17:54 < _hc> chun: or also there is the 'option' command with classes

17:54 < _hc> that's global

17:54 < dmotd> chun, on a related tangent could menu items be changed from within the canvas? allowing a configuration setup to be saved as a patch

17:55 < _hc> msp: do you have any objections to including the msgcat localization stuff?

17:55 < msp> chun, making object backgrounds configurable would certainly require dipping into the C code the way it's implemented now.  I think in the longer term that sort of stuff should migrate to the tk side.

17:55 < _hc> if you don't want to include the translations they can safely be omitted, and it'll just stick to the english that is typed inline in th ecode

17:56 < matju> msp: wikipedia mostly distinguishes between "canadian ratings outside Quebec" and "Quebec system"... http://en.wikipedia.org/wiki/Canadian_motion_picture_rating_system

17:56 < msp> _hc, I don't understand it well enough to object.  Certainly the advantages are huge, and I don't see any downside at all yet.

17:56 < _hc> I don't either, msgcat has been included in Tcl for a while

17:56 < chun> dmotd: sorry, i don't understand what you meant:/

17:56 -!- myosound (n=myosound@static-71-127-149-42.bltmmd.fios.verizon.net) has joined #dataflow

17:57 < _hc> msp: it's not very complicated, mostly it would be a matter of if you feel like including the translation files

17:57 < _hc> chun: I think you should check option, it can set things globally: http://tcl.tk/man/tcl8.5/TkCmd/option.htm

17:58 < _hc> plus canvas windows are given the class CanvasWindow in pd-devel

17:58 < chun> _hc: sure, i will have a look at it

17:58 -!- ksssss (n=ss@093105025160.swk.vectranet.pl) has quit (Remote closed the connection)

17:59 -!- ksssss (n=ss@093105025160.swk.vectranet.pl) has joined #dataflow

17:59 < dmotd> chun, using messages to change settings.. ie, (; pd dsp 1 (

17:59 < chun> another problem would be where to save these appearance options to..

17:59 < msp> _hc, looks like it's not in ASCII - that would suggest putting it in a new directory parallel to "src", assuming that's possible.

18:00 < _hc> msp: yeah, its already in "src/locale"

18:00 -!- tim (n=tim@85-127-156-37.dynamic.xdsl-line.inode.at) has quit ("Leaving")

18:00 < _hc> those files are UTF-8, definitely not asci

18:00 < chun> dmotd: you meant have a patch to save the way you like your menus to be?

18:00 < msp> _hc, is "locale" possible instead of "src/locale"?

18:01 < dmotd> chun, i guess it's like declaring settings with a loadbang.. sorry.. its very late here and i'm losing my brain a bit.. 

18:02 < _hc> msp it makes life much easier if it is in the same place in the dir hierarchy as it is once it is installed

18:02 < chun> dmotd: same here..:/

18:02 < _hc> but I suppose the makefile could copy it

18:02 < dmotd> chun, you're in .tw right?

18:03 < chun> dmotd: yep, you?

18:03 < msp> _hc, is there a downside to having it live in "locale", even at runtime?

18:03 < dmotd> chun, .au

18:03 < _hc> msp:  you mean paralell to "bin"? Not that I can see

18:03 < chun> dmotd: right

18:03 < msp> _hc, right.

18:04 < matju> msp: it's in src/locale because in my implementation of locales they are plain tcl files that are installed the same way as the tcl files that are in src.

18:05 < msp> well, one slight downside is that the toplevel shouldn't get too crowded with extra dirs, I suppose,

18:05 < _hc> I just remembered, in regard to font/box sizes, pd-devel works differently.  Basically, the box sizes are hardcoded in pixels, then the font is measured to fit inside those boxes

18:05 < chun> dmotd: i guess what you are saying is that, eventually, all the settings window are just pd patches, right?

18:05 < _hc> so there is a box size for 8 pt, 10pt, 12pt, etc. then the font sizes are chosen to fit in those boxdes

18:05 < dmotd> chun, exactly.. 

18:06 < chun> dmotd: yeah, i think _hc mentioned this at some point too

18:06 < msp> _hc, that's clearly the best solution anyone's been able to think of yet for box sizes.  I think Matju was the first to suggest it a couple of years ago.

18:07 < _hc> msp: I don't really have any preference of where "locale" should go besides having it live in teh same  place in src and once installed (which I guess it currently isn't...)

18:07 < dmotd> chun, which would allow for finer tuning of  settings than those necessary for the menu itself, and settings can be localized for particular patches

18:07 < matju> msp: perhaps, but it's also been implemented... with variable-width font support, too.

18:07 < dmotd> chun, sorry this is a struggle without any stimulants now ;)

18:07 < msp> _hc, at least in that it has the same relationship with the tcl code in src as it then does in bin, it's coherent the way it is now.

18:08 < chun> dmotd: hehe

18:08 < _hc> chun: you mentioned wanting to work on key bindings, do you have anything particular in mind? 

18:08 < matju> msp: oh, i misunderstood at first. i'm not talking about the same font thing.

18:09 < _hc> another idea I had is having the GUI look for a file called startup.tcl in the Pd path and load any that it finds.  this could be used for setting up custom menu items, key bindings, color schemes, etc.

18:09 < msp> _hc, my original idea, and the reason I was copying the tcl code from src to bin, was that bin should be self-contained.  But that idea never really held up.

18:10 < _hc> msp: what about just compiling in place and using "make install" to put into bin?

18:10 < msp> _hc, on the other hand, it would feel strange to me to have pd looking inside a directory names "src" at runtime.

18:10 < _hc> same with pd/obj

18:10 < matju> msp: instead, what i'm talking about is, first use the font on the screen, then measure the resulting canvasitem and then wrap a box around it.

18:11 < chun> _hc: i guess one of the things needing to talk about its where to save the bindings to, if they can be customised, same as the appearances

18:11 < msp> matju, AFAIK, that's the way I've always done it.

18:11 < IOhannes>  /me's concert has started; if anybody want's to listen to Schubert (and Hindemith, and ...) while chatting go to http://www.kug.ac.at/schubert

18:11 < _hc> matju:  the problem with that approach is that hte box sizes then vary depending on Font, OS, DPI, etc.  and the C code mouse cilck detection is based on the box sizes.  Plus this breaks GUI objcest

18:11 < matju> msp: no, you have never done it like that, which is why we had to redo it so that variable-width be supported.

18:11 < chun> _hc: i see you alreayd mentioned startup.tcl

18:11 < msp> matju, the idea of enforcing a fixed box size seems to me an improvement.

18:11 < _hc> IOhannes: where you able to follow any of this?

18:12 < msp> matju, Oh, I see, I was tacitly assuming fixed-width, yes.

18:12 < IOhannes> _hc, you mean the last few pages of chat?

18:12 < _hc> IOhannes: y

18:12 < IOhannes> msp, LATER i would go for a feedback from the gui how big the boxes actually are

18:13 < IOhannes> if the fonts and dpis and everything is the same then it will look the same everywhere

18:13 < IOhannes> the gui will have to assure that it looks the same on all platforms, not the dsp-engine

18:13 -!- kareemk (n=kareem@84.36.13.194) has quit (Read error: 110 (Connection timed out))

18:13 < _hc> IOhannes: then the .pd file needs to store the sizes, otherwise GUI objects break

18:13 -!- kareemk (n=kareem@84.36.10.83) has joined #dataflow

18:14 < msp> IOhannes, yes, but the one thing I've been unable to find for years is a way to specify the exact desired pixel size of a font.

18:14 < _hc> either the .pd file needs to store the sizes or the sizes need to be fixed

18:14 < _hc> msp: it works when you fix tk scaling

18:14 < chr15m> _hc: .pd file storing sizes sounds best to me, so layout doesn't break.

18:14 < msp> _hc, not on my machine it doesnt - unless I'm missing something

18:15 -!- BenLauDC (n=benlau@221.125.8.105) has quit ("Leaving.")

18:15 < chr15m> _hc: with the option to zoom the patch for the visually impaired

18:15 < _hc> msp: you have to use the exact same font, just because the different oses have fonts called "Courier" does mean they all have the same sizes

18:15 < _hc> hence my use of Bitstream Vera Sans Mono

18:15 < _hc> same file on all platforms

18:16 < msp> _hc which my machine doesn't have (and by extension the default user's wouldn't either :)

18:16 < IOhannes> well, ship the font with Pd 

18:16 < _hc> Bitstream Vera Sans Mono is included in Fedora, Debian, and Ubuntu.

18:16 < _hc> it is installed by default with GNOME

18:16 < msp> IOhannes, then you need an "installer" - another big step.

18:16 < _hc> Pd-extedned installs Bitstream Vera Sans Mono on Windows

18:16 < IOhannes> if we can ship wish.exe, then we can ship "Bitstream vera sans mono" as well

18:17 < _hc> and on Mac, Monaco is included by default and close enough to Bitstream Vera Sans Mono that is doesn't matter

18:17 < mescalinum> _hc: I think it's also the user's DPI setting that affects the font pixel size

18:17 < dmotd> _hc, yes i use this font too.. it is clean and clear.. 

18:17 < msp> IOhannes, I don't know how to make wish _find_ a font without putting it in a fixed place on at least some OSes.

18:18 < chr15m> _hc: is Bistream Vera Sans Mono the one i'm seeing when i start pd-devel?

18:18 < _hc> msp:  on linux you need a font manager

18:18 < mescalinum> _hc: hence the code that brute-forces a desired pixel size in (font configure)

18:18 < IOhannes> msp, can't tcl use a font on a relative path?

18:18 < _hc> chr15m: donno, depends on your setup, it defaults to COurier

18:18 < dmotd> _hc, is the Vera set distributable with the pd license?

18:18 < msp> IOhannes, I think that on Windows it can't.

18:18 < chr15m> _hc: i think forcing the user to use a specific font is much uglier than saving the object box relative sizes into the .pd file

18:18 < IOhannes> msp, on windows i would go for an installer anyhow :-)

18:19 < chr15m> _hc: but i know you've done a lot of work on that

18:19 < chun> i am going to crash soon, i will read the log tomorrow if that happens..

18:19 < IOhannes> using NSIS or ... (whatever _hc is using for pd-extended) is really really simple to setup

18:19 < msp> dmotd, that might not be a problem - for instance, "expr" is GPL, so I ship it as an "extra".

18:19 < _hc> chun: do you have any other questions before you go?

18:19 < _hc> IOhannes: InnoSetup

18:19 < mescalinum> msp: tk canvas can be extended in C by adding new types. it could be add a new type like a bitmap font, which I think is the behavior you want: same pixel size on every platform at any dpi setting

18:19 < chun> not really

18:20 < _hc> mescalinum: not necessary, if you set tk scaling to 1, then 12 pt should be the same size on all pltforms

18:20 < _hc> works so far on Pd-extened

18:20 < msp> mescalinum, this would mean re-integrating C code into the GUI, which HC has been working to separate out.

18:20 < mescalinum> _hc, no, again the font server takes in acount also the dpi

18:21 < mescalinum> _hc lower dpi, smaller font

18:21 < chun> _hc: i will read about the idea of startup.tcl, if the discussion moves that way later on

18:21 < dmotd> msp, it looks to be good anyhow.. just quickly checked.. much like BSD, copy/modify/sell with copyright notice.. 

18:21 < msp> dmotd, perfect then, if only there's a way to get it loaded at runtime.

18:21 < IOhannes> mescalinum, do you have a font-server on w32?

18:21 < mescalinum> msp: well, it would just mean that the canvas widget should take care of all the gui stuff

18:21 < _hc> mescalinum: I believe that Tk handles different DPI screens with tk scaling

18:22 < mescalinum> msp: it could be done also in pure-tcl

18:22 < _hc> so if fix it, then the pixel sizes are the same

18:22 < _hc> i.e tk scaling 1

18:22 < dmotd> chr15m, g'night!

18:22 < msp> _hc, I've tried setting tk_scaling, and I STILL get machine-dependent changes in font sizes.

18:22 < _hc> msp: with the exact same font?

18:23 < mescalinum> _hc: I see. then find_font_size {} (in pd devel) should be able to find out an optimal pixel size by tweaking tk scaling?

18:23 < mescalinum> (maybe it's not called exactly find_font_size)

18:23 < _hc> the Courier  included withthe variuos OSes is not the same size and the others

18:23 < msp> _hc, no, because there's no exact-same-font available on arbitrary machines.

18:23 < chr15m> seeya dmotd!

18:23 < dmotd> chr15m, are you still in UK?

18:23 < _hc> msp: if you have web access, this one is available: http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/

18:23 < chr15m> dmotd: yep

18:24 < dmotd> chr15m, great!

18:24 < msp> Sure... but working on arbitrary machines, to me, means not requiring that I add installation steps.

18:24 < mescalinum> when I talked with tcl developers, we come up with two solutions: brute-force font configure for finding the desired font size (it could fail in some weird cases). or: use bitmap fonts

18:24 < _hc> what I set up works in Pd-extended

18:25 < msp> ... but, if there's a way that Pd could include its own copy of its fonts and lode them at runtime, the problem would be solved.

18:25 < msp> mescalinum, and yes, bitmap fonts are best in this context.

18:25 < _hc> here's how: use a Windows installer, install the Bitstream package on Fedora, Debian, Ubuntu, and use Monaco on Mac

18:25 < IOhannes> or more pragmatic: if the same font exists on an arbitrary machine (at the users disposition) it will look exactly the same; else the looks might vary

18:26 < IOhannes> this is not necessarily a bad thing

18:26 < IOhannes> probably i do want my Pd look different than yours....

18:26 < chr15m> IOhannes: if that is the case then the only solution is to save the relative box sizes

18:27 < IOhannes> why? ( i probably missed that)

18:27 < mescalinum> btw, _hc would be possible to have at least the box sizes calculated from the real text width?

18:28 < chr15m> IOhannes: maybe i am confused. if you want your Pd to look different, and the font is a non-compatible size (e.g. non-fixed-width for example) then it will break everything. isn't that what we're discussing?

18:28 < dmotd> is it possible to force box width and fit in one scenario, and use system size in another (default)? 

18:28 < _hc> mescalinum: again, that breaks GUI objets

18:28 -!- excalibas (n=x@bl5-22-12.dsl.telepac.pt) has joined #dataflow

18:29 < dmotd> thus the metrics get saved into the patch but can be disregarded at the users discretion?

18:29 < _hc> either fixed boxes or save box sizes in the .pd file

18:30 < IOhannes> chr15m, if i want my Pd to look different than it will look different; i wouldn't say that this breaks everything

18:30 < IOhannes> even, if it is aligned in a different way.

18:30 < chr15m> IOhannes: yes it will.

18:30 < IOhannes> what will break? (seems like i missed a lot while doing subtitles,..)

18:31 < _hc> GUI patches won't line up

18:31 < chr15m> IOhannes: if you have a font with different widths for different letters, the relative spacing and sizes of boxes between boxes will be completely different

18:31 < _hc> they will be tied to a certain machine

18:31 < chr15m> IOhannes: yeah, what _hc said :)

18:31 < IOhannes> this is what i was saying as well

18:31 < _hc> this is an ancient issue, it is solved since Pd-extended 0.39.3

18:31 < IOhannes> if i want it to look different, then by all means itt should look different

18:31 < _hc> IOhannes: read the archives about this, there was lots of discussion

18:31 < IOhannes> however: it should be _easy_ to recreate the exact same look

18:32 < _hc> that means changing the file format

18:32 < _hc> to store the sizes

18:33 < chr15m> in the meantime, it's solved already by _hc for people who don't want a custom font

18:33 < IOhannes> which is  good thing

18:33  * IOhannes is really not opposing

18:36 -!- gyokimae (n=chatzill@121-80-62-127.eonet.ne.jp) has left #dataflow ()

18:36 -!- gyokimae (n=chatzill@121-80-62-127.eonet.ne.jp) has joined #dataflow

18:37 < _hc> chr15m: pd-devel allows custom fonts

18:37 < _hc> hey gyokimae 

18:37 < _hc> the box sizes are fixed, the fonts are then measured to fit into those box sizes

18:37 < gyokimae> _hc, hi, I've been auditting. :)

18:38 < IOhannes> and having a default font that looks exactly the same on all platforms is (imo) not opposed to getting the exact object-sizes from the gui size rather than assuming them on the dsp side

18:38 < chr15m> _hc: so you added to the file format?

18:38 < _hc> no, fixed box sizes

18:38 < _hc> the font size is changed to fit in the box, rather than vice versa

18:39 < dmotd> _hc, how does this relate to locale issues that are coming up in pd-list at present..

18:39 < dmotd> _hc, sorry not to throw a spanner in the works.. 

18:39 < _hc> dmotd: it doesn't?  

18:39 < mescalinum> _hc: that procedure should be adjusted so that when it fails it tries next size (because it can fail to fit some specific font into that size at lower pt-sizes)

18:40 < chr15m> _hc: i am confused (but that's not unusual)

18:40 < _hc> (I should mention that mescalinum wrote the font fitting support)

18:40 < chr15m> _hc: all boxes have a fixed size?

18:41 < _hc> in pd-extended as of 0.39.3 and pd-devel 0.41.4

18:41 < mescalinum> chr15m: no, each character cell (i.e. one letter) has to fit into fixed dimensions

18:41 < msp> _hc, where's the font fitting support?

18:41 < chr15m> mescalinum: ahhhh cool. what does that make non-fixed-width fonts look like? spacey?

18:41 < _hc> msp: pd.tk

18:41 < mescalinum> msp: fit_font_into_metrics

18:41 < chr15m> mescalinum: what do i have to run to test that?

18:41 < _hc> chr15m: http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-devel/0.41.4/src/pd.tk

18:42 < _hc> check out font_fixed_metrics

18:42 < chr15m> _hc: yeah i mean what command line. how do i change the font?

18:42 < chr15m> never mind

18:42 < mescalinum> chr15m: they look like they are in a bigger box than thay need

18:42 < mescalinum> afk

18:42 < chr15m> i am RTFMing

18:42 < _hc> these are the triplets:   fontsize_in_points  charwidth_in_pxiels charheight_in_Pixels

18:42 < msp> _hc, got it... will read carefully later.

18:43 < _hc> chr15m: it still uses the pd command line flag, or hard code it in pd.tk

18:44 < msp> Now, to pop up a level, what, in people's opinion, needs doing before this can be usable?  What I've noticed so far is the Pd "main" window and "preferences" dialogs.

18:45 < _hc> well, its barely usable now ;)

18:45 < _hc> who needs scrollbars?

18:46 < msp> Is it feasible, for instance, for me to try to drop in the "old" code where new code is missing, for

18:46 < msp> the purpose of testing it more thoroughly?

18:46 < _hc> I think so

18:46 < _hc> for like pd window, send message window, probably prefs

18:47 < _hc> I tihnk the basics are all there, but nothing that amkes life easy, like scrollbars, undo/redo, prefs

18:48 < msp> Also I think there are a couple of bugs ("pd repertory" patches don't work, probably for simple reasons.)

18:48 < _hc> ah, whchi? I'll check them out

18:49 < _hc> there are some glitches in the bindigns that I am currently working on

18:50 < msp> _hc, for instance, open manoury-jupiter.pd - lots of objects missing, probably related to errors I'm seeing on stderr.

18:51 < IOhannes> which would mean, that cmdline args (or prefs) are ignored?

18:51 < _hc> no, I didn't touch that stuff, that's in the C code

18:51 < IOhannes> since the C-side of things has not been touched...

18:52 < _hc> s_inter.c was changed a bit regarding the wish loading

18:52 < IOhannes> but cmdline args could get munged by starting pd-dsp from pd-gui(?)

18:52 < _hc> perhaps, yes

18:53 < IOhannes> that's the only thing i could think of which might trigger millers problems

18:53 < msp> I'm getting stuff like: UNHANDLED ERROR: wrong # args: should be ".xc035b0.c create type coords ?arg arg ...?"

18:53 < _hc> I just found a new bug, sliders aren't updating graphically...

18:53 < _hc> msp: is that patch downloadable?

18:53 < msp> http://crca.ucsd.edu/~msp/pdrp/latest/pdrp-11.tgz

18:54 < _hc> msp: is it manoury-jupiter/jupiter.pd?

18:55 < msp> ... the errors all look minor.  Roger manoury-jupiter/jupiter.pd.

18:56 < dmotd> _hc, not just sliders but all number boxes too.. 

18:56 < msp> Of course, with such a huge, real-world patch, it would be amazing if everything "just worked" :)

18:56 < chr15m> msp: more generally with backwards compatibility stuff, i wonder if you would be open to occasionally breaking backwards compatibility if it was possible to supply a flag like "-compat 0.42"

18:57 < _hc> msp: where do I get scofo?

18:57 < msp> chr15m, I think in 0.41 I started putting a version stamp in the filename, so it should be possible to make this automatic.

18:57 < IOhannes> chr15m, wouldn't it be better to just include the version-number in the file

18:57 < msp> ... for instance, I want to make it possible to control the width of individual boxes :)

18:58 < chr15m> msp: :D

18:58 < msp> I'm gonna have to leave momentarily -- work beckons.

18:59 < IOhannes> msp, while doing so (the individual boxes width, not the leaving) do you plan to make it more general?

18:59 < IOhannes> e.g. something like "#G" to modify the graphical-properties of the last object?

19:00 < IOhannes> rather than only implement "box-width§

19:00 < msp> dunno, have to think about that.  I rather like matju's suggestion of adding codecils (i.e., chaser messages) after creation messages to alter things in an extensible number of ways.

19:00 < IOhannes> yes, that's basically what i meant

19:01 < IOhannes> it would be nice (e.g.) to have the "#A" as used with arrays be available for all objects automatically

19:01 < msp> e.g., #X obj 10 10 +, w 30;

19:01 < IOhannes> why not (re) use the #A method from arrays?

19:02 < msp> that could work too.  

19:02 < IOhannes> it would mean not needing to invent a new scheme...

19:02 < chr15m> and keep patches backwards compatible right?

19:02 < msp> OTOH, I don't like the practice of having things bind themselves to funny names at creation - I'd like a better way.

19:03 < matju> msp: codecils? never seen that word before...

19:03 < IOhannes> msp, i was rather thinking of Pd doing the binding for the objects

19:03 < msp> I might be misspelling it - they're the documents one adds to one's will as an afterthought.

19:04 < chr15m> codicil - a supplement to a will; a testamentary instrument intended to alter an already executed will  

19:04 < chr15m> hmmm, Pd seems to be getting deadly serious

19:04 < matju> IOhannes: i had started implementing #V at one point but got sidetracked a few times for it... i remember a mysterious bug kept on clearing the #V hash, but i don't recall whether that was before i switched from t_hash * to std::map, or after.

19:05 < matju> IOhannes: the V is for Visual.

19:05 < msp> off to get ready for work -- will check by momentarily in 10 minutes or so before leaving :)

19:05 < dmotd> chr15m, pd-dictator branch?

19:05 < chr15m> :)

19:06 < matju> msp: comma in #X would send the w message to #X, not to the object just created, because that's how pd's comma works

19:06 < IOhannes> matju, i was thinking about having separate receivers for purely-gui related staff (#V) and ordinary messages (#A) as well

19:07 < IOhannes> but am uncertain whether these things should be kept apart

19:07 < matju> msp: and then, the object just created can't just have random selectors reserved for special purposes, because some object classes define an anything-method for all methods in first-inlet... well, they could use CLASS_NOINLET together with inlet_new, i presume.

19:07 < IOhannes> probably better to use "reserved" messages

19:07 < IOhannes> :-)

19:07 < IOhannes> there _are_ special messages in Pd already.

19:07 < matju> IOhannes: yes, my plan involved separate receivers because of the nameclash problems for selectors.

19:08 < IOhannes> yes i understand this

19:08 < matju> IOhannes: what do you mean?

19:08 < IOhannes> send (dsp( to (hip~)

19:08 < IOhannes> (even though (hip~) is no class_addanything())

19:09  * IOhannes wonders when msp is going to fix this

19:09 < IOhannes> anyhow, i coulld be happy with 2 both #V and #A

19:09 < IOhannes> and would like to see both

19:10 < IOhannes> (esp. the latter)

19:10 < IOhannes> i was just thinking that one could have both for one :-)

19:11 < IOhannes> matju, as for the CLASS_NOINLET kludge, i think this is not very backwards compatible

19:14 < matju> IOhannes: oh yeah, that magic "dsp" message. in general it doesn't appear as a problem because inlets are rarely ever message-inlets and dsp-inlets at once, and if they ever do, they don't necessarily define the anything-method

19:15 < matju> IOhannes: what's so bw-incompatible about it?

19:16 < matju> IOhannes: oh yeah, it'd have to be changed in all externals... ;)

19:16 < matju> IOhannes: guess it's sort of why i didn't go that route...

19:16 < IOhannes> most likely

19:18 < msp> .. ok, sorry to all that I can't stay longer -- I'll check out the log to see what else develops.

19:18 -!- msp (n=msp@netblock-68-183-177-246.dslextreme.com) has quit ("Leaving")

19:18 < matju> i was gonna ask whether the meeting's over...

19:20 < _hc> seems that way, now we can hang out and play! :D