Re: Tooltip for GtkTextView contents
Also should note - the detection of whether the pointer is over a word
or not ( $iter->inside_word ) *is* working correctly ... as my app
appears to be returning correctly when I'm pointing at whitespace. It
just prints blank lines when I point at some text.
Dan
On Fri, Feb 17, 2017 at 3:50 PM, Daniel Kasak wrote:
> Hi all.
>
> I'd like to provide help on special text ( tokens in code ) in a
> GtkSourceView / GtkTextView. I see my question is basically:
> https://mail.gnome.org/archives/gtk-list/2010-May/msg00107.html
>
> ... and the important part of the response to this question was:
>
> "Simply set text view's "has-tooltip" property to "TRUE" and connect handler
> to
> "query-tooltip" signal. Use coordinates provided by callback to find
> the word that cursor hovers over and then do the lookup. I think
> things should be relatively simple."
>
> So I've done attempted this in Perl:
>
> ---
>
> sub on_PARAM_VALUE_query_tooltip {
>
> my ( $self, $sourceview, $window_x, $window_y, $keyboard_mode,
> $tooltip ) = @_;
>
> my ( $buffer_x, $buffer_y ) = $sourceview->window_to_buffer_coords
> ( 'GTK_TEXT_WINDOW_TEXT', $window_x, $window_y );
>
> my ( $trailing, $iter ) = $sourceview->get_iter_at_position(
> $buffer_x, $buffer_y );
>
> if ( ! $iter->inside_word ) {
> return FALSE;
> }
>
> my $start_iter;
>
> if ( $iter->starts_word ) {
> $start_iter = $iter;
> } else {
> $iter->backward_word_start;
> $start_iter = $iter;
> }
>
> $iter->forward_word_end;
>
> my $text = $sourceview->get_buffer->get_text( $start_iter, $iter, 1 );
>
> print "$text\n";
>
> }
>
> ---
>
> This code runs, produces iters where expected, but then never gets any text.
>
> What have I done wrong?
>
> Thanks :)
>
> Dan
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Tooltip for GtkTextView contents
Hi all.
I'd like to provide help on special text ( tokens in code ) in a
GtkSourceView / GtkTextView. I see my question is basically:
https://mail.gnome.org/archives/gtk-list/2010-May/msg00107.html
... and the important part of the response to this question was:
"Simply set text view's "has-tooltip" property to "TRUE" and connect handler to
"query-tooltip" signal. Use coordinates provided by callback to find
the word that cursor hovers over and then do the lookup. I think
things should be relatively simple."
So I've done attempted this in Perl:
---
sub on_PARAM_VALUE_query_tooltip {
my ( $self, $sourceview, $window_x, $window_y, $keyboard_mode,
$tooltip ) = @_;
my ( $buffer_x, $buffer_y ) = $sourceview->window_to_buffer_coords
( 'GTK_TEXT_WINDOW_TEXT', $window_x, $window_y );
my ( $trailing, $iter ) = $sourceview->get_iter_at_position(
$buffer_x, $buffer_y );
if ( ! $iter->inside_word ) {
return FALSE;
}
my $start_iter;
if ( $iter->starts_word ) {
$start_iter = $iter;
} else {
$iter->backward_word_start;
$start_iter = $iter;
}
$iter->forward_word_end;
my $text = $sourceview->get_buffer->get_text( $start_iter, $iter, 1 );
print "$text\n";
}
---
This code runs, produces iters where expected, but then never gets any text.
What have I done wrong?
Thanks :)
Dan
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
g_convert() character encode converter failure for GBK to utf8
Hi Glib developers: We found a issue of g_convert() when convert the GBK encode to the UTF8. We are using glib-2.0_2.40.0. After doing some investigation, I feel it might be caused by the iconv APIs. Since the conversion also fail with the iconv API directly. As I understand the iconv API is come from glibc. So I try to do following test: download the separate library libiconv from https://www.gnu.org/software/libiconv/ 1.14 version do cross compile for ARM on target: export LD_PRELOAD=/usr/lib/preloadable_libiconv.so run my test to verify it fixed the issue and the g_convert() success to do the conversion of GBK to utf8. My questions are: 1. is this caused by the glibc ? because it provided the iconv API for glib. So I need update the glibc ? 2. can I rebuild the glib with the configuration --with-libiconv to fix this issue ? Best regards Weller HUANG Base SW (CM/ESW12-CN) Bosch Automotive Products (Suzhou) Co. Ltd | No. 126, Su Hong Xi Road Suzhou Industrial Park | Suzhou P.R.China | P.R.CHINA Tel. +86(512)6767-4518 | weller.hu...@cn.bosch.com Sitz: Suzhou, Registergericht: State Administration of Industry & Commerce, P.R.China Board of Directors: Yudong Chen, Patrick Leinenbach, Liming Chen ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK Queue Draw Subtle Question
Sad to say, it seems that you're in a common position of not understanding
the basic structure of a GUI program. In its simplest form, it looks like
this:
main ()
{
initialize_stuff();
while (not_time_to_quit()) {
wait_for_events_and_timeouts ();
process_events_and_timeouts ();
if (redraws_requested) {
do_redraw ();
}
}
finalize_stuff ();
}
your menu handlers execute as part of "process_events_and_timeouts ()". You
can see that if they take a long time, you are necessarily preventing the
program from reaching the "do_redraw()" stage.
you need to refactor your code so that either your menu handlers do not
take so long or you execute them in a different thread, and then use an
idle handler to queue a redraw in any relevant widgets when they are done
(queuing an idle handler is the one and only GTK-related thing you can do
from the other thread(s)).
On Wed, Feb 15, 2017 at 11:30 PM, Thomas Dineen
wrote:
> Gentle People:
>
>I have a rather large project in progress based on the GTK2/Cairo
> packages.
> Which brings me to the following question about gtk_widget_queue_draw:
> For each Menu Function, meaning a C function, which is called by a menu
> event handle,
> in response to a Menu Selection. I place a gtk_widget_queue_draw at the
> end of the function
> to cause the screen to update in response to the command. Learned behavior
> from examples
> and experience. This seems to work great.
>
> Now the question: If the menu function is complex, requiring seconds or
> minutes to execute
> the screen freezes or if windows are moved fails to update and we are left
> with a default
> grey screen. Is there any way to cause a queue draw and screen up date
> from within this
> long latency function.
>
> My experience indicates that calling gtk_widget_queue_draw from within
> this long latency
> function dose not cause a screen update.
>
> Thomas Dineen
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
