tcllib-devel — Discussion of development for tcllib

Re: [Tcllib-devel] Next Tcllib release (1.12) ...

[Arjen M. <arj...@de...>]

On 2009-10-27 12:30, Larry W. Virden wrote:
> On Mon, Oct 26, 2009 at 6:48 PM, Andreas Kupries
> <and...@ac...> wrote:
> 
>> Based on these dates my proposal
>>
>>        Mo Nov  9       4 weeks Testing, CVS bugfix commits, writing up release
>>                                notes, fixing version numbers.
>>        Mo Dec  7       1 week  RC available for general testing, CVS frozen
>>        Mo Dec 14       Release
>>
> 
> Should one of the goals be to run the test suite against the current
> CVS head for Tcl 8.5 and 8.6, to verify the various modules are
> working against the current release as well as the impending release?
> 

That would be an excellent test for 8.6, I'd say.

Regards,

Arjen

Re: [Tcllib-devel] Next Tcllib release (1.12) ...

[Larry W. V. <lv...@gm...>]

On Mon, Oct 26, 2009 at 6:48 PM, Andreas Kupries
<and...@ac...> wrote:

> Based on these dates my proposal
>
>        Mo Nov  9       4 weeks Testing, CVS bugfix commits, writing up release
>                                notes, fixing version numbers.
>        Mo Dec  7       1 week  RC available for general testing, CVS frozen
>        Mo Dec 14       Release
>

Should one of the goals be to run the test suite against the current
CVS head for Tcl 8.5 and 8.6, to verify the various modules are
working against the current release as well as the impending release?


-- 
Tcl - The glue of a new generation.   http://wiki.tcl.tk/
Larry W. Virden
http://www.xanga.com/lvirden/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

[Tcllib-devel] Next Tcllib release (1.12) ...

[Andreas K. <and...@ac...>]

Well, we missed doing a release for the Tcl Conference at the beginning of the 
month.

The next natural place would be in December, as a Xmas release. The last 
possible day for that is Dec 18 2009, because after that I am in vacation, till 
Jan 15, 2010.

Based on these dates my proposal

	Mo Nov  9	4 weeks	Testing, CVS bugfix commits, writing up release
				notes, fixing version numbers.
	Mo Dec	7	1 week	RC available for general testing, CVS frozen
	Mo Dec 14	Release

-- 
Sincerely,
     Andreas Kupries <an...@ac...>
     Developer @    <http://www.activestate.com/>

Re: [Tcllib-devel] Question about BWidget CVS update problem (util.tcl)...

[Harald O. <Har...@El...>]

Dear Johann,

sorry that you meet dificulties about cvs. Please keep reading and try 
to understand how it works.

 > Dear Admin's,
dear admin too ;-)

 > After checking out "bwidget-1-9-0" I do not get util.tcl Version1.16
 > (which appears to be the very lates change from Harald) -instead the
 > util.tcl V1.15 appears in the sandbox.
 > Subsequently, when doing the commit with the new version 1.17 - I get a
 > failure.

It is not "tagged". Please checkout the trunc or do an update.
Tagging is only done for releases.
---
Long reading following: my 2 coins about cvs best practive and bwidget.
I post this to everybody to eventually collect other pennies.

I think, the magic is, that I have committed the patch twice, one in 
trunc and once in the branch called "bwidget".

The reason was that I planned to give up compatibilitity to tcl8.1 in 
the trunc. And this version should keep this compatibility and should 
get only bug fixes. You may do this differently.
For me, it was to use for example "if {$a eq "a"}" and other convenient 
things of recent releases in the trunc.

To do any operations on the branch, add a "-r bwidget" to all commands.

You may do this differently. This was my plan and I still follow it.
But things are different now. This depends on you, I wait for your input 
on the compatibility issue.

How to change files in cvs:
- make your version ready in a private folder
- do a checkout or an update, if you already have a checkout:
(replace update by checkout to make a checkout)
cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib update 
-P bwidget
- make your changes by copying your version into it
- Make a remark in the "ChangeLog"
- commit to cvs. I propose to use the changelog remark verbatim in the 
commit remark. I have done this by cut and paste into the editor. The 
cvs command is:
cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib commit 
bwidget

The crucial point is the "update". You will get commit errors.
That is also the reason why you should work on a private copy.
The update may destroy modifications you have done when another guy (me)
modified at the same source code line.

I suppose, this is the issue with the modified "utils.tcl" file.
Please opy your version and invoke an update on the ckeckout.

Please remark, that it is common practive to modify multiple files at a 
time using one commit, if the modification belon to one enhancement.

I personnally always collected all patches over one day and committed it 
once a day to cvs. There are at least two files modified: ChangeLog and 
the modified source.

This does not work to add new folders and files. I have not done this 
but you did.

I used the web interface at sourceforge a lot how others did things and 
copied it. There, you may also explore the issue with the bwidget sticky 
tag (branch). Go on "csv browse" and enter "bwidget" as sticky tag to 
see the branched version. All modified files will get version ids with 
four numbers (dynhelp 1.20.2.1).

[Tcllib-devel] Question about BWidget CVS update problem (util.tcl)...

[Johann O. <joh...@go...>]

Dear Admin's,

