tcllib-devel — Discussion of development for tcllib

Re: [Tcllib-devel] [Tcl-soc2008] GSoC 2009: Where do we stand so far?

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

Clif Flynt wrote:
> Hi,
>   I've exchanged some e-mail with Kryzstof, who worked with
> me last year, and Joe English about seeing if we can put the kind
> of introspection into the TTK widgets that normal Tk widgets support.
> 
>   I've jumped through all the hoops with Google, and should see the
> money from last year's efforts showing up in the next bank statement.
> 
>   Do we have the wiki and/or whatever infrastructure for managing the
> proposals set up?  Would someone remind me where it is if I've been too
> lost in the weeds to notice?

"Project Ideas for Google Summer of Code 2009" is at
	http://wiki.tcl.tk/22182

Andreas.

Re: [Tcllib-devel] GSoC 2009: Where do we stand so far?

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

Hi Clif,

a bunch of proposals have been collected at http://wiki.tcl.tk/22182.

Regards,

Arjen

On 2009-02-19 13:50, Clif Flynt wrote:
> Hi,
>   I've exchanged some e-mail with Kryzstof, who worked with
> me last year, and Joe English about seeing if we can put the kind
> of introspection into the TTK widgets that normal Tk widgets support.
> 
>   I've jumped through all the hoops with Google, and should see the
> money from last year's efforts showing up in the next bank statement.
> 
>   Do we have the wiki and/or whatever infrastructure for managing the
> proposals set up?  Would someone remind me where it is if I've been too
> lost in the weeds to notice?
> 
>   Thanks,
>   Clif
> 


Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. 

 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Tcllib-devel] GSoC 2009: Where do we stand so far?

[Clif F. <cl...@cf...>]

Hi,
  I've exchanged some e-mail with Kryzstof, who worked with
me last year, and Joe English about seeing if we can put the kind
of introspection into the TTK widgets that normal Tk widgets support.

  I've jumped through all the hoops with Google, and should see the
money from last year's efforts showing up in the next bank statement.

  Do we have the wiki and/or whatever infrastructure for managing the
proposals set up?  Would someone remind me where it is if I've been too
lost in the weeds to notice?

  Thanks,
  Clif

-- 
... Clif Flynt ... http://www.cwflynt.com ... cl...@cf... ...
.. Tcl/Tk: A Developer's Guide (2nd edition) - Morgan Kauffman ..
.... 16'th Annual Tcl/Tk Conference:  2009,  West Coast, USA ....
.............  http://www.tcl.tk/community/tcl2008/  ............

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

Joe English wrote:
> Andreas Kupries wrote:
> 
>> Joe English wrote:
>>> The fd.o spec
>> Googling for this ... This is the "freedesktop.org" specification ? Is there
>> particular sub-spec I should look at ?
> 
> That would be the freedesktop.org "Icon Theme Specification",
> see previous message:
> 
> | [1] http://freedesktop.org/wiki/Specifications/icon-theme-spec
> | [2] http://freedesktop.org/wiki/Specifications/basedir-spec
> | [3] http://freedesktop.org/wiki/Specifications/icon-naming-spec
> 
> ... which looks like it got delivered out of order,
> see *next* message :-)

Correct.

