Menu
▾
▴
tktable-tile-dev
|
From: Joe E. <jen...@fl...> - 2005-08-10 13:49:12
|
I posted a tentative release schedule to comp.lang.tcl last week (which, for some reason, google groups doesn't have in the archive); but there's been talk recently about merging Tile into the core, so the previous tentative plan is no longer operative... The immediate short-term goal is now to get the codebase in shape for integration. Most of this will just be internal cleanups, but it will involve a few important user-visible changes. Mainly: all of the transitional compatibility options are going away sooner rather than later. The [ttk::progress] widget will also be removed shortly, (so if you haven't yet switched to the [ttk::progressbar], now would be a good time to do so...). The "Step", "Clam", and possibly "Classic" themes are also going away, possibly to return as separate loadable extensions. More changes later as I come across them. --Joe English jen...@fl... |
|
From: Mats B. <ma...@pr...> - 2005-08-10 14:16:54
|
Why is "Clam" going away? To me this is definitely the best looking theme on unix. Very clean and with soft contrasts. Mats Joe English wrote: > > I posted a tentative release schedule to comp.lang.tcl last week > (which, for some reason, google groups doesn't have in the archive); > but there's been talk recently about merging Tile into the core, > so the previous tentative plan is no longer operative... > > The immediate short-term goal is now to get the codebase in > shape for integration. Most of this will just be internal > cleanups, but it will involve a few important user-visible > changes. Mainly: all of the transitional compatibility > options are going away sooner rather than later. > > The [ttk::progress] widget will also be removed shortly, > (so if you haven't yet switched to the [ttk::progressbar], > now would be a good time to do so...). The "Step", "Clam", > and possibly "Classic" themes are also going away, possibly > to return as separate loadable extensions. > |
|
From: Mark G. <du...@ya...> - 2005-08-10 14:29:39
|
I'll second that. Clam was for me the obvious choice on Linux. Mark Mats Bengtsson <ma...@pr...> wrote: Why is "Clam" going away? To me this is definitely the best looking theme on unix. Very clean and with soft contrasts. Mats Joe English wrote: > > I posted a tentative release schedule to comp.lang.tcl last week > (which, for some reason, google groups doesn't have in the archive); > but there's been talk recently about merging Tile into the core, > so the previous tentative plan is no longer operative... > > The immediate short-term goal is now to get the codebase in > shape for integration. Most of this will just be internal > cleanups, but it will involve a few important user-visible > changes. Mainly: all of the transitional compatibility > options are going away sooner rather than later. > > The [ttk::progress] widget will also be removed shortly, > (so if you haven't yet switched to the [ttk::progressbar], > now would be a good time to do so...). The "Step", "Clam", > and possibly "Classic" themes are also going away, possibly > to return as separate loadable extensions. > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Tktable-tile-dev mailing list Tkt...@li... https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev --------------------------------- Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. |
|
From: Damon C. <dam...@tc...> - 2005-08-10 14:33:00
|
Third. Clam was the only one on UNIX that actually looked decent. I've never really cared for its darker color scheme, but I definitely appreciate the softer, more-rounded look of it all. My multiplatform stuff definitely uses Clam as the default on UNIX systems until something better comes along. Damon > I'll second that. Clam was for me the obvious choice on Linux. > > Mark > > > Mats Bengtsson <ma...@pr...> wrote: > Why is "Clam" going away? To me this is definitely the best looking > theme on unix. Very clean and with soft contrasts. > > Mats > > Joe English wrote: >> >> I posted a tentative release schedule to comp.lang.tcl last week >> (which, for some reason, google groups doesn't have in the archive); >> but there's been talk recently about merging Tile into the core, >> so the previous tentative plan is no longer operative... >> >> The immediate short-term goal is now to get the codebase in >> shape for integration. Most of this will just be internal >> cleanups, but it will involve a few important user-visible >> changes. Mainly: all of the transitional compatibility >> options are going away sooner rather than later. >> >> The [ttk::progress] widget will also be removed shortly, >> (so if you haven't yet switched to the [ttk::progressbar], >> now would be a good time to do so...). The "Step", "Clam", >> and possibly "Classic" themes are also going away, possibly >> to return as separate loadable extensions. >> > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Tktable-tile-dev mailing list > Tkt...@li... > https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev > > > > --------------------------------- > Yahoo! Mail for Mobile > Take Yahoo! Mail with you! Check email on your mobile phone. |
|
From: Steve L. <st...@Di...> - 2005-08-10 15:05:01
|
Fourth On 10/08/2005, at 10:35 PM, Damon Courtney wrote: > Third. Clam was the only one on UNIX that actually looked decent. > I've never really cared for its darker color scheme, but I definitely > appreciate the softer, more-rounded look of it all. My multiplatform > stuff definitely uses Clam as the default on UNIX systems until > something better comes along. > > Damon > > > >> I'll second that. Clam was for me the obvious choice on Linux. >> >> Mark >> >> >> Mats Bengtsson <ma...@pr...> wrote: >> Why is "Clam" going away? To me this is definitely the best looking >> theme on unix. Very clean and with soft contrasts. >> >> Mats >> >> Joe English wrote: >> >>> >>> I posted a tentative release schedule to comp.lang.tcl last week >>> (which, for some reason, google groups doesn't have in the archive); >>> but there's been talk recently about merging Tile into the core, >>> so the previous tentative plan is no longer operative... >>> >>> The immediate short-term goal is now to get the codebase in >>> shape for integration. Most of this will just be internal >>> cleanups, but it will involve a few important user-visible >>> changes. Mainly: all of the transitional compatibility >>> options are going away sooner rather than later. >>> >>> The [ttk::progress] widget will also be removed shortly, >>> (so if you haven't yet switched to the [ttk::progressbar], >>> now would be a good time to do so...). The "Step", "Clam", >>> and possibly "Classic" themes are also going away, possibly >>> to return as separate loadable extensions. >>> >>> >> >> >> ------------------------------------------------------- >> SF.Net email is Sponsored by the Better Software Conference & EXPO >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle >> Practices >> Agile & Plan-Driven Development * Managing Projects & Teams * >> Testing & QA >> Security * Process Improvement & Measurement * http://www.sqe.com/ >> bsce5sf >> _______________________________________________ >> Tktable-tile-dev mailing list >> Tkt...@li... >> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev >> >> >> >> --------------------------------- >> Yahoo! Mail for Mobile >> Take Yahoo! Mail with you! Check email on your mobile phone. >> > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/ > bsce5sf > _______________________________________________ > Tktable-tile-dev mailing list > Tkt...@li... > https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev > |
|
From: Jeff H. <je...@Ac...> - 2005-08-10 16:56:11
|
Steve Landers wrote: > Fourth -1. See below ... > On 10/08/2005, at 10:35 PM, Damon Courtney wrote: > > Third. Clam was the only one on UNIX that actually looked decent. > > I've never really cared for its darker color scheme, but I definitely > > appreciate the softer, more-rounded look of it all. My multiplatform > > stuff definitely uses Clam as the default on UNIX systems until > > something better comes along. > >> Mats Bengtsson <ma...@pr...> wrote: > >> Why is "Clam" going away? To me this is definitely the best looking > >> theme on unix. Very clean and with soft contrasts. Just going through the demos again, aside from the scrollbars, I don't see much improvement over a mix of Default and Revitalized. The clipped corners seems ok for some things (like the entry), but the button looks ill-defined. Of the three, here are my unix prefs (and maybe now is the time to mix/match the "best" default): Radio/Checkbuttons: revit (clam is close) normal buttons: default notebook: revit scrollbar: clam (like the [|||] handle) scale: clam (like the [|||] handle) progressbar: default labelframe: default/revit entry: default (maybe clam) menubutton: revit (like arrow, don't like fat bd) general colors: NOT clam tree: default > >> Joe English wrote: > >>> will involve a few important user-visible changes. Mainly: all of > >>> the transitional compatibility options are going away sooner rather > >>> than later. FWIW, this is a good, albeit short-term painful thing. I had a bug in our code because -vcmd for entries wasn't supported, only the extended -validatecommand, although nothing complained. This is *bad* when trying to "port" code. On a side note, I do question why we can't keep the shorter opt names. I lk to abbr thgs. > >>> The "Step", "Clam", and possibly "Classic" themes > >>> are also going away, possibly to return as separate loadable > >>> extensions. Will this save us lots of code? I do prefer the idea that we strengthen the "default" look. Less can be more (as we've seen in options, choice can paralyze). However, I would want to encourage focus on whatever can make the unix side pick up either kde and/or gnome looks. Jeff |
|
From: Brett S. <bre...@ya...> - 2005-08-10 17:42:01
|
I would say overall, I like clam, default, revit, in that order. Here is my list: Radio/Checkbuttons: clam,revit normal buttons: clam,default notebook: revit scrollbar: clam, default scale: clam, revit progressbar: revit, default labelframe: default/revit entry: clam,default menubutton: revit (arrow, not fat bd), clam general colors: all are ok tree: default,clam --brett ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs |
|
From: Joe E. <jen...@fl...> - 2005-08-10 18:25:14
|
Jeff Hobbs wrote:
> Just going through the demos again, aside from the scrollbars,
> I don't see much improvement over a mix of Default and
> Revitalized. The clipped corners seems ok for some things
> (like the entry), but the button looks ill-defined. Of the
> three, here are my unix prefs (and maybe now is the time to
> mix/match the "best" default): [...]
Sounds reasonable, but we should also consider what the
rest of the desktop looks like.
The "Clam" theme was designed to match (what was at the time)
the default XFCE theme, and "default" is designed to match the
Gnome "Simple" theme. "Clam" is also a reasonable, though not
great, match for ClearLooks. Similarly "default" is a reasonable
match for most members of the Mist family.
Another design goal for the "default" theme is that it should
be as plain and simple as possible; no graphical elements should
clash with anything else on the desktop. "default" doesn't need
to be the default theme on X11, but the root theme does need to
be clean and featureless (no grips, no fancy borders, etc.)
I'm working -- slowly -- on themes that will match BlueCurve,
Galaxy, and a couple of the standard KDE themes. Work in progress
in the DARCS repository here:
<URL: http://www.flightlab.com/~joe/repos/themebag >
[ As an aside to the Windows and OSX users -- "Clam" et al. really
need to be seen under X11. Due to numerous small glitches
in Tk's Xlib emulation layer that just aren't worth working
around right now, Clam looks like utter crap on Windows
and the Mac. ]
> > >>> The "Step", "Clam", and possibly "Classic" themes
> > >>> are also going away, possibly to return as separate loadable
> > >>> extensions.
>
> Will this save us lots of code?
In the end, not a whole lot, but it will save a lot of
grunt-work in the meantime if we can reduce the number
of themes to be maintained moving forward. If we're going
to support all the different L&F that I'd like to support,
I think a different approach is needed (see themebag,
above -- the basic idea is to make it easier to assemble
a theme out of a large stock collection of predefined
graphical elements).
--Joe English
jen...@fl...
|
|
From: Joe E. <jen...@fl...> - 2005-08-10 18:31:49
|
[ I wrote: ] > I posted a tentative release schedule to comp.lang.tcl last week > (which, for some reason, google groups doesn't have in the archive); For those who didn't see it, here it is again: ----- Newsgroups: comp.lang.tcl Subject: Tile release schedule (WAS Re: tile: bug in paned widget?) Date: 5 Aug 2005 11:31:52 GMT Message-ID: <dcv...@ne...> References: <QSMHe.2375$6D...@ne...> <dco...@ne...> <6ou...@co...> Bugs wrote: >Would there happen to be a new release of Tile on the near horizon? =) Not on the near horizon, but probably before October. Current goals are to get all of the ttk::treeview bugs fixed for 0.6.6 (and any new ttk::combobox bugs that pop up -- all known bugs have been fixed, but from experience it's a safe bet that more are lurking :-(. I also want to get ttk::dialog and related routines into their final form, and integrate the (really nice!) file selection dialogs that Schelte Bron contributed. These might go into 0.6.6, or there might be a 0.6.8 release too. Release 0.7.0 will follow shortly afterwards. This is when all the BWidget compatibility hacks will be removed. Hopefully by that time there will have been a new BWidget release with Tile integration done right (Damon? Any progress on that?) Somebody (maybe me) is eventually going to implement a spinbox widget; that might show up in the 0.6 series (if somebody else does it :-) or the 0.7 series. After that: the 8.4-compatibility options have to go away at some point before Tile 1.0. This is going to cause some pain for early adopters who used the [namespace import] trick to convert existing applications, so I'm reluctant to do it, but it will happen either at 0.8.0 or 0.9.0. The other things that need to happen before 1.0 are: (1) solve The Background Problem; (2) solve The Scrollbar Problem; and (3) solve The Color Mismatch Problem. [ Explanation: (1) is why the contents of [ttk::notebook]s don't look right on Windows XP, and why nothing really looks right under OSX. (2) is why Tile still doesn't have native-looking scrollbars in the aqua and tile-qt themes. (3) is why e.g. a ttk::frame inside a core toplevel often have different colors on X11. (3) is almost solved; (1) and (2) still have me stumped. ] --Joe English |
|
From: Damon C. <dam...@tc...> - 2005-08-10 18:55:54
|
> Release 0.7.0 will follow shortly afterwards. This is when
> all the BWidget compatibility hacks will be removed. Hopefully
> by that time there will have been a new BWidget release with
> Tile integration done right (Damon? Any progress on that?)
The new BWidget release should be hitting a beta pretty soon here.
Jeff said he had some stuff to commit, and I need to get his in and
call a freeze before merging all of my stuff. Now that I have a clear
roadmap for Ttk, I can make all the needed modifications to BWidget to
finish off the support. After the first iteration, some of the
options still look at Tk resources for their values, which was fine
when Ttk was still including dummy options, but now that they're going
away, I need to make sure BWidget's use of them does too.
As far as Ttk support in widgets goes, I have some basic stuff going
on that should work decently well, but it basically mimics some of the
(unwanted?) behavior that Ttk has now. Like a Button, for example,
has a new -style option that will pass on to Ttk, but it still has all
the rest of the options that just don't do anything. So, you can do:
Button .b -background white -foreground black -style Style
And if you're using Ttk, the style option does something while the
other two do nothing, but if you're not using Ttk, the style option
does nothing and the other two do. Should we go a different route
with this? Turning on Ttk support in BWidgets goes like this:
BWidget::use ttk
Should we use this to redefine the widget classes? Should the Button
class only inherit the options for what it's actually using? IE:
if {[BWidget::using ttk]} {
## Define Ttk options for the button class
Widget::declare Button ...
} else {
## Define using normal options.
Widget::declare Button ...
}
I, personally, kinda' like having the options dummy'd out in BWidgets
because it lets BWidgets become a bridge between Tk and Ttk. I can
specify all of my options including a style, and if I've chosen to
turn on Ttk support for this platform, it will draw using Ttk, and if
I've chosen not to turn it on, I don't have to rewrite anything. The
BWidget Button will just do the right thing.
Opinions? Jeff?
> [ Explanation: (1) is why the contents of [ttk::notebook]s don't
> look right on Windows XP, and why nothing really looks right
> under OSX. (2) is why Tile still doesn't have native-looking
> scrollbars in the aqua and tile-qt themes. (3) is why e.g.
> a ttk::frame inside a core toplevel often have different
> colors on X11. (3) is almost solved; (1) and (2) still
> have me stumped. ]
For "The Scrollbar Problem," couldn't you just accept that themes like
OS X and KDE don't want you to draw element-by-element and just draw
them as one, big thing when using those themes? If I understand
correctly, the problem is that OS X and KDE provide APIs to draw
entire scrollbars but not smaller elements within them, right? So, if
the user has chosen a theme with that limitation, just draw it that
way. How many people fiddle with the damn scrollbars anyway? I don't
think I've ever changed a scrollbar option outside of -orient.
Damon
|
|
From: Bryan O. <oa...@ba...> - 2005-08-10 19:09:44
|
Damon Courtney wrote: > For "The Scrollbar Problem," couldn't you just accept that themes like > OS X and KDE don't want you to draw element-by-element and just draw > them as one, big thing when using those themes? If I understand > correctly, the problem is that OS X and KDE provide APIs to draw > entire scrollbars but not smaller elements within them, right? So, if > the user has chosen a theme with that limitation, just draw it that > way. How many people fiddle with the damn scrollbars anyway? I don't > think I've ever changed a scrollbar option outside of -orient. One instance where it would be nice to "fiddle with the damn scrollbars" is in an application like tkdiff, which has a special scrollbar that has graphical elements (colored lines) in the trough. I was experimenting with this the other day and was able to use a dynamic photo image in the trough area. It was pretty neat having a "real" scrollbar with a drawable area in it. Admittedly, that's a fairly unique thing to do, and could be done other ways (such as how tkdiff does it today...). |
|
From: Damon C. <dam...@tc...> - 2005-08-10 19:12:21
|
> One instance where it would be nice to "fiddle with the damn scrollbars"
> is in an application like tkdiff, which has a special scrollbar that has
> graphical elements (colored lines) in the trough.
>
> I was experimenting with this the other day and was able to use a
> dynamic photo image in the trough area. It was pretty neat having a
> "real" scrollbar with a drawable area in it.
>
> Admittedly, that's a fairly unique thing to do, and could be done other
> ways (such as how tkdiff does it today...).
And, while I agree that that's REALLY cool, I don't think ANY of the
"native" scrollbars will give you that kind of action. Heck, even the
current Tk scrollbar doesn't have that kind of customizability.
You're always going to have to roll your own for that.
Damon
|
|
From: Bryan O. <oa...@ba...> - 2005-08-10 19:59:08
|
Damon Courtney wrote: > And, while I agree that that's REALLY cool, I don't think ANY of the > "native" scrollbars will give you that kind of action. Heck, even the > current Tk scrollbar doesn't have that kind of customizability. > You're always going to have to roll your own for that. Agreed. Though it would be Really Nice if it looked and acted just like a native scrollbar, save for the eye candy in the trough. Not mandatory just Really Nice. One of tkdiff's minor failings, IMO, is the rather clunky emulation of a scrollbar (and hey, I wrote a bunch of that code so I'm largely dissing myself here...) I was pretty happy when I discovered I could use a style to draw in the trough but didn't have to worry about drawing the arrows or thumb myself. I've been blown away by tile for quite a while now, but that added a little extra wind :-) It's a feature I could live without quite easily though. This is only one of maybe two times in my career when I wanted to do something non-standard with a scrollbar. |
|
From: Jeff H. <je...@Ac...> - 2005-08-10 20:05:54
|
> It's a feature I could live without quite easily though. This is only > one of maybe two times in my career when I wanted to do something > non-standard with a scrollbar. But let's face it, those "1 or 2" times for such customizations as a trough-enhanced scrollbar in a diff app *make* the app. That is why it is important to have both simple, themed widgets for the 90% solutions while still allowing users to get that extra 10% that really makes their apps kick *ss. Jeff |
|
From: Jeff H. <je...@Ac...> - 2005-08-10 20:12:56
|
Damon Courtney wrote:
> > Release 0.7.0 will follow shortly afterwards. This is when all the
> > BWidget compatibility hacks will be removed. Hopefully by that time
> > there will have been a new BWidget release with Tile integration done
> > right (Damon? Any progress on that?)
>
> The new BWidget release should be hitting a beta pretty
> soon here.
> Jeff said he had some stuff to commit, and I need to get his
> in and call a freeze before merging all of my stuff. Now
I have commited my BWidgets changes that reflect tile
"awareness". There are likely more fixes to come, but I
haven't even made them yet (like BWidgets dialogs need a
platform-awareness overhaul).
> we go a different route with this? Turning on Ttk support in
> BWidgets goes like this:
>
> BWidget::use ttk
Mind you, I added (not documented):
Widget::theme ?bool?
I don't mind the above either, but perhaps 'theme' instead of
'use' is better? That way it can default to classic or something.
> Should we use this to redefine the widget classes?
> Should the Button class only inherit the options for what
> it's actually using? IE:
>
> if {[BWidget::using ttk]} {
I have done some stuff like that, see font.tcl, statusbar.tcl
and scrollframe.tcl. Those are only ones I used, but others
could be updated. In some cases though, you just have to
punt/abort/port. For example, if you use the BWidgets
ComboBox, then you should just replace it with a ttk one and
figure out the options changes.
> I, personally, kinda' like having the options dummy'd out
> in BWidgets because it lets BWidgets become a bridge between
> Tk and Ttk. I can specify all of my options including a
Again, I'm against this due to the enhanced possibility of
bugs (as my previous Entry -vcmd example).
Jeff
|
|
From: Joe E. <jen...@fl...> - 2005-08-10 21:33:28
|
Damon Courtney wrote: > For "The Scrollbar Problem," couldn't you just accept that themes like > OS X and KDE don't want you to draw element-by-element and just draw > them as one, big thing when using those themes? If I understand > correctly, the problem is that OS X and KDE provide APIs to draw > entire scrollbars but not smaller elements within them, right? So, if > the user has chosen a theme with that limitation, just draw it that > way. That's more or less what I plan to do, the only question is where to put the logic. --Joe English jen...@fl... |
|
From: Kevin W. <sw...@wo...> - 2005-08-10 21:41:53
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've got a related question...
I've been using Bryan Oakley's combobox on the Mac with a horrible hack
(a gif taken from a screenshot of a native Aqua dropdown combobox arrow)
because it has a native scrollbar, but have been playing with Tile's
combobox, where the scrollbar looks wrong.
I've found that if I add this to the Tile combobox.tcl file:
if {[string equal [tk windowingsystem] "aqua"]} {
~ interp alias {} ::ttk::scrollbar {} ::scrollbar
}
the scrollbar looks right. Consequently, I'm probably going to move to
using the Tile combobox, as it has similar functionality to Bryan's.
Is this worth a patch at SF? Where should I submit it? Or should I just
keep this in my own apps?
Cheers,
Kevin Walzer, PhD
WordTech Software
http://www.wordtech-software.com
http://www.kevin-walzer.com
sw at wordtech-software.com
Joe English wrote:
| Damon Courtney wrote:
|
|
|> For "The Scrollbar Problem," couldn't you just accept that themes like
|>OS X and KDE don't want you to draw element-by-element and just draw
|>them as one, big thing when using those themes? If I understand
|>correctly, the problem is that OS X and KDE provide APIs to draw
|>entire scrollbars but not smaller elements within them, right? So, if
|>the user has chosen a theme with that limitation, just draw it that
|>way.
|
|
| That's more or less what I plan to do, the only question
| is where to put the logic.
|
|
| --Joe English
|
| jen...@fl...
|
|
| -------------------------------------------------------
| SF.Net email is Sponsored by the Better Software Conference & EXPO
| September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
| Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
| Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
| _______________________________________________
| Tktable-tile-dev mailing list
| Tkt...@li...
| https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC+nSVJmdQs+6YVcoRAmgbAJ9oLkhpnON2XaOnCKfqaFVtMFhVmACfXd5U
mfWyt4S4mNvudC6fBHqVhLY=
=/I/6
-----END PGP SIGNATURE-----
|
|
From: Jeff H. <je...@Ac...> - 2005-08-10 21:46:11
|
Kevin Walzer wrote:
> I've been using Bryan Oakley's combobox on the Mac with a
> horrible hack (a gif taken from a screenshot of a native Aqua
> dropdown combobox arrow) because it has a native scrollbar,
> but have been playing with Tile's combobox, where the
> scrollbar looks wrong.
>
> I've found that if I add this to the Tile combobox.tcl file:
>
> if {[string equal [tk windowingsystem] "aqua"]} {
> ~ interp alias {} ::ttk::scrollbar {} ::scrollbar
> }
>
> the scrollbar looks right. Consequently, I'm probably going
> to move to using the Tile combobox, as it has similar
> functionality to Bryan's.
This eliminates the ttk scrollbar totally, which isn't ideal.
I have already patched tile (in cvs) to use the regular
scrollbar on aqua for the combobox.
Jeff
|
|
From: Kevin W. <sw...@wo...> - 2005-08-10 19:04:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Damon Courtney wrote: | If I understand | correctly, the problem is that OS X and KDE provide APIs to draw | entire scrollbars but not smaller elements within them, right? So, if | the user has chosen a theme with that limitation, just draw it that | way. How many people fiddle with the damn scrollbars anyway? | On OS X, I do fiddle with the Tile scrollbars, or rather, I call scrollbar instead of ttk::scrollbar, because the Tile scrollbars on OS X don't look right, whereas the standard Tk scrollbars are natively-drawn. It's a simple workaround. If the Tile scrollbars are still broken in the forthcoming versions, that is what I'll continue to do. Cheers, Kevin Walzer, PhD WordTech Software http://www.wordtech-software.com http://www.kevin-walzer.com sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFC+k/JJmdQs+6YVcoRAlX+AJwLFoLK4wJ/2EAe5xwyXst8E93X1QCXXSjd BxofCIxK602YY57gRxWmVg== =Ir64 -----END PGP SIGNATURE----- |
|
From: Damon C. <dam...@tc...> - 2005-08-10 19:10:29
|
> On OS X, I do fiddle with the Tile scrollbars, or rather, I call
> scrollbar instead of ttk::scrollbar, because the Tile scrollbars on OS X
> don't look right, whereas the standard Tk scrollbars are natively-drawn.
> It's a simple workaround. If the Tile scrollbars are still broken in the
> forthcoming versions, that is what I'll continue to do.
Well, and that's exactly what I do. It just doesn't make much sense
that if you used the THEMED widgets, you don't get a native scrollbar,
but if you use the NON-THEMED widgets, you do. I know it's not an
easy problem to solve, and I'm forced to do the same thing. I just
hope we can clear it up before it goes into 8.5. I'd also REALLY love
to see tile-qt get bumped up to tier 1, so to speak.
Damon
|
|
From: Mats B. <ma...@pr...> - 2005-08-11 08:14:39
|
Another thing: It would be a good thing if tile could still be built as a shared lib even when placed in the tk source tree. If you have read about my tclkit adventures here and elsewhere you understand my motivitaion. There can be reasons to use tile in earlier versions than 8.4.12?, 8.5b1? Mats Joe English wrote: > > I posted a tentative release schedule to comp.lang.tcl last week > (which, for some reason, google groups doesn't have in the archive); > but there's been talk recently about merging Tile into the core, > so the previous tentative plan is no longer operative... > > The immediate short-term goal is now to get the codebase in > shape for integration. Most of this will just be internal > cleanups, but it will involve a few important user-visible > changes. Mainly: all of the transitional compatibility > options are going away sooner rather than later. > > The [ttk::progress] widget will also be removed shortly, > (so if you haven't yet switched to the [ttk::progressbar], > now would be a good time to do so...). The "Step", "Clam", > and possibly "Classic" themes are also going away, possibly > to return as separate loadable extensions. > > More changes later as I come across them. > > --Joe English > > jen...@fl... > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Tktable-tile-dev mailing list > Tkt...@li... > https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev |
|
From: Donal K. F. <don...@ma...> - 2005-08-11 08:55:51
|
Mats Bengtsson wrote: > It would be a good thing if tile could still be built as a shared lib even > when placed in the tk source tree. If you have read about my tclkit > adventures here and elsewhere you understand my motivitaion. > There can be reasons to use tile in earlier versions than 8.4.12?, 8.5b1? The only on-the-table plan for integrating Tile and Tk is a scheme for co-distribution. I see no reason for necessarily having Tk and Ttk widgets in the same library, just as I see no reason for having Tk in the same library as Tcl... Donal. |
|
From: Jeff H. <je...@Ac...> - 2005-08-11 15:32:27
|
Donal K. Fellows wrote: > Mats Bengtsson wrote: > >> It would be a good thing if tile could still be built as a shared lib >> even >> when placed in the tk source tree. If you have read about my tclkit >> adventures here and elsewhere you understand my motivitaion. >> There can be reasons to use tile in earlier versions than 8.4.12?, 8.5b1? > > > The only on-the-table plan for integrating Tile and Tk is a scheme for > co-distribution. I see no reason for necessarily having Tk and Ttk > widgets in the same library, just as I see no reason for having Tk in > the same library as Tcl... That is going to change, the integration will be in full for 8.5. However, Joe has already noted that he plans to maintain an 8.4 compatible extension, which would address Mats' needs. -- Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos |
