GNOME Bugzilla – Bug 498954
cannot modify highlighting patterns
Last modified: 2008-12-06 15:02:16 UTC
Please describe the problem: when trying to modify the syntax highlighting patterns, the existing/default patterns do not show up at the relevant fields. Steps to reproduce: 1. in Bluefish, open Preferences. 2. choose the Syntax highlighting tab. 3. on top, choose a filetype you wish to modify, e.g. Javascript. 4. choose a pattern to modify, e.g. Comment(C) - no patterns show up, no color information, and also the Up/Down buttons do not work. Actual results: it just doesn't work. Expected results: I would like to be able to change syntax highlighting colors, for example. Does this happen every time? Yes. Other information: This happens on Fedora 8 and also on Ubuntu 7.10.
Sounds like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449288.
(In reply to comment #1) > Sounds like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449288. > Thanks, that's exactly it. I'll try to rebuild Bluefish with the debug info on my Ubuntu machine and post here.
Hm. I'm able to reproduce this issue from a new user account (every session) and from a GNOME session. I'm unable to reproduce the issue from my XFCE session.
Ok. I think I found something. But I don't know, what's causing this. If I enable full debugging mode I receive: highlightpattern_selection_changed_cb, started highlightpattern_selection_changed_cb, selected=HTML highlightpattern_apply_changes, started highlightpattern_apply_changes, no curstrarr, nothing to apply changed applied, searching for the data of the new selection highlightpattern_selection_changed_cb, found strarr=0x85f58c8 0=php, 1=HTML, 2=1, 3=<(/?[a-z][a-z0-9]*), 4=> strarr[10]=0, highlightpattern_selection_changed_cb, started highlightpattern_selection_changed_cb, selected=<html> Tags highlightpattern_apply_changes, started highlightpattern_apply_changes, curstrarr==tmplist->data==0x85f58c8 highlightpattern_create_strarr for php-HTML at 0x85f58c8 highlightpattern_create_strarr, strarr at 0x85f58c8 with count 11 highlightpattern_apply_changes, new strarr for php-HTML changed applied, searching for the data of the new selection highlightpattern_selection_changed_cb, found strarr=0x85f59b8 0=php, 1=<html> Tags, 2=1, 3=1, 4= highlightpattern_type_toggled, started highlightpattern_type_toggled, done highlightpattern_type_toggled, started highlightpattern_type_toggled, done strarr[10]=0, in my XFCE4 session, where I cannot observe the issue. But in my GNOME session, where I can reproduce the bug I see: highlightpattern_selection_changed_cb, started highlightpattern_selection_changed_cb, selected=HTML highlightpattern_apply_changes, started highlightpattern_apply_changes, no curstrarr, nothing to apply changed applied, searching for the data of the new selection highlightpattern_selection_changed_cb, started highlightpattern_selection_changed_cb, selected=<html> Tags highlightpattern_apply_changes, started highlightpattern_apply_changes, no curstrarr, nothing to apply Full logs are attached. Any ideas?
Because the logs are a little bit big, I uploaded them to my webspace: http://debian.wgdd.de/temp/498954/
Hm. Tracked it further down by adding a new debug message to highlightpattern_selection_changed_cb(). This is what I get 0=php, 1=HTML, pattern=<html> Tags, pd->hpd.selected_filetype=Sans ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ and "Sans" != "php", so the condition fails. What's causing this? Do we have a broken pointer here?
Or is it a problem in Gtk and we need to reassign it?
I've been further debugging. The string that is placed in pd->hpd.selected_filetype is a pointer to the internal string in a gtk label. This gtk label is the child of a menuitem label. How the code is designed: as long as this menuitem exists, the label will exist, and thus the string can be used. But for some reason this doesn't work. If I request the active menuitem in highlightpattern_selection_changed_cb(): GtkWidget *menuitem = gtk_menu_get_active(GTK_MENU(gtk_option_menu_get_menu(GTK_OPTION_MENU(pd->hpd.popmenu)))); and I request the child from this menuitem: GTK_BIN(menuitem)->child I get NULL.. So the label doesn't exist anymore, and we use an internal string from the label.... in previous gtk versions this worked, but now something is broken. Could be a gtk optimization of some kind.
I can confirm this problem on an x86 system running Gentoo, Bluefish v1.0.7 under Gnome v2.20.1. I use Bluefish for professional web design and have a serious need to update syntax highlighting, so unless this problem gets fixed soon, I'm considering writing a wxPython app to maintain ~/.bluefish/highlighting :-) I'll also file a bug on the Gentoo bug system and maybe one of the devs there could take a look at it, since the last post on this bug here was a month ago.
We did not yet find the cause of the problem. It might be in the Gtk+ code and not inside bluefish or maybe we missed an important change in Gtk+ 2.12. We appreciate any help to solve this. Many distributions, including Debian, Ubuntu and RedHat/Fedora (and now Gentoo too) have reported this issue.
Hi Daniel, This definitely appears to either be a bug or a change in the behavior of GTK. I think more likely a bug. Possibly in GtkOptionMenu. It has been depreciated since GTK 2.4. It probably is not tested very much anymore. I committed a workaround to the 1.0.x branch of CVS. Appears to be fixed now.
Created attachment 103236 [details] [review] Patch Patch that was committed to CVS.
works under Debian (many thanks Jim)
Cool, thanks for testing it Daniel.
Works in Gentoo, too, against Bluefish-1.0.7. Thanks!
(In reply to comment #11) > Hi Daniel, > > This definitely appears to either be a bug or a change in the behavior of GTK. > I think more likely a bug. Possibly in GtkOptionMenu. It has been depreciated > since GTK 2.4. It probably is not tested very much anymore. > > I committed a workaround to the 1.0.x branch of CVS. Appears to be fixed now. > Jim, This might be somewhat of a newbie question- How do I install/reinstall Bluefish 1.0.7 from CVS? There are instructions on the website for checking out bluefish-gtk2 which is an unstable new version, and I haven't found 1.0.7 in the CVS tree. Thanks, Shaike
http://bfwiki.tellefsen.net/index.php?pagename=DownloadingFromCVS -> Checkout the current stable branch
Hmm, the address in those instructions is incorrect. It should be.. cvs -z3 -d:pserver:anonymous@bluefish.cvs.sourceforge.net:/cvsroot/bluefish co -d bluefish-1_0 -r bluefish_1_0 bluefish-gtk2
(In reply to comment #18) > Hmm, the address in those instructions is incorrect. It should be.. > > cvs -z3 -d:pserver:anonymous@bluefish.cvs.sourceforge.net:/cvsroot/bluefish co > -d bluefish-1_0 -r bluefish_1_0 bluefish-gtk2 > Thank you Jim. is there a difference between using 'bluefish_1_0' and 'bluefish_1_0_7'?
When you checkout 'bluefish_1_0' you are checking out the current stable branch from CVS. This means you are checking out 1.0.7 plus any bug fixes and changes made after the release of 1.0.7. If you were to checkout 'release_1_0_7. you would only be checking out the 1.0.7 version of Bluefish.
(In reply to comment #20) > When you checkout 'bluefish_1_0' you are checking out the current stable branch > from CVS. This means you are checking out 1.0.7 plus any bug fixes and changes > made after the release of 1.0.7. > > If you were to checkout 'release_1_0_7. you would only be checking out the > 1.0.7 version of Bluefish. > I checked out ver. 1_0, compiled, and indeed the issue is fixed, and Bluefish now appears as version 1.0.8 . Thank you all, Shaike
*** Bug 499856 has been marked as a duplicate of this bug. ***