Loading ...
Sorry, an error occurred while loading the content.

Hello, is anyone out there?

Expand Messages
  • rcseege
    Hello, I m a newcomer to this list, and in way of introduction, my name is Rob Seegel. I use Tix for Perl and Python, but not Tcl (not anymore anyway), and am
    Message 1 of 9 , Feb 18, 2002
    View Source
    • 0 Attachment
      Hello,

      I'm a newcomer to this list, and in way of
      introduction, my name is Rob Seegel. I use Tix
      for Perl and Python, but not Tcl (not anymore anyway),
      and am currently most active on the Perl/Tk newsgroup.

      Recently, on the NG, I raised the issue on apparent
      incompatibilities/inconsistancy issues between Tix
      and the Tk widgets. I proposed that we tweak HList
      so that it would behave a bit more like Listbox in
      the following areas:

      - bindings (keyboard and mouse)
      - select modes
      - decoupling of the active/anchor idea. The version of
      tixHList mixes the two, and these two are separate things
      within Listbox. Even within tixHList with the use of
      of DisplayItems, there are activebackground/activeforeground
      options. It seems odd that these options would be linked
      to anchor set.

      Over the past year or two, I crafted many patches, and
      recently I pulled them together and reimplemented the
      perl bindings for tixHList which closely mirrored the tcl
      bindings. Among my changes:

      -selectmodes works identically to Listbox

      There is a new code:

      - mapping active set|clear to anchor set|clear

      - that implements anchor set|clear as a way of
      setting the anchor to another variable. This way,

      - that implements info anchor active, and retrieves
      the respective entry path information

      - overrode nearest with the GetNearest procedure that
      had been implemented in the bindings. This way the
      additional functionality was exposed to more users.
      In retrospect, since the procedure was called nearest,
      perhaps a better approach would have been to create
      something called info entry <yCoord> to get the precise
      entry that the yCoord fell within, or nothing at all.
      I could go either way on that.

      - created an option (-showactive)that disabled/enabled
      highlighting when an entry was made active (er anchored,
      sorry ;)

      There were a few other issues, as well, but this was all
      done without changing a line of C code. Not that some c code
      changes wouldn't be nice...

      Here are some further enhancements that would be nice:

      ability to change the highlighting style (dashborder,
      solidborder, underline, none, etc). This would effectively
      render my option -showactive unecessary

      ability to set some more of the default value for display
      items at the hlist level - things like activebackground,
      activeforeground in particular.

      ability to associate each entry with a numeric index,
      indicating it's position within the list, and way of
      translating index->entryPath and entryPath->index.

      a Fix to a bug that allows embedded widgets to be
      seen *through* the header while being scrolled.

      By the way... has anyway sat down and listed all the current
      deficiences of tixGrid so that all of the problems could be
      widely known (and perhaps corrected)?

      Thanks, that's all for now.

      Rob


























      I realize that the toolkits involved are
      different, but a certain amount of consistancy between the
      two isn't an unattainable goal.
    • rcseege
      ... Ok, after looking through the code here s a second take ... This is too broad, unless there were different internal styles defined for each state NORMAL,
      Message 2 of 9 , Feb 19, 2002
      View Source
      • 0 Attachment
        --- In tix@y..., "rcseege" <rcseege@y...> wrote:

        > Here are some further enhancements that would be nice:

        Ok, after looking through the code here's a second take
        on what I'd like:

        > ability to change the highlighting style (dashborder,
        > solidborder, underline, none, etc). This would effectively
        > render my option -showactive unecessary

        This is too broad, unless there were different internal
        styles defined for each state NORMAL, ACTIVE, DISABLED,
        SELECTED. This might be the most flexible, but also might
        be a bit over the top. Something like:

        highlightstyle: dash | solid | none

        > ability to set some more of the default value for display
        > items at the hlist level - things like activebackground,
        > activeforeground in particular.

        I was looking at this in particular today, and it wouldn't
        be too hard to add this.

        > ability to associate each entry with a numeric index,
        > indicating it's position within the list, and way of
        > translating index->entryPath and entryPath->index.

        Ok, I take this one back. Too much of a headache. Easier
        to handle on the scripting side for certain specific
        needs.

        Rob
      • Ioi Lam
        ... Just a quick note. On Tix 8.2.0, I tried to make the NORMAL, ACTIVE, DISABLED, SELECTED styles configurable at compile time. So even if you can t configure
        Message 3 of 9 , Feb 19, 2002
        View Source
        • 0 Attachment
          rcseege wrote:
          >
          > --- In tix@y..., "rcseege" <rcseege@y...> wrote:
          >
          > > Here are some further enhancements that would be nice:
          >
          > Ok, after looking through the code here's a second take
          > on what I'd like:
          >
          > > ability to change the highlighting style (dashborder,
          > > solidborder, underline, none, etc). This would effectively
          > > render my option -showactive unecessary
          >
          > This is too broad, unless there were different internal
          > styles defined for each state NORMAL, ACTIVE, DISABLED,
          > SELECTED. This might be the most flexible, but also might
          > be a bit over the top. Something like:

          Just a quick note. On Tix 8.2.0, I tried to make the NORMAL, ACTIVE,
          DISABLED,
          SELECTED styles configurable at compile time. So even if you can't
          configure everything at run-time, you still have a good default
          look-and-feel for tixHList that's close the the built-in Tk widgets.

          - Ioi

          > highlightstyle: dash | solid | none
          >
          > > ability to set some more of the default value for display
          > > items at the hlist level - things like activebackground,
          > > activeforeground in particular.
          >
          > I was looking at this in particular today, and it wouldn't
          > be too hard to add this.
          >
          > > ability to associate each entry with a numeric index,
          > > indicating it's position within the list, and way of
          > > translating index->entryPath and entryPath->index.
          >
          > Ok, I take this one back. Too much of a headache. Easier
          > to handle on the scripting side for certain specific
          > needs.
          >
          > Rob
          >
          >
          >
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

          --
          Ioi Lam
          Sun Microsystems, Inc.
          4210 Network Circle, USCA21-212
          Santa Clara, CA 95054
          408-276-7480
        • rcseege
          ... I must have completely missed that when I was looking at the source code for tixHlist. I looked at the one included in the Perl/Tk distribution, and the
          Message 4 of 9 , Feb 19, 2002
          View Source
          • 0 Attachment
            --- In tix@y..., Ioi Lam <ioi.lam@s...> wrote:
            > rcseege wrote:
            >
            > Just a quick note. On Tix 8.2.0, I tried to make the NORMAL, ACTIVE,
            > DISABLED,
            > SELECTED styles configurable at compile time. So even if you can't
            > configure everything at run-time, you still have a good default
            > look-and-feel for tixHList that's close the the built-in Tk widgets.
            >

            I must have completely missed that when I was looking at the
            source code for tixHlist. I looked at the one included in the Perl/Tk
            distribution, and the most recent Tix release, and I didn't remember
            seeing that in the latest tix release - I must have missed it. Is it
            documented? That would have definitely been handy for me more than
            once in the past. The other thing that wouldn't currently cover,
            unless I've missed it as well, is being able to modify the line_style
            of LineDoubleDash.

            Rob
          • rcseege
            ... ACTIVE, ... widgets. I m sorry - I must have misunderstood. Did you mean C compile time, or during widget initialization within tcl, perl, etc? I was doing
            Message 5 of 9 , Feb 19, 2002
            View Source
            • 0 Attachment
              --- In tix@y..., "rcseege" <rcseege@y...> wrote:
              > > Just a quick note. On Tix 8.2.0, I tried to make the NORMAL,
              ACTIVE,
              > > DISABLED,
              > > SELECTED styles configurable at compile time. So even if you can't
              > > configure everything at run-time, you still have a good default
              > > look-and-feel for tixHList that's close the the built-in Tk
              widgets.

              I'm sorry - I must have misunderstood. Did you mean C compile
              time, or during widget initialization within tcl, perl, etc?

              I was doing some experimentation, and was able to easily
              add the -activebackground/-activeforeground options to the C
              code so that they could be set during initialization. This is a
              useful feature because if any other background is set at
              initialization time, and you wish the normal background to be
              the same as the active background you will have to create a
              new style and apply it to each entry. If a default
              background/foreground exists, then shouldn't the activeforeground/
              activebackground likewise exist?

              Rob
            • Ioi Lam
              Oops, I wasn t clear. I was talking about the default configurations, which is set at compile time. E.g., I have tixWinDefault.h: #define
              Message 6 of 9 , Feb 20, 2002
              View Source
              • 0 Attachment
                Oops, I wasn't clear. I was talking about the default configurations,
                which is set at compile time. E.g., I have tixWinDefault.h:

                #define DEF_NOTEBOOKFRAME_INACTIVE_BG_COLOR NORMAL_BG
                #define DEF_NOTEBOOKFRAME_INACTIVE_BG_MONO WHITE
                #define DEF_NOTEBOOKFRAME_BACKPAGE_COLOR NORMAL_BG
                #define DEF_NOTEBOOKFRAME_BACKPAGE_MONO WHITE
                #define DEF_NOTEBOOKFRAME_BG_COLOR NORMAL_BG
                #define DEF_NOTEBOOKFRAME_BG_MONO WHITE

                These options are set so that the default look-and-feel of the Tix
                widgets are the same as the other native TK widgets. Previous versions
                of Tix were also trying to do this, but wasn't very consistent.

                Also, I added a new command tixGetDefault to access the default options
                at the Tcl level, so the mega widgets will also look like the native
                widgets.

                - Ioi


                rcseege wrote:
                >
                > --- In tix@y..., "rcseege" <rcseege@y...> wrote:
                > > > Just a quick note. On Tix 8.2.0, I tried to make the NORMAL,
                > ACTIVE,
                > > > DISABLED,
                > > > SELECTED styles configurable at compile time. So even if you can't
                > > > configure everything at run-time, you still have a good default
                > > > look-and-feel for tixHList that's close the the built-in Tk
                > widgets.
                >
                > I'm sorry - I must have misunderstood. Did you mean C compile
                > time, or during widget initialization within tcl, perl, etc?
                >
                > I was doing some experimentation, and was able to easily
                > add the -activebackground/-activeforeground options to the C
                > code so that they could be set during initialization. This is a
                > useful feature because if any other background is set at
                > initialization time, and you wish the normal background to be
                > the same as the active background you will have to create a
                > new style and apply it to each entry. If a default
                > background/foreground exists, then shouldn't the activeforeground/
                > activebackground likewise exist?
                >
                > Rob
              • rcseege
                ... configurations, ... OK, thanks for clarifying. In that case, yes I did see these, and they do go a ways in setting up some common colors and other default
                Message 7 of 9 , Feb 20, 2002
                View Source
                • 0 Attachment
                  --- In tix@y..., Ioi Lam <ioi.lam@s...> wrote:
                  > Oops, I wasn't clear. I was talking about the default
                  configurations,
                  > which is set at compile time. E.g., I have tixWinDefault.h:
                  >
                  > #define DEF_NOTEBOOKFRAME_INACTIVE_BG_COLOR NORMAL_BG
                  > #define DEF_NOTEBOOKFRAME_INACTIVE_BG_MONO WHITE
                  > #define DEF_NOTEBOOKFRAME_BACKPAGE_COLOR NORMAL_BG
                  > #define DEF_NOTEBOOKFRAME_BACKPAGE_MONO WHITE
                  > #define DEF_NOTEBOOKFRAME_BG_COLOR NORMAL_BG
                  > #define DEF_NOTEBOOKFRAME_BG_MONO WHITE
                  >

                  OK, thanks for clarifying. In that case, yes I did see these,
                  and they do go a ways in setting up some common colors and
                  other default variables which is good.

                  The common user, however, will not be setting these and
                  recompiling the widgets, nor should he. My problem was that
                  on one hand, I can set background and foreground colors to
                  be used for the default style, and selectbackground/
                  selectforeground as well. So it would stand to reason that
                  I should also be able to set default activebackground/
                  activeforeground values. Instead, if I want to create a change
                  to the overall activeforeground/activebackground, I have to
                  create a new itemstyle, and change those values, and assign it
                  to all created entries. Not very convenient or consistent ;)

                  I realize I'm new here and all, but are patches accepted
                  for consideration?

                  Rob









                  > These options are set so that the default look-and-feel of the Tix
                  > widgets are the same as the other native TK widgets. Previous
                  versions
                  > of Tix were also trying to do this, but wasn't very consistent.
                  >
                  > Also, I added a new command tixGetDefault to access the default
                  options
                  > at the Tcl level, so the mega widgets will also look like the native
                  > widgets.
                  >
                  > - Ioi
                  >
                  >
                  > rcseege wrote:
                  > >
                  > > --- In tix@y..., "rcseege" <rcseege@y...> wrote:
                  > > > > Just a quick note. On Tix 8.2.0, I tried to make the NORMAL,
                  > > ACTIVE,
                  > > > > DISABLED,
                  > > > > SELECTED styles configurable at compile time. So even if you
                  can't
                  > > > > configure everything at run-time, you still have a good
                  default
                  > > > > look-and-feel for tixHList that's close the the built-in Tk
                  > > widgets.
                  > >
                  > > I'm sorry - I must have misunderstood. Did you mean C compile
                  > > time, or during widget initialization within tcl, perl, etc?
                  > >
                  > > I was doing some experimentation, and was able to easily
                  > > add the -activebackground/-activeforeground options to the C
                  > > code so that they could be set during initialization. This is a
                  > > useful feature because if any other background is set at
                  > > initialization time, and you wish the normal background to be
                  > > the same as the active background you will have to create a
                  > > new style and apply it to each entry. If a default
                  > > background/foreground exists, then shouldn't the activeforeground/
                  > > activebackground likewise exist?
                  > >
                  > > Rob
                • Ioi Lam
                  ... OK, the stuff you re looking for is around the call to Tix_SetDefaultStyleTemplate() inside tixHList.c. I have defaults for the NORMAL and SELECTED fg/bg
                  Message 8 of 9 , Feb 21, 2002
                  View Source
                  • 0 Attachment
                    rcseege wrote:
                    >
                    > --- In tix@y..., Ioi Lam <ioi.lam@s...> wrote:
                    > > Oops, I wasn't clear. I was talking about the default
                    > configurations,
                    > > which is set at compile time. E.g., I have tixWinDefault.h:
                    > >
                    > > #define DEF_NOTEBOOKFRAME_INACTIVE_BG_COLOR NORMAL_BG
                    > > #define DEF_NOTEBOOKFRAME_INACTIVE_BG_MONO WHITE
                    > > #define DEF_NOTEBOOKFRAME_BACKPAGE_COLOR NORMAL_BG
                    > > #define DEF_NOTEBOOKFRAME_BACKPAGE_MONO WHITE
                    > > #define DEF_NOTEBOOKFRAME_BG_COLOR NORMAL_BG
                    > > #define DEF_NOTEBOOKFRAME_BG_MONO WHITE
                    > >
                    >
                    > OK, thanks for clarifying. In that case, yes I did see these,
                    > and they do go a ways in setting up some common colors and
                    > other default variables which is good.
                    >
                    > The common user, however, will not be setting these and
                    > recompiling the widgets, nor should he. My problem was that
                    > on one hand, I can set background and foreground colors to
                    > be used for the default style, and selectbackground/
                    > selectforeground as well. So it would stand to reason that
                    > I should also be able to set default activebackground/
                    > activeforeground values. Instead, if I want to create a change
                    > to the overall activeforeground/activebackground, I have to
                    > create a new itemstyle, and change those values, and assign it
                    > to all created entries. Not very convenient or consistent ;)
                    >
                    > I realize I'm new here and all, but are patches accepted
                    > for consideration?

                    OK, the stuff you're looking for is around the call to
                    Tix_SetDefaultStyleTemplate() inside tixHList.c. I have defaults for the
                    NORMAL and SELECTED fg/bg there. You need to fix it to add the default
                    colors for ACTIVE and DISABLED as well. You also need to add switches
                    like -activeforeground to the tixHList widget.

                    If you have a working patch for tix 8.2.0, I'd be happy to merge it into
                    my CVS at http://tixlibrary.sourceforge.net/

                    - Ioi
                  • rcseege
                    ... for the ... default... Yes, that is precisely what I did, except I didn t take it all the way with disabled bg/fg. Additionally, I did it using the source
                    Message 9 of 9 , Feb 21, 2002
                    View Source
                    • 0 Attachment
                      --- In tix@y..., Ioi Lam <ioi.lam@s...> wrote:
                      > rcseege wrote:
                      > >
                      > > --- In tix@y..., Ioi Lam <ioi.lam@s...> wrote:
                      > > > Oops, I wasn't clear. I was talking about the default
                      > OK, the stuff you're looking for is around the call to
                      > Tix_SetDefaultStyleTemplate() inside tixHList.c. I have defaults
                      for the
                      > NORMAL and SELECTED fg/bg there. You need to fix it to add the
                      default...

                      Yes, that is precisely what I did, except I didn't take it all
                      the way with disabled bg/fg. Additionally, I did it using the
                      source that comes with the Perl/Tk (which is older than 8.2.0.
                      I can see that that portion hasn't changed radically in 8.2.0
                      which I have downloaded. I will be happy to replicate the
                      changes and send them to you. I had changed 3 files: tixDef.h
                      (adding the new defines for the options), tixHList.h (modifying
                      the structure to accommodate the options, and tixHList.c
                      adding the optinos to ConfigSpecs, initializing the new items
                      in the structure, and the changes you mentioned. I can apply
                      the mods to 8.2.0 and send them to you later today, updating
                      DISABLED as well.

                      Thanks,

                      Rob
                    Your message has been successfully submitted and would be delivered to recipients shortly.