> 
>>  > classifies icons by size (12x12, 16x16, 32x32, 36x36, etc...);
>>> there can be multiple versions of a single icon at different sizes.
>>> I find it more useful to classify them by "context", i.e.,
>>> icons for menus, for buttons, for toolbars, for dialog boxes, etc., ...
>>> (This fits in nicely with Oakley's "Actions").

>> Hm. Not sure if I understand this correctly ... different icons for the same
>> action but in different contexts ?
> 
> Yes: you might want a 12x12 icon for use in menus,
> a 24x24 icon for command button -images, and a 48x48 icon
> for toolbar button -images.  I find it more convenient to say
> "Gimme an icon that will fit in a menuitem -image" than have
> to remember that menuitem images are 12x12.  The appropriate
> size icon for a particular context can also vary by platform
> and/or user and application preferences.

Ok, this definitely makes the picture regarding the handling of size clearer.
Not something the application code specifies directly, but indirectly through 
the context. Explicit sizes should not appear in the highlevel API.

 > In some cases the
> content of the icon itself varies by platform (e.g., dialog
> icons for error/info/question/warning on OSX should be the
> application icon, with the error/info/question symbol as
> an overlay).

Oh. Computed icons ... Or precomputed and put somewhere ... Although computed 
is likely more correct because I am guessing that the e/i/q-symbols are 
provided by OS X itself, in a std location.

>> This is something the package could handle internally ... Look for state
>> specific icons first, and auto-stipple/brighten if no physical icon is found
>> for the requested variant ... Question is, should we ?
> 
> I'd say initially no, YAGNI.  It's just something that I've found
> useful myself occasionally, thought it was worth mentioning.

YAGNI ... Ah, you aren't gonna need it.

Opposite view to JeffH's.

Andreas.

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

[Joe E. <jen...@fl...>]

Andreas Kupries wrote:

> Joe English wrote:
> > The fd.o spec
>
> Googling for this ... This is the "freedesktop.org" specification ? Is there
> particular sub-spec I should look at ?

That would be the freedesktop.org "Icon Theme Specification",
see previous message:

| [1] http://freedesktop.org/wiki/Specifications/icon-theme-spec
| [2] http://freedesktop.org/wiki/Specifications/basedir-spec
| [3] http://freedesktop.org/wiki/Specifications/icon-naming-spec

... which looks like it got delivered out of order,
see *next* message :-)

