TkPath maintainer?
in [TCL]
|
From: Georgios Petasis on 10 Mar 2010 17:52 στις 10/3/2010 22:49, O/H Arndt Roger Schneider έγραψε: > George Petasis schrieb: > >> στις 10/3/2010 7:31 μμ, O/H Arndt Roger Schneider έγραψε: >> >>> Jeff Godfrey schrieb: >>> >>>> Hi All, >>>> >>>> In the past, I had a project I was developing around TkPath. After the >>>> untimely loss of Mats B., I moved away from TkPath as I assumed the >>>> project would rot from lack of a maintainer. >>>> >>>> However, I see it mentioned from time to time here and wonder if >>>> someone else has picked up the project? Looking at its SF CVS >>>> repository, it looks like the latest checkins were nearly a year ago. >>>> >>>> So, does anyone have any info on the current and future state of >>>> TkPath? Has someone picked it up, or is everyone just using it in it >>>> current state? >>>> >>>> Thanks, >>>> >>>> Jeff Godfrey >>> >>> >>> I've talked with Carlos Tasada (He is listed as a developer of >>> tcbitprint) >>> in December 2009, tkpath is currently orphand software. >>> >>> I intend to fork tkpath from tclbitprint, because I am using >>> tkpath extensivly myself. >>> >>> Currently, I have a custom 0.2.9 version running on PowerPC G5, >>> which I want to use as the first forked release. >>> >>> As for: 0.3.1, the 0.3 version requires considerable more >>> work than 0.2 --the code is unstable. >>> Coding on 0.4 will start after the release of tcl/tk 8.6. >>> >>> The next needed features in 0.4 are clip-path and viewports. >>> >>> -roger >>> >> >> I am also interested in tkpath (to help as much I can), and I am >> puzzled by your decision to fork a 0.2.x tkpath. I understand the >> complexity of implementing a new canvas widget, but what are the >> reasons that led Mat to introduce this support in 0.3.x? >> I don't know why he took this decision. But I think there are >> advantages to it, for exaple using a gradient as a fill for the canvas >> backgound (it cannot currently be done, but it is possible with a >> custom canvas). > >> On the other hand, stability fixes may be easy to make, once detected. >> We just need more bug reports. >> >> George > > > Sorry, my posting wasn't entirely clear. > I do not question Mats implementation of tkpath 0.3 > --well Mats and I discussed gradients in 0.3 > before it was released by him and I did oppose the > way he wanted to implement gradients in 0.3. > > It is easier to improve the 0.2 branch first (bugfixes), with support for > tk 8.4 and 8.5, and after that to stabilize and extend 0.3 > --which is what I mean with 0.4-- for tk8.6. > > The two dominant features in 0.3 are groups and surface, > the group implementation is what causes the instabillity in 0.3. > > SVG is the actual specification for tkpath, the tk canvas plugin > mechanism is insufficient to go any further toward SVG, that > is why Mats started a new canvas implementation --simpler. > > tclbitprint and tkpath are unrelated projects, > both are created by Mats Bengtsson. > > So, leave the tclbitprint project to tclbitprint and > make a new project for tkpath. > > -roger > > PS: There is a lot more to say about gradients, and your argument > about gradients as the window background is very sound. I see. To say the truth I also liked better the 0.2.x implementation of gradients (which could be defined outside of a canvas), than the 0.3.x approach (the gradients have to be defined inside the canvas widget). This way the same gradient has to be defined multiple times (one for each canvas widget that uses it). I still haven't used groups and surfaces, so I cannot comment on them :-) George
From: Arndt Roger Schneider on 10 Mar 2010 18:53 Georgios Petasis schrieb: > στις 10/3/2010 22:49, O/H Arndt Roger Schneider έγραψε: > >> George Petasis schrieb: >> >>> στις 10/3/2010 7:31 μμ, O/H Arndt Roger Schneider έγραψε: >>> >>>> Jeff Godfrey schrieb: >>>> >>>>> Hi All, >>>>> >>>>> In the past, I had a project I was developing around TkPath. After >>>>> the >>>>> untimely loss of Mats B., I moved away from TkPath as I assumed the >>>>> project would rot from lack of a maintainer. >>>>> >>>>> However, I see it mentioned from time to time here and wonder if >>>>> someone else has picked up the project? Looking at its SF CVS >>>>> repository, it looks like the latest checkins were nearly a year ago. >>>>> >>>>> So, does anyone have any info on the current and future state of >>>>> TkPath? Has someone picked it up, or is everyone just using it in it >>>>> current state? >>>>> >>>>> Thanks, >>>>> >>>>> Jeff Godfrey >>>> >>>> >>>> >>>> I've talked with Carlos Tasada (He is listed as a developer of >>>> tcbitprint) >>>> in December 2009, tkpath is currently orphand software. >>>> >>>> I intend to fork tkpath from tclbitprint, because I am using >>>> tkpath extensivly myself. >>>> >>>> Currently, I have a custom 0.2.9 version running on PowerPC G5, >>>> which I want to use as the first forked release. >>>> >>>> As for: 0.3.1, the 0.3 version requires considerable more >>>> work than 0.2 --the code is unstable. >>>> Coding on 0.4 will start after the release of tcl/tk 8.6. >>>> >>>> The next needed features in 0.4 are clip-path and viewports. >>>> >>>> -roger >>>> >>> >>> I am also interested in tkpath (to help as much I can), and I am >>> puzzled by your decision to fork a 0.2.x tkpath. I understand the >>> complexity of implementing a new canvas widget, but what are the >>> reasons that led Mat to introduce this support in 0.3.x? >>> I don't know why he took this decision. But I think there are >>> advantages to it, for exaple using a gradient as a fill for the canvas >>> backgound (it cannot currently be done, but it is possible with a >>> custom canvas). >> >> >>> On the other hand, stability fixes may be easy to make, once detected. >>> We just need more bug reports. >>> >>> George >> >> >> >> Sorry, my posting wasn't entirely clear. >> I do not question Mats implementation of tkpath 0.3 >> --well Mats and I discussed gradients in 0.3 >> before it was released by him and I did oppose the >> way he wanted to implement gradients in 0.3. >> >> It is easier to improve the 0.2 branch first (bugfixes), with support >> for >> tk 8.4 and 8.5, and after that to stabilize and extend 0.3 >> --which is what I mean with 0.4-- for tk8.6. >> >> The two dominant features in 0.3 are groups and surface, >> the group implementation is what causes the instabillity in 0.3. >> >> SVG is the actual specification for tkpath, the tk canvas plugin >> mechanism is insufficient to go any further toward SVG, that >> is why Mats started a new canvas implementation --simpler. >> >> tclbitprint and tkpath are unrelated projects, >> both are created by Mats Bengtsson. >> >> So, leave the tclbitprint project to tclbitprint and >> make a new project for tkpath. >> >> -roger >> >> PS: There is a lot more to say about gradients, and your argument >> about gradients as the window background is very sound. > > > I see. To say the truth I also liked better the 0.2.x implementation > of gradients (which could be defined outside of a canvas), than the > 0.3.x approach (the gradients have to be defined inside the canvas > widget). > This way the same gradient has to be defined multiple times (one for > each canvas widget that uses it). ....and cached... The change was necessary for technical reasons: redrawing of an element with a gradient doesn't work properly within 0.2 > I still haven't used groups and surfaces, so I cannot comment on them :-) > > George I suspect the creation of surface was related to tclbitprint. Surface can be utilized to export a (SVG) graphic as an image. -roger
From: Georgios Petasis on 10 Mar 2010 19:05 στις 11/3/2010 01:53, O/H Arndt Roger Schneider έγραψε: >> I see. To say the truth I also liked better the 0.2.x implementation >> of gradients (which could be defined outside of a canvas), than the >> 0.3.x approach (the gradients have to be defined inside the canvas >> widget). >> This way the same gradient has to be defined multiple times (one for >> each canvas widget that uses it). > > ...and cached... > > The change was necessary for technical reasons: redrawing of > an element with a gradient doesn't work properly within 0.2 > Does this relate to the faulty behaviour of the 0.2.x series shown in this image? http://www.ellogon.org/~petasis/tcl/Images/WP4Toolkit.png All boxes have the same gradient, but are drawn differently. George
From: Arndt Roger Schneider on 11 Mar 2010 05:07 Georgios Petasis schrieb: > στις 11/3/2010 01:53, O/H Arndt Roger Schneider έγραψε: > >>> I see. To say the truth I also liked better the 0.2.x implementation >>> of gradients (which could be defined outside of a canvas), than the >>> 0.3.x approach (the gradients have to be defined inside the canvas >>> widget). >>> This way the same gradient has to be defined multiple times (one for >>> each canvas widget that uses it). >> >> >> ...and cached... >> >> The change was necessary for technical reasons: redrawing of >> an element with a gradient doesn't work properly within 0.2 >> > > Does this relate to the faulty behaviour of the 0.2.x series shown in > this image? > http://www.ellogon.org/~petasis/tcl/Images/WP4Toolkit.png > All boxes have the same gradient, but are drawn differently. > > George Not likely. It's a transient effect, objects ain't automatically refreshed after changing the gradient, the Z-order gets disrupted, too. Show some code pieces. -roger
From: George Petasis on 11 Mar 2010 05:29 στις 11/3/2010 12:07 μμ, O/H Arndt Roger Schneider έγραψε: > Georgios Petasis schrieb: > >> στις 11/3/2010 01:53, O/H Arndt Roger Schneider έγραψε: >> >>>> I see. To say the truth I also liked better the 0.2.x implementation >>>> of gradients (which could be defined outside of a canvas), than the >>>> 0.3.x approach (the gradients have to be defined inside the canvas >>>> widget). >>>> This way the same gradient has to be defined multiple times (one for >>>> each canvas widget that uses it). >>> >>> >>> ...and cached... >>> >>> The change was necessary for technical reasons: redrawing of >>> an element with a gradient doesn't work properly within 0.2 >>> >> >> Does this relate to the faulty behaviour of the 0.2.x series shown in >> this image? >> http://www.ellogon.org/~petasis/tcl/Images/WP4Toolkit.png >> All boxes have the same gradient, but are drawn differently. >> >> George > > Not likely. It's a transient effect, objects ain't automatically > refreshed after changing the > gradient, the Z-order gets disrupted, too. > > Show some code pieces. > > -roger The screenshot dates back to 2007, no need to see that code any more :-) I tried to use tkpath back then in a project, but I gave up because of this bug. But it was at the times tkpath was making its first steps. I tried again now, and tkpath works for me, apart from some minor issues, which I fixed in the CVS. The latest screenshot is here: http://www.ellogon.org/~petasis/tcl/TkRibbon/images/EllogonSystem-Gradient.png (It is the same code as the previous screenshot with minor tweaks to use a tkpath canvas). George
First
|
Prev
|
Pages: 1 2 Prev: Tell if command was invoked from menu or button? Next: bidirectional pipe question |