sorry to disturb you with a (very basic) question regarding cvs.
When trying to update files with cvs, I got stuck in the middle of the  
process:

After checking out "bwidget-1-9-0" I do not get util.tcl Version1.16  
(which appears to be the very lates change from Harald) -instead the  
util.tcl V1.15 appears in the sandbox.
Subsequently, when doing the commit with the new version 1.17 - I get  
a failure.

Versions aren't tagged correctly for util.tcl ?

Maybe someone can help me out with this issue - I lost quite some time  
with various trials...
Is there a quick guide for cvs somewhere around and maybe a proposal  
for a reasonable good CVS client program for the Mac?

Due to this problem, bwidget-1-9-1 remains inconsistent and the update  
isn't completed yet.

Many thanks & Rgds,
   Johann

Re: [Tcllib-devel] BWidget Revitalization... my sourceforge user name is now activated - heureka!

[Johann O. <joh...@go...>]

Hello Andreas,

thank you very much!

I am now going to update BW's CVS repository step by step. For today I  
just created a new file "themeutil.tcl" as a 1st test ...
When the update is finished and tagged to 1.9.1 (hopefully tomorrow) I  
'll let you know.
Harald has already promised me to do some tests.

It is possible to change styles in both modes (tk and ttk styled) -  
thank's to <<ThemeChanged>>,  therefore I adopted the demo code as well.

Re: [Tcllib-devel] BWidget Revitalization... my sourceforge user name is now activated - heureka!

[Andreas K. <and...@ac...>]

Johann Oberdorfer wrote:
> Dear Admins,
> 
> after juggling around with google mail, which automatically hided away 
> the notification e-mail (no...@so... 
> <mailto:no...@so...>) I finally managed to register (sorry 
> for the delay), I am now:
> 
> Username: oberdorfer
> Publicly displayed name: Johann Oberdorfer 

Ok, after getting sidetracked by work for a bit I have now added Johann as 
developer to the project (cvs and shell access), and also added him as 
tech+admin for all trackers.

He should now have access he needs to work on BWidget sources and tickets.

Andreas.

Re: [Tcllib-devel] tcllib cvs head test suite vs tcl 8.6 beta?

[Andreas K. <and...@ac...>]

Larry W. Virden wrote:
> I am wondering whether anyone else besides me has tried running the
> latest tcllib test suite against the latest tcl.
> There appears to be some serious changes that will require a bit of
> work. I don't mean changes in the error output of commands - that's
> something that happens frequently.
> 
> I'm seeing things like:
> ---- doctools-idx-50.0.1 start
> 
> ==== doctools-idx-50.0.1 doctools::idx deserialize = docidx, nokeys, ok FAILED
> ==== Contents of test case:
> 
>             I deserialize = $data docidx
>             doctools::idx::structure print [I serialize]
> 
> ---- Test generated error; Return code was: 1
> ---- Return code should have been one of: 0 2
> ---- errorInfo: Unable to locate or load plugin "docidx" (ERROR for slave interp
> 1 : can not find channel named "stdout")

This is something in either the pluginmgr of Tcllib, or in the Tcl SafeBase it 
is using, getting confused by unknown changes in the Tcl core. I think. I 
haven't looked deeper yet.

I seem to recall that you opened a bug report for this already ?!

>     while executing
> :
> and lots more stuff
> :
> This error is occurring through most, if not all, of the doctools test suite.

Andreas.

[Tcllib-devel] tcllib cvs head test suite vs tcl 8.6 beta?

[Larry W. V. <lv...@gm...>]

I am wondering whether anyone else besides me has tried running the
latest tcllib test suite against the latest tcl.
There appears to be some serious changes that will require a bit of
work. I don't mean changes in the error output of commands - that's
something that happens frequently.

I'm seeing things like:
---- doctools-idx-50.0.1 start

==== doctools-idx-50.0.1 doctools::idx deserialize = docidx, nokeys, ok FAILED
==== Contents of test case:

            I deserialize = $data docidx
            doctools::idx::structure print [I serialize]

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: Unable to locate or load plugin "docidx" (ERROR for slave interp
1 : can not find channel named "stdout")
    while executing
:
and lots more stuff
:
This error is occurring through most, if not all, of the doctools test suite.

Re: [Tcllib-devel] BWidget Revitalization... my sourceforge user name is now activated - heureka!

[Johann O. <joh...@go...>]

Dear Admins,

after juggling around with google mail, which automatically hided away  
the notification e-mail (no...@so...) I finally managed to  
register (sorry for the delay), I am now:

Username: oberdorfer
Publicly displayed name: Johann Oberdorfer

Rgds,
   Johann

On Aug 26, 2009, at 6:58 PM, Andreas Kupries wrote:

> Harald Oehlmann wrote:
>> Hello Johann, Hello Jeff, Hello Community,
>> I want to welcome Johann Oberdorfer who pushes BWidget ttk forward.
>> I propose him as tcllib developper how should be active on cvs, file
>> release and the web site. Please provide him with the corresponding
>> rights and the support.
>
> We (the admins) will have to know Johann's user name on SourceForge.
>
> Andreas.

Re: [Tcllib-devel] BWidget Revitalization... progress report 25.08.09

[Andreas K. <and...@ac...>]

