From: Gregory F. M. <ma...@gf...> - 2004-03-18 18:40:16
|
On Mar 18, 2004, Ethan Blanton <ebl...@cs...> wrote: |While I agree in general with this principle, the buddy list tooltips |are a _huge_ usability win in many instances, and in the common case of Ethan, I clearly am missing something - I've heard several times from several people how valuable the BLT (Buddy List Tooltips) are, but I am having a hard time grappling with why they are SO valuable. Can you possibly provide some insight? Perhaps describing how you use them (that I'm obviously not doing)? What would you loose if they were a popup window instead, or gone entirely? |local access (I personally use remote X rather more often than I would |like to admit, but that is not a common usage pattern these days) it |just isn't an efficiency concern. Well, on my P-166 it is a really big efficiency concern. So is mozilla for that matter. It used to be that linux was great to run on older hardware, but this has become somewhat of a misnomer these days (ah, the good old days of ctwm and netscape -owncmap! :-)). Thanks, /greg -- Gregory F. March -=- http://www.gfm.net:81/~march -=- AIM:GfmNet |
From: Gregory F. M. <ma...@gf...> - 2004-03-18 19:35:48
|
On Mar 18, 2004, Christian Hammond <ch...@gn...> wrote: |If we removed these, I don't even want to think about the number of |people that would be complaining and threatening to switch clients. But, I thought Luke said users didn't matter? ;-) |You can always use a patch. That's not what I was asking... |I have a P166 also, and yes, it is a shame that stuff doesn't work so |well anymore. I also wish I could still use my C64 for a lot of |things, but I'm over here, in reality. Sure is a good thing that |computers are so cheap now, isn't it? If it's that big of an |inconvenience, hold off on that extra candy bar, or that coffee, or |the pizza. Do that for a little bit and buy a $400 computer. Put it on |a credit card. Whatever. They're cheap now, and there's really no |excuse not to have something that runs applications at least fairly |reasonably. No reason to take the high road - I didn't say the P166 was my only machine. But there is also no reason why a capable machine shouldn't perform reasonable. That P166 makes a great SETI@Home server. Anyway, this is off topic... /greg -- Gregory F. March -=- http://www.gfm.net:81/~march -=- AIM:GfmNet |
From: Gregory F. M. <ma...@gf...> - 2004-03-18 20:01:05
|
On Mar 18, 2004, Ethan Blanton <ebl...@cs...> wrote: |Preference bloat. For some reason this keeps being dismissed by the |vocal advocates of turning off the tooltips, but I'm not sure why... Because, quite frankly, there aren't that many preferences in gaim to even be thinking it is a problem. Like I said before, look at some more complex apps (like eclipse, openoffice, etc.) and you will see that the huge amount of preferences are handled quite nicely WHEN DESIGNED PROPERLY and pretty terrible when not. To even be worried that gaim has too many options is just silly. However, a design principle to limit frivolous preferences is not and I respect that. But to say that we can't add a feature that some people seem to want because there are too many preferences is something that I have to question. /greg -- Gregory F. March -=- http://www.gfm.net:81/~march -=- AIM:GfmNet |
From: Ka-Hing C. <ja...@ja...> - 2004-03-18 20:13:16
|
On Thu, Mar 18, 2004 at 03:01:01PM -0500, Gregory F. March wrote: > > On Mar 18, 2004, Ethan Blanton <ebl...@cs...> wrote: > > |Preference bloat. For some reason this keeps being dismissed by the > |vocal advocates of turning off the tooltips, but I'm not sure why... > > Because, quite frankly, there aren't that many preferences in gaim to > even be thinking it is a problem. Like I said before, look at some > more complex apps (like eclipse, openoffice, etc.) and you will see > that the huge amount of preferences are handled quite nicely WHEN > DESIGNED PROPERLY and pretty terrible when not. I have not used eclipse much, but I disagree that openoffice's preferences are "handled quite nicely." I would definitely put it in the category of "preference bloat". > To even be worried that gaim has too many options is just silly. > However, a design principle to limit frivolous preferences is not and > I respect that. But to say that we can't add a feature that some > people seem to want because there are too many preferences is > something that I have to question. Because other than the remote X problem that the other person mentioned, no one has given any good reason why they want to have such a preference. -khc |
From: Vince <lo...@in...> - 2004-03-19 00:17:48
|
On Thu, Mar 18, 2004 at 12:13:15PM -0800, Ka-Hing Cheung wrote: > I have not used eclipse much, but I disagree that openoffice's > preferences are "handled quite nicely." I would definitely put it in > the category of "preference bloat". Actually I'm not sure that this is true. OpenOffice is a much larger program, so it makes sense that it has more preferences. I think if you wrote a program of that scale, you'd be hard-pressed to avoid having plenty of prefs as well. Comparing Gaim with OpenOffice when it comes to prefs is thus kind of silly. I'm sure there are candidates which are more in Gaim's weight class ;) Vince -- Vincent Ho loki /at/ internode.on.net Every complex problem is a simple hierarchy of simple problems. |
From: Ka-Hing C. <ja...@ja...> - 2004-03-19 00:26:50
|
On Fri, Mar 19, 2004 at 11:17:41AM +1100, Vince wrote: > Actually I'm not sure that this is true. OpenOffice is a much larger > program, so it makes sense that it has more preferences. I think if you > wrote a program of that scale, you'd be hard-pressed to avoid having > plenty of prefs as well. > > Comparing Gaim with OpenOffice when it comes to prefs is thus kind of > silly. I'm sure there are candidates which are more in Gaim's weight > class ;) No, I am not comparing Gaim with OpenOffice, but OpenOffice with itself. There are just way to many preferences that people won't/should not need to change (memory usage anyone?), and similiar preferences that exist once for each specific applications. -khc |
From: Ethan B. <ebl...@cs...> - 2004-03-18 20:18:23
|
Gregory F. March spake unto us the following wisdom: > On Mar 18, 2004, Ethan Blanton <ebl...@cs...> wrote: > |Preference bloat. For some reason this keeps being dismissed by the > |vocal advocates of turning off the tooltips, but I'm not sure why... >=20 > Because, quite frankly, there aren't that many preferences in gaim to > even be thinking it is a problem. Like I said before, look at some > more complex apps (like eclipse, openoffice, etc.) and you will see > that the huge amount of preferences are handled quite nicely WHEN > DESIGNED PROPERLY and pretty terrible when not. No, there are not that many preferences in gaim, and I think this is a testament to some of the developers' commitment to not allowing frivolous (I like that classification, if I may borrow it...) prefs. The very attitude that there aren't that many so there is no need to worry is the way horrible monstrosities like OpenOffice happen. An ounce of prevention is worth a pound of cure... > To even be worried that gaim has too many options is just silly. > However, a design principle to limit frivolous preferences is not and > I respect that. But to say that we can't add a feature that some > people seem to want because there are too many preferences is > something that I have to question. I am actually of the opinion that it does have too many preferences have pointed out, "some people seem to want" it is a very poor justification for a new preference. I personally believe this topic has been exhausted, and will no longer participate in it. It is clear that there is a vocal group of no more than a handful of people who truly do not want to see blist tooltips, and it is equally clear that there are a number of developers who object to adding preferences for the sake of this objection. Neither side seems to feel the arguments of the other merit (or do not merit, as the case may be) change, and I'm not seeing anything but more and more far-reaching "but I've seen X in app (or doc- ument) Y" arguments turning up. My opinions on this matter are not nearly worth the time I've spent expressing them. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Todd V. <tv...@du...> - 2004-03-22 16:52:52
|
On Thu, 18 Mar 2004, Christian Hammond wrote: : Stop complaining and just patch gaim. OK, will do. But realize that "just patch" for a feature DOES NOT imply only changing source code -- binary packaging is involved too. Not everyone can or does build from source, and this sort of response leaves Win32 users in the dust. So, since there will be no concessions made on the part of the Gaim maintainers, I'm being forced into a corner. I don't like this situation, but it has become necessary. I therefore must announce: ===== The OpenGaim project has been launched to provide a version of the Gaim instant messaging client (http://gaim.sourceforge.net/) containing additional features requested by users which are not available in the Gaim project's distribution. OpenGaim will be maintained as a loose relative of the Gaim codebase, and will contain at least as many features as the Gaim project's distribution. While the project will continue to strive to preserve the core/UI split and other superb architecture aspects of the Gaim codebase, OpenGaim will also aim to provide increased customizability for advanced end users and increased frequency of releases to fix major problems early. The first release of OpenGaim should be out the second or third week of April. http://opengaim.sourceforge.net/ Contributing developers are welcome. -- -- Todd Vierling <tv...@du...> <tv...@po...> |
From: Christian H. <ch...@gn...> - 2004-03-22 21:03:55
|
On Mon, Mar 22, 2004 at 11:52:03AM -0500, Todd Vierling wrote: > The OpenGaim project has been launched to provide a version of the Gaim > instant messaging client (http://gaim.sourceforge.net/) containing > additional features requested by users which are not available in the Gaim > project's distribution. That's a lot easier than bundling a package with a patch. Bravo. Since we're running the same code now, forward any bug fixes to us. Thanks. Christian =20 --=20 Christian Hammond <> The GNUpdate Project ch...@gn... <> http://www.gnupdate.org/ An optimist believes we live in the best world possible; a pessimist fears this is true. |
From: Todd V. <tv...@du...> - 2004-03-22 21:51:00
|
On Mon, 22 Mar 2004, Christian Hammond wrote: : > The OpenGaim project has been launched to provide a version of the Gaim : > instant messaging client (http://gaim.sourceforge.net/) containing : > additional features requested by users which are not available in the Gaim : > project's distribution. : : That's a lot easier than bundling a package with a patch. Bravo. Indeed, for end users, it is. It provides a central point of collimation for "patches" that turn into real, bundled builds that not everyone has to build from source. (After all, you can't merge features from two one-off "patched" binary builds.) -- -- Todd Vierling <tv...@du...> <tv...@po...> |
From: Gregory F. M. <ma...@gf...> - 2004-03-18 21:20:19
|
On Mar 18, 2004, Ka-Hing Cheung <ja...@ja...> wrote: |> Because, quite frankly, there aren't that many preferences in gaim to |> even be thinking it is a problem. Like I said before, look at some |> more complex apps (like eclipse, openoffice, etc.) and you will see |> that the huge amount of preferences are handled quite nicely WHEN |> DESIGNED PROPERLY and pretty terrible when not. | |I have not used eclipse much, but I disagree that openoffice's |preferences are |"handled quite nicely." I would definitely put it in the category of |"preference bloat". Sorry! - that was the point I was trying to make eclipse = designed properly, oo = not. |Because other than the remote X problem that the other person mentioned, |no one has given any good reason why they want to have such a preference. That's not true. Go read the thread... /greg -- Gregory F. March -=- http://www.gfm.net:81/~march -=- AIM:GfmNet |
From: Ka-Hing C. <ja...@ja...> - 2004-03-18 21:29:28
|
On Thu, Mar 18, 2004 at 04:20:05PM -0500, Gregory F. March wrote: > |Because other than the remote X problem that the other person mentioned, > |no one has given any good reason why they want to have such a preference. > > That's not true. Go read the thread... > I have been keeping up (sadly, considering that I have a midterm in 4 hours) , the only other two reasons I've seen: 1) Those tooltips stick on Windows! Great, go fix GTK. 2) Those tooltips cover some buddies! Great, move your mouse. Any tooltip may potentially cover other widgets, it's a small price to pay. 3) I hate tooltips! I hate you. -khc |
From: Ka-Hing C. <ja...@ja...> - 2004-03-18 21:35:46
|
> I have been keeping up (sadly, considering that I have a midterm in 4 hours) > , the only other two reasons I've seen: Of course, I meant 3. -khc |
From: Mark D. <ma...@ki...> - 2004-03-18 22:24:07
|
On Thu, 18 Mar 2004 13:29:27 -0800, Ka-Hing Cheung wrote > 1) Those tooltips stick on Windows! > Great, go fix GTK. Per http://bugzilla.gnome.org/show_bug.cgi?id=135206 , this should be fixed. I would be grateful if someone using Windows could verify that the bug is actually fixed. gtk 2.4 should have the fix, I believe. -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Andrew S. <gt...@ma...> - 2004-03-19 10:01:52
|
On Thu, 2004-03-18 at 16:29, Ka-Hing Cheung wrote: > 2) Those tooltips cover some buddies! > Great, move your mouse. Any tooltip may potentially cover other widgets, it's > a small price to pay. The only way to prevent a tooltip from showing up when your mouse is actually in the area of the buddy list is to constantly move it, or rest it on a group. Constantly moving it is a pain in the wrist and large lists will often not have groups close enough to the buddies you want to use for that to work. The best workaround for this problem is probably to rest your mouse over one of the scroll bars. Most users of scroll wheels just wouldn't think of this because they don't need to use vertical scroll bars very often. The scroll wheel works just as well over the scroll bar, so there is no loss here. I don't care about the preference, but I agreed with the reasons why people would want the preference until I took a few minutes to solve the problem with the given interface. -- Andrew Sayman <gt...@ma...> |
From: Jeremy B. <je...@br...> - 2004-03-19 19:23:21
|
I hate to rain on the tooltip party, but does anyone know when 0.76 will be out? I heard mention of a string freeze a week or so ago, but nothing since. Thanks in advance, Jeremy |
From: Luke S. <lsc...@us...> - 2004-03-19 19:35:26
|
We hoped to get it out first thursday last week, then by this week, and currently by next week. a series of bugs in the new wysiwyg input widgets are holding us up. luke On Fri, Mar 19, 2004 at 02:23:15PM -0500, Jeremy Brown wrote: > I hate to rain on the tooltip party, but does anyone know when 0.76 will > be out? I heard mention of a string freeze a week or so ago, but > nothing since. > > Thanks in advance, > > Jeremy > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- -This email is made of 100% recycled electrons. |
From: Mark D. <the...@us...> - 2004-03-30 01:56:22
|
FYI, there is a preference in Gaim (without a GUI) you can use to disable buddy list tooltips or set their time delay. It's /gaim/gtk/blist/tooltip_delay. You should find it if you search ~/.gaim/prefs.xml for "tooltip_delay." A value of 0 disables the tooltips altogether. Other values specify the delay in milliseconds. Gaim must not be running when the value is changed. -Mark -- O O Mark Doliner \ | ma...@ki... \ | www.kingant.net "There needs to be a better word for weird." |
From: Vince <lo...@in...> - 2004-03-30 12:28:08
|
On Mon, Mar 29, 2004 at 08:56:09PM -0500, Mark Doliner wrote: > FYI, there is a preference in Gaim (without a GUI) you can use to > disable buddy list tooltips or set their time delay. Let me be the first to say thanks for your work guys :) I look forward to trying it out when the next release rolls out. Vince -- Vincent Ho loki /at/ internode.on.net Every complex problem is a simple hierarchy of simple problems. |
From: Lenny M. <ld...@ho...> - 2004-03-30 13:28:26
|
Thank you! It did not seem like something to fork over. Vince provided the following wisdom on 3/30/2004 7:28 AM: > On Mon, Mar 29, 2004 at 08:56:09PM -0500, Mark Doliner wrote: > > >>FYI, there is a preference in Gaim (without a GUI) you can use to >>disable buddy list tooltips or set their time delay. > > > Let me be the first to say thanks for your work guys :) I look forward > to trying it out when the next release rolls out. > > > Vince > |
From: Josh S. <jo...@vi...> - 2004-03-30 21:06:40
|
"happyhappyjoyjoy" etc... :) Mark Doliner wrote: >FYI, there is a preference in Gaim (without a GUI) you can use to disable >buddy list tooltips or set their time delay. It's >/gaim/gtk/blist/tooltip_delay. You should find it if you search >~/.gaim/prefs.xml for "tooltip_delay." A value of 0 disables the tooltips >altogether. Other values specify the delay in milliseconds. Gaim must not be >running when the value is changed. >-Mark > >-- >O O Mark Doliner > \ | ma...@ki... > \ | www.kingant.net >"There needs to be a better word for weird." > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Gaim-devel mailing list >Gai...@li... >https://lists.sourceforge.net/lists/listinfo/gaim-devel > > -- ________________________________________________________________ live experimental electronic music -- http://bluevitriol.com independent u.s. drum'n'bass -- http://vitriolix.com |
From: Christian H. <ch...@gn...> - 2004-03-18 18:59:29
|
On Thu, Mar 18, 2004 at 01:40:11PM -0500, Gregory F. March wrote: >=20 > On Mar 18, 2004, Ethan Blanton <ebl...@cs...> wrote: >=20 > |While I agree in general with this principle, the buddy list tooltips > |are a _huge_ usability win in many instances, and in the common case of >=20 > Ethan, >=20 > I clearly am missing something - I've heard several times from several > people how valuable the BLT (Buddy List Tooltips) are, but I am having > a hard time grappling with why they are SO valuable. If we removed these, I don't even want to think about the number of people that would be complaining and threatening to switch clients. I find them very valuable. When I want to know somebody's away message, how long they've been online, which of my accounts I'm seeing thgem on, etc., all I have to do is hover over them. If I want to move my mouse elsewhere on the buddy list, I just move it down and the tooltip goes away. No big deal. In my opinion, it's one of the things that makes Gaim stand out from other clients. > Can you possibly provide some insight? Perhaps describing how you use > them (that I'm obviously not doing)? What would you loose if they > were a popup window instead, or gone entirely? Convenience, and we'd gain a lot of angry people. Aside from that, no developer (to my knowledge) wants this to happen, so it won't. You can always use a patch. > |local access (I personally use remote X rather more often than I would > |like to admit, but that is not a common usage pattern these days) it > |just isn't an efficiency concern. >=20 > Well, on my P-166 it is a really big efficiency concern. So is > mozilla for that matter. It used to be that linux was great to run on > older hardware, but this has become somewhat of a misnomer these days > (ah, the good old days of ctwm and netscape -owncmap! :-)). I have a P166 also, and yes, it is a shame that stuff doesn't work so well anymore. I also wish I could still use my C64 for a lot of things, but I'm over here, in reality. Sure is a good thing that computers are so cheap now, isn't it? If it's that big of an inconvenience, hold off on that extra candy bar, or that coffee, or the pizza. Do that for a little bit and buy a $400 computer. Put it on a credit card. Whatever. They're cheap now, and there's really no excuse not to have something that runs applications at least fairly reasonably. Christian =20 --=20 Christian Hammond <> The GNUpdate Project ch...@gn... <> http://www.gnupdate.org/ If it jams, force it. If it breaks, it needed replacing |
From: Todd V. <tv...@du...> - 2004-03-18 19:33:46
|
On Thu, 18 Mar 2004, Ethan Blanton wrote: : While the current implementation is relatively large and heavyweight, : they are not actually difficult to draw in most respects, given appro- : priate usage of the X protocol. You're assuming that X11 is the on-the-wire protocol being used to display the client remotely -- or that, if X11 is the protocol, the server might support speedup extensions to make some widget happier. "Don't do that." 8-) : While I agree in general with this principle, the buddy list tooltips : are a _huge_ usability win in many instances, That's fine and dandy, but you don't say why it's bad to be able to turn them off optionally. I'm perfectly happy with them, and use them!, *if* I'm local. But when I'm remote, I'd like them gone to save the lag. I never proposed removing them altogether. -- -- Todd Vierling <tv...@du...> <tv...@po...> |
From: Ethan B. <ebl...@cs...> - 2004-03-18 19:47:41
|
Todd Vierling spake unto us the following wisdom: > On Thu, 18 Mar 2004, Ethan Blanton wrote: > : While the current implementation is relatively large and heavyweight, > : they are not actually difficult to draw in most respects, given appro- > : priate usage of the X protocol. >=20 > You're assuming that X11 is the on-the-wire protocol being used to display > the client remotely -- or that, if X11 is the protocol, the server might > support speedup extensions to make some widget happier. "Don't do that." > 8-) I am assuming X11. I don't care about other protocols. What I am talk- ing about does not require speedup extensions, however ... displaying a server-stored pixmap is as simple as referencing it by its ID, and requires no transmission of the pixmap; likewise, X11 text is as simple as sending the ASCII representation of the text you would like to draw. If you break our tooltips down, they are extremely simple to draw -- we don't happen to draw them particularly efficiently, but this is a bug of sorts and should not be counted against the concept. > : While I agree in general with this principle, the buddy list tooltips > : are a _huge_ usability win in many instances, >=20 > That's fine and dandy, but you don't say why it's bad to be able to turn > them off optionally. I'm perfectly happy with them, and use them!, *if* = I'm > local. But when I'm remote, I'd like them gone to save the lag. Preference bloat. For some reason this keeps being dismissed by the vocal advocates of turning off the tooltips, but I'm not sure why... Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Josh S. <jo...@vi...> - 2004-03-18 20:09:25
|
Ethan Blanton wrote: >>That's fine and dandy, but you don't say why it's bad to be able to turn >>them off optionally. I'm perfectly happy with them, and use them!, *if* I'm >>local. But when I'm remote, I'd like them gone to save the lag. >> >> > >Preference bloat. For some reason this keeps being dismissed by the >vocal advocates of turning off the tooltips, but I'm not sure why... > >Ethan > > > because for some reason all of a sudden preference bloat is being cited as some holy grail of the project, when a cursory glance at the preference dialog shows that this is obviously not a big concern 99% of the time. when you arbirarily cite "preference bloat" when you have other bizarre individual taste options like "show numbers in groups", "automatically expand contacts", "dim idle buddies", "display remote nicknames..." ... so why are you guys being so stubborn about it now? -- ________________________________________________________________ live experimental electronic music -- http://bluevitriol.com independent u.s. drum'n'bass -- http://vitriolix.com |