>  > classifies icons by size (12x12, 16x16, 32x32, 36x36, etc...);
> > there can be multiple versions of a single icon at different sizes.
>
> > I find it more useful to classify them by "context", i.e.,
> > icons for menus, for buttons, for toolbars, for dialog boxes, etc., ...
> > (This fits in nicely with Oakley's "Actions").
>
> Hm. Not sure if I understand this correctly ... different icons for the same
> action but in different contexts ?

Yes: you might want a 12x12 icon for use in menus,
a 24x24 icon for command button -images, and a 48x48 icon
for toolbar button -images.  I find it more convenient to say
"Gimme an icon that will fit in a menuitem -image" than have
to remember that menuitem images are 12x12.  The appropriate
size icon for a particular context can also vary by platform
and/or user and application preferences.  In some cases the
content of the icon itself varies by platform (e.g., dialog
icons for error/info/question/warning on OSX should be the
application icon, with the error/info/question symbol as
an overlay).

> > I've also found it useful to have variants based on state;
>
> Right ... Did not think of that, should have, we have stuff like that in the
> Tcl Dev Kit applications. although not everywhere I believe, there may parts
> managing it automatically ...
>
>  > for instance
> > a toolbar icon might have a grayscale variant for when it's disabled
> > and a brighter variant for when it's active.  (AIUI, Qt and Gtk+
> > manage this programmatically.  Tk can do this to a certain degree --
> > autostippling images when disabled, f'rinstance
>
> This is something the package could handle internally ... Look for state
> specific icons first, and auto-stipple/brighten if no physical icon is found
> for the requested variant ... Question is, should we ?

I'd say initially no, YAGNI.  It's just something that I've found
useful myself occasionally, thought it was worth mentioning.


--Joe English

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

Joe English wrote:
> Andreas Kupries wrote:
> 
>> How are KDE, Gtk, Qt handling the icons ? Do they have a general framework wi
>> th
>> configurable icon search paths ? Or is that part of an app handled by the app
>> itself still ?
> 
> KDE and Gnome applications use the freedesktop "Icon Theme
> Specification" [1] to locate icon themes, which in turn
> is based on the "Desktop Base Directory" spec [2].

Thanks for the references. Getting them now. This mail actually arrived here 
after your 'some other notes' mail. Now it is clear to me that fd.o there meant 
freedesktop.org.

> Those specs just say where to look for icons; what to name
> them (or conversely, what icons an application can expect
> to be present) is described in the "Icon Naming Specification" [3].
> 
> (At least that's how it works in theory.  The KDE and Gnome
> toolkits have support for [1] and [2] built-in, so almost
> all apps use those two, but I'm not sure how widely [3]
> has been adopted.  In the past, icon themes have been
> more-or-less ad-hoc.)

Andreas.

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

The API which gelled in my mind yesterday on the way home and sleeping
over it.

NOTE
	This doesn't contain anything brought up by the continued
	discussion today.

(Names are subject to change)

	icons::loaded
		Returns list containing the names of the icon themes
		in memory.

	icons::themes
		Returns list containing the names of all icon themes
		we can activate/load.

	icons::activate FOO
		Load package 'icons::theme::FOO'
		Switch all icons already in use to this theme if
		possible.

	icons::get name ?theme?

		Get tk image for the named icon. If a theme is
		specified pull the icon from that theme. Without a
		theme specified search through all loaded themes,
		last theme loaded is searched first.

Notes
	I am equating icon themes to packages here, with a standard
	API between the icons framework and the theme packages.

	(This API presently undefined)

	Theme discovery (see above) becomes package discovery. Which,
	while not perfect (package require __bogus +
	(tcl::tm::lisyt+glob)) we have workable solutions for.

	Not necessarily clear from the above, multiple themes can be
	activated, and the theme activated last is the 'active'
	theme. Holes in that theme, i.e. icons the application needs,
	but are not found there, are satisfied by search through the
	older theme. i.e. a stack is managed and searched from the top
	down.

	Re-activating a previously loaded theme brings it to the top
	of the stack, and all icons in use are resolved again to
	ensure that they are switched to the icon in the newly
	activated theme, if at all possible.

	The responsibility for locating the icons searched for is in
	the theme packages. Could be a virtual filesystem, or on disk
	as part of the package, on disk using system search paths
	provided by the desktop environment, etc. Whatever strikes our
	fancy and/or is relevant to how an application is deployed.

Example starpack:

	Have a desktop theme wrapped, and a theme directly containing
	some implementation of all the icons used by the app, as
	fallback for everything not found by the desktop theme.


Onward, to integrate the results of today's discussion.

Andreas.

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

[Joe E. <jen...@fl...>]

Andreas Kupries wrote:

> How are KDE, Gtk, Qt handling the icons ? Do they have a general framework wi
> th
> configurable icon search paths ? Or is that part of an app handled by the app
> itself still ?

KDE and Gnome applications use the freedesktop "Icon Theme
Specification" [1] to locate icon themes, which in turn
is based on the "Desktop Base Directory" spec [2].

Those specs just say where to look for icons; what to name
them (or conversely, what icons an application can expect
to be present) is described in the "Icon Naming Specification" [3].

(At least that's how it works in theory.  The KDE and Gnome
toolkits have support for [1] and [2] built-in, so almost
all apps use those two, but I'm not sure how widely [3]
has been adopted.  In the past, icon themes have been
more-or-less ad-hoc.)

[1] http://freedesktop.org/wiki/Specifications/icon-theme-spec
[2] http://freedesktop.org/wiki/Specifications/basedir-spec
[3] http://freedesktop.org/wiki/Specifications/icon-naming-spec


--Joe English

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

Time to summarize a bit ...

Concepts
	Theme, Icon theme
	*	Each theme has a name, is identified by it.

	*	The totality of all themes forms a set, with no further
		structure.

	Icon
	*	Distinguish between logical and physical identifications.

	*	A single logical icon is identified by a name.
		It can have multiple physical representations.

	*	The set of logical icons can be partitioned into multiple
		sub-sets by various criteria:

		-	standard vs non-standard names aka meanings
		-	context the icon is used in (dialog, menu, button,
			toolbar, ...).

		???	Should the context of the icon be reflected in the
			name, i.e. like
				'menu.folder'	|	'folder.button'
				'button.folder'	|	'folder.menu'

	*	A physical icon is identified by

		Name of the logical icon it belongs to.
		Name of the theme it is made for.
		Size
		Name of the mode it is for.

		The physical icon for the smaller sizes and the active/disabled
		modes can be automatically derived from the largest physical
		icon for mode 'normal' in its equivalence class.

		Physical icons are in the same class if they have identical
		names for logical icon and theme.

	Mode
	*	Three modes, 'normal', 'disabled', and 'active'.
		Normal is the standard look of the icon in the theme.
		Active is 'brighter', i.e. highlighted.
		Disabled is 'greyed out'.

		???	Should we distinguish between 'active' and 'selected'

So, physical icons are organized in a 2-dimensional matrix, with the theme 
names and logical icon names as the axes. Assuming that representations for 
smaller sizes and different modes are computed from the 'normal' icon with a 
standard size this is enough. Otherwise we need two more dimensions.

The structure among the logical icon names due to context of use can be either 
a separate axis (argument in the package API), or folded into the icon name 
through some sort of scheme.



Andreas.

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

On Feb 11, 2009, at 12:18 PM, Jeff Hobbs wrote:

> On 11-Feb-09, at 10:11 AM, Joe English wrote:
>> I've also found it useful to have variants based on state; for
>> instance
>> a toolbar icon might have a grayscale variant for when it's disabled
>> and a brighter variant for when it's active.  (AIUI, Qt and Gtk+
>> manage this programmatically.  Tk can do this to a certain degree --
>> autostippling images when disabled, f'rinstance -- but the results
>> aren't ideal.)
>
> I think this is something we should rely on Tk to do, then improve Tk
> to do it right.  treectrl has an imagetint command that should be used
> by (added into) the core for such things.

I wrote a toolbar for Mac that used imagetint and the transparency  
capabilities of tkpng to make a button that did exactly what it was  
supposed to as a toolbutton.  If the -image option has a single image,  
handling disabled, pressed and active images should be automatic.  If  
they pass in a map of image states, we don't muck with it and let them  
handle it all themselves.

D

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

Joe English wrote:
> Andreas Kupries wrote:

Side note: And what a nice response to something I just hacked together in half 
an hour, on the side, for use in a private app. :D Seems I poked an area of 
(very) high interest.

>>  From the quick look ICONS has at least one thing Jeff wants and I had not
>> cared about in my famfam packages ... Multiple themes, and standard icon name
>> s across themes.
> 
> Some other notes:

Thanks.

> The fd.o spec

Googling for this ... This is the "freedesktop.org" specification ? Is there 
particular sub-spec I should look at ?

 > classifies icons by size (12x12, 16x16, 32x32, 36x36, etc...);
> there can be multiple versions of a single icon at different sizes.

> I find it more useful to classify them by "context", i.e.,
> icons for menus, for buttons, for toolbars, for dialog boxes, etc., ...
> (This fits in nicely with Oakley's "Actions").

Hm. Not sure if I understand this correctly ... different icons for the same 
action but in different contexts ?

> I've also found it useful to have variants based on state;

Right ... Did not think of that, should have, we have stuff like that in the 
Tcl Dev Kit applications. although not everywhere I believe, there may parts 
managing it automatically ...

 > for instance
> a toolbar icon might have a grayscale variant for when it's disabled
> and a brighter variant for when it's active.  (AIUI, Qt and Gtk+
> manage this programmatically.  Tk can do this to a certain degree --
> autostippling images when disabled, f'rinstance

This is something the package could handle internally ... Look for state 
specific icons first, and auto-stipple/brighten if no physical icon is found 
for the requested variant ... Question is, should we ?

 > -- but the results
> aren't ideal.)

Andreas.

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

On 11-Feb-09, at 10:11 AM, Joe English wrote:
> I've also found it useful to have variants based on state; for  
> instance
> a toolbar icon might have a grayscale variant for when it's disabled
> and a brighter variant for when it's active.  (AIUI, Qt and Gtk+
> manage this programmatically.  Tk can do this to a certain degree --
> autostippling images when disabled, f'rinstance -- but the results
> aren't ideal.)

I think this is something we should rely on Tk to do, then improve Tk  
to do it right.  treectrl has an imagetint command that should be used  
by (added into) the core for such things.

Jeff

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

[Joe E. <jen...@fl...>]

Andreas Kupries wrote:
>
>  From the quick look ICONS has at least one thing Jeff wants and I had not
> cared about in my famfam packages ... Multiple themes, and standard icon name
> s across themes.

Some other notes:

The fd.o spec classifies icons by size (12x12, 16x16, 32x32, 36x36, etc...);
there can be multiple versions of a single icon at different sizes.
I find it more useful to classify them by "context", i.e.,
icons for menus, for buttons, for toolbars, for dialog boxes, etc., ...
(This fits in nicely with Oakley's "Actions").

I've also found it useful to have variants based on state; for instance
a toolbar icon might have a grayscale variant for when it's disabled
and a brighter variant for when it's active.  (AIUI, Qt and Gtk+
manage this programmatically.  Tk can do this to a certain degree --
autostippling images when disabled, f'rinstance -- but the results
aren't ideal.)


--Joe English

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

Michael Schlenker wrote:
> Andreas Kupries schrieb:
>> Requesting review of a new module for tklib, before committing.

> Icons in tklib is a good idea.
> 
> Did you look at Adrian Davis ICONS package?
> http://www.satisoft.com/tcltk/icons/

No. I had forgotten that it existed. Thanks for reminding us of it.

... Ok, per http://www.satisoft.com/tcltk/icons/license.html
the code is BSD, and icons themselves are freely distributable.

Ok, one more thing for my todo list, review the API of this library.

(And I better write up my own ideas for the API as much as they have gelled 
since yesterday before I do that to actually have something to compare to).


 From the quick look ICONS has at least one thing Jeff wants and I had not 
cared about in my famfam packages ... Multiple themes, and standard icon names 
across themes.

> It might be good if those could coexist or maybe even use the same
> format/API.

Andreas.

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

[Michael S. <sc...@un...>]

Andreas Kupries schrieb:
> Requesting review of a new module for tklib, before committing.
> 
> Sources available at
> 	ftp://ftp.tcl.tk/pub/incoming/tklib-famfam.tgz
> 	(Can't put up on SF, they limit attachments to 256 KB, this file is 2
> 	MB compressed (6 MB uncompressed)).
> 
> A module containing 2 packages wrapping around the silk and flags icon sets of 
> famfam, to make their use in tcl apps easier. Just require the package, then 
> load an icon/image by name.
> 
> 
> Examples of use
>      package require famfam::silk
>      set arrows [famfam::silk list *arrow*]
>      set rotccw [famfam::silk get arrow_rotate_anticlockwise]
> 
>      package require famfam::flags
>      set dubya [famfam::flags list w*]
>      set wales [famfam::flags get wales]

Icons in tklib is a good idea.

Did you look at Adrian Davis ICONS package?
http://www.satisoft.com/tcltk/icons/

It might be good if those could coexist or maybe even use the same
format/API.

Michael

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

Jeff Hobbs wrote:
> On 10-Feb-09, at 3:35 PM, Andreas Kupries wrote:
>> Jeff Hobbs wrote:
>>> Another couple of thoughts on this ... plugin-like would be similar 
>>> to  themes and how we can add themes to Ttk.
>>
>> Hm ... Ttk allows switching themes on the fly, at runtime, right ? 
>> That could actually be handled ... The 'icon-theme' package would have 
>> to remember the images it handed out to the app, and the associated 
>> general icon names ... Switch the theme, go through the remembered 
>> images and reload their content ...
> 
> Note that Tk handles this already through named images.  You just change 
> it with [$img configure -file ...] and Tk does the updating for all 
> widgets using -image $img.

Exactly. Note that it has to remember which icons it has handed out, you do not 
wish to
	$img configure -file ...

for an icon the application has not used (yet).

>> GSoC project ?!
> 
> Good idea.


Andreas.

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

On 10-Feb-09, at 3:35 PM, Andreas Kupries wrote:
> Jeff Hobbs wrote:
>> Another couple of thoughts on this ... plugin-like would be similar  
>> to  themes and how we can add themes to Ttk.
>
> Hm ... Ttk allows switching themes on the fly, at runtime, right ?  
> That could actually be handled ... The 'icon-theme' package would  
> have to remember the images it handed out to the app, and the  
> associated general icon names ... Switch the theme, go through the  
> remembered images and reload their content ...

Note that Tk handles this already through named images.  You just  
change it with [$img configure -file ...] and Tk does the updating for  
all widgets using -image $img.

>> On that note as well, it might be nice as an enhancement to devise  
>> a  "standard" set of icons that each "icon theme" would represent,  
>> though  they could have many more than the standard.  Similar to  
>> font and font  families (icon families ??), and our use of  
>> TkFontFixed, TkFont... but  for icons it would be "file", "dir",  
>> "open" ... maybe not an immediate  feature, but do consider our  
>> existing core facilities that have  similar ideas and apply them  
>> (Ttk themes, fonts, ...).
>
> GSoC project ?!

Good idea.

Jeff

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

Jeff Hobbs wrote:
> Another couple of thoughts on this ... plugin-like would be similar to  
> themes and how we can add themes to Ttk.

Hm ... Ttk allows switching themes on the fly, at runtime, right ? That could 
actually be handled ... The 'icon-theme' package would have to remember the 
images it handed out to the app, and the associated general icon names ... 
Switch the theme, go through the remembered images and reload their content ...

> On that note as well, it might be nice as an enhancement to devise a  
> "standard" set of icons that each "icon theme" would represent, though  
> they could have many more than the standard.  Similar to font and font  
> families (icon families ??), and our use of TkFontFixed, TkFont... but  
> for icons it would be "file", "dir", "open" ... maybe not an immediate  
> feature, but do consider our existing core facilities that have  
> similar ideas and apply them (Ttk themes, fonts, ...).

GSoC project ?!

We may not have time (remember I threw mine together right quick, minimal 
thought), however maybe we can interest someone ...

How are KDE, Gtk, Qt handling the icons ? Do they have a general framework with 
configurable icon search paths ? Or is that part of an app handled by the app 
itself still ?

Andreas.

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

On 10-Feb-09, at 3:08 PM, Andreas Kupries wrote:
> Jeff Hobbs wrote:
>> My preference would be a more general icons package that supported   
>> multiple sets of icons, perhaps starting with famfam.  This would  
>> be  like the tklib style package, with substyles.
>> So you have something more like:
>> package require icons
>> set groups [icons::get groups] ; # or packages or something
>> => famfam kdeicons ...
>> set group famfam
>> set icons [icons::list *arrow* ?$group?]
>> ...
>> Where the grouping can be done by some ordering of directories  
>> with  files of matching known image format types.
>
>> Mind you, I don't have time to write this, so it's just an idea ...
>
> Your idea seems to exist on the level above of what I threw together  
> on the quick.
>
> I wanted simple physical access, and you seem to be building icon  
> themes on top. Where an abstract icon name exists across all themes,  
> and each theme maps that it proper physical icon.
>
> Although from your description it could also be a general physical  
> access. One package, configured with path(s) to icon master  
> directories, or having them as siblings, and automatically picks up  
> a new 'group' when a sub-directory is made for it in a master, and  
> filled.
>
> Ok, more meditation required ... might be possible to get something  
> like this in an incremental fashion. Plugin-like ...

Another couple of thoughts on this ... plugin-like would be similar to  
themes and how we can add themes to Ttk.

On that note as well, it might be nice as an enhancement to devise a  
"standard" set of icons that each "icon theme" would represent, though  
they could have many more than the standard.  Similar to font and font  
families (icon families ??), and our use of TkFontFixed, TkFont... but  
for icons it would be "file", "dir", "open" ... maybe not an immediate  
feature, but do consider our existing core facilities that have  
similar ideas and apply them (Ttk themes, fonts, ...).

Jeff


>
>
>> Jeff
>> On 10-Feb-09, at 12:31 PM, Andreas Kupries wrote:
>>> Requesting review of a new module for tklib, before committing.
>>>
>>> Sources available at
>>> 	ftp://ftp.tcl.tk/pub/incoming/tklib-famfam.tgz
>>> 	(Can't put up on SF, they limit attachments to 256 KB, this file  
>>> is 2
>>> 	MB compressed (6 MB uncompressed)).
>>>
>>> A module containing 2 packages wrapping around the silk and flags   
>>> icon sets of
>>> famfam, to make their use in tcl apps easier. Just require the   
>>> package, then
>>> load an icon/image by name.
>>>
>>>
>>> Examples of use
>>>    package require famfam::silk
>>>    set arrows [famfam::silk list *arrow*]
>>>    set rotccw [famfam::silk get arrow_rotate_anticlockwise]
>>>
>>>    package require famfam::flags
>>>    set dubya [famfam::flags list w*]
>>>    set wales [famfam::flags get wales]
>>>
>>>
>>> Ideas for the future
>>> - Commands to generate packages containing a subset of the icon set.
>>>   - With the icons hardwired into the package code (base64 encoded).
>>>     => Deployable as Tcl Module.
>>>   - With the icons in a subdirectory as for the original package.
>>>   - With the icons attached to the base tcl code (virtual fs).
>>>
>>>
>>> Andreas.
>>

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

Jeff Hobbs wrote:
> My preference would be a more general icons package that supported  
> multiple sets of icons, perhaps starting with famfam.  This would be  
> like the tklib style package, with substyles.
> 
> So you have something more like:
> 
> package require icons
> set groups [icons::get groups] ; # or packages or something
> => famfam kdeicons ...
> set group famfam
> set icons [icons::list *arrow* ?$group?]
> ...
> 
> Where the grouping can be done by some ordering of directories with  
> files of matching known image format types.

> Mind you, I don't have time to write this, so it's just an idea ...

Your idea seems to exist on the level above of what I threw together on the quick.

I wanted simple physical access, and you seem to be building icon themes on 
top. Where an abstract icon name exists across all themes, and each theme maps 
that it proper physical icon.

Although from your description it could also be a general physical access. One 
package, configured with path(s) to icon master directories, or having them as 
siblings, and automatically picks up a new 'group' when a sub-directory is made 
for it in a master, and filled.

Ok, more meditation required ... might be possible to get something like this 
in an incremental fashion. Plugin-like ...



> Jeff
> 
> On 10-Feb-09, at 12:31 PM, Andreas Kupries wrote:
> 
>> Requesting review of a new module for tklib, before committing.
>>
>> Sources available at
>> 	ftp://ftp.tcl.tk/pub/incoming/tklib-famfam.tgz
>> 	(Can't put up on SF, they limit attachments to 256 KB, this file is 2
>> 	MB compressed (6 MB uncompressed)).
>>
>> A module containing 2 packages wrapping around the silk and flags  
>> icon sets of
>> famfam, to make their use in tcl apps easier. Just require the  
>> package, then
>> load an icon/image by name.
>>
>>
>> Examples of use
>>     package require famfam::silk
>>     set arrows [famfam::silk list *arrow*]
>>     set rotccw [famfam::silk get arrow_rotate_anticlockwise]
>>
>>     package require famfam::flags
>>     set dubya [famfam::flags list w*]
>>     set wales [famfam::flags get wales]
>>
>>
>> Ideas for the future
>>  - Commands to generate packages containing a subset of the icon set.
>>    - With the icons hardwired into the package code (base64 encoded).
>>      => Deployable as Tcl Module.
>>    - With the icons in a subdirectory as for the original package.
>>    - With the icons attached to the base tcl code (virtual fs).
>>
>>
>> Andreas.
> 
> 
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel

Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

My preference would be a more general icons package that supported  
multiple sets of icons, perhaps starting with famfam.  This would be  
like the tklib style package, with substyles.

So you have something more like:

package require icons
set groups [icons::get groups] ; # or packages or something
=> famfam kdeicons ...
set group famfam
set icons [icons::list *arrow* ?$group?]
...

Where the grouping can be done by some ordering of directories with  
files of matching known image format types.

Mind you, I don't have time to write this, so it's just an idea ...

Jeff

On 10-Feb-09, at 12:31 PM, Andreas Kupries wrote:

>
> Requesting review of a new module for tklib, before committing.
>
> Sources available at
> 	ftp://ftp.tcl.tk/pub/incoming/tklib-famfam.tgz
> 	(Can't put up on SF, they limit attachments to 256 KB, this file is 2
> 	MB compressed (6 MB uncompressed)).
>
> A module containing 2 packages wrapping around the silk and flags  
> icon sets of
> famfam, to make their use in tcl apps easier. Just require the  
> package, then
> load an icon/image by name.
>
>
> Examples of use
>     package require famfam::silk
>     set arrows [famfam::silk list *arrow*]
>     set rotccw [famfam::silk get arrow_rotate_anticlockwise]
>
>     package require famfam::flags
>     set dubya [famfam::flags list w*]
>     set wales [famfam::flags get wales]
>
>
> Ideas for the future
>  - Commands to generate packages containing a subset of the icon set.
>    - With the icons hardwired into the package code (base64 encoded).
>      => Deployable as Tcl Module.
>    - With the icons in a subdirectory as for the original package.
>    - With the icons attached to the base tcl code (virtual fs).
>
>
> Andreas.

[Tcllib-devel] GSoC 2009 - Looking for Project Ideas ...

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

Google's Summer of Code is spinning up again ...

If any of you have ideas for in the area of Tcl, Tk, Tcllib, Tklib, etc. pp. 
please add them to our project page at

	http://wiki.tcl.tk/22182

If you are a student, consider putting up your own project and ideas for which 
you could then apply.

Regardless of having ideas or not, please propagate this around to your 
friends, co-workers, other mailing lists, possible mentors, students, etc.

Andreas.

[Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

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

Requesting review of a new module for tklib, before committing.

Sources available at
	ftp://ftp.tcl.tk/pub/incoming/tklib-famfam.tgz
	(Can't put up on SF, they limit attachments to 256 KB, this file is 2
	MB compressed (6 MB uncompressed)).

A module containing 2 packages wrapping around the silk and flags icon sets of 
famfam, to make their use in tcl apps easier. Just require the package, then 
load an icon/image by name.


Examples of use
     package require famfam::silk
     set arrows [famfam::silk list *arrow*]
     set rotccw [famfam::silk get arrow_rotate_anticlockwise]

     package require famfam::flags
     set dubya [famfam::flags list w*]
     set wales [famfam::flags get wales]


Ideas for the future
  - Commands to generate packages containing a subset of the icon set.
    - With the icons hardwired into the package code (base64 encoded).
      => Deployable as Tcl Module.
    - With the icons in a subdirectory as for the original package.
    - With the icons attached to the base tcl code (virtual fs).


Andreas.

[Tcllib-devel] GSoC 2009 [Fwd: Logo and Flyer now available]

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

FYI and propagation ...

Re: [Tcllib-devel] pheap - alternate prioqueue ipmlementation

[Murr, F. <flo...@si...>]

I use pheap in the context of some Dijkstra search algorithms, where
'contains', 'insert', 'promote' and 'popmin' are heavily used.
To compare performance, I do sorting of random numbers using

proc pheap::cmp-numeric-count {a b} {
    incr ::pheap::cmpCount   ;# for Testing!
    expr {($a<$b)?-1:(($a==$b)?0:1)}
} 

So that I know how many calls to the compare-callback have been made and
I measure milliseconds.
Since sorting 

proc pheap::sort {alist args} {
    set q [::pheap::pheap {*}$args ::pheap[incr ::pheap::counter]]
    foreach i $alist { $q insert [incr cnt] $i }

    set rval {}
    while {[$q popmin cnt i]} { lappend rval $i }
    $q destroy
    set rval
}

just uses 'insert', but not the *very* important 'promote' (a major
reason for using a priority queue), it is no fair test!
(But it gives some indication whether pheap0.1 or pheap0.2 is faster
with respect to 'insert' and 'popmin')

To compare two prioques one should define a (big!) random number of
'setp' ('insert' | 'promote', but *not* 'demote' (nobody needs that))
and 'popmin' operations and let both prioques perform them.
Repeat that any number of times and calculate the average time used.

That probably might indicate a way of how to find out which
priority-queue outperforms the other.

Regards,
- Florian

-----Original Message-----
From: Andreas Kupries [mailto:and...@ac...] 
Sent: Friday, February 06, 2009 5:50 PM
To: Tcllib Developers
Cc: Andreas Kupries Home; Murr, Florian
Subject: pheap - alternate prioqueue ipmlementation

pheap - Priority Queue
	A Pairing-heap [1] priority queue in Tcl

[0]	http://wiki.tcl.tk/22428
[1]	http://en.wikipedia.org/wiki/Pairing_heap

<quote [0]>
Comparison with package struct::prioqueue: Prioqueue lacks the sometimes
essential functionality of setp or promote and its implementation seems
to be a bubblesort in disguise, which is detrimental to performance if
one is dealing with many items. Pheap on the other hand, reflects more
closely the intention and performance characteristics of a priority
queue and it seems to be more versatile, too. (The interface of get and
peek in struct::prioqueue makes me frown, too. Imho the distinction of
lists and strings should not be blurred more, but less.) </quote>

Hm. We have no benchmarks for the struct::prioqueue code ...
	Time to write some it seems ...
	However, what are sensible benchmarks for prioqueue ...

Andreas