Harald Oehlmann wrote:
> Hello Johann, Hello Jeff, Hello Community,
> 
> I want to welcome Johann Oberdorfer who pushes BWidget ttk forward.
> I propose him as tcllib developper how should be active on cvs, file
> release and the web site. Please provide him with the corresponding
> rights and the support.

We (the admins) will have to know Johann's user name on SourceForge.

Andreas.

Re: [Tcllib-devel] BWidget Revitalization... progress report 25.08.09

[Harald O. <Har...@El...>]

Hello Johann, Hello Jeff, Hello Community,

I want to welcome Johann Oberdorfer who pushes BWidget ttk forward.
I propose him as tcllib developper how should be active on cvs, file
release and the web site. Please provide him with the corresponding
rights and the support.

Some folks got an intermediate version of BWidget 1.9.1. You may drop
him (or me) an E-Mail if you want it for evaluation or support purposes.

Most passed discussions of the last month initiated by me about ttk
BWidget are obsolate. I will remove any steps done for TWidget.

Basicly, ttk support will be in the normal package which will be
compatible to tcl/tk 8.4. This package might be BWidget 1.10 or 2.0, I
don't know. The interface stays intact, so no need for 2.0 any more.

I will stay available to bring BWidget foreward and support Johann.
Please support him, too.

Best regards,
Harald

Johann Oberdorfer schrieb:
> Hello Harald and as well hello to Dr.Csaba Nemethi,
> 
> I have done some progress:
> I now merged my code changes with the changes you did (BW 1.9.0) and
> raised the sub-version to 1.9.1.
> I am not completely finished/happy with it, so I am asking for some more
> patient until the code is ready to go.
> 
> Basically I'am planning/proposing to have only one package which is
> initialized as usual with: "package require BWidget".
> Doing so, everything is compatible to previous tcl/tk releases (I am
> still forced to use tcl/tk 8.4 for some techn. reasons - without further
> explanations given here).
> If a programmer want's to have ttk, then here are just 2 more lines
> required:
> 
> package require tile 0.8
> package require BWidget
>   BWidget::using ttk
> 
> Further on in the code, we distinguish between both cases with the
> [BWidget:using ttk] procedure. Unless otherwise stated in the text
> below, using a proc has the advantage to initialize some more extensions
> as well (maybe tablelist package ?). This might be a bit more "future"
> proove, if you agree, performance for 1 more proc to call should not be
> an issue.
> 
> I really like the idea to encapsulate the ttk functionality within the
> package, without confusing the programmer's with additional namings, but
> this is just one opinion of many -  at the end of the day, it's the
> functionality and usability which counts.
> 
> When dealing with tablelist and tablelist_tile the only thing I
> discovered is that you have to take the decision beforehand, what you
> want to have: initializing both on different places in the code will
> raise an error, which drops off a bit of flexibility.
> By the way tablelist is marvelous from the functionality point of view
> and very well documented as well - thank you Csaba.
> 
> Once a tile theme has changed (for interactively choosing a user's
> favorite theme), I am planning to bind to each class, which needs to be
> updated (e.g. ListBox, Notebook, ...) a "_themechanged" procedure, which
> in turn retrieves colors from ttk "ttk::style configure ." and
> propagates them back to BWidget widget's (mostly based on a canvas's).
> Therfore the <<ThemeChanged>> virtual event seems to be perfect - I have
> read through the tablelist source, of this problem is solved there.
> 
> And for sure, there needs to be a createOrUpdateBWCustomStyles procedure
> somehow, for setting up special commonly used style declarations - if
> required. Otherwise styles are defined within each widget related source
> file.
> 
> Oh: I still need to create a sourceforge user. Once this is done I'll
> let you know.
> 
> See attachement for the current developemet version 1.9.1 for testing
> (maybe) - still flagged as preliminary!
> 
> 
> One more thing:
> It's would also be beneficial to gather famous icon themes together and
> put them into one package/project, windxpblue, keramik, plastik, etc,
> ... Q: Does something already exist ?
> 
> Thank you all for support and information - comments are welcome!
> 
> With kind regards,
>     Johann

Re: [Tcllib-devel] Review - Re: Michael Antoniewski committed [45]: Tests, descriptions and some other improvements

[Andreas K. <and...@ac...>]

Michał Antoniewski wrote:
> Next update availiable.

Reviewing rev 46.

> Previous leaks in tests you mentioned are corrected.

Verified.

> And also graph theory section in documentation is done. I arranged it 
> this way (using your idea with subsections):
> - it contains descriptions for almost all problems in graphops
> - problems for which descriptions where quite short have those 
> descriptions near procedure info, e.g. Vertices Cover.
> - information in graph theory section contain the most important facts - 
> mainly it is divided into definitions and generalizations for problems.
> - problems in graph theory section are described generally, without any 
> references to procedures in graphops. All details about particular 
> algorithm or its implementation - like complexity or approximation 
> factor - are included in description of that particular procedure.

That looks like a good organization ... Yes, very nice in the HTML.

> Tomorrow I will send update with last implementation and it's tests.

Ok.

> About Christofides test set, which you probably noticed is not full - 

Not really :/

