From: Magnus L. H. <ma...@he...> - 2003-12-27 11:22:26
|
Hi! I need valign.middle and noticed that it didn't work in the CVS version. Upon looking in the source, I saw the comment "class _valignmiddle is missing!". Why has it been removed? Was the old one unsatisfactory/non-functional? -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
From: Joerg L. <jo...@us...> - 2003-12-27 13:39:34
|
Hi Magnus, On 27.12.03, Magnus Lie Hetland wrote: > I need valign.middle and noticed that it didn't work in the CVS > version. Upon looking in the source, I saw the comment "class > _valignmiddle is missing!". Why has it been removed? Was the old one > unsatisfactory/non-functional? Due to a rewrite of the attribute system (see a message to pyx-user sent by André a few days ago: http://sourceforge.net/mailarchive/message.php?msg_id=6684291), at the moment, the CVS code is not really in a fully usable state. What concerns the valign attribute, I think that André plans to change something, but I'm not sure about that... Jörg |
From: Magnus L. H. <ma...@he...> - 2003-12-27 13:44:42
|
Joerg Lehmann <jo...@us...>: > [snip] > Due to a rewrite of the attribute system (see a message to pyx-user sen= t > by Andr=E9 a few days ago: > http://sourceforge.net/mailarchive/message.php?msg_id=3D6684291), OK. I noticed that the code had changed. > at the moment, the CVS code is not really in a fully usable state. OK. I just couldn't get 0.4.1 to work properly, but the CVS version seemed quite a bit better wrt. compiling the extensions and the like. > What concerns the valign attribute, I think that Andr=E9 plans to > change something, but I'm not sure about that... Right -- I'll just wait and see, then :) > J=F6rg --=20 Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
From: Andre W. <wo...@us...> - 2003-12-28 20:40:10
|
Hi Magnus, On 27.12.03, Magnus Lie Hetland wrote: > > What concerns the valign attribute, I think that André plans to > > change something, but I'm not sure about that... > > Right -- I'll just wait and see, then :) Yes, valign.middle was removed by accident as noted in CHANGES and the source. I likely happened when I moved the code to the new attribute system and I couldn't do much more then writing a note because I was traveling when I noticed it (I don't have access to CVS when I'm on the train, where I did most of the develoment during the last weeks -- well, I didn't did much develoment during the last weeks at all, but I'll hopefully get more time for the development in near future). I've now restored the valign.middle (the old implementation was ok) using the new attribute system. Jörg: please take a look at the merge method when combining exclusiveattr and sortbeforeattr (I've corrected it style.linewidth as well). The attribute should not be added twice. Thus the code looks like: def merge(self, attrs): return attr.sortbeforeattr.merge(self, attr.exclusiveattr.merge(self, attrs)[:-1]) We may add a combined exclusive and sort attr because we do have this merge code several times in the attributes already ... what do you think? André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Magnus L. H. <ma...@he...> - 2003-12-28 20:57:06
|
Andre Wobst <wo...@us...>: > > Hi Magnus, Hi! > Yes, valign.middle was removed by accident as noted in CHANGES and the > source. I likely happened when I moved the code to the new attribute > system and I couldn't do much more then writing a note because I was > traveling when I noticed it [snip] I see :) > I've now restored the valign.middle (the old implementation was ok) > using the new attribute system. Ah -- good. (It doesn't seem to be checked into CVS yet, though...?) -- Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
From: Andre W. <wo...@us...> - 2003-12-29 09:23:37
|
Hi Magnus, On 28.12.03, Magnus Lie Hetland wrote: > > I've now restored the valign.middle (the old implementation was ok) > > using the new attribute system. > > Ah -- good. (It doesn't seem to be checked into CVS yet, though...?) This might be a sourceforge problem. They had quite some performance problems with the CVS. Originally they moved the anonymous login (and the CVS web access) to a read only copy, which is updated with up to 24 hours delays. Now they have new maschines for the CVS, but the delay might still be present ... I'm not reading the sourceforge announcements carefull to know the current state accurately. (The CVS statistics is broken for months now as well ... we did a lot of development and there is a "0" all the time ;-() Another note about your original problem with the valign: Did you consider a baseline alignment and an appropriate vertical shift? You gain a vertical alignment independend of the box extent. See the valign example ... André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Magnus L. H. <ma...@he...> - 2003-12-29 09:45:04
|
Andre Wobst <wo...@us...>: > [snip] > This might be a sourceforge problem. They had quite some performance > problems with the CVS. Indeed -- it's there now :) [snip] > Another note about your original problem with the valign: Did you > consider a baseline alignment and an appropriate vertical shift? Well, I tried to use text.vshift.char(0.5), but that didn't work (deprecated?). Is that the same as text.vshift(0.5)? > You gain a vertical alignment independend of the box extent. See the > valign example ... This might be a possibility. What I need this for at the moment is placing labels in circular graph nodes. I'm thinking about writing an automated graph algorithm visualization program (for producing slides for an algorithm class I'm teaching), and PyX seems like a good thing to use. (I'll probably write a separate module for graph drawing, which might be useful to other PyX users as well.) If I place several nodes alongside each other, it may be good to have the labels aligned by their baselinge, so that (e.g.) b and g are properly aligned. However, if the nodes are scattered all over the place, simply aligning based on the total height of the character will "fill out" the node more, and seem less vertically skewed. (I could, of course, use only capital letters... Or numbers... Then there would be no problem :) Anyway, thanks for your help. I'll experiment a bit with shifting and aligning and see what I end up with. (Maybe I'll just use dotted nodes with external labels.) > Andr=E9 --=20 Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
From: Andre W. <wo...@us...> - 2003-12-29 17:32:57
|
Hi Magnus, On 29.12.03, Magnus Lie Hetland wrote: > Well, I tried to use text.vshift.char(0.5), but that didn't work > (deprecated?). Is that the same as text.vshift(0.5)? No, its not deprecated. It's an important feature! It might have been broken in some cases in the CVS before yesterday. (It was broken due to some sorting problem of the attributes -- it should work now again.) And to your question: text.vshift(0.5) should work. It is the same like text.vshift.middlezero; text.vshift.char is removed in CVS since it was not needed anymore after some cleanups. > If I place several nodes alongside each other, it may be good to have > the labels aligned by their baselinge, so that (e.g.) b and g are > properly aligned. However, if the nodes are scattered all over the > place, simply aligning based on the total height of the character will > "fill out" the node more, and seem less vertically skewed. (I could, > of course, use only capital letters... Or numbers... Then there would > be no problem :) Or you take a look at the box align methods ... linealign and circlealign. It can perform more complicated alignment tasks very well. > Anyway, thanks for your help. I'll experiment a bit with shifting and > aligning and see what I end up with. (Maybe I'll just use dotted nodes > with external labels.) Have you seen the text style of the graph module? I do know this code is not documented. I'm working on a cleanup and documentation of the hole graph module and it goes well, although it takes a long time. For the moment this code to take a look at is all I can offer ... but it sounds like you want to do something simular. The test_graph.py in the functional test directory uses this code and should be working in the current state. But I'm currently doing xy-graphs only, although many things are designed to work for different graph geometries as well ... we'll see in the future. André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Magnus L. H. <ma...@he...> - 2003-12-29 17:44:57
|
Andre Wobst <wo...@us...>: > > Hi Magnus, >=20 > On 29.12.03, Magnus Lie Hetland wrote: > > Well, I tried to use text.vshift.char(0.5), but that didn't work > > (deprecated?). Is that the same as text.vshift(0.5)? >=20 > No, its not deprecated. It's an important feature! It might have been > broken in some cases in the CVS before yesterday. (It was broken due > to some sorting problem of the attributes -- it should work now > again.) And to your question: text.vshift(0.5) should work. It is the > same like text.vshift.middlezero; text.vshift.char is removed in CVS > since it was not needed anymore after some cleanups. Ah, right. text.vshift.char was the only one I had problems with here (that is, it wasn't there) :) So, that's basically what I meant -- that text.vshift.char is deprecated. (Unless I misunderstand you?) [snip] > Or you take a look at the box align methods ... linealign and > circlealign. It can perform more complicated alignment tasks very > well. Ah. I'll take a closer look. Thanks. (I've just browsed the docs for what I *thought* I needed so far ;) > > Anyway, thanks for your help. I'll experiment a bit with shifting and > > aligning and see what I end up with. (Maybe I'll just use dotted node= s > > with external labels.) >=20 > Have you seen the text style of the graph module? I do know this code > is not documented. I'm working on a cleanup and documentation of the > hole graph module and it goes well, although it takes a long time. For > the moment this code to take a look at is all I can offer ... but it > sounds like you want to do something simular. Actually, by graph I mean network -- not the kind of graphs in the PyX graph modules. The graph module looks very good for that sort of thing. > The test_graph.py in the functional test directory uses this code > and should be working in the current state. But I'm currently doing > xy-graphs only, although many things are designed to work for > different graph geometries as well ... we'll see in the future. Sounds good -- but, as I said, what I'm working on at the moment is graphs in the network sense. Nodes and edges with various forms of highlighting to indicate various stages of an algorithms etc. > Andr=E9 --=20 Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
From: Andre W. <wo...@us...> - 2003-12-30 11:08:53
|
Hi Magnus, On 29.12.03, Magnus Lie Hetland wrote: > Ah, right. text.vshift.char was the only one I had problems with here > (that is, it wasn't there) :) > > So, that's basically what I meant -- that text.vshift.char is > deprecated. (Unless I misunderstand you?) Right. I removed it since it was a stupid design mistake (to my mind). Its removed in the doc as well already. Please note, that I consider the alpha development to do exactly those things -- which of course breaks code even without further notice (although usually its easy to correct those things). We might get into beta next year, where those breakage should become rare and should be documented. We'll see. > [snip] > > Or you take a look at the box align methods ... linealign and > > circlealign. It can perform more complicated alignment tasks very > > well. > > Ah. I'll take a closer look. Thanks. (I've just browsed the docs for > what I *thought* I needed so far ;) So when building networks you may also start with boxes and take a look to the connector stuff Michael Schindler contributed a few months ago. It should be quite usable (although it might be currently broken CVS -- I'm not sure about that). You could use it to connect different boxes (notes) ... I'm not sure if this would help you for the tasks you have in mind ... André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Magnus L. H. <ma...@he...> - 2003-12-30 11:24:01
|
Andre Wobst <wo...@us...>: > > Hi Magnus, >=20 > On 29.12.03, Magnus Lie Hetland wrote: > > Ah, right. text.vshift.char was the only one I had problems with here > > (that is, it wasn't there) :) > >=20 > > So, that's basically what I meant -- that text.vshift.char is > > deprecated. (Unless I misunderstand you?) >=20 > Right. I removed it since it was a stupid design mistake (to my mind). > Its removed in the doc as well already. Right. I've been following the 0.4.1 docs for now :) > Please note, that I consider the alpha development to do exactly > those things -- which of course breaks code even without further > notice (although usually its easy to correct those things). Sure. [snip] > > Ah. I'll take a closer look. Thanks. (I've just browsed the docs > > for what I *thought* I needed so far ;) >=20 > So when building networks you may also start with boxes and take a > look to the connector stuff Michael Schindler contributed a few > months ago. Yes, I've looked at it and it seems very nice. > It should be quite usable (although it might be currently broken CVS > -- I'm not sure about that). You could use it to connect different > boxes (notes) ... I'm not sure if this would help you for the tasks > you have in mind ... It might indeed be useful. > Andr=E9 --=20 Magnus Lie Hetland "The mind is not a vessel to be filled, http://hetland.org but a fire to be lighted." [Plutarch] |
From: Joerg L. <jo...@us...> - 2003-12-29 18:10:32
|
Hi André, On 28.12.03, Andre Wobst wrote: <snip> > I've now restored the valign.middle (the old implementation was ok) > using the new attribute system. Jörg: please take a look at the merge > method when combining exclusiveattr and sortbeforeattr (I've corrected > it style.linewidth as well). The attribute should not be added twice. > Thus the code looks like: > > def merge(self, attrs): > return attr.sortbeforeattr.merge(self, attr.exclusiveattr.merge(self, attrs)[:-1]) Hmm, this assumes implicitly that attr.exclusiveattr.merge returns self as last element in the list -- which is currently the case. > We may add a combined exclusive and sort attr because we do have this > merge code several times in the attributes already ... what do you > think? Taking into account the problem mentioned above, I think this is a good idea. So what about a sortbeforeexclusiveattr class? If there are no objections, I'll go ahead and implement this. Jörg |
From: Andre W. <wo...@dp...> - 2003-12-30 11:08:48
|
Hi Jörg, On 29.12.03, Joerg Lehmann wrote: > > def merge(self, attrs): > > return attr.sortbeforeattr.merge(self, attr.exclusiveattr.merge(self, attrs)[:-1]) > > Hmm, this assumes implicitly that attr.exclusiveattr.merge returns self as > last element in the list -- which is currently the case. Well, it should be the last element since it doesn't modify the order of the attributes but removes unneeded entries (which come before the last element). But you're right, its quite implicit ... I mean, when I realized (again), that a new merge method is needed when we use both, exculsiveattr and sorfbeforeattr, I was already sure we want to have it once and for all. > > We may add a combined exclusive and sort attr because we do have this > > merge code several times in the attributes already ... what do you > > think? > > Taking into account the problem mentioned above, I think this is a > good idea. So what about a sortbeforeexclusiveattr class? If there > are no objections, I'll go ahead and implement this. Ok, please do so. It should be straigt forward. The name you suggested is kind of lengthly, but I think, its ok for that task, since its really part of the internal attribute system ... (and multiple inheritance of both parts was even longer to type not even taking into account the merge method). André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |