is anyone else experiencing a problem using the font-style buttons in a conversation window where pressing one inserts a </TAG><TAG> into the message, and the cursor remains infront of both tags? i've talked to some of the other developers who say it works fine, but this is happening on a fresh install of slack7 with gnome 1.2, so i don't think it's just my system that's affected. any other input would be greatly appreciated :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
fflew,
THANK YOU! I'm not insane! it happens to me too....and I know exactly how you can fix it, cuz I patched it in my version (i submitted the patch to SF and I thought rob accepted it, but I dunno) anyway, here...open up your favorite text editor and find surround() in conversation.c
the if clause is for a selection. (you'll notice that if you put some text in the box, SELECT it, and push a font button, it works right. but just a plain font button will reverse itself.
so go down to the else for that if, and where it says:
dummy = pos;
should be:
dummy = pos + strlen(pre); (to account for the fact that the first tag is now in the box!) and then, two lines later, in the gtk_editable_set_position, use dummy in place of pos. this will put the tags back in order and put your cursor between them. what it was actually doing before, was putting the front tag in, NOT updating the position to accomodate, and putting the back tag in the same place it put the front tag, so they come out backwards. the interesting dilemma we have here, however, is not this bug, but rather the fact that if you look at the code before you patch it, you will see that it should do this for EVERYONE, not just us, and the fact that it doesn't is mystifying to me. maybe you will have some luck figuring out why (I maintain that it's rob and eric and the hundreds of other users this happens to that have messed up systems, and ours are the sane ones. =) ) seriously though: is it our gtk's? looking at the calls to gtk_editable_insert_text, the last parameter is passed with an &, indicating an address. is gtk supposed to be updating this variable when it puts text in the box, and that's why the developers didn't do it themselves, but gtk just isn't doing it for us? I dunno. anyway, just wanted to help out. Cheers.
~Aubin LaBrosse
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for the help, i just commited your changes... now we get to see everyone else complain about broken font style buttons :) i still don't understand why no one else gets this; i've tried it on a stock system fresh after an install, my old customized system, and then recompiled gtk+/glib for the stock machine just to be safe... it happened every time. it's like the daemon from my openbsd machine spread through the network to my linux box... oh well ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So the final result is that some systems have a broken GTK (or broken gcc or broken whatever), and you two are the only ones. gtk_editable_insert_text is supposed to modify its final argument, but it doesn't, but only for the two of you. That's why the patch broke things for me (and probably most other people) but didn't break things for you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
is anyone else experiencing a problem using the font-style buttons in a conversation window where pressing one inserts a </TAG><TAG> into the message, and the cursor remains infront of both tags? i've talked to some of the other developers who say it works fine, but this is happening on a fresh install of slack7 with gnome 1.2, so i don't think it's just my system that's affected. any other input would be greatly appreciated :)
fflew,
THANK YOU! I'm not insane! it happens to me too....and I know exactly how you can fix it, cuz I patched it in my version (i submitted the patch to SF and I thought rob accepted it, but I dunno) anyway, here...open up your favorite text editor and find surround() in conversation.c
the if clause is for a selection. (you'll notice that if you put some text in the box, SELECT it, and push a font button, it works right. but just a plain font button will reverse itself.
so go down to the else for that if, and where it says:
dummy = pos;
should be:
dummy = pos + strlen(pre); (to account for the fact that the first tag is now in the box!) and then, two lines later, in the gtk_editable_set_position, use dummy in place of pos. this will put the tags back in order and put your cursor between them. what it was actually doing before, was putting the front tag in, NOT updating the position to accomodate, and putting the back tag in the same place it put the front tag, so they come out backwards. the interesting dilemma we have here, however, is not this bug, but rather the fact that if you look at the code before you patch it, you will see that it should do this for EVERYONE, not just us, and the fact that it doesn't is mystifying to me. maybe you will have some luck figuring out why (I maintain that it's rob and eric and the hundreds of other users this happens to that have messed up systems, and ours are the sane ones. =) ) seriously though: is it our gtk's? looking at the calls to gtk_editable_insert_text, the last parameter is passed with an &, indicating an address. is gtk supposed to be updating this variable when it puts text in the box, and that's why the developers didn't do it themselves, but gtk just isn't doing it for us? I dunno. anyway, just wanted to help out. Cheers.
~Aubin LaBrosse
thanks for the help, i just commited your changes... now we get to see everyone else complain about broken font style buttons :) i still don't understand why no one else gets this; i've tried it on a stock system fresh after an install, my old customized system, and then recompiled gtk+/glib for the stock machine just to be safe... it happened every time. it's like the daemon from my openbsd machine spread through the network to my linux box... oh well ;)
So the final result is that some systems have a broken GTK (or broken gcc or broken whatever), and you two are the only ones. gtk_editable_insert_text is supposed to modify its final argument, but it doesn't, but only for the two of you. That's why the patch broke things for me (and probably most other people) but didn't break things for you.