> I've done those tests but until MaxMatching is done not all tests will 
> be passed (because Greedy MaxMatching is an approximation). I started 
> Max Matching implementation but whole procedure with test set I think 
> will be ended after GSoC as tomorrow (17) there is a start of sending 
> final evaluations. If I saw well in timeline of the project, final 
> evaluation should be sent between 17-24 of August.
>  
> Is it okay, if I add those Christofides tests after the Max Matching is 
> done?

Yes.

> Oh...now I've noticed that it's probably like in mid-term evaluation 
> that now it's again only survey and code will be sent to Google after 
> September 3.... hmmm, I'm curious then if they want us to sent the code 
> made only before August 17 or also code done later can be placed.

Code done later can be placed. The 'code done before Aug 17' refers to the 
project evaluation. In our case that would be the rev 46 you notified us of 
yesterday. Which is in a good enough state to make this a "pass" (*).

However, I do encourage you to continue, to fill in the last gaps. Of course, I 
also hope that you will stay with us (the Tcllib and Tcl community) even after 
the project has really closed, and continue to contribute.


Now I have to find out how/where they expect us to provide the final 
evaluation. There doesn't seem to be a form for this on the GSoC site yet.


(*) The documentation parts were necessary for this, more important than the 
having the latest algorithms, which is why I asked you to switch to that in the 
last weeks.

 > I
> think I have seen something about it at GSoC mailing list...I should 
> find an answer there:)

I am inlining a mail from Alexander Pico here, which I believe is a good 
description of the various dates ...

<q>
	Here is how I interpret the timeline:
http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#timeli
ne

	* Aug 10th: "suggested pencils down" =  Best practices suggests taking
		time to clean-up and document.

	* Aug 17th:  "firm pencils down" = Students are under no obligation
		from the GSoC program to write any code beyond this date. 			Mentors can begin
		submitting evaluations.  *IF* students want to continue writing
		code up until Aug 24th, then great!  Mentor evaluations can
		include work completed during this time, e.g., if relevant to
		the measure of the students performance.

	* Aug 24th: Evaluations are due. Any work performed by students after
		this date won't be reflected in evaluations (obviously) and
		shouldn't be included in the code sample submitted to Google.

	Hope this helps!
	 -Alex
</q>

Andreas

Re: [Tcllib-devel] Review - Re: Michael Antoniewski committed [45]: Tests, descriptions and some other improvements

[Michał A. <ant...@gm...>]

Next update availiable.

Previous leaks in tests you mentioned are corrected.

And also graph theory section in documentation is done. I arranged it this
way (using your idea with subsections):
- it contains descriptions for almost all problems in graphops
- problems for which descriptions where quite short have those descriptions
near procedure info, e.g. Vertices Cover.
- information in graph theory section contain the most important facts -
mainly it is divided into definitions and generalizations for problems.
- problems in graph theory section are described generally, without any
references to procedures in graphops. All details about particular algorithm
or its implementation - like complexity or approximation factor - are
included in description of that particular procedure.

Tomorrow I will send update with last implementation and it's tests.

About Christofides test set, which you probably noticed is not full - I've
done those tests but until MaxMatching is done not all tests will be passed
(because Greedy MaxMatching is an approximation). I started Max Matching
implementation but whole procedure with test set I think will be ended after
GSoC as tomorrow (17) there is a start of sending final evaluations. If I
saw well in timeline of the project, final evaluation should be sent between
17-24 of August.

Is it okay, if I add those Christofides tests after the Max Matching is
done?

Oh...now I've noticed that it's probably like in mid-term evaluation that
now it's again only survey and code will be sent to Google after September
3.... hmmm, I'm curious then if they want us to sent the code made only
before August 17 or also code done later can be placed. I think I have seen
something about it at GSoC mailing list...I should find an answer there:)



Best Regards,
Michał Antoniewski

[Tcllib-devel] Review - Re: Michael Antoniewski committed [45]: Tests, descriptions and some other improvements

[Andreas K. <and...@ac...>]

gra...@al... wrote:
> 
> Tests, descriptions and some other improvements
> Commit from user: Michael Antoniewski
> 
> More details 
> <http://code.assembla.com/graphmanipulations/subversion/changesets/45>

I found that a number of the new tests have resource leaks. I.e. they create a 
temp graph in result, and then overwrite the variable, losing the reference, 
and not destroying the temp graph.

I saw this in
	kcenter.test
	mdst.test
	bfs.test

Example of the problem (taken from kcenter):

	set result [lsort -dict [$result arcs]]

	result hold the name of the temp graph, then overwrites it with the
	list of arcs, and now we cannot destroy the tmep graph any longer.
	Should use a different variable, i.e. not 'result', for to hold
	the temp graph, then we can destroy it as part of the test case cleanup
	code.

Overall looking good however.

Andreas.

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Harald O. <Har...@El...>]

Hi Jeff, Hi Community,

thank you for contributing and resuming the situation and tklib.

Personnaly, I would like to use more tklib and treecntrl, but it is just
not the case because BWidget was always so easy to anything still works.
I mainly started supporting BWidget due to anoying ScrolledWindow bugs
(Koen fixed them).

Twidget might see the world, because there is an implementation by
Johann and why not give it a chance.

I would like to have a new widget set using ttk and tcloo and this will
not be BWidget or TWidget but something new (I hope) and propably no
developpment I am involved in (highly missing skills).

---2nd part of this mail---

