Problem identifying GtkTextTags for syntax highlighting
I am trying to do a bit of syntax highlighting. I am using
gtk_text_buffer_create_tag and gtk_text_buffer_insert_with_tags to
syntax-highlight the intial text (from file). That works fine.
The program needs to identify existing syntax tokens in order to do appropriate
syntax checking should the user decide to go back and amend them and I am
having problems with this.
Find a token-tag from current position:
[code]
static int findtagfromcursor ( GtkTextBuffer * buf )
{
GtkTextMark * mark = gtk_text_buffer_get_insert (buf);
GtkTextIter curiter ;
gtk_text_buffer_get_iter_at_mark (buf, &curiter, mark);
int k = 0 ;
while ( k < NUMTOKENS )
{
if ( gtk_text_iter_has_tag ( &curiter , tags [ k ] ) )
{
return k ;
}
k++ ;
}
return -1 ;
}
[/code]
The tags array is set by calls to gtk_text_buffer_create_tag when the text is
read in.
Initialisation:
[code]
GtkWidget * e = gtk_text_view_new ( ) ;
GtkTextBuffer * buf = gtk_text_view_get_buffer (GTK_TEXT_VIEW (e));
gtk_text_view_set_editable ( (GtkTextView *)e , true ) ;
g_signal_connect_after ( G_OBJECT (e) , "button-press-event" ,
G_CALLBACK (buttonpresscb) , buf ) ;
[/code]
Skeleton callback:
[code]
static gboolean buttonpresscb ( GtkWidget * w, GdkEventButton *event, char *
data )
{
GtkTextBuffer * buf = (GtkTextBuffer *)data ;
int tokenix = findtagfromcursor ( buf ) ;
if ( tokenix != -1 )
{
printf ( "MTOKEN %s(%d): \n" tokenlkup [ tokenix ] , tokenix ) ;
}
else
{
printf ( "MTOKEN %d: \n" , tokenix ) ;
}
return false;
}
[/code]
Textview text:
text text ... TOKEN2TEXT text text... TOKEN0TEXT text text ... TOKEN1TEXT
'text text...' is unadorned text.
TOKEN0TEXT, TOKEN1TEXT, TOKEN2TEXT ... are categories of text associated with
different visual attributes. The program identifies these with numbers 0,1,2
internally. When the user clicks on a token the program needs to identify the
token.
When I click TOKEN2TEXT the callback reports no-token (-1). Then when I click
TOKEN0TEXT it reports the TOKEN2TEXT (2) and when I click TOKEN1TEXT it reports
TOKEN0TEXT (0) and so on.
I thought this is because buttonpresscb is called before the text handler that
changes the current text position to the mouse-click position, so I changed the
connect call to g_signal_connect_after ( G_OBJECT (e) , "but... ).
That did not work. I received no buttonpress events at all.
Why? I am totally stuck, so would be most grateful for advice.
Get your new Email address!
Grab the Email name you've always wanted before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Problem identifying GtkTextTags for syntax highlighting
Hi Ken,
The cursor value which your code is calculating from insert mark is getting
updated in button-release-event. So the syntax tokens can be identified in
button-release-event callback.
You can even try using below method to find the cursor position in
button-press-event itself.
1. Convert the x,y coordinates received in the button-press-event to buffer
coordindates.
2. Calculate the GtkTextIter from the buffer coordinates.
eg :
/* Button press callback */
{
gtk_text_view_window_to_buffer_coords(text_view,
gtk_text_view_get_window_type (GTK_TEXT_VIEW(text_view),
event->window),event->x, event->y, &x, &y);
gtk_text_view_get_iter_at_location (GTK_TEXT_VIEW (text_view), &curr, x,
y);
/* Identify if curr iter is associated with syntax token tag array */
...
...
}
regards ,
Sanny
On Sun, Feb 28, 2010 at 5:23 PM, Ken Resander wrote:
> I am trying to do a bit of syntax highlighting. I am using
> gtk_text_buffer_create_tag and gtk_text_buffer_insert_with_tags to
> syntax-highlight the intial text (from file). That works fine.
>
> The program needs to identify existing syntax tokens in order to do
> appropriate syntax checking should the user decide to go back and amend them
> and I am having problems with this.
>
>
> Find a token-tag from current position:
> [code]
> static int findtagfromcursor ( GtkTextBuffer * buf )
>{
>GtkTextMark * mark = gtk_text_buffer_get_insert (buf);
>GtkTextIter curiter ;
>gtk_text_buffer_get_iter_at_mark (buf, &curiter, mark);
>int k = 0 ;
>while ( k < NUMTOKENS )
> {
> if ( gtk_text_iter_has_tag ( &curiter , tags [ k ] ) )
> {
> return k ;
> }
> k++ ;
> }
>return -1 ;
>}
> [/code]
>
> The tags array is set by calls to gtk_text_buffer_create_tag when the text
> is read in.
>
> Initialisation:
> [code]
>GtkWidget * e = gtk_text_view_new ( ) ;
>GtkTextBuffer * buf = gtk_text_view_get_buffer (GTK_TEXT_VIEW (e));
>gtk_text_view_set_editable ( (GtkTextView *)e , true ) ;
>g_signal_connect_after ( G_OBJECT (e) , "button-press-event" ,
> G_CALLBACK (buttonpresscb) , buf ) ;
> [/code]
>
> Skeleton callback:
> [code]
> static gboolean buttonpresscb ( GtkWidget * w, GdkEventButton *event, char
> * data )
>{
>GtkTextBuffer * buf = (GtkTextBuffer *)data ;
>int tokenix = findtagfromcursor ( buf ) ;
>if ( tokenix != -1 )
> {
> printf ( "MTOKEN %s(%d): \n" tokenlkup [ tokenix ] , tokenix ) ;
> }
>else
> {
> printf ( "MTOKEN %d: \n" , tokenix ) ;
> }
>return false;
>}
> [/code]
>
> Textview text:
> text text ... TOKEN2TEXT text text... TOKEN0TEXT text text ... TOKEN1TEXT
>
> 'text text...' is unadorned text.
> TOKEN0TEXT, TOKEN1TEXT, TOKEN2TEXT ... are categories of text associated
> with different visual attributes. The program identifies these with numbers
> 0,1,2 internally. When the user clicks on a token the program needs to
> identify the token.
>
> When I click TOKEN2TEXT the callback reports no-token (-1). Then when I
> click TOKEN0TEXT it reports the TOKEN2TEXT (2) and when I click TOKEN1TEXT
> it reports TOKEN0TEXT (0) and so on.
>
> I thought this is because buttonpresscb is called before the text handler
> that changes the current text position to the mouse-click position, so I
> changed the connect call to g_signal_connect_after ( G_OBJECT (e) , "but...
> ).
>
> That did not work. I received no buttonpress events at all.
>
> Why? I am totally stuck, so would be most grateful for advice.
>
>
> --
> New Email addresses available on Yahoo!
>
Use Umlauts on a Swiss Keyboard
Hi, I'm not sure if the following question belongs to this group. I use several applications under Windows that use GTK as their widget library e.g. HgTortoise and Sylpheed. I always had problems entering capital umlauts. I always thought that it has something to do with my computer, but I recently discovered that others have this problems as well, but only if they have activated the swiss keyboard layout. With the german keyboard layout everything seems fine. What's the difference? On german layouts you enter a capital umlaut like a small umlaut, while holding the shift key. On swiss layouts this is impossible (In Word, Excel, ... aswell). You have to press Caps-Lock first, then write the small umlaut, and then press Caps-Lock again. This may seem a bit odd, but because capital umlauts are not that frequent, it is not that bad. Every application on Windows works that way, but unfortunately it seems that it is impossible to enter an capital umlaut in every GTK applications. If I copy a capital umalut into the clipboard (e.g. with notepad) and paste it into the GTK application, GTK is able to display the umlaut without any problem, therefore it's not the rendering engine that has a problem. Has anyone any idea how to change this behaviour, or is this a bug? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Use Umlauts on a Swiss Keyboard
> Has anyone any idea how to change this behaviour, or is this a bug? If keyboard input in GTK on Windows behaves significantly differently than Microsoft's toolkit(s) for normal Microsoft-produced keyboard layouts, then yes, it is a bug. Will it be fixed? Not necessarily, unless somebody submits a patch (and participates in an iterative review of the patch). This bug report is perhaps suitablty generic: https://bugzilla.gnome.org/show_bug.cgi?id=371371 . --tml ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
On Tue, Feb 23, 2010 at 9:05 PM, <1...@depikt.net> wrote: > Yes - there are maintainance problems with gtk+ - serious maintainance > problems. let me attempt to rephrase for you: "During the development of our application, we have found that our designs seem to require features in GTK that are either missing, poorly or incorrectly implemented. We could have chosen to inspect what the wide range of existing GTK applications (some of them very large and complex) do when trying to handling situations like the ones we believe we face. However, I've decided instead to write about GTK as if it has some sort of fundamental problems, especially in comparison to another toolkit whose documentation I have definitely glanced at, but I can't tell you whether I'ved used it or not." Reasonable summary? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Remarks on gtk docs
Hm - not fully. I've used TK with tcl 1995-1999 writing software to handle plain TeX on Linux. And nearly every Python programmer is using it in the Tkinter form, when making the first steps in Python (which by its readability is well fit to large projects - far more than a better tcl or php). I turned away from it, because it has no tabular widget and from my kind of perfectionism - in my eyes it's unbearable, that TKinter is internally starting tcl. And i have some C++ experience with XView (long ago and not with exact remembrance enough to compare). No, when you have alleged to the Qt i've mentioned, that is not, what i meant. And gtk 2.18.6 currently has the following bug on my system: Leaving entries the pointer icon is remaining the text icon and the pointer only functional after any extra click. Besides the pointer gets sometimes invisible when over the application of the left entry. With focus handling at all one can have all sorts of catastrophies, especially dysfunctional focus chains. The key-release-event with tab definitely goes to the next widget. When one wants live editing of TreeView cells from an outer entry widget (a quite normal Excel function) connected to marked cells there is the problem, that sorting by that column stays active and every new letter causes sorting without the selection moving along. Thus you write into other cells after each letter. I found no way to turn off column sorting on enter-events (and turning on on leave-events) for that entry widget - gtk has the methods for that, but the code didn't work reliably. The letters inside the table's cells must be as small as possible, as long as they stay comfortably readable, because as many lines as possibly should be on the screen. They are too small for comfortable writing then (that means especially: For setting insertion points with the pointer comfortably). This has be overlooked by the programmers, who have provided the default way of cell editing - let alone support for editing some number of cells (to the same content) simultaneously. Misdesign. The missing feature, that sorting of a column cannot regularly made with a one-way-action without changing any state of the column is so bad, that i consider that as a bug. It would have been so easy to provide this. This is no proposal, as soon as i have some 40 hours to spare, i will write my own table for depikt (without any cell renderer, drawing on an unparted surface. Framing of cells for example is easy so). The Python model is finished meanwhile. Gtk is probably better as a widget builder than as a GUI-builder. The bugs around keyboard focus are bugs with basic behavior and demonstrating, that there is no core of reliable code established. "... as if it has some sort of fundamental problems ..." - yes, i write so (but not with every single problem, let alone question), but not in any "as-if"-pose. The entry-leaving error is not in pygtk - currently i have switched back to gtk-2.16 with the same pygtk, there it doesn't appear. Besides: That is nicely easy from the ambulance of gtk - just renaming of directories (my Python apps set the PATH themselves). It is on Windows - and that should be the platform of main interest. Because Xlib abstraction with gdk is useless on Unix - there alone it were just idling. The XProtocoll also could provide interfacing with non-C-languages, would Xlib be under the hood of gtk, not gdk. This is about tables and focus chains, about bureau software. What your beautiful DAW is using, might be from better parts of gtk. No, really no "as-if"-pose, but i might have misunderstood you. Thanks for reading, Joost ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
