Menu
▾
▴
tcllib-devel
|
From: Andreas K. <and...@ac...> - 2009-02-10 20:32:35
|
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. |
|
From: Jeff H. <je...@ac...> - 2009-02-10 22:55:49
|
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. |
|
From: Andreas K. <and...@ac...> - 2009-02-10 23:10:03
|
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 |
|
From: Andreas K. <and...@ac...> - 2009-02-10 23:36:35
|
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. |
|
From: Jeff H. <je...@ac...> - 2009-02-10 23:17:19
|
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. >> |
|
From: Joe E. <jen...@fl...> - 2009-02-11 18:59:54
|
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 |
|
From: Andreas K. <and...@ac...> - 2009-02-11 19:46:55
|
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. |
|
From: Jeff H. <je...@ac...> - 2009-02-10 23:39:42
|
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 |
|
From: Andreas K. <and...@ac...> - 2009-02-10 23:44:41
|
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. |
|
From: Michael S. <sc...@un...> - 2009-02-11 03:00:18
|
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 |
|
From: Andreas K. <and...@ac...> - 2009-02-11 16:56:29
|
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. |
|
From: Joe E. <jen...@fl...> - 2009-02-11 18:11:42
|
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 |
|
From: Andreas K. <and...@ac...> - 2009-02-11 18:26:05
|
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. |
|
From: Andreas K. <and...@ac...> - 2009-02-11 18:53:57
|
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. |
|
From: Andreas K. <and...@ac...> - 2009-02-11 19:42:22
|
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. |
|
From: Joe E. <jen...@fl...> - 2009-02-11 19:52:54
|
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 |
|
From: Andreas K. <and...@ac...> - 2009-02-11 20:08:47
|
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. |
|
From: Jeff H. <je...@ac...> - 2009-02-11 18:18:31
|
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 |
|
From: Damon C. <da...@tc...> - 2009-02-11 18:50:52
|
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 |
×
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