The following wiget tour reflects the action of our company.
We do not use anything fancy and no ttk at all.
I have deleted widgets we do not use:
      Label, Entry    : Yes for DynHelp
      Button          : Yes for DynHelp and style "Link"
      MainFrame       : Use it all the time, just handy
      TitleFrame      : Use a lot
      ScrolledWindow  &
      ScrollableFrame : Much used, solves many issues of this
complicated corner of tk.
      PanedWindow     : Use this or the core one. Both have
disadvantages when trying to save and restore state (at least some years
ago)
      NoteBook        : Much used instead of core version. The core
version does not have the left/right buttons when the pad list is full.
      ComboBox        : Yes for dynhelp
      SpinBox         : Seldomly used

In resume, we like the fact that BWidget is relatively complete and easy
to use. The points missing in tklib are
- Documentation
- it should feel like a complete solution to manage a gui
- ScrolledWindow/ScrollableFrame
  This is IMHO an important widget, which could also be in the core
  like panedwindow.


Thank you,
Harald

Re: [Tcllib-devel] Graphops - Documentation

[Andreas K. <and...@ac...>]

Michal Antoniewski wrote:
> I reworked structuring like you said, please see if it now looks okay. 

Doing now ...

> In some places I left old style as I thought it looks better for those 
> cases (mainly case of not a lot of text and single arguments). If you 
> like I can change structure for them as well.

... Checking ... Greedy(Weighted)MaxIndependentSet, VerticesCover.

The shorter description does work for them. I would have preferred consistency. 
On the other hand I cannot complain too much here, given that I am often not 
fully consistent either in my work.

> For some procedures with e.g. single graph argument maybe it would look 
> better when it's written in a single line?

Actually for the non-structured description using 2 lines seems to be better 
than one.


> I've added some keywords and a graph theory section. Now, it has only 
> k-approximation algorithm definition but I will scan whole problem set, 
> so maybe some more interesting things could be added (also there is a 
> reference to wiki concerning approximation algorithms). Maybe each 
> problem could have it's definition in that section, but on the other 
> hand there are references which do the same.

I was thinking similarly when looking at the description, i.e. moving the 
definitions to the graph theory section. As for definitions which are the same, 
that would be no problem. You can have multiple references to the same thing.

Note here that we can not only have [section]s, but [subsection]s as well, 
which can be [sectref]'d. I.e. each specific definition could be put into a 
referencable sub-section, and then referenced directly.



>  
>  >>Any particular reason not modifying
>  >>       modules/struct/graphops.man
>  >>directly ?
>  
> Oh, I did so, but I created new documentation folder to separate 
> documentation work from the rest for better access (division) at SVN.

Hm. I am more comfortable with work within the existing structure. It also 
makes comparison easier, as I run a simple diff not only between last and 
current, but also the original baseline and current. The latter gives me a list 
of the files which have been added or changed within the tcllib structure. That 
tells us what we have to save from the project for integration. Well, assuming 
we wish to save only the changed parts. If we don't wish optimize (= save 
space) just saving the whole 'struct' directory would work as well. That also 
assumes that the work was done inside the existing directory and file structure.

> I was also doing some rechecking with test cases, so next upcoming 
> update will include tests.

Rev 44 ...


 >  419:	[emph Note:] Algorithm finds solutions dynamically. It compares all 
possible paths through the graph

When you say 'dynamically', do you mean 'Dynamic Programming' ?

 >  531:	[arg_def {Graph Object} G input]
 >  533:	Graph [arg G].

'The graph to cut.'

 >  535:	[arg_def {List} U input]
 >  536:	
 >  537:	Variable storing first set of nodes (cut) given by solution.
 >  538:	
 >  539:	[arg_def {List} V input]
 >  540:	
 >  541:	Variable storing second set of nodes (cut) given by solution.

U/V are also output, in a sense.


 >  704:	[arg_def {Integer} desiredGlow input]

