From: Gregory F. M. <ma...@gf...> - 2004-02-20 21:01:03
|
Thanks for replying... I know that is the case (and it has been for at least a year now!), but gaim could have an option to turn off the tooltips. I rarely use them anyway. IMO, this fix would "get out" a heck of a lot faster... Thanks, /greg On Feb 20, 2004, Herman Bloggs <her...@ya...> wrote: |This is a GTK+ problem. You may want to file a bug report with them. | |- Herman | |--- "Gregory F. March" <ma...@gf...> wrote: |> |> Hi all... I posted this the other day. Unfortunately, it looks like |> no one has a solution at this time. |> |> When I'm forced to run windows, I try to make it act as close as I |> can |> to X windows. I set windows to have focus-follows-mouse and I run a |> virtual desktop (virtual dimension and/or vern). The frustration |> level |> with windows moving them mouse on me when desktops are switched (it |> seems windows thinks it needs to move the mouse over a window that |> last had the focus and gaim seems to always be the winner because |> it's |> sticky) and the tooltips that won't go away is so high that I have no |> choice but to switch to the ad-laden AOL version until the problem |> can |> be addressed. |> |> Since I have no development environment on my windows work box (other |> than J2EE stuff), I can't even tackle the problem myself. |> |> If anyone has a workaround, I'd *really* like to get it!! |> |> Thanks, |> |> /greg |> |> On Feb 17, 2004, "Gregory F. March" <ma...@gf...> wrote: |> |> |There has been an issue with tooltips, GTK+ and windows for some |> time now. |> |Specifically, the fact that they pop up over other apps if you |> happen to drag |> | |> |the mouse through gaim and they don't go away until you mouse over |> them. |> |Then, with the latest release of GTK+, it got worse - now they |> won't go away |> |until they are clicked on. |> | |> |Would it be possible to have an option to turn off the tooltips in |> the |> |preferences dialog? |> | |> |Or... does anyone know of some other way to get rid of them? |> |> -- |> Gregory F. March -=- http://www.gfm.net:81/~march -=- |> AIM:GfmNet |> |> |> ------------------------------------------------------- |> SF.Net is sponsored by: Speed Start Your Linux Apps Now. |> Build and deploy apps & Web services for Linux with |> a free DVD software kit from IBM. Click Now! |> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click |> _______________________________________________ |> Gaim-devel mailing list |> Gai...@li... |> https://lists.sourceforge.net/lists/listinfo/gaim-devel | | |__________________________________ |Do you Yahoo!? |Yahoo! Mail SpamGuard - Read only the mail you want. |http://antispam.yahoo.com/tools -- Gregory F. March -=- http://www.gfm.net:81/~march -=- AIM:GfmNet |
From: Daniel A. <DAt...@le...> - 2004-02-20 21:37:51
|
> On Feb 17, 2004, "Gregory F. March" <ma...@gf...> wrote: > When I'm forced to run windows, I try to make it act as close as I can > to X windows. I set windows to have focus-follows-mouse. I suspect that this (focus-follows-mouse) serves to make the problem worse. I occasionally notice tooltips that don't go away, but it is barely noticeable let alone a major problem. -D |
From: Todd V. <tv...@du...> - 2004-03-12 16:46:36
|
On Fri, 20 Feb 2004, Daniel Atallah wrote: : > When I'm forced to run windows, I try to make it act as close as I can : > to X windows. I set windows to have focus-follows-mouse. : : I suspect that this (focus-follows-mouse) serves to make the problem worse. : I occasionally notice tooltips that don't go away, but it is barely : noticeable let alone a major problem. Regardless of focus policy, is there some reason (other than lack of code to do it) that the tooltips cannot be disabled via Preferences? I'd very much like to be able to turn them off -- not because of bugs, but because "I like it that way". -- -- Todd Vierling <tv...@du...> <tv...@po...> |
From: Mark D. <ma...@ki...> - 2004-03-12 22:53:38
|
On Fri, 12 Mar 2004 11:33:59 -0500 (EST), Todd Vierling wrote > On Fri, 20 Feb 2004, Daniel Atallah wrote: > > : > When I'm forced to run windows, I try to make it act as close as > I can : > to X windows. I set windows to have focus-follows-mouse. > : : I suspect that this (focus-follows-mouse) serves to make the > problem worse. : I occasionally notice tooltips that don't go away, > but it is barely : noticeable let alone a major problem. > > Regardless of focus policy, is there some reason (other than lack of > code to do it) that the tooltips cannot be disabled via Preferences? > I'd very much like to be able to turn them off -- not because of > bugs, but because "I like it that way". > > -- > -- Todd Vierling <tv...@du...> <tv...@po...> I am personally against this for the reasons outlined in http://www106.pair.com/rhp/free-software-ui.html (see the section titled "The Question of Preferences"). Tobias, the same goes for your question about being able to disable the use of groups in the buddy list. -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Steven G. <ste...@si...> - 2004-03-12 23:07:00
|
> I am personally against this for the reasons outlined in > http://www106.pair.com/rhp/free-software-ui.html (see the section titled "The > Question of Preferences"). > -Mark I concur. The best way to deal with this is to help find out what causes the tooltips to stick longer than they should on windows and get it fixed. A preference to work around a bug should be avoid. Steven Garrity |
From: Mark D. <ma...@ki...> - 2004-03-12 23:16:31
|
On Fri, 12 Mar 2004 19:06:50 -0400, Steven Garrity wrote > > I am personally against this for the reasons outlined in > > http://www106.pair.com/rhp/free-software-ui.html (see the section titled "The > > Question of Preferences"). > > -Mark > > I concur. The best way to deal with this is to help find out what causes > the tooltips to stick longer than they should on windows and get it > fixed. A preference to work around a bug should be avoid. > > Steven Garrity I'm sure this is going to make someone respond with, "but even if the bug didn't exist, I STILL want to turn off the tooltips because they're annoying." I just want to make it clear that even if the bug didn't exist, I STILL don't think there should be an option to turn off the tooltips--it doesn't seem like something many people would use. -Mark PS. Go Wolfpack! -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Ka-Hing C. <ja...@ja...> - 2004-03-12 23:32:14
|
On Fri, Mar 12, 2004 at 06:16:18PM -0500, Mark Doliner wrote: > I'm sure this is going to make someone respond with, "but even if the bug > didn't exist, I STILL want to turn off the tooltips because they're annoying." > I just want to make it clear that even if the bug didn't exist, I STILL don't > think there should be an option to turn off the tooltips--it doesn't seem like > something many people would use. > -Mark > I think even if many people like such a "feature", since it's toolkit level stuff they should bug gtk+ people to let you disable it in gtkrc (if it's not possible already) -khc |
From: Todd V. <tv...@du...> - 2004-03-13 00:11:44
|
On Fri, 12 Mar 2004, Mark Doliner wrote: : > Regardless of focus policy, is there some reason (other than lack of : > code to do it) that the tooltips cannot be disabled via Preferences? : > I'd very much like to be able to turn them off -- not because of : > bugs, but because "I like it that way". : I am personally against this for the reasons outlined in : http://www106.pair.com/rhp/free-software-ui.html (see the section titled "The : Question of Preferences"). Yeah, I've read it, and that's a nice torch-passing crock. But that aside: I'll give you another reason. I use gaim and many other apps via a remote protocol (RDP; sometimes VNC as well) so that I can have a relocateable desktop that is usable over 802.11b, and even from across the city (my home machine's display at my employer is common). In such a context, tooltips are VERY BAD because they cause lots of spurious screen updates that increase bandwidth demand. In a remote display, turning off all nonessential screen updates is essential. This is probably why my preference is, indeed, to disable all tooltips. So you can take the above as a technical request to provide such an option to disable tooltips altogether. -- -- Todd Vierling <tv...@du...> <tv...@po...> |
From: Mark D. <ma...@ki...> - 2004-03-13 06:00:47
|
This is probably bad form, but I'm going to address this last slew of emails in one big chunk. And these are, of course, just my opinions. On Fri, 12 Mar 2004 19:04:11 -0500, Gregory F. March wrote > In principle, I agree that point. However, this request is for the > purpose of allowing the user to work around an issue in a dependent > piece of software (GTK+ in this case). It does not fall in the > category of "add preferences because I can...". > > Personally, I don't care how it's done - if a plugin could do it, > fine with me. But these tooltips have to go! (I'm biased on that last > point :-) ) > > /greg That doesn't change the fact that it is still an addition of a preference that, in theory, should not be desired by the majority of users. Whatever that gtk bug is should be fixed. Adding a work-around in Gaim removes some amount of incentive for them to fix it. On Fri, 12 Mar 2004 15:32:12 -0800, Ka-Hing Cheung wrote > I think even if many people like such a "feature", since it's > toolkit level stuff they should bug gtk+ people to let you disable > it in gtkrc (if it's not possible already) > > -khc On Fri, 12 Mar 2004 19:06:25 -0500, Gregory F. March wrote > No... tooltips are an application specific thing. You may want > tooltips for some application (like ones that are new to you), while > for more advanced users, they may not be applicable. > > To turn them off on the toolkit level is just wrong... > > /greg I'm with greg on this one. If tooltips are going to be disabled somewhere I think it would be best if it were in the application, for his reason and because gtk isn't really easy to configure. On Fri, 12 Mar 2004 19:09:05 -0500 (EST), Todd Vierling wrote > I'll give you another reason. I use gaim and many other apps via a remote > protocol (RDP; sometimes VNC as well) so that I can have a relocateable > desktop that is usable over 802.11b, and even from across the city > (my home machine's display at my employer is common). In such a > context, tooltips are VERY BAD because they cause lots of spurious > screen updates that increase bandwidth demand. In a remote display, > turning off all nonessential screen updates is essential. > > This is probably why my preference is, indeed, to disable all > tooltips. So you can take the above as a technical request to > provide such an option to disable tooltips altogether. And how many Gaim users actually do that? (This is rhetorical, I'm sure the percentage of people on this mailing list that do this is higher than the overall percentage.) I don't feel like disabling tooltips is the correct solution to this problem, either. IMO better solutions are to get more bandwidth/lower latency, don't use a graphical IM client, or don't use IM remotely at all. And yeah, those solutions aren't ideal, but I don't think catering to the small percentage of people that want to disable tooltips is a good solution, either. And again, these are just my thoughts, printed on 100% recycled something or anothers. -Mark PS. NNNNNNNN CCCCCCCCCCCCC STAAAAAAATTTEEE -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Todd V. <tv...@du...> - 2004-03-14 01:15:24
|
On Sat, 13 Mar 2004, Mark Doliner wrote: : > I'll give you another reason. I use gaim and many other apps via a remote : > protocol (RDP; sometimes VNC as well) so that I can have a relocateable : > desktop that is usable over 802.11b, and even from across the city : > (my home machine's display at my employer is common). In such a : > context, tooltips are VERY BAD because they cause lots of spurious : > screen updates that increase bandwidth demand. In a remote display, : > turning off all nonessential screen updates is essential. : And how many Gaim users actually do that? Does it matter? One does. And others want tooltips off for other reasons. : I don't feel like disabling tooltips is the correct solution to this : problem, either. And why not? This request mirrors an option available in the vast majority of GUI-intensive apps out there. Mouse-motion GUI events are considered bad form in many circles, if they cannot be disabled. Gaim should not be considered so Special that it can't implement something [on "principle"] that's so widely available elsewhere in popular applications. Users have diverse environments, and if some number of users want a commonly available option that is trivial to implement it, then why are we here arguing about whether it should be implemented at all? Talking about only the technical reason I posted: : IMO better solutions are to get more bandwidth/lower latency, That's not always possible. : don't use a graphical IM client, No command line client supports all the protocols I require. (Read: That's not always possible.) : or don't use IM remotely at all. That's not always possible. : And yeah, those solutions aren't ideal, but I don't think catering to the : small percentage of people that want to disable tooltips is a good : solution, either. No, it just makes some people look like uber-idealists who think that their idea of GUI layout is what everyone must be forced to use. High-horse positions that contradict actual user wants/needs like these are forming a disturbing trend; that's how source forks happen. (I have experience with such a fork -- an entire non-Linux operating system was born because of it.) I switched from Trillian to Gaim specifically because Gaim was much less graphics intensive, since it is specifically not skinned with megacolor image templates. Now Gaim is getting nearly as bad, because simple pointer motion (no clicks) is triggering relatively large GUI popups. There's no philosophy to it here; I just want to turn those popup windows off. How is that so difficult to make happen? -- -- Todd Vierling <tv...@du...> <tv...@po...> |
From: Stu T. <st...@no...> - 2004-03-14 02:30:01
|
some comments below, feel free to ignore, I'm just an observer.... > : > screen updates that increase bandwidth demand. In a remote display, > : > turning off all nonessential screen updates is essential. > > : And how many Gaim users actually do that? > > Does it matter? One does. And others want tooltips off for other reasons. Yes, it matters. The vast majority of open source applications thrive on "I'll scratch this itch...", if it isn't itching for many people, it doesn't get scratched. > : I don't feel like disabling tooltips is the correct solution to this > : problem, either. > > And why not? This request mirrors an option available in the vast majority > of GUI-intensive apps out there. Mouse-motion GUI events are considered bad > form in many circles, if they cannot be disabled. Tooltips are common in many apps, I don't think that many (if any!) give a per-app option to disable them. > : don't use a graphical IM client, > > No command line client supports all the protocols I require. (Read: That's > not always possible.) bitlbee? > I switched from Trillian to Gaim specifically because Gaim was much less > graphics intensive, since it is specifically not skinned with megacolor > image templates. Now Gaim is getting nearly as bad, because simple pointer > motion (no clicks) is triggering relatively large GUI popups. There's no > philosophy to it here; I just want to turn those popup windows off. heh! Regards, Stu. |
From: Todd V. <tv...@du...> - 2004-03-14 03:31:18
|
On Sat, 13 Mar 2004, Stu Tomlinson wrote: : > Does it matter? One does. And others want tooltips off for other reasons. : : Yes, it matters. The vast majority of open source applications thrive on : "I'll scratch this itch...", if it isn't itching for many people, it : doesn't get scratched. Everyone at my workplace who uses gaim hates them. That's ~50 or so. Is that enough users? Where's the threshold? : > And why not? This request mirrors an option available in the vast majority : > of GUI-intensive apps out there. Mouse-motion GUI events are considered bad : > form in many circles, if they cannot be disabled. : : Tooltips are common in many apps, I don't think that many (if any!) give : a per-app option to disable them. "Enable Tooltips" is a checkbox option in at least half the apps on my Windoze box. The other half don't use tooltips. Even the OS itself has the option (though in the registry, and offered by TweakUI). Adobe Photoshop has it -- is that popular enough for you? It's an option on most the X11 apps I use, most of which are KDE and/or GTK based. And Mozilla and the Gimp have the option -- are those popular enough to assert the point? At this point I'd be happy for it to be a hidden prefs.xml option as was suggested in another post. Anything that can fix the problem is worth it. -- -- Todd Vierling <tv...@du...> <tv...@po...> |
From: Josh S. <jo...@vi...> - 2004-03-15 19:16:48
|
>Tooltips are common in many apps, I don't think that many (if any!) give >a per-app option to disable them. > the vast majority of tooltips are small, quick and unobtrusive. gaim's are none of these. they often take 3-5 seconds to fully draw on my system, adn they completely block out the entire buddy list. i often click on the buddy list to see who's online in a glance, only to have this giant tooltip popup and cover the whole buddy list, thereby making me either wiggle the mouse around (or when the sticky tooltip bug hits, click randomly until it finally decides to go away), it causes much frustration. compare this to the tooltips on 99.9% of other apps which are ofter 1-3 words and appear *not covering* the buttons you are mousing over, and hence do not get in the way. -- ________________________________________________________________ live experimental electronic music -- http://bluevitriol.com independent u.s. drum'n'bass -- http://vitriolix.com |
From: Ronnie M. <rg...@al...> - 2004-03-14 02:21:26
|
On Mar 12, 2004, at 10:00 PM, Mark Doliner wrote: > That doesn't change the fact that it is still an addition of a > preference that, in theory, should not be > desired by the majority of users. Whatever that gtk bug is should be > fixed. Adding a work-around > in Gaim removes some amount of incentive for them to fix it. > > <snip> > > I'm with greg on this one. If tooltips are going to be disabled > somewhere I think it would be best if it > were in the application, for his reason and because gtk isn't really > easy to configure. If the main objection is adding an additional preference pane/check-box/whatever, couldn't gaim support setting this preference in your ~/.gaim/prefs.xml manually? Don't add the preference UI, but let users who know what they're doing add the pref by hand. (And hopefully document it somewhere in the FAQ or something...) Just my two cents... Ronnie |
From: Vince <lo...@in...> - 2004-03-14 06:25:49
|
On Sat, Mar 13, 2004 at 01:00:33AM -0500, Mark Doliner wrote: > That doesn't change the fact that it is still an addition of a > preference that, in theory, should not be desired by the majority of > users. I'm not sure I really follow that argument. You don't normally hear a "majority" of users arguing for any preference, including this one. All people generally want is for the software to work the way they like. The preference is a concession to the fact that not everyone likes it the same way ;) > I'm with greg on this one. If tooltips are going to be disabled > somewhere I think it would be best if it were in the application, for > his reason and because gtk isn't really easy to configure. Absolutely. Tooltips are used in many apps as learning aids, and the reason people turn them off is because they can be distracting once you no longer need them. People will not be at equal levels of competence in all their apps. > And how many Gaim users actually do that? (This is rhetorical, I'm > sure the percentage of people on this mailing list that do this is > higher than the overall percentage.) I don't feel like disabling > tooltips is the correct solution to this problem, either. IMO better > solutions are to get more bandwidth/lower latency, don't use a > graphical IM client, or don't use IM remotely at all. > > And yeah, those solutions aren't ideal, but I don't think catering to > the small percentage of people that want to disable tooltips is a good > solution, either. Configuring tooltip usage and/or delay is standard practice in many modern graphical apps. Actually, having a large tooltip delay could well be a workable solution, especially if it's a hidden preference. Setting it to something like 3000 ms (3 seconds) would probably stop it turning up unless you really wanted to see it. However, I don't know in what context tooltips are showing up for the person who wants this pref. Vince -- Vincent Ho loki /at/ internode.on.net Every complex problem is a simple hierarchy of simple problems. |
From: Evan M. <ma...@da...> - 2004-03-13 23:33:47
|
On Fri, Mar 12, 2004 at 07:09:05PM -0500, Todd Vierling wrote: > I'll give you another reason. I use gaim and many other apps via a remote > protocol (RDP; sometimes VNC as well) so that I can have a relocateable > desktop that is usable over 802.11b, and even from across the city (my home > machine's display at my employer is common). In such a context, tooltips > are VERY BAD because they cause lots of spurious screen updates that > increase bandwidth demand. In a remote display, turning off all > nonessential screen updates is essential. This is an excellent reason, and another example of why such a feature belongs in the toolkit and not the application. It'd be trivial to hack this up with an LD_PRELOAD. I don't know if Windows has some equivalent, though... -- Evan Martin ma...@da... http://neugierig.org |
From: Todd V. <tv...@du...> - 2004-03-14 01:17:18
|
On Sat, 13 Mar 2004, Evan Martin wrote: : This is an excellent reason, and another example of why such a feature : belongs in the toolkit and not the application. I'd be ~happy with a gtkrc solution, if one were to exist. I don't know of such an option. That doesn't negate the fact that most popular applications using tooltips provide an option to disable tooltips on a per-app basis. : It'd be trivial to hack this up with an LD_PRELOAD. I don't know if : Windows has some equivalent, though... No such equivalent on Win32. Regardless, this doesn't belong in an API hack. <sigh> -- -- Todd Vierling <tv...@du...> <tv...@po...> |
From: Curtis M. <cum...@mt...> - 2004-03-15 03:23:58
Attachments:
gaim-notips.patch.gz
|
Holy smokes, this may be the longest thread in Gaim history. Does this patch (against CVS) to add an option to disable tooltips have any serious problems? It compiles for me, and does the job quite nicely. I guess it does violate the string freeze by adding a new preferences option. That "Interface" pane looks like it needed something else on it. :) -- Curtis Magyar |
From: Gary K. <gr...@re...> - 2004-03-15 05:07:19
|
it's by no means a new patch... i wrote it awhile ago when i saw it in the feature request tracker, proposed it to sean, and he said no, just throw it on the tracker... So long story short... it's not getting added... Gary |
From: Curtis M. <cum...@mt...> - 2004-03-15 09:48:51
|
On Sun, 2004-03-14 at 23:06 -0600, Gary Kramlich wrote: > it's by no means a new patch... i wrote it awhile ago when i saw it in > the feature request tracker, proposed it to sean, and he said no, just > throw it on the tracker... So long story short... it's not getting > added... Did you get any reason? Was a problem with the implementation or just stubbornness? -- Curtis Magyar |
From: Gary K. <gr...@re...> - 2004-03-15 09:57:08
|
the reason is very simply this... the tooltips for the buddy list are informative.. there is no better place to put the information of the account that that buddy is on, their online time, etc... So they do _not_ and will _not_ remove it.. It's not a learn tool, it's an informative tool. I wrote the patch because people wanted to remove them.. If they want them removed that badly.. then apply the patch thats all there is to it.. It will not be added to the code, but it's there for all you people bitching about it to be able to remove them. There is no reason why this thread needs to continue anymore. Gary |
From: Curtis M. <cum...@mt...> - 2004-03-15 10:40:00
|
On Mon, 2004-03-15 at 03:57 -0600, Gary Kramlich wrote: > the reason is very simply this... the tooltips for the buddy list are > informative.. there is no better place to put the information of the > account that that buddy is on, their online time, etc... Nonetheless, its not essential information. Being able to disable them gives more flexibility, and is a useful option for people who don't want to see them. > So they do > _not_ and will _not_ remove it.. It's not a learn tool, it's an > informative tool. I wrote the patch because people wanted to remove > them.. If they want them removed that badly.. then apply the patch thats > all there is to it.. It will not be added to the code, but it's there > for all you people bitching about it to be able to remove them. There > is no reason why this thread needs to continue anymore. Trying to maintain a patch against a changing codebase is infinitely more difficult than just supplying the option within the code itself. There's more things that should be configurable but aren't, such as being able to disable the annoying reconnect dialogs. If a user wants to stop that, and just have the auto-reconnect dialog do its work and inform them via the docklet which already does happen without focus stealing dialogs then what is the sense in forcing them to see the dialog? I've already given up that fight, and the accompanying patch but I'll still bitch about it at every available opportunity. I fully agree, there is no reason this thread needs to continue. I just can't figure out why patches that make the application more flexible are being rejected for no better reason than I like tooltips. -- Curtis Magyar |
From: Todd V. <tv...@du...> - 2004-03-15 12:17:38
|
On Mon, 15 Mar 2004, Gary Kramlich wrote: : If they want them removed that badly.. then apply the patch thats : all there is to it.. That doesn't work in the long run in production environments. "Duh." -- -- Todd Vierling <tv...@du...> <tv...@po...> |
From: Christian H. <ch...@gn...> - 2004-03-15 14:00:40
|
On Mon, Mar 15, 2004 at 07:15:56AM -0500, Todd Vierling wrote: > On Mon, 15 Mar 2004, Gary Kramlich wrote: >=20 > : If they want them removed that badly.. then apply the patch thats > : all there is to it.. >=20 > That doesn't work in the long run in production environments. "Duh." It's a good thing then that we're not targetting production environments. We're scratching an itch. You're free to roll your own packages of gaim with the package. Heck, if it'll stop this mind-boggingly stupid thread, you're encouraged to roll your own packages. Christian =20 --=20 Christian Hammond <> The GNUpdate Project ch...@gn... <> http://www.gnupdate.org/ "We anticipate a global world-market with place for perhaps five compute= rs." -- Tom Watson, IBM 1949 |
From: Vince <lo...@in...> - 2004-03-15 22:55:35
|
On Mon, Mar 15, 2004 at 06:00:33AM -0800, Christian Hammond wrote: > Heck, if it'll stop this mind-boggingly stupid thread, you're > encouraged to roll your own packages. I'm not personally that bothered by the tooltip problem (even though I do find they pop up too often when I'm just browsing my buddy list). However, ignore the "demands" for disabling tooltips and step back for a second - concentrate on the fundamental problem - why are people demanding it when it's not in every other app with tooltips? And IMO the reason is because Gaim's tooltips are somewhat intrusive. The request for a pref is just a symptom of a problem in the UI. I'm not stomping my foot demanding you fix it, nor am I going to tell you what to do about it. I think this thread has gone too far into some lame "developers vs users" ranting on both sides. All I want is for you to step back for a second and consider that maybe the tooltips are being too intrusive, and that's causing the other complaints. Vince -- Vincent Ho loki /at/ internode.on.net Every complex problem is a simple hierarchy of simple problems. |