Re: textview widget selection buffer_select_range is cleared when dialog closes (intermittently?)
On 02/22/2017 12:34 AM, David C. Rankin wrote: > All, > > I have a textview widget being used in an editor where an incremental search > is performed. The matched words are highlighted with: > > gtk_text_buffer_select_range (buffer, , ); > > After the last match in the search range (either whole buffer, from cursor > [insert mark] or by selection), a gtk_message_dialog is displayed asking if > the user would like to "Continue search from beginning?". > > The search then continues from the beginning of the buffer (or selected > range). What is weird, is depending on 'how quickly' the user clicks 'Yes' > button, the selection (implemented immediately on close of the dialog if 'Yes' > is chosen) can be removed from the matched word as focus from the dialog is > returned to the textview. > > Is there some standard way to prevent the closing of a dialog from impacting > an active selection in the parent window? > > (with Gtk+ 2.24) > Opps, If you need to see the implementation, it is the 'find' function in: https://github.com/drankinatty/gtkwrite/blob/master/gtk_findreplace.c -- David C. Rankin, J.D.,P.E. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
textview widget selection buffer_select_range is cleared when dialog closes (intermittently?)
All, I have a textview widget being used in an editor where an incremental search is performed. The matched words are highlighted with: gtk_text_buffer_select_range (buffer, , ); After the last match in the search range (either whole buffer, from cursor [insert mark] or by selection), a gtk_message_dialog is displayed asking if the user would like to "Continue search from beginning?". The search then continues from the beginning of the buffer (or selected range). What is weird, is depending on 'how quickly' the user clicks 'Yes' button, the selection (implemented immediately on close of the dialog if 'Yes' is chosen) can be removed from the matched word as focus from the dialog is returned to the textview. Is there some standard way to prevent the closing of a dialog from impacting an active selection in the parent window? (with Gtk+ 2.24) -- David C. Rankin, J.D.,P.E. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK3 Glade and rendering in Windows/Linux]
Finally could style with css and Glade in Windows adnd adjust the margins
(actually using padding as the margin seems not be able to change it while
in Linux it did).
"GtkWindow" (instead of "window") is what seems needed to be used in
Windows. Apparently Windows and Linux uses different css class tags for
styling.
Some other issues I am having:
1. Not able to set the background color of a GtkButton
GtkButton
{
color: blue;
padding: 0px 0px 0px 0px;
margin: 0px 0px 0px 0px;
font: "Segoe UI";
font-size: 8px;
}
2. Not able to change the width and height of a GtkButton (only the font
color) - the default button styles a bit too large.
3. A RadioButton both styles using GtkButton and GtkRadioButton
4. Windows uses as default the "Segoe UI" font and when using this in CSS
the compiler reports:
(win-gtk-cpp.exe:12088): Pango-WARNING **: couldn't load font ""Segoe
UI" Not-Rotated 8", falling back to "Sans Not-Rotated 8", expect ugly
output.
(win-gtk-cpp.exe:12088): Pango-WARNING **: couldn't load font ""Segoe
UI" 8", falling back to "Sans 8", expect ugly output.
5. Not able to change the radio button more into the standard Windows style
(the circle). Is this possible somehow ?
P.S the original attached .glade file does not load into the windows Glade
interface Designer. Are the Linux and Windows version not compatible ?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Next release deadline: Saturday, March 25th, 2017 at 00:01 UTC
Hi folks, Based on the Gnome 3.23.x release calendar [1], I am setting the deadline for code submissions for the next release of Gtk-Perl modules to be Saturday, March 25th, 2017, at 00:01 UTC. Please have all code submissions into the Gtk-Perl maintainers before the above deadline; please allow time for the maintainers to audit and test code submissions. If you have your favorite RT ticket[2][3] or Gnome bug tracker bug[4] that you would like looked at, don't be afraid to bring it up for discussion here on the mailing list. Once the above deadline date arrives, I will begin packaging any new code in the Gtk-Perl git repos. After packaging, I will distribute tarballs to CPAN and Sourceforge, and post the release announcements, usually within a few days of the release date. If you have any questions about the above, please ask. Heads up for April, the release deadline will be April 15th, 2017, at 00:01UTC. Thanks, Brian [1] https://wiki.gnome.org/ThreePointTwentythree [2] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=XAOC [3] https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=TSCH [4] https://bugzilla.gnome.org/browse.cgi?product=gnome-perl ___ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
No Gtk-Perl releases for February 2017
Hi folks, There was no new code in the Gtk-Perl Git repos, so there will be no releases for February. I'll send out another email with the release deadlines for March in just a bit... Thanks, Brian ___ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Tooltip for GtkTextView contents
Thanks for the response. It came down to a simple logic error. In this code:
my $start_iter;
if ( $iter->starts_word ) {
$start_iter = $iter;
} else {
$iter->backward_word_start;
$start_iter = $iter;
}
$iter->forward_word_end;
... I set $start_iter to be $iter. This *doesn't* make a copy of the
iter ... so when I call $iter->backward_word_start or
$iter->forward_word_end ... both $start_iter and $iter are pointing to
the same position. The correct method of getting 2 iters ( eg for
'start' and 'end' ) is to create them independently.
Dan
On Sat, Feb 18, 2017 at 6:51 AM, wrote:
>
> Hi Dan,
>
> I am not very good with Perl but it looks like the iters aren't getting
> moved forward and backwards on the word the cursor is over. In C, the
> callback would look something like
>
> static gboolean query_tooltip(GtkWidget *textview, gint x, gint y, gboolean
> keyboard_mode, GtkTooltip *tooltip, gpointer user_data)
> {
> GtkTextIter start_iter;
> GtkTextIter end_iter;
> GtkTextBuffer *buffer=gtk_text_view_get_buffer(GTK_TEXT_VIEW(textview));
> gtk_text_view_get_iter_at_location(GTK_TEXT_VIEW(textview), _iter,
> x, y);
> if(gtk_text_iter_inside_word(_iter))
> {
> start_iter=end_iter;
> gtk_text_iter_forward_word_end(_iter);
> gtk_text_iter_backward_word_start(_iter);
> gchar *string=gtk_text_buffer_get_text(buffer, _iter,
> _iter, TRUE);
> gtk_tooltip_set_text(tooltip, string);
> g_free(string);
> return TRUE;
> }
> return FALSE;
> }
>
> Should be similar in Perl, right?
>
> Eric
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk2 provide a case 'in'-sensitive text search via 'gtk_text_iter_..._search'?
On 02/17/2017 08:26 PM, cecas...@aol.com wrote:
> David,
>
> I asked a question about this on the gtk-devel-list
>
> https://mail.gnome.org/archives/gtk-devel-list/2017-January/msg00018.html
>
> last month. A lot I didn't know about this. For UTF-8 it is a bit complicated
> even for English. For GTK's case in-sensitive search they use a casefold
> function and a normalizing function. This way you can do a case in-sensitive
> search on strings with ligatures and accents. If you are just sticking with
> asci english chars then just converting and comparing case should work. There
> is a bit more to it though for UTF-8 and unicode chars.
>
> I worked on this a little bit so that I could understand it better. My last
> attempt was
>
> https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/Csamples/search_textbuffer4.c
>
> The GTK developers are working on GTK4. GTK3.22 should be stable for 3. GTK2
> or 3 is fine with me.
>
> Eric
>
Eric,
After working with it a bit more, I encapsulated the forward and reverse
case-insensitive search functions for use without gtksourceview. They are part
of a little editor project I put together at:
https://github.com/drankinatty/gtkwrite
The functions are:
/** case insensitive forward search for implementation without
* GtkSourceView.
*/
gboolean gtk_text_iter_forward_search_nocase (GtkTextIter *iter,
const gchar *text,
GtkTextSearchFlags flags,
GtkTextIter *mstart,
GtkTextIter *mend)
{
gunichar c;
gchar *lctext = g_strdup (text); /* copy text */
gsize textlen = g_strlen (text); /* get length */
str2lower (lctext);
for (;;) { /* iterate over all chars in range */
gsize len = textlen; /* get char at iter */
c = g_unichar_tolower (gtk_text_iter_get_char (iter));
if (c == (gunichar)lctext[0]) /* compare 1st in lctext */
{
*mstart = *iter; /* set start iter to current */
for (gsize i = 0; i < len; i++)
{
c = g_unichar_tolower (gtk_text_iter_get_char (iter));
/* compare/advance -- order IS important */
if (c != (gunichar)lctext[i] ||
!gtk_text_iter_forward_char (iter))
goto next; /* start next search */
}
*mend = *iter; /* set end iter */
if (lctext) g_free (lctext);/* free lctext */
return TRUE;/* return true */
}
next:; /* if at end of selecton break */
if (!gtk_text_iter_forward_char (iter))
break;
}
if (lctext) g_free (lctext);/* free lctext */
if (mstart || mend || flags) {}
return FALSE;
}
/** case insensitive backward search for implementation without
* GtkSourceView.
*/
gboolean gtk_text_iter_backward_search_nocase (GtkTextIter *iter,
const gchar *text,
GtkTextSearchFlags flags,
GtkTextIter *mstart,
GtkTextIter *mend)
{
gunichar c;
gchar *lctext = g_strdup (text); /* copy text */
gsize textlen = g_strlen (text); /* get length */
str2lower (lctext); /* convert to lower-case */
*mend = *iter;/* initialize end iterator */
while (gtk_text_iter_backward_char (iter)) {
gsize len = textlen - 1; /* index for last in lctext */
c = g_unichar_tolower (gtk_text_iter_get_char (iter));
if (c == (gunichar)lctext[len]) /* initial comparison */
{
/* iterate over remaining chars in lctext/compare */
while (len-- && gtk_text_iter_backward_char (iter))
{
c = g_unichar_tolower (gtk_text_iter_get_char (iter));
if (c != (gunichar)lctext[len]) {
/* reset iter to right of char */
gtk_text_iter_forward_char (iter);
goto prev;
}
}
*mstart = *iter; /* set start iter before last char */
if (lctext) g_free (lctext);/* free lctext */
return TRUE;/* return success */
}
prev:;
*mend = *iter; /* set end iter after next search char */
}
if (lctext) g_free (lctext);/* free lctext */
if (mstart || mend || flags) {}
return FALSE; /* no match */
}
Implementation is using the cpp #define HAVESOURCEVIEW for compilation
purposes, e.g.
/* case sensitive forward/reverse search from iter for 'text' setting
* iters mstart & mend pointing to first & last char in matched text.
*/
if
Re: GTK3 Glade and rendering in Windows/Linux]
That works, but this only does work on Linux.
On Windows it reads the css file but the css is not applied.
http://wikistack.com/use-css-gtk/
With as css:
window
{
background-color:rgba(233,23,34,1);
}
Thanks
On Sun, 2017-02-19 at 08:25 -0800, Phil Wolff wrote:
> In the example you cite, the css file should read
>
> window {
> background-color:rgba(233,23,34,1);
> }
>
>
> On 02/19/2017 04:33 AM, Happy wrote:
> > I dont mind the windows theme to look different than the Ubuntu
> > one, if
> > it looks close or equal to native Windows, that would be great.
> > The concern is, under windows the spacing is pretty large.
> > So, I started to look at css, compiled and run this (non glade)
> > example
> > : http://wikistack.com/use-css-gtk/
> > As with my own (glade0 application, the css seems not being
> > applied,
> > My window is still grey instead of red.
> >
> >
> > On Tue, 2017-01-31 at 14:50 +0100, Tilo Villwock wrote:
> > > Well for one: The appearance on Ubuntu deviates from the default
> > > GTK
> > > theme, so I'm not really sure if the comparison makes sense.
> > >
> > > Also, did you actually verify that this is a problem, that
> > > pertains
> > > to
> > > Glade only?
> > >
> > > Either way, if it bothers you too much, you have to start
> > > tweaking
> > > the
> > > css style context.
> > >
> > > --Tilo
> > >
> > > Am Dienstag, den 31.01.2017, 20:54 +0800 schrieb Happy:
> > > > Thanks for the note. Hope the following links work. As you can
> > > > see
> > > > the
> > > > windows are much different in size as well as the spacing.
> > > >
> > > > Ubuntu:
> > > > https://drive.google.com/file/d/0BxjwKUaYdW_zYnUydWExX2NNdE0/vi
> > > > ew?u
> > > > sp
> > > > =s
> > > > haring
> > > >
> > > > Windows:
> > > > https://drive.google.com/file/d/0BxjwKUaYdW_zeFhZdFYtelViUGM/vi
> > > > ew?u
> > > > sp
> > > > =s
> > > > haring
> > > >
> > > > Glade.glade file:
> > > > https://drive.google.com/file/d/0BxjwKUaYdW_zYWY4UnZweDhRbGc/vi
> > > > ew?u
> > > > sp
> > > > =s
> > > > haring
> > > >
> > > > Thanks
> > > >
> > > >
> > > > On Tue, 2017-01-31 at 20:09 +1100, Daniel Kasak wrote:
> > > > > Neither of your messages had any attachments. Probably
> > > > > they're
> > > > > stripped out by the mailing list server. If you're trying to
> > > > > point
> > > > > people to files, screenshots, etc, try chucking them on a
> > > > > blog
> > > > > or
> > > > > pastebin or something.
> > > > >
> > > > > Dan
> > > > >
> > > > > On Sun, Jan 29, 2017 at 12:44 PM, Happy
> > > > >
> > > > > wrote:
> > > > > > Attached is a glade file. These render as seen in the
> > > > > > attachments
> > > > > > in
> > > > > > Windows and Ubuntu(16.10). In Windows(10) the window is far
> > > > > > larger
> > > > > > as
> > > > > > well as is for the spacing. It there a away to get the
> > > > > > spacing
> > > > > > and
> > > > > > size
> > > > > > down alike the rendering in Windows ? I guess this is not
> > > > > > so
> > > > > > much
> > > > > > related to glade but more towards GTK, but if this
> > > > > > assumption
> > > > > > is
> > > > > > wrong,
> > > > > > then apologies for posting.
> > > > > >
> > > > > > ___
> > > > > > gtk-app-devel-list mailing list
> > > > > > gtk-app-devel-list@gnome.org
> > > > > > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> > > >
> > > > ___
> > > > gtk-app-devel-list mailing list
> > > > gtk-app-devel-list@gnome.org
> > > > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
> > ___
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
> --
> Saying what we think gives us a wider conversational range than
> saying
> what we know.
> — Cullen Hightower
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