Typo: Glow --> Flow

 >  727:	for sparse graphs, but also there exist some patological cases (those 
cases generally don't appear in practise) that

Typo: patological -> pathological


 >  728:	make time complexity increase exponentially with the growth of the 
number of nodes.
 >  729:	
 >  730:	[para]
 >  731:	[list_begin definitions]
 >  732:	
 >  733:	[def Arguments:]
 >  734:	[list_begin arguments]
 >  735:	[arg_def {Graph Object} G input]
 >  736:	Input graph.
 >  737:	[arg_def {Node} s input]
 >  738:	Source node for which all distances to each other node in graph [arg 
G] are computed.
 >  739:	[list_end][comment {-- arguments --}]
 >  740:	
 >  741:	[def "Options and result:"]
 >  742:	[list_begin options]
 >  743:	[opt_def -distances]

distances, not -distances, per the code (graphops.tcl, line 1706-1716).

Either fix documentation, or the code.

 >  744:	
 >  745:	When selected [arg outputFormat] is [const distances] - procedure 
returns dictionary containing
 >  746:	distances between source node [arg s] and each other node in graph 
[arg G].
 >  747:	
 >  748:	[opt_def -paths]

Ditto. paths, not -paths


 >  781:	[opt_def -graph]
 >  786:	[opt_def -tree]

Ditto. Compare graphops.tcl, lines 1811-1820.


 >  787:	
 >  788:	When selected [option outputFormar] is [option tree] - procedure 
returns a tree structure ([cmd struct::tree]),

outputFormat


 >  959:	[call [cmd struct::graph::op::createResidualGraph] [arg G] [arg f]]

 >  971:	[arg_def {Graph Object} G input]
 >  972:	Flow network (directed graph where each edge has set attribute: [term 
throughput] ).

Argument f is not documented.



 > 1010:	[call [cmd struct::graph::op::createLevelGraph] [arg Gf] [arg s]]
 > 1021:	[arg_def {Graph Object} G input]

G -> Gf




Andreas.

Re: [Tcllib-devel] Graphops - Documentation

[Michał A. <ant...@gm...>]

I reworked structuring like you said, please see if it now looks okey. In
some places I left old style as I thought it looks better for those cases
(mainly case of not a lot of text and single arguments). If you like I can
change structure for them as well.

For some procedures with e.g. single graph argument maybe it would look
better when it's written in a single line?

I've added some keywords and a graph theory section. Now, it has only
k-approximation algorithm definition but I will scan whole problem set, so
maybe some more interesting things could be added (also there is a reference
to wiki concering approximation algorithms). Maybe each problem could have
it's definition in that section, but on the other hand there are references
which do the same.

>>Any particular reason not modifying
>>       modules/struct/graphops.man
>>directly ?

Oh, I did so, but I created new documentation folder to separate
documentation work from the rest for better access (division) at SVN.

I was also doing some rechecking with test cases, so next upcoming update
will include tests.


Best Regards,
Michał Antoniewski

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Kevin W. <kw...@co...>]

On 8/7/09 3:19 PM, Damon Courtney wrote:
>
>
> The DnD stuff should be more generic to all Tk Widgets and should use
> a command (like tklib/tooltip) instead of embedding an option on every
> single widget to handle drag-and-drop.  A simple DnD package could be
> written that would just drop into any app and allow drag-and-drop
> between widgets in the app.

I've done this with simplednd: 
http://www.codebykevin.com/opensource/xplat_oss.html ... look for 
"simplednd" on the page. I haven't done much with it in an application 
yet, but was planning to stress test it some more and submit it to tklib 
at some point. Anyone's welcome to try it out!

>
>
> The only comment I would make here is that I think the ListBox and
> Tree widget are extremely useful, and the biggest thing that makes
> them so useful is their API.  Treectrl is immensely powerful but a
> real bitch to use if you just want to slap together a quick listbox
> with some icons.  On the other side of that coin, ttk::treeview is
> woefully inadequate for most jobs.

The listbox and tree are the portions of BWidget I use heavily in my own 
apps. Their API is relatively straightforward, and they are very 
configurable. I have no problem turning an ugly Windows-98-style BWidget 
Tree into a reasonable implementation of a modern Mac source list with 
appropriate icons, colors, and so on.

>
> I would rather see a listbox and tree widget both built upon treectrl
> that simply wrap treectrl into the same APi that BWidget already
> uses.  The BWidget API for trees and listboxes is consistent and easy
> to grasp with just a quick look of the docs.  The same cannot be said
> of treectrl.

+1, which is why I don't use treectrl.
>
> This would, of course, create a dependency on treectrl for any
> toolkit.  I don't know how anyone else feels about that, but I
> personally think treectrl should be a part of the core anyway.  I'm
> willing to require it as a dependency because I think you're silly to
> try and make any modern UI without it these days.  I just want it to
> be wrapped for when I just want to slap a little listbox in there.
>
>

The chief problem with this is that treectrl, at least on the Mac, 
delves heavily into the deprecated Carbon API, and doesn't work with the 
new Cocoa version of Tk that will be the standard in 8.6. I'd rather 
leave the tree and listbox widgets as is for this reason. Like 
tablelist, they work best as script-level widgets that aren't so 
dependent on the underlying binary implementation.

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Andreas K. <and...@ac...>]

Harald Oehlmann wrote:
> sftp> put index.html
> Uploading index.html to /home/groups/t/tc/tcllib/bwidget/BWman/index.html
> Couldn't get handle: Permission denied
> sftp> ls -l index.html
> -rw-r--r-- 0 techentin tcllib 230 Aug 3 1999 index.html

> Following the file permissions, only user techentin has write access on
> the files and folders.
> Group access is missing on the rights.


> I suppose this might be a general hint to the tcllib project.
> Nearly all files are not group writeable which is ok if there is one
> maintainer.

Ok. I have now fixed this using the Shell service.
Basically,

(1)	copied BWman to somewhere else,
	the resulting files were then owned by me.
(2)	Changed the permissions to group writable.
(3)	Moved BWman out of the way.
(4)	Moved my copy of BWman into place.

The website seems to still work, and the files are now group writable. 
Hopefully that is now good enough for the sftp access.

Andreas.

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Damon C. <da...@tc...>]

On Aug 7, 2009, at 12:59 PM, Jeff Hobbs wrote:

