Menu
▾
▴
tcllib-devel
|
From: Jeff H. <je...@ac...> - 2009-06-09 21:24:09
|
Hi Harald, On 09/06/2009 8:42 AM, Harald Oehlmann wrote: > Jeff Hobbs schrieb: >> On 07/05/2009 1:35 AM, Harald Oehlmann wrote: >>> in a recent discussion about BWidget, you spoke about little >>> resources to fix bugs or accept patches in BWidgets. >>> >>> Could I help here ? I could do administrative, code and >>> testing tasks on windows and linux. >> It is always helpful if someone triages the bugs list, weeded out the >> ones that are no longer reproducible, or confirming more clearly the >> vaguely worded bugs with reproducible steps. >> >> However the harder part would be the general maintenance and fixes. >> Kevin Walzer already looked into it and decided that indeed the core >> coding of BWidgets is rather complicated. >> >> However, it should still have some life in it should you choose to do a >> bug triage. > > I started the bug triage last week. > There are now 3 patches which might just fix issues. > > What would be a good way to apply patches and finally maintain the code. > > Could you grant me privilegies to do so or is there another way ? Thanks very much for triaging the bwidgets bug area. I am cc'ing Damon, who had assisted in maintenance before, and tcllib-devel in general to let them know you have been added in and will be poking around that area. If anybody else has the time and will to assist Harald, that would be appreciated. When you feel BWidgets needs a "release", ping back and we'll work on cementing one. Thanks again, Jeff |
|
From: Jeff H. <je...@ac...> - 2009-08-05 16:59:19
|
On 04/08/2009 11:31 PM, Harald Oehlmann wrote: >> Note that if you do that, rename all the lower level APIs (_after_ >> branching) so that TWidget and BWidget can both be used in the same app. >> If that isn't necessary, then call it BWidget 2.0 and just force the >> issue. > > I would like to rename the package. I did not plan to enable the > possibility to load BWidget and TWidget simultaneously, so no renaming > of for example namespace "Widget". > > The name difference is to allow that both packages exist simultaneously. If you don't expect them to both be loaded simultaneously, then BWidget 1.9 and 2.0 are just fine. Especially if you don't rename the underlying namespaces. Both of those can be on the system, since Tcl supports that perfectly fine, it will just be a matter of the end user saying: package require BWidget 1|2 Now of course without the version number, it will find 2, but if that is actually widget-name-and-function compatible (theming issues aside), then that isn't an issue anyways. Jeff |
|
From: Damon C. <da...@tc...> - 2009-06-09 22:05:36
|
> Thanks very much for triaging the bwidgets bug area. I am cc'ing > Damon, who had assisted in maintenance before, and tcllib-devel in > general to let them know you have been added in and will be poking > around that area. If anybody else has the time and will to assist > Harald, that would be appreciated. > > When you feel BWidgets needs a "release", ping back and we'll work > on cementing one. I can help with this. I haven't looked at the BWidget code in a long while, but I'm still very familiar with all of it and how everything comes together. Just let me know if you have any questions, or if you need some advice or help on the release. Like Jeff says, when you think you're ready for a release, we'll hammer one together. Lords knows it could use one. 0-] Damon |
|
From: Harald O. <Har...@El...> - 2009-06-10 08:22:13
|
Damon Courtney schrieb: >> Thanks very much for triaging the bwidgets bug area. I am cc'ing >> Damon, who had assisted in maintenance before, and tcllib-devel in >> general to let them know you have been added in and will be poking >> around that area. If anybody else has the time and will to assist >> Harald, that would be appreciated. >> >> When you feel BWidgets needs a "release", ping back and we'll work on >> cementing one. > > I can help with this. I haven't looked at the BWidget code in a long > while, but I'm still very familiar with all of it and how everything > comes together. Just let me know if you have any questions, or if you > need some advice or help on the release. Like Jeff says, when you think > you're ready for a release, we'll hammer one together. Lords knows it > could use one. 0-] > > Damon Hi Damon, Hi Jeff, hi community, thank you, so I may start. I would also appreciate if you monitor my activities. I am new in this field. I will contact you in case of any ideas. Harald |
|
From: Harald O. <Har...@El...> - 2009-07-20 13:11:16
|
Hi Damon, Hi Jeff, Hi community,
1) Tag BWidget 1.9
IMHO BWidget made a good step in direction bug fixing.
I plan to release the 1.9 bugfix release friday this week.
Are there any objections about that ?
2) Themed BWidget:
I propose to move BWidget direction themed widgets (e.g. ttk).
The last fix which was included (Scrollable Frame) showed, that it
requires quite a couple of trade-offs to support tk and ttk in the same
packages. The number of "if {[Widget::themed]}" are increasing and hit
the parameter level now.
I suggest to branch BWidget here into two loadable packages:
- BWidget - tk version (requires tk 8.1 (afaik))
- TBWidget - ttk version (requires tk 8.5)
They should be compatible if senseful (as tk and ttk).
The difference is to issue a different "package require".
If you don't use any themed parameters, they should be identical on the
script level. In future, both may move forward and new widgets may only
be implemented in one of them.
All current themed code will be removed from BWidget and will only be
present in TBWidget (here, someone may complain. The current
Implementation is IMHO only half functional as for example the -bg
parameter mostly runs into an error).
If both packages would be loadable together ?
Propably not.
Please discuss the issue on this list.
Looking forward to your comments,
Harald
|
|
From: Harald O. <Har...@El...> - 2009-08-03 13:10:58
|
Hi community, **I would apreciate, if a tcl-lib expert would answer the question at the end of this e-mail** as announced in my email on this list: Subject: [Tcllib-devel] BWidget verification, tagging and TBWidget Date: 2009-07-20 it is planed to branch BWidget into two source trees: - BWidget - use tk8.1 and later, no ttk code - TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code Why two source trees ? It is a real split of scope. BWidget is complicated enough. To support ttk and tk, many code will be doubled. In addition, I don't want to drop tk8.1 compatibility, but many things just would be more elegant and some work-arounds will go away. I am in doubt on the cvs level how to do this. Two alternatives: 1) use module bwidget and put TBWidget into a branch How to branch: cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib rtag -b -r bwidget-1-9-0 tbwidget bwidget How to checkout: cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib checkout -r tbwidget -P bwidget Advantage: all history kept Disadvantages: - No head revision for tbwidget - Have to specify -r tbwidget on all operations for tbwidget 2) Create a new module tbwidget cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib import tbwidget oehhar tbwidget Advantage: Own head revision for BWidget and TBWidget, much clearer Disadvantage: file history lost for TBWidget 3) do something else ??? Other ideas ? Migrate to subversion where this is not an issue ;-) Properties of both solutions: - No change for BWidget on the cvs level Thank you for any insights. Regards, Harald |
|
From: Jeff H. <je...@ac...> - 2009-08-04 23:54:09
|
On 03/08/2009 5:59 AM, Harald Oehlmann wrote: > it is planed to branch BWidget into two source trees: > - BWidget - use tk8.1 and later, no ttk code > - TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code FWIW, I would just call it TWidget. Not sure about dropping 8.4+tile at this point - any reason not to still support that rather common combination? > 1) use module bwidget and put TBWidget into a branch > > How to branch: > > cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib rtag -b > -r bwidget-1-9-0 tbwidget bwidget > > How to checkout: > > cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib > checkout -r tbwidget -P bwidget > > Advantage: all history kept > Disadvantages: > - No head revision for tbwidget > - Have to specify -r tbwidget on all operations for tbwidget I would instead recommend that TWidget become the head of the bwidget repository, with BWidget 1.9 becoming the 1-9-0 branch. I don't see any major work will be done on that, so essentially what we are doing is creating BWidget 2.0, and just calling it TWidget to reduce confusion. Note that if you do that, rename all the lower level APIs (_after_ branching) so that TWidget and BWidget can both be used in the same app. If that isn't necessary, then call it BWidget 2.0 and just force the issue. Jeff |
|
From: Koen D. <ko...@re...> - 2009-08-05 09:16:26
|
Harald,
Another option is to simply add some files to the current BWidget sources, to support ttk. For example, there is scrollframe.tcl, and you could add a tscrollframe.tcl file which uses ttk widgets. This has the advantage that tk bwidgets and ttk bwidgets can be used in the same application, which would not be possible in your proposal. (And which is not even possible in the current half-working approach, since there is a single global BWidget::theme variable).
Of course, this is not possible if you want (or need) to rewrite the complete framework (in widget.tcl). But in that case, maybe it would even be better to start from scratch and make a new CWidget package... :-/
Concerning compatibility: I agree it is hard to keep compatible with old Tk releases. I'm really used to operators such as {*}, eq, ne,... and I don't realize anymore they only exist since Tcl 8.5. I really think we should move forward - after all bug fixing on Tk 8.4 has also stopped. People who keep using 8.4, can also keep using BWidget 1.9.
Regards,
Koen
Harald Oehlmann wrote:
> Hi community,
>
> **I would apreciate, if a tcl-lib expert would answer the question at
> the end of this e-mail**
>
> as announced in my email on this list:
> Subject: [Tcllib-devel] BWidget verification, tagging and TBWidget
> Date: 2009-07-20
>
> it is planed to branch BWidget into two source trees:
> - BWidget - use tk8.1 and later, no ttk code
> - TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code
>
> Why two source trees ? It is a real split of scope.
> BWidget is complicated enough. To support ttk and tk, many code will be
> doubled. In addition, I don't want to drop tk8.1 compatibility, but many
> things just would be more elegant and some work-arounds will go away.
>
> I am in doubt on the cvs level how to do this.
>
> Two alternatives:
>
> 1) use module bwidget and put TBWidget into a branch
>
> How to branch:
>
> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib rtag -b
> -r bwidget-1-9-0 tbwidget bwidget
>
> How to checkout:
>
> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib
> checkout -r tbwidget -P bwidget
>
> Advantage: all history kept
> Disadvantages:
> - No head revision for tbwidget
> - Have to specify -r tbwidget on all operations for tbwidget
>
> 2) Create a new module tbwidget
>
> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib import
> tbwidget oehhar tbwidget
>
> Advantage: Own head revision for BWidget and TBWidget, much clearer
> Disadvantage: file history lost for TBWidget
>
> 3) do something else ???
> Other ideas ? Migrate to subversion where this is not an issue ;-)
>
> Properties of both solutions:
> - No change for BWidget on the cvs level
>
> Thank you for any insights.
>
> Regards,
> Harald
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel
>
>
|
|
From: Harald O. <Har...@El...> - 2009-08-05 09:33:36
|
Koen, Thank you contributing. The one Widget::_theme variable may be replaced by widget names or other mechanism, this is IMHO no issue. The issue is IMHO just the raising complexity to support tk and ttk by one set of code. Making a new CWidget (O-T-BWidget) packet is anyway a todo to support oo and ttk. But this is not the aim at the moment. Koen Danckaert schrieb: > Another option is to simply add some files to the current BWidget > sources, to support ttk. For example, there is scrollframe.tcl, and you > could add a tscrollframe.tcl file which uses ttk widgets. This has the > advantage that tk bwidgets and ttk bwidgets can be used in the same > application, which would not be possible in your proposal. (And which is > not even possible in the current half-working approach, since there is a > single global BWidget::theme variable). > > Of course, this is not possible if you want (or need) to rewrite the > complete framework (in widget.tcl). But in that case, maybe it would > even be better to start from scratch and make a new CWidget package... :-/ > Harald Oehlmann wrote: >> it is planed to branch BWidget into two source trees: >> - BWidget - use tk8.1 and later, no ttk code >> - TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code >> >> Why two source trees ? It is a real split of scope. >> BWidget is complicated enough. To support ttk and tk, many code will be >> doubled. In addition, I don't want to drop tk8.1 compatibility, but many >> things just would be more elegant and some work-arounds will go away. |
|
From: Jeff H. <je...@ac...> - 2009-08-05 16:56:35
|
I agree that perhaps 8.5 is now an acceptable base version.
On 05/08/2009 2:16 AM, Koen Danckaert wrote:
> Harald,
>
> Another option is to simply add some files to the current BWidget
> sources, to support ttk. For example, there is scrollframe.tcl, and you
> could add a tscrollframe.tcl file which uses ttk widgets. This has the
> advantage that tk bwidgets and ttk bwidgets can be used in the same
> application, which would not be possible in your proposal. (And which is
> not even possible in the current half-working approach, since there is a
> single global BWidget::theme variable).
>
> Of course, this is not possible if you want (or need) to rewrite the
> complete framework (in widget.tcl). But in that case, maybe it would
> even be better to start from scratch and make a new CWidget package... :-/
>
> Concerning compatibility: I agree it is hard to keep compatible with old
> Tk releases. I'm really used to operators such as {*}, eq, ne,... and I
> don't realize anymore they only exist since Tcl 8.5. I really think we
> should move forward - after all bug fixing on Tk 8.4 has also stopped.
> People who keep using 8.4, can also keep using BWidget 1.9.
>
> Regards,
> Koen
>
>
>
> Harald Oehlmann wrote:
>> Hi community,
>>
>> **I would apreciate, if a tcl-lib expert would answer the question at
>> the end of this e-mail**
>>
>> as announced in my email on this list:
>> Subject: [Tcllib-devel] BWidget verification, tagging and TBWidget
>> Date: 2009-07-20
>>
>> it is planed to branch BWidget into two source trees:
>> - BWidget - use tk8.1 and later, no ttk code
>> - TBWidget - use ttk8.5 and later, no tk and tcl8.1-8.4 code
>>
>> Why two source trees ? It is a real split of scope.
>> BWidget is complicated enough. To support ttk and tk, many code will be
>> doubled. In addition, I don't want to drop tk8.1 compatibility, but many
>> things just would be more elegant and some work-arounds will go away.
>>
>> I am in doubt on the cvs level how to do this.
>>
>> Two alternatives:
>>
>> 1) use module bwidget and put TBWidget into a branch
>>
>> How to branch:
>>
>> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib rtag -b
>> -r bwidget-1-9-0 tbwidget bwidget
>>
>> How to checkout:
>>
>> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib
>> checkout -r tbwidget -P bwidget
>>
>> Advantage: all history kept
>> Disadvantages:
>> - No head revision for tbwidget
>> - Have to specify -r tbwidget on all operations for tbwidget
>>
>> 2) Create a new module tbwidget
>>
>> cvs -z3 -d:ext:oe...@tc...:/cvsroot/tcllib import
>> tbwidget oehhar tbwidget
>>
>> Advantage: Own head revision for BWidget and TBWidget, much clearer
>> Disadvantage: file history lost for TBWidget
>>
>> 3) do something else ???
>> Other ideas ? Migrate to subversion where this is not an issue ;-)
>>
>> Properties of both solutions:
>> - No change for BWidget on the cvs level
>>
>> Thank you for any insights.
>>
>> Regards,
>> Harald
|
|
From: Donald G P. <don...@ni...> - 2009-08-05 17:03:34
|
Jeff Hobbs wrote:
>> Concerning compatibility: I agree it is hard to keep compatible with old
>> Tk releases. I'm really used to operators such as {*}, eq, ne,... and I
>> don't realize anymore they only exist since Tcl 8.5. I really think we
>> should move forward - after all bug fixing on Tk 8.4 has also stopped.
>> People who keep using 8.4, can also keep using BWidget 1.9.
If you drop support for an older Tcl or Tk, be sure to use filtering
in the index script so that if your new BWidget release gets installed
within reach of one of those older Tcl or Tk libraries, they continue
to get the older BWidget version they can use, and not the new one that
will fail.
--
| Don Porter Mathematical and Computational Sciences Division |
| don...@ni... Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
|
|
From: Andreas K. <and...@ac...> - 2009-08-05 17:20:47
|
Donald G Porter wrote:
> Jeff Hobbs wrote:
>>> Concerning compatibility: I agree it is hard to keep compatible with old
>>> Tk releases. I'm really used to operators such as {*}, eq, ne,... and I
>>> don't realize anymore they only exist since Tcl 8.5. I really think we
>>> should move forward - after all bug fixing on Tk 8.4 has also stopped.
>>> People who keep using 8.4, can also keep using BWidget 1.9.
>
> If you drop support for an older Tcl or Tk, be sure to use filtering
> in the index script so that if your new BWidget release gets installed
> within reach of one of those older Tcl or Tk libraries, they continue
> to get the older BWidget version they can use, and not the new one that
> will fail.
Don is talking about code like
andreask@gila:~/lsf/tcllib/modules> cat amazon-s3/pkgIndex.tcl
# pkgIndex.tcl --
# Copyright (c) 2006 Darren New
# This is for the Amazon S3 web service packages.
if {![package vsatisfies [package provide Tcl] 8.5]} {return}
package ifneeded xsxp 1.0 [list source [file join $dir xsxp.tcl]]
package ifneeded S3 1.0.0 [list source [file join $dir S3.tcl]]
I.e. code which prevents the registration of the package if the Tcl core
running the script is not up to snuff to support the package.
That way an older Tcl will not even see the newer package, and keep using the
older one. Assuming that both are installed.
Andreas
|
|
From: Harald O. <Har...@El...> - 2009-08-06 07:04:43
|
Hello Community,
thank you all for your contributions.
To resume:
TWidget:
- Packet name: TWidget
- cvs: head of module BWidget of tcl-lib
- first release version: 2.0
- tcl/tk 8.5 or newer
- supports ttk as much as possible
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
The packages will use:
if {![package vsatisfies [package provide Tcl] 8.5]} {return}
to avoid loading in a non-suitable interpreter
Why two package names:
- to allow current BWidget to continue evolving and to allow a release
of 2.0
- Why version numbers 2.0 for both packages ?
To terminate the common 1.x period, where both packages were still unified.
- I do not think BWidget is dead when TWidget is out.
Further actions:
- create the item TWidget for the tracker (bugs/patch/feature request)
(have already read about, will find it I think)
- create a file release area (no problem)
Actions I do not know how to do (please help):
- Update web page: http://tcllib.sourceforge.net/
- Currently, the BWidget docs are old and I would like to update them
- add TWidget and TWidget documentation
* should I perform this task or is there someone else for this task ?
Thank you all,
Harald
|
|
From: Jeff H. <je...@ac...> - 2009-08-06 22:25:04
|
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.
My $.02,
Jeff
On 05/08/2009 11:55 PM, Harald Oehlmann wrote:
> Hello Community,
>
> thank you all for your contributions.
>
> To resume:
>
> TWidget:
> - Packet name: TWidget
> - cvs: head of module BWidget of tcl-lib
> - first release version: 2.0
> - tcl/tk 8.5 or newer
> - supports ttk as much as possible
>
> 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
>
> The packages will use:
> if {![package vsatisfies [package provide Tcl] 8.5]} {return}
> to avoid loading in a non-suitable interpreter
>
> Why two package names:
> - to allow current BWidget to continue evolving and to allow a release
> of 2.0
> - Why version numbers 2.0 for both packages ?
> To terminate the common 1.x period, where both packages were still unified.
> - I do not think BWidget is dead when TWidget is out.
>
> Further actions:
> - create the item TWidget for the tracker (bugs/patch/feature request)
> (have already read about, will find it I think)
> - create a file release area (no problem)
>
> Actions I do not know how to do (please help):
>
> - Update web page: http://tcllib.sourceforge.net/
> - Currently, the BWidget docs are old and I would like to update them
> - add TWidget and TWidget documentation
> * should I perform this task or is there someone else for this task ?
>
> Thank you all,
> Harald
|
|
From: Harald O. <Har...@El...> - 2009-08-07 07:30:28
|
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 |
|
From: Jeff H. <je...@ac...> - 2009-08-07 16:00:27
|
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 |
|
From: Damon C. <da...@tc...> - 2009-08-07 16:33:09
|
> 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 |
|
From: Jeff H. <je...@ac...> - 2009-08-07 18:00:28
|
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 |
|
From: Damon C. <da...@tc...> - 2009-08-07 19:20:05
|
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 |
|
From: Kevin W. <kw...@co...> - 2009-08-07 22:49:45
|
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 |
|
From: Harald O. <Har...@El...> - 2009-08-10 17:38:13
|
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
|
|
From: Harald O. <Har...@El...> - 2009-08-07 07:11:42
|
Hi Andreas, thank you for the sftp hint. Unfortunately, my permissions do not seam to be sufficient: Andreas Kupries schrieb: > https://sourceforge.net/project/admin/features.php?group_id=12883 > Project Web I get a web page (while logged in in sourceforge) saying: Permission Denied Access to this page is restricted (either to project members or to project administrators) and you do not meet the requirements to access this page. Please contact the administrator of this project for further assistance. > https://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web I tried: sftp oehhar,tc...@we... Login worked. But when uploading files: 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 sftp> del index.html Invalid command. sftp> rm index.html Removing /home/groups/t/tc/tcllib/bwidget/BWman/index.html Couldn't delete file: Permission denied 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. |
|
From: Andreas K. <and...@ac...> - 2009-08-07 19:26:06
|
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. |
|
From: Andreas K. <and...@ac...> - 2009-08-06 16:14:54
|
Harald Oehlmann wrote: > Actions I do not know how to do (please help): > > - Update web page: http://tcllib.sourceforge.net/ > - Currently, the BWidget docs are old and I would like to update them > - add TWidget and TWidget documentation https://sourceforge.net/project/admin/features.php?group_id=12883 Project Web ==> https://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web This has an example on how to upload files to a project's web area using sftp. Similarly it should be possible to list the existing files. > * should I perform this task or is there someone else for this task ? Andreas. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X