> On 07/08/2009 9:06 AM, Damon Courtney wrote:
>> What does tklib/widget currently support that is basically ripped  
>> from
>> BWidget?  What widgets from BWidget are actually worth saving?
>
> One thing lacking in tklib/widget is docs for most of the widgets, but
> let me expound a bit on that here and answer the above.  Note that
> tklib/widget uses Ttk where ever possible.
>
> Existing widgets in tklib/widget:
>
> * widget::dialog
>   A dialog shell, with auto-timeout and other features.  Similar to
> BWidget Dialog but with more features
> * widget::menuentry
>   Extends ttk::entry with a drop-down menu icon (e.g. for a search  
> box)
> * widget::calendar & dateentry
>   calendar is a nice little month widget for selecting dates, and
> dateentry extends ttk::entry to make a date-selection entry widget.
> * widget::panelframe & superframe
>   Extended frame styles that wrap up and extend the ones in BWidget.
> * widget::ruler & screenruler
>   Cute little ruler, as widget or special purpose toplevel
> * widget::scrolledwindow & scrolledtext
>   Improvement on BWidget scrolledwindow, and scrolledtext which is  
> more
> of an example widget that extends it
> * widget::statusbar & toolbar
>   Based on BWidget statusbar to start, these became a bit different.
> They could and should be rationalized to the same API, but I let
> statusbar and toolbar diverge a bit as I was playing with APIs that
> "felt right" in actual use.

 From what I have seen, most of the widgets in tklib/widget that  
replace a BWidget counterpart are far superior to the original.  Also,  
because they do use TTK wherever possible, they tend to have a more  
native feel.

> Note that I don't use any DnD stuff, and BWidget's dynamic help is
> inferior (IMO) to tklib/tooltip, so many widgets are pointless when  
> you
> take those "features" away.

The DnD stuff should be more generic to all Tk Widgets and should use  
a command (like tklib/tooltip) instead of embedding an option on every  
single widget to handle drag-and-drop.  A simple DnD package could be  
written that would just drop into any app and allow drag-and-drop  
between widgets in the app.

>     Button 	Deprecated by core

I always wanted a button that was a little more complete.   
Specifically, rather than a separate menubutton widget, why not a - 
menu option on the button?  Then you could have a -command option that  
says, "if the user clicks the button, do this" with a menu arrow on  
the right that could be clicked to drop down the menu (a la back  
buttons on most browsers).

>     LabelEntry 	bad UI
>     ComboBox 	Deprecated by core
>     SpinBox 	Deprecated by core
>     Tree 	Deprecated by core
>     ListBox 	prefer treectrl
>     MessageDlg 	tk_messageBox anyone?
>     ProgressDlg 	Use widget::toolbar with a ttk::progressbar
>     PasswdDlg 	meh
>     SelectFont 	not bad, but I always had to modify some bits
>     SelectColor 	should port this one

The only comment I would make here is that I think the ListBox and  
Tree widget are extremely useful, and the biggest thing that makes  
them so useful is their API.  Treectrl is immensely powerful but a  
real bitch to use if you just want to slap together a quick listbox  
with some icons.  On the other side of that coin, ttk::treeview is  
woefully inadequate for most jobs.

I would rather see a listbox and tree widget both built upon treectrl  
that simply wrap treectrl into the same APi that BWidget already  
uses.  The BWidget API for trees and listboxes is consistent and easy  
to grasp with just a quick look of the docs.  The same cannot be said  
of treectrl.

This would, of course, create a dependency on treectrl for any  
toolkit.  I don't know how anyone else feels about that, but I  
personally think treectrl should be a part of the core anyway.  I'm  
willing to require it as a dependency because I think you're silly to  
try and make any modern UI without it these days.  I just want it to  
be wrapped for when I just want to slap a little listbox in there.

D

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Jeff H. <je...@ac...>]

On 07/08/2009 9:06 AM, Damon Courtney wrote:
> What does tklib/widget currently support that is basically ripped from
> BWidget?  What widgets from BWidget are actually worth saving?

One thing lacking in tklib/widget is docs for most of the widgets, but 
let me expound a bit on that here and answer the above.  Note that 
tklib/widget uses Ttk where ever possible.

Existing widgets in tklib/widget:

* widget::dialog
   A dialog shell, with auto-timeout and other features.  Similar to 
BWidget Dialog but with more features
* widget::menuentry
   Extends ttk::entry with a drop-down menu icon (e.g. for a search box)
* widget::calendar & dateentry
   calendar is a nice little month widget for selecting dates, and 
dateentry extends ttk::entry to make a date-selection entry widget.
* widget::panelframe & superframe
   Extended frame styles that wrap up and extend the ones in BWidget.
* widget::ruler & screenruler
   Cute little ruler, as widget or special purpose toplevel
* widget::scrolledwindow & scrolledtext
   Improvement on BWidget scrolledwindow, and scrolledtext which is more 
of an example widget that extends it
* widget::statusbar & toolbar
   Based on BWidget statusbar to start, these became a bit different. 
They could and should be rationalized to the same API, but I let 
statusbar and toolbar diverge a bit as I was playing with APIs that 
"felt right" in actual use.

In addition to the above, I have unfinished versions of ...

console, calculator, cmdmenu, taskpanel (this one is cool, contributed 
by Jeff Godfrey), and maybe some other stuff.

What about the rest of what BWidget has?  Let me go through the list, 
and you guys can add your own comments.

http://tcllib.sourceforge.net/BWman/contents.html

Note that I don't use any DnD stuff, and BWidget's dynamic help is 
inferior (IMO) to tklib/tooltip, so many widgets are pointless when you 
take those "features" away.

     Label 	Pointless, S.A.
     Entry 	Pointless, S.A.
     Button 	Deprecated by core
     ArrowButton 	99.9% used by ComboBox, deprecated by core
     ProgressBar 	Deprecated by core
     ScrollView 	Never used it, might be easy to port
     Separator 	Deprecated by core

Manager Widgets
     MainFrame 	Manage toplevel with menu, toolbar and statusbar
	I found this not useful, switched to widget::dialog
     LabelFrame 	Deprecated by core
     TitleFrame 	Deprecated by core
     PanelFrame 	Deprecated by core or widget::panelframe
     ScrolledWindow 	widget::scrolledwindow
     ScrollableFrame 	Don't use ... easy to port?
     PanedWindow 	Deprecated by core
     ButtonBox 	Meh, mostly used by MainFrame, prefer other methods
     PagesManager 	Nice if you need it, might be deprecated if the 
ttk::notebook improves to a good tabless-display
     NoteBook 	Deprecated by core
     Dialog 	widget::dialog
     StatusBar 	widget::statusbar

Composite Widgets
     LabelEntry 	bad UI
     ComboBox 	Deprecated by core
     SpinBox 	Deprecated by core
     Tree 	Deprecated by core
     ListBox 	prefer treectrl
     MessageDlg 	tk_messageBox anyone?
     ProgressDlg 	Use widget::toolbar with a ttk::progressbar
     PasswdDlg 	meh
     SelectFont 	not bad, but I always had to modify some bits
     SelectColor 	should port this one

So there is my review.  I encourage comments in support or against, as 
that will help move this or a new widget set forward.

Jeff

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Damon C. <da...@tc...>]

> FWIW we (at ActiveState) have largely dropped BWidget in favor of the
> tklib widget package (which I'm the primary author for) that is snit
> (snidget) based, along with using newer core widgets.
>
> I do wonder the efficacy of a pure ttk TWidget ... done "right", it
> would remove a lot of BWidget cruft and look like tklib/widget.  Of
> course you can just make it 100% BWidget compatible, but that seems to
> be what BWidget 1.9 already is.

BWidget is a fine package, but the underlying structure of the widgets  
is not very nice to program in.  In fact, it's quite a pain in the  
ass.  BWidget 1.9 is a fine, final release of the package.  Call it  
what it is and let's move on to something else.

There are things in BWidget worth saving, but I think we're better off  
taking what is good, moving it into a package like tklib/widget and  
then building on that.  There's a lot of cruft in BWidget that simply  
can't be gotten rid of if you want to maintain any sort of backward  
compatibility.  I don't think that should be our goal.

Which is not to say that the widget-level APIs should change just for  
the sake of change, but I don't think we should include every widget  
currently in the BWidget toolkit in some new toolkit.  Some of the  
widgets are just plain stupid, and several others are completely  
unnecessary.

What does tklib/widget currently support that is basically ripped from  
BWidget?  What widgets from BWidget are actually worth saving?

D

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Jeff H. <je...@ac...>]

On 07/08/2009 12:21 AM, Harald Oehlmann wrote:
> If there is for example a new widget which has an implementation for
> BWidget and TWidget, I would not mind to develop BWidget and release a
> new version. Maybe, it might be senseful, to for example have the same
> widgets in a BWidget 2.2 and TWidget 2.2 release (same release number,
> same widget set).

FWIW we (at ActiveState) have largely dropped BWidget in favor of the 
tklib widget package (which I'm the primary author for) that is snit 
(snidget) based, along with using newer core widgets.

I do wonder the efficacy of a pure ttk TWidget ... done "right", it 
would remove a lot of BWidget cruft and look like tklib/widget.  Of 
course you can just make it 100% BWidget compatible, but that seems to 
be what BWidget 1.9 already is.

Jeff

Re: [Tcllib-devel] TBWidget Branch (please help on cvs organisation)

[Harald O. <Har...@El...>]

Jeff Hobbs wrote:
> I would not not create the modified BWidget "2.0" until you actually
> have changes to implement.  Don't strip out ttk support and call that
> 2.0, as that seems pointless.  If noone else steps up to support it that
> is OK, but only create a new version if you plan to push it forward.
>
> We can live with BWidget 1.9 and TWidget 2.0.
>> BWidget
>> - Package name: BWidget
>> - cvs: branch "BWidget" of module BWidget of tcl-lib
>> - next release version: 2.0
>> - tcl/tk 8.2 or newer
>> - no ttk support at all, will be removed

Ok.

The current support for ttk in BWidget is only useable the way "use what
is senseful" but for example specifying a -bg somewhere leads mostly to
error messages and undefined state.

So the plan is:
- do not use BWidget with ttk - no support here - plan to remove what is
there (time frame: 1 year)
- use TWidget with ttk (when it is there)

About version numbers:
1.9 or 2.0 - I want to stay open here.
No need to do things without reason but there should be a scope.

If there is for example a new widget which has an implementation for
BWidget and TWidget, I would not mind to develop BWidget and release a
new version. Maybe, it might be senseful, to for example have the same
widgets in a BWidget 2.2 and TWidget 2.2 release (same release number,
same widget set).
I don't know, we will see.


Thank you,
Harald