Re: ANNOUNCE: Phasing out GTK mailing lists and move to Discord
On 03/18/2019 12:02 PM, Emmanuele Bassi via gtk-app-devel-list wrote: > Hi all; > > as announced in: > > https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg0.html > > we have created a Discourse instance available at: > > https://discourse.gnome.org RIP gtk-app-devel. I hope this discourse thing succeeds. Personally I find it just another awkward, cumbersome run of the mill QA site. The mailing list should be preserved. But what do I know? I've only seen about 90% of these migrations to forum like sites lose users and community involvement over the past 20 years. Here's to hoping that gtk-app-devel-list will be one of the 10%. What is the technological hold-up to doing both? Listserves are no cost simple implementations that should be able to mirror posts from discourse to the existing list and vice-versa. That would seem to be the way to go until you have some assurance that discourse will preserve community involvement instead of just doing it on hope. -- 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: Moving from mailing lists to Discourse
On 02/06/2019 05:46 AM, Emmanuele Bassi via gtk-app-devel-list wrote: > Are there any objections? Did somebody already try out Discourse and has > opinions about it that they want to share with the community? > > Ciao, > Emmanuele. Improvements are always welcome, but I've seen a number of moves away from the traditional mailing list, or fragmentation of a list into sub-topics fail miserably. (it fragments the community as well) I'm not sure I see the logic on how a mailing list change could make GTK more friendly to newcomers. You have a good thing going here that has stood the test of time. I would at least maintain the mailing list as is until you have some confirmation that any change actually accomplishes its stated goals. I for one see no benefit in discourse. -- 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
Is it possible to change buffer in TextView (SourceView) when providing Word-Completion?
All, I have been wrestling with this issue for a month (not continually, but as time and curiosity permit). I have posted before with the specifics of the problem (see thread: "Howto register/unregister words completion provider on buffer change in textview?") I have boiled it down to a simple question: "Is it possible to change the buffer shown in a TextView (using gtksourceview) and have word-completion continue to work within that TextView?" The reason I ask is that it appears the completion is indelibly bound to the original buffer in the textview when word-completion is first activated. There does not seem to be a way to: gtk_source_completion_remove_provider /* removing and unreffing all */ and then after gtk_text_view_set_buffer (view, newbuf); gtk_source_completion_add_provider and have word-completion function. Similarly, there seems to be no way to retain the same completion provider (so remove/add is unnecessary) and simply: gtk_source_completion_words_unregister (prov_words, oldbuf); and then to update the words in the provider: gtk_source_completion_words_register (prov_words, newbuf); In all cases, the exact same behavior is observed. When the buffer is changed and all GtkSourceCompletionWords providers removed and a new provider created, words registered and added with the new buffer in the textview, word completion is non functional, no popup, no nothing. However if I go through the same process again and change the buffer shown in the textview from newbuf to original, remove all providers, creating a new provider, registering words (in the exact same order), then Walah! completion is magically working again. I've looked at the source code for GtkSourceView and unfortunately, most of it is bewildering, but it does appear there is a binding between the original buffer and the GtkSourceCompletion for the textview and the original buffer in the textview when completion is first activated. Is this right?? And, if it is, doesn't that effectively prevent changing buffers in a sourceview and having completion continue to function? And if that is the case, is this a bug or a feature? The code is currently written using GtkSourceView 2.11.2, but 3.23.2 and 4.0.2 seem identical in this regard. If nobody knows, is there a GtkSourceView specific list I can follow up on? It just doesn't seem right that I would need to destroy the entire textview window just to keep completion working with a new buffer. Any help greatly appreciated. -- 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: GTK+ 2.0/3.0 Windows runtimes
On 10/23/2018 02:16 AM, John Mills wrote: > I have been developing a C-language GTK+ 2.0 application for MS Windows 10 > using mingw > cross-compilation on Linux, and deploying it by installing the Windows GTK+ > 2.0 runtime > bundle on the Windows machine. > http://ftp.gnome.org/pub/gnome/binaries/win32/ > Those are fine. > The procedure was: on Linux development machine, unzip the gtk Windows bundle > in a directory > with the C source, set up a Makefile with the appropriate CFLAGS and LDFLAGS, > 'make mingw' > and deploy the EXE. This procedure suited my development style. > That is the 'start'. There are always additional pieces you may need to install like any additional needed build dependencies like, e.g. gtksourcview, libxml, etc.. When I set this up, I simply create a base /opt directory at c:\opt and then install the various packages for gtk2 under c:\opt\gtk2. You then simply add the the directory containing your the libraries to your PATH. > Do I now need to port to GTK+ 3? No, not unless you simply want to. It depends on the size of the source and how much time you want to devote to it. I still build gtk+2 with the binaries you are using on Win10 without issue. > Is MSYS2 now the best/only way to deploy the dependencies to Windows? No, not needed. Simply install the dependencies wherever you like (as my c:\opt\gtk2) and then add the path to the libraries (e.g. c:\opt\gtk2\bin) to your User (not system) PATH variable. You will also need the path to the mingw\bin directory in your path as well. Then I just open the good ole windows command prompt (cmd.exe) and build. Remember if you are using mingw-TDM, the binaries are named, e.g. mingw32-make (for make), etc... I have additional mingw/gtk2/windows build information at https://github.com/drankinatty/gtkwrite > Using the binaries available through MSYS2/pacman, can I still develop on > Linux and deploy > mingw executables to Windows? You should be able to, but I have not set up the cross-compile chain on Linux to test. I just used the windows gtk2 binaries and it works fine for my purposes. > Can anyone point me to a guide for doing that? Somebody else will have to fill this in... Good luck. -- 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: Howto register/unregister words completion provider on buffer change in textview?
On 09/16/2018 03:53 AM, David C. Rankin wrote:
> On 09/16/2018 03:21 AM, David C. Rankin wrote:
>> Each treemodel entry has a struct containing a pointer to its
>> GtkSourceCompletionWords provider.
>
> Uugh...
>
> That should read the editor instance struct associated with the sourceview has
> a pointer to its GtkSourceCompletionWords provider. (the tree model just holds
> a struct containing a pointer to its GtkSourceBuffer which is what allows
> updating the textview/sourceview window on the right with the new buffer).
>
> So when I click a different file in the treeview, I want to associate that
> buffer as the word-source for the GtkSourceCompletionWords provider for the
> textview by unregistering the existing buffer as the word-source and
> registering the new buffer as the source for the provider in the textview.
>
Let me bump this thread again and update with the next approach I have taken
that also failed. By way of short background, I have an editor where multiple
files are opened and displayed in a Treeview on the left of the main window.
Selecting a file will display its buffer in the textview, e.g.
+===+
|menu |
++--+
| file_a | |
| file_b | |
| file_c | TextView |
|| with |
|| WordCompletion |
|| |
|| |
|| |
|| |
++--+
I enable word completion within the textview on the first file when the window
is created. What I need to do is be able to make the word completion continue
to work with the new word-provider associated with each file when a new file
is displayed in the textview.
As noted in the earlier post, the completion object is associated with the
Textview itself, but the words provider is associated with each file. Earlier
I attempted to use the same provider, by 'registering' and 'unregistering' the
words contained within a single provider.
In this test, I have created a new words completion provider associated with
each file instance and have attempted to remove the current provider and add
the provider associated with the new buffer to be displayed with the following:
GList *providers = gtk_source_completion_get_providers (completion);
while (providers) {
/* TODO add validation and GError */
gtk_source_completion_remove_provider (completion,
GTK_SOURCE_COMPLETION_PROVIDER (providers->data), NULL);
providers = providers->next;
}
/* register the words in the current buffer for provider */
if (!inst->prov_words) {
/* create the words provider */
inst->prov_words = gtk_source_completion_words_new (NULL, NULL);
gtk_source_completion_words_register (inst->prov_words,
gtk_text_view_get_buffer (GTK_TEXT_VIEW (view)));
}
/* add provider to completion - make sure to unref when done */
gtk_source_completion_add_provider (completion,
GTK_SOURCE_COMPLETION_PROVIDER (inst->prov_words), NULL);
However, the results are the same. Word completion works fine for the first
buffer associated with the textview (say 'file_a' above). Switching buffers
(say to 'file_b'), there is no word-completion triggered at all within the
same textview for the new buffer. However, switching back to the first buffer
(file_a) and word completion begins working fine again.
Anybody have any other ideas how to make word completion continue to work
within a textview when the buffer displayed is changed?
Thanks for any thoughts or ideas you may have.
--
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
That reminds me -- is there a signal that can be used when mouse over mainwin titlebar?
All, Thanks to the other "is there a signal?" question, that reminded me I have been looking for a signal (or way) to detect when the user has the mouse over the titlebar of the main window in an editor where I would like to activate a tooltip showing the absolute path for the file in the currently focused textview. I just cannot find a signal or event window scheme to do it -- probably because the main window titlebar is owned by the window manager and not the application. But still, I see other editors that are capable of this. Is there any such signal, or something that can be used in conjunction with the set_window_title call that would also provide a tooltip on mouseover I could respond to? -- 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: How to get GtkNotebook tab padding?
On 09/12/2018 01:58 PM, Game On via gtk-app-devel-list wrote:
> Hi,What's the correct way to get the tab padding of a GtkNotebook widget?
> It's easy enough to set them, but I'm not sure how to get those values back?
> My custom gtk.css file with:notebook tab { padding: 20px 20px 20px 20px;
> }
> I've tried many incantations, including this without success:// Assume I have
> GtkWidgetPath path and GtkStyleContext
> contextgtk_widget_path_append_type(path, GTK_TYPE_NOTEBOOK);
> gtk_style_context_set_path(context,
> path);gtk_style_context_add_class(context, "tab");
>
> GtkBorder padding;gtk_style_context_get_padding(context,
> GTK_STATE_FLAG_NORMAL, );
>
> Thanks for your help.
I'm not sure with Gtk+3, but prior to that you would use
g_object_get (GTK_NOTEBOOK (notebook), property1, , property2, ,
NULL);
See the manual (and it does apply in Gtk+3)
https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#g-object-get
--
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: Howto register/unregister words completion provider on buffer change in textview?
On 09/16/2018 03:21 AM, David C. Rankin wrote: > Each treemodel entry has a struct containing a pointer to its > GtkSourceCompletionWords provider. Uugh... That should read the editor instance struct associated with the sourceview has a pointer to its GtkSourceCompletionWords provider. (the tree model just holds a struct containing a pointer to its GtkSourceBuffer which is what allows updating the textview/sourceview window on the right with the new buffer). So when I click a different file in the treeview, I want to associate that buffer as the word-source for the GtkSourceCompletionWords provider for the textview by unregistering the existing buffer as the word-source and registering the new buffer as the source for the provider in the textview. -- 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
Howto register/unregister words completion provider on buffer change in textview?
All, I have an editor that holds the open files on the left in a treeview/treemodel and displays the buffer containing each file in a textview (sourceview) window on the right. Each treemodel entry has a struct containing a pointer to its GtkSourceCompletionWords provider. The word-completion works fine for the first buffer shown in the window, but when I change files and display a different buffer in the textview window, I am not able to register/unregister the current buffer from the words provider and use the new buffer as a source? Essentially I create the initial completion object as: GtkSourceCompletion *completion; GtkSourceCompletionWords *prov_words; completion = gtk_source_view_get_completion (view); prov_words = gtk_source_completion_words_new (NULL, NULL); gtk_source_completion_words_register (prov_words, gtk_text_view_get_buffer (GTK_TEXT_VIEW (view))); gtk_source_completion_add_provider (completion, GTK_SOURCE_COMPLETION_PROVIDER (prov_words), NULL); /* store a pointer to the completions words provider as part of * the editor instance. */ einst->prov_words = prov_words; When displaying a new buffer in the textview, I use the treeview "changed" signal to display the new buffer, update the window title, etc.. and I tried to unregister the current buffer from the prov_words provider and then register the new buffer as the word source with: GtkSourceCompletionWords *prov_words = einst->prov_words; /* unregister current buffer from words completion provider */ gtk_source_completion_words_unregister (prov_words, GTK_TEXT_BUFFER(oldbuf)); /* register new buffer with words completion provider */ gtk_source_completion_words_register (prov_words, GTK_TEXT_BUFFER(newbuf)); However, I am obviously missing something as the new buffer displayed does not provide any completion functionality at all. Since the completion object (GtkSourceCompletion) is part of the sourceview (GtkSourceView) and the completion provider (GtkSourceCompletionWords) is part of the completion object, there should be no need to create another object or provider as the sourceview window is the same. The only thing that I see that needs doing is to change the buffer registered as the source of words for the provider on buffer change -- but so far I have not met with any success... Is there something I am missing when changing the buffer in the sourceview that is needed to change the completion so that word completion continues to function but simply drawing words from the new buffer instead of the old? When I switch focus back to the original buffer -- completion works fine again, it's something in the switch to the new that I must be missing. Help? -- 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: Appending to treestore - how to set selection on new entry?
On 08/28/2018 04:24 PM, infirit wrote: > Next is to get the selection from your view with > gtk_tree_view_get_selection and call gtk_tree_selection_select_iter with > the toplevel iter from earlier. It should now have selected the newly > added row. > > ~infirit Yes, thank you, that is what I did. The problem I had to solve was the reverse of the appending case. There where toplevel is used, I am simply adding an entry to the tree model. The case I had to solve was when the model was completely filled and I had multiple views which could be associated with any one instance contained in the model. The challenge was to take the focus on any of the views and then go figure out which entry in the tree model the focused textview buffer came from. For example, here is the editor interface shown with the treeview and 3 editor windows: http://paste.opensuse.org/25076757 The task was to be able to click to place focus in any one of the edit (textview) windows and have the selection automatically move to the associated file. That's where using the "focus-in-event" signal from the textview allowed getting the associated buffer which I could then iterate through the treemodel and match with the buffer held in the model using the iterator to set the selection. -- 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: Appending to treestore - how to set selection on new entry?
On 08/27/2018 01:24 AM, David C. Rankin wrote:
> "How do I use the pointer stored in column 2 of the model to set the
> selection on that treeview entry?"
>
> (the full source of the interface is https://github.com/drankinatty/gtkate
> which is just a concept at the moment, the project will provide the
> functionality of https://github.com/drankinatty/gtkwrite within a
> multi-document/multi-view interface when done)
>
> I have not worked with tree models/stores a great deal and I am a bit
> bewildered by how to get an iter or treepath given the value of column 2 to
> then set the selection on that row/entry in the treeview. I guess I could do a
> for_each and loop over the pointers, but I'm unsure if that is the correct way
> or one of my logical hacks that would be better implemented some other way.
>
Well,
I'm not sure this was the best way to go about it, but from the callback
from the "focus-in-event" signal from the textview, I call the following which
uses the pointer to the textview buffer to compare for equality against the
pointer held in each treemodel instance pointer. This gives me the GtkTreeIter
that I can then use with gtk_tree_selection_select_iter(), e.g.
/** given inst use tree iter to set focus on current view
* (widget is textview associated with window clicked inside)
*/
void tree_get_inst_iter (GtkWidget *widget, gpointer data)
{
mainwin_t *app = data;
GtkTreeModel *model = NULL;
GtkTreeSelection *selection;
GtkTreeIter iter;
gpointer buf = gtk_text_view_get_buffer (GTK_TEXT_VIEW(widget));
gboolean valid, found = FALSE;
/* initialize selection to current */
selection = gtk_tree_view_get_selection (GTK_TREE_VIEW(app->treeview));
/* get treemodel, validate */
model = gtk_tree_view_get_model(GTK_TREE_VIEW(app->treeview));
if (!model) {
g_print ("error: tree_view_get_model - failed.\n");
return;
}
/* get first iter, return in validate */
valid = gtk_tree_model_get_iter_first (model, );
while (valid) { /* loop over each entry in model */
gchar *str = NULL;
kinst_t *inst = NULL;
/* TODO - remove COLNAME & str after debugging done */
gtk_tree_model_get (model, , /* get name & inst */
COLNAME, , COLINST, , -1);
/* compare pointer to sourceview with buf from textview (widget) */
if ((gpointer)(inst->buf) == buf) {
gtk_tree_selection_select_iter (selection, );
g_free (str);
found = TRUE;
break;
}
g_free (str);
valid = gtk_tree_model_iter_next (model, );
}
if (!found)
g_warning ("tree_get_inst_iter inst not found.");
if (widget) {}
}
--
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
Appending to treestore - how to set selection on new entry?
All, I have been playing with an editor interface that has a treeview in the left of an hpaned widget, and then instances of scrolled windows with textview objects packed into a vbox in the right pane (to provide one or more splits views of files to edit). When I add a new file (entry) to the treestore/treemodel, how do I adjust the selection so that the new entry is selected? (or how do I get a treepath or iter from the new entry to allow me to set the selection?) The treestore holds the name of the entry in the 1st col and then a pointer to a struct containing details for that textbuffer (e.g. line, col, full path, filemode, uid/gid, textview and sourceview lang_id along with comment syntax, etc..) There are two instances when I need to set the treeview selection on a specific entry: (1) when I append the entry to the tree, e.g. GtkTreeStore *treestore; GtkTreeIter toplevel; ... treestore = GTK_TREE_STORE(gtk_tree_view_get_model ( GTK_TREE_VIEW(app->treeview))); /* (validate omitted) */ /* appeand name and pointer to inst as entry in treeview */ gtk_tree_store_append (treestore, , NULL); gtk_tree_store_set (treestore, , COLNAME, name, -1); gtk_tree_store_set (treestore, , COLINST, inst, -1); (here I know the 'inst' which is the pointer stored in column 2) (2) when the user clicks in one of the edit textviews (there can be multiple split views) in right of the hpaned object. Currently I track which textview is focused using the "focus-in-event" signal from the textview object to loop over the array of editor instances to determine which textview widget is focused (which also provides me with the 'inst' which is column 2 in the treestore/model) So in both cases I have the value of the pointer that is stored in column 2 of the tree model. "How do I use the pointer stored in column 2 of the model to set the selection on that treeview entry?" (the full source of the interface is https://github.com/drankinatty/gtkate which is just a concept at the moment, the project will provide the functionality of https://github.com/drankinatty/gtkwrite within a multi-document/multi-view interface when done) I have not worked with tree models/stores a great deal and I am a bit bewildered by how to get an iter or treepath given the value of column 2 to then set the selection on that row/entry in the treeview. I guess I could do a for_each and loop over the pointers, but I'm unsure if that is the correct way or one of my logical hacks that would be better implemented some other way. Any help greatly appreciated. -- 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: Copywrite protection and source-code distribution
On 07/31/2018 08:41 AM, Roger Matthews via gtk-app-devel-list wrote: > I have developed an application using GTK+3.10. What copy-write protection > can you (GTK+) provide for me. I have been told that copywrite is free and > automatic and that to protect the software from piracy I need sufficient > money to prove prior usage in a court of law. I don't see how the > requirement of including my source code in the package will allow for > successful commercialisation when someone can just simply copy the > source-code. I have no problems about acknowledging GTK+ for providing the > GUI development platform and for helping with problems in coding, etcetera. > Without adequate protection this requirement (including the source-code) > renders GTK+ useless as far as any kind of commercialisation is concerned, > please enlighten me on this matter. > > Roger Matthews > GTK+ is licensed under the GNU LGPL 2.1 allowing development of both free and proprietary software with GTK+ without any license fees or royalties. ... To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. ... By using Gtk+ in your project, you have agreed to both these rights and responsibilities. However, the protections against piracy depends largely on how your code is factored and the uses it can be put to. While you have an obligation to provide the Gtk+source and any modification and use you have made of it, but that doesn't necessarily extend to all your source code. If you have a "proprietary" part of your code, that does not include or rely on Gtk+ or any extension and modification from it, you may well be free to copyright the non-open portion any way you like. (I have seen decisions that carve out parts of projects that can be protected. Remember how long and how much money the SCO suit cost? Litigation is something to avoid. It you want to impose a stricter license on some part of your code, make sure you can prove that code doesn't rely on Gtk and isn't an extension or modification from it. Then nothing prevents you from licensing that part as you see fit. But if you can't make a clear delineation between where the open-source code stop and where yours begins, it may not be worth the hassle. Depending on what the code is, and your competitors in the market, that may just provide a bullseye they were looking for. -- 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: Can you specify the No. of chars before SourceView Completion window is displayed?
On 07/28/2018 03:35 AM, David C. Rankin wrote: > All, > > I have implemented word completion with GtkSourceView, but I cannot find a > simple way to prevent the provider and proposals from popping up until 3 (or > more) characters are typed? Is there an easier way to adjust this rather than > counting chars with an iter from every begins_word and blocking the display of > the completion window until the desired number of characters have been typed? > Found it. In the SourceView version I'm using in the (*Undocumented* in 2.11) completion-providers/words subdirectory of the source, gtksourcecompletionwordsbuffer.h exposes: void gtk_source_completion_words_buffer_set_minimum_word_size ( GtkSourceCompletionWordsBuffer *buffer, guint size); that can be used to set the "minimum-word-size" property. You can also set the property directly with g_object_set called on the GtkSourceCompletionWords provider. The default value is 2. Setting to 3 does just what I wanted. -- 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: Can you specify the No. of chars before SourceView Completion window is displayed?
On 07/28/2018 08:12 AM, John Coppens wrote: > David, is 'set_minimum_key_length' what you are looking for? Oh, no, no, no, not entry-completion, *word-completion* in a text editor window. (which explains why it was no where to be found in the gtkSourceView code :) -- 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: How to scroll to a specific line
On 07/28/2018 08:29 AM, John Coppens wrote: > On Sat, 28 Jul 2018 07:42:16 -0400 > Reuben Rissler wrote: > >>> Thanks for the suggestion. Believe it or not, I had just arrived at >>> that same solution! I first tried to use GLib.timeout_add(), and >>> that worked too, if the time was larger than 300 - 400 ms, which is >>> on the verge of annoying. I then tried idle_add(), and I guess that >>> makes the 300-400ms 'built-in'. >>> >> How many lines of text do you have? With 500 - 700 lines of text, my >> scrolling is instantaneous. The scroll feature itself has a 'soft' >> stop, but that is quite acceptable for me, as it is easier to adjust >> my eyes to the change. > > Reuben, > > The code I'm using to test is short (about 250 lines). I'm using the system > to single step program execution, so I will do many steps. The problem at > the moment is when loading the program, and scrolling to the start of > the program (the 'reset' position), but I see that the slowing down delay > is quite visible even when scrolling just one line with the arrow keys. > > I have some Gtk-2 programs where the delay is not apparent. Maybe this > is configurable? > > John > > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > John, Maybe we can trade help. There are actually two functions you can use to scroll the window to insure a text mark (usually the 'insert' mark) is visible within your view, e.g. (the following is from a find/replace widget I made) https://github.com/drankinatty/gtkwrite/blob/master/gtk_findreplace.c#L920 /* scroll window to mark to insure match is visible */ #ifndef TOMARK gtk_text_view_scroll_to_mark (GTK_TEXT_VIEW (app->view), app->last_pos, 0.0, TRUE, 0.95, 0.8); #else gtk_text_view_scroll_mark_onscreen (GTK_TEXT_VIEW (app->view), app->last_pos); #endif The gtk_text_view_scroll_to_mark give you finer control over how far from the bottom/top of your view the mark is displayed, the gtk_text_view_scroll_mark_onscreen just makes sure it is visible (but generally does a fine job) I left a #define in the code when I wrote it so I could compare the behavior of each. I use the gtk_text_view_scroll_to_mark by default. Both give instantaneous performance, even in a longer file (for me that is 2000 - 5000 lines) Also note it is called from 'btnreplace_activate' https://github.com/drankinatty/gtkwrite/blob/master/gtk_findreplace.c#L1001 and the scroll is wrapped within begin/end user action to prevent any selection bound changes being momentarily visible during the find/replace operation: gtk_text_buffer_begin_user_action (buffer); (code for gtk_text_view_scroll_to_mark gtk_text_buffer_end_user_action (buffer); You shouldn't notice any delay when implementing the scroll in any reasonable size file. -- 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: Can you specify the No. of chars before SourceView Completion window is displayed?
On 07/28/2018 08:12 AM, John Coppens wrote: > On Sat, 28 Jul 2018 03:35:02 -0500 > "David C. Rankin" wrote: > >> All, >> >> I have implemented word completion with GtkSourceView, but I cannot >> find a simple way to prevent the provider and proposals from popping >> up until 3 (or more) characters are typed? Is there an easier way to >> adjust this rather than counting chars with an iter from every >> begins_word and blocking the display of the completion window until >> the desired number of characters have been typed? >> > > David, is 'set_minimum_key_length' what you are looking for? > > John John, That sounds *exactly* like what I am looking for, but I can't find it. Currently the completion is triggered after 2-characters are type. That is way way too over-inclusive and results in the GList of proposals being way larger than need be. I've been through every property and grepped the source with $ grep -r 'set_minimum_key_length' gtksourceview/* and I can't find any reference to it that would provide an interface to it. Is this new in gtksourceview4? I have grepped the source for versions 2.11 and 3.23 and nothing turns up. Also, (as a bonus question :) how do I hide the priority column in the completion window and nuke the titlebar and statusbar with the "Details/All" links? see: screen shot of completion window: http://paste.opensuse.org/94232695 (link good for 6 days) For example, I don't want to display the 1, 2, 3, 4, 5, etc.., priority column, I just want the words displayed in a small tight window. I don't want to have the titlebar or the footer with the links to the extra "info" for this provider (there never will be any, they are just words from the document). What I'm trying to achieve is a normal completion window, e.g. http://paste.opensuse.org/48387224 Is there any way to achieve something like that other than capturing the "show" signal (which would already have displayed the window) and attempting to hide the titlebar and statusbar of the completion popup? The "CompletionInfo" window has a "before-show" signal, but there is nothing similar for the actual completion window? -- 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
Can you specify the No. of chars before SourceView Completion window is displayed?
All, I have implemented word completion with GtkSourceView, but I cannot find a simple way to prevent the provider and proposals from popping up until 3 (or more) characters are typed? Is there an easier way to adjust this rather than counting chars with an iter from every begins_word and blocking the display of the completion window until the desired number of characters have been typed? -- 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: Does 'left-gravity' for text_mark work in windows to preserve selection bounds? (gtk2)
On 07/17/2018 11:12 PM, David C. Rankin wrote: > Is this a problem with gtk select_range under windows, or just the result of > windows selection being something gtk cannot interface with given the > different windows API? Uugh! Disregard. It does work and will affect the selection bounds in windoze. After another complete rebuild, the selection is extended to include the opening comment tag. My only guess on the earlier failure is an earlier version of the editor was running and after the prior rebuild invoking the editor name at the command line apparently started a second instance of the running/cached version instead of re-reading the new executable. Regardless, it isn't a gtk issue. -- 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
Does 'left-gravity' for text_mark work in windows to preserve selection bounds? (gtk2)
All,
I was implementing block comments in a Text/Sourceview Buffer in a function
that is passed start and end iters representing the selection bounds, e.g.
void buffer_comment_lines (kwinst *app,
GtkTextIter *start,
GtkTextIter *end)
{
(full code at)
https://github.com/drankinatty/gtkwrite/blob/master/gtk_filebuf.c#L518
Within the function I create a start_mark and end_mark to revalidate the
text iterator throughout the function and before control is returned to the
caller. The start_mark is created with LEFT-gravity so when the comment syntax
is inserted at the beginning of the selection, the mark remains to the left of
the inserted text expanding the selection bounds to contain the newly inserted
opening comment string, e.g.
/* preserve marks for start/end to revalidate iterators before return
* using left gravity on start to mark stays left of inserted text.
*/
start_mark = gtk_text_buffer_create_mark (buffer, NULL, start, TRUE);
end_mark = gtk_text_buffer_create_mark (buffer, NULL, end, FALSE);
Prior to the end of the function, the start/end iterators are revalidated
and the selection is remade between the start/end iterators to insure when the
function returns the selection encompasses the block comment syntax as well as
the commented text so if the user chooses, has a change of mind, whatever,
they can 'uncomment' without having to touch the keyboard or mouse to adjust
the selection, e.g.
/* revalidate iters */
gtk_text_buffer_get_iter_at_mark (buffer, start, start_mark);
gtk_text_buffer_get_iter_at_mark (buffer, end, end_mark);
/* extend selection to cover new comment syntax (for uncomment) */
gtk_text_buffer_select_range (buffer, end, start);
This works perfectly when compiled and run under Linux, but fails to include
the opening syntax for the block comment when compiled/run under windoze.
Instead the `start` iter behaves as if it has RIGHT-gravity and is outside of
the selection when the function ends.
I have even manually set the iter to the beginning of the line with:
gtk_text_iter_set_line_offset (start, 0);
But still the selection is not adjusted in windows as all.
Is this a problem with gtk select_range under windows, or just the result of
windows selection being something gtk cannot interface with given the
different windows API?
--
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: GtkInfoBar - How do you set "button-spacing" style property.
On 08/29/2017 11:48 PM, David C. Rankin wrote: > How do you package this snippet of any rcfile and have it read by your > application -- in addition to the default theme in use? (Gtk+2)? > Got it -- gtk_rc_parse (filename); -- 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: GtkInfoBar - How do you set "button-spacing" style property.
On 08/27/2017 04:53 AM, David C. Rankin wrote:
>
> The problem is the 6px spacing is way to big and the info bar takes up too
> much space. I want to set the "button-spacing" style property to 2 (or 1) to
> cut down the vertical height.
>
> How do I set the "button-spacing" style property?
>
> (it's these little, seemingly simple things, that are the most frustrating)
>
>
Well,
I can't find an easy way to do it. I stumbled around and created an rcfile
entry that will do it. Here is what I cam up with:
style "infobar-button-spacing"
{
GtkInfoBar::button-spacing = 2
}
widget_class "*.GtkInfoBar" style "infobar-button-spacing"
Is there a better way to do it? Is there a better way to limit application
and search time to only apply to infobars?
How do you package this snippet of any rcfile and have it read by your
application -- in addition to the default theme in use? (Gtk+2)?
--
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
GtkInfoBar - How do you set "button-spacing" style property.
All,
I've pulled my hair out trying to find any easy way to set the GtkInfoBar
"button-spacing" style properly. This seems like something that should be so
simply, but it looks damn near impossible. I've been though the gtk_reference
manual, the gobject_reference manual and the best I can do is get the
property, e.g.
GtkWidget *infobar; /* the infobar widget */
infobar = gtk_info_bar_new (); /* create new infobar */
gint spacing;
...
gtk_widget_style_get (infobar, "button-spacing", , NULL);
g_print ("spacing: %d\n", spacing);
Which then confirms that the default "button-spacing" is 6, but how the heck
do I set it?
I have an infobar to handle File->Quit from an editor which checks
gtk_text_buffer_get_modified and then provides 3 buttons in the action_area:
"Do you want to save the changes you have made?"
"_Yes"- save if filename or call file-save-as dialog
"_No" - tidy up and gtk_main_quit ();
"_Cancel" - close infobar and go back to editor
The problem is the 6px spacing is way to big and the info bar takes up too
much space. I want to set the "button-spacing" style property to 2 (or 1) to
cut down the vertical height.
How do I set the "button-spacing" style property?
(it's these little, seemingly simple things, that are the most frustrating)
--
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
Bug in Gtk+2 gtk_text_buffer_insert() of a '\n' following an existing '\r'?
/* if end-of-line begins with LF */
...
}
else if (c == '\r') { /* if end-of-line begins with CR */
if (app->eol == LF) { /* handle change to LF */
...
}
else if (app->eol == CRLF) {/* handle change to CRLF */
gtk_text_iter_forward_char ();
if (gtk_text_iter_get_char () != '\n') { /* if not '\n' */
/* just insert '\n' */
/* CODE THAT PRODUCES THE BUG */
gtk_text_buffer_insert (buffer, , app->eolstr[LF], -1);
}
...
}
gtk_text_buffer_get_iter_at_mark (buffer, , app->last_pos);
}
...
}
The resulting file is:
$ hexdump -C eol_messcr.txt
6d 79 0d 0d 0a 64 6f 67 0d 0d 0a 20 20 68 61 73 |my...dog... has|
0010 0d 0d 0a 20 20 66 6c 65 61 73 0d 0d 0a 61 20 6c |... fleas...a l|
0020 6f 74 0d 0d 0a 20 20 20 20 6f 66 20 66 6c 65 61 |ot...of flea|
0030 73 0d 0d 0a |s...|
0034
That's just wrong. A '\r\n' is inserted following the existing '\r' instead
of '\n' alone. (it looks like gtk_text_buffer_insert() anticipates that a CRLF
should be created out of the '\r' and the inserted '\n', but leaves the
original '\r' unchanged and, in fact, inserts a CRLF of its own -- bizarre).
Here is the same function with the backspace over '\r' and insert of '\r\n'
that works as intended:
else if (app->eol == CRLF) {/* handle change to CRLF */
gtk_text_iter_forward_char ();
if (gtk_text_iter_get_char () != '\n') { /* if not '\n' */
/* then backspace, reinit iter, and insert '\r\n' */
if (gtk_text_buffer_backspace (buffer, , FALSE, TRUE))
{
gtk_text_buffer_get_iter_at_mark (buffer, ,
app->last_pos);
gtk_text_buffer_insert (buffer, ,
app->eolstr[CRLF], -1);
}
'\r' is removed and replaced by '\r\n' and the resulting file produced is:
$ hexdump -C eol_messcr2.txt
6d 79 0d 0a 64 6f 67 0d 0a 20 20 68 61 73 0d 0a |my..dog.. has..|
0010 20 20 66 6c 65 61 73 0d 0a 61 20 6c 6f 74 0d 0a | fleas..a lot..|
0020 20 20 20 20 6f 66 20 66 6c 65 61 73 0d 0a|of fleas..|
002e
Why does the following fail?
if (gtk_text_iter_get_char () != '\n') {
gtk_text_buffer_insert (buffer, , app->eolstr[LF], -1);
}
When the following works?
if (gtk_text_iter_get_char () != '\n') {
if (gtk_text_buffer_backspace (buffer, , FALSE, TRUE)) {
gtk_text_buffer_get_iter_at_mark (buffer, , app->last_pos);
gtk_text_buffer_insert (buffer, , app->eolstr[CRLF], -1);
}
Either I'm crazy and have botched something (which is always possible, but
unlikely here), or there is a bug in Gtk+2 (latest) gtk_text_buffer_insert()
that is triggered by attempting to insert a one-character string "\n" after an
exising '\r' in the buffer. Maybe gtk_text_iter_forward_to_line_end ()
correctly moves to the end and gtk_text_iter_forward_char (); correctly
moves to the next position follwing '\r', but gtk_text_buffer_insert (buffer,
, "\n", -1); fails to insert a '\n' following the exising '\r' and
instead inserts '\r\n' -- which is just wrong.
Is this a bug? If so, I'll report it. If not, then I'm sure there is a
deeper explaination for why the obvious won't work.
--
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: Gtk+2 Clipboard - handling EOL better on paste or copy/cut?
On 07/31/2017 02:05 AM, David C. Rankin wrote: > Does this approach sound reasonable, or like one I'll spend 1/2 day coming > to regret? It was... something to regret (but was solved without regret...) I decided to write the conversion routine first -- it answered the question. You don't care what format the cut/copy/paste end-of-line is. You simply handle the conversion on file-save, or run though the range of lines after paste providing the conversion 'in-buffer' on a per-paste basis. Much simpler. (Win32 builds need the conversion on a per-paste basis due to the way 'indention' is handled, on Linux/Unix you can just do a one-time conversion on save) -- 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
Gtk+2 Clipboard - handling EOL better on paste or copy/cut?
All,
I have a simple editor project I've been tinkering with
(https://github.com/drankinatty/gtkwrite) and I've implemented EOL handling
for LF, CRLF, and CR to accommodate Linux/Unix/OSX, DOS/Win, and Mac
(pre-OSX). I've run into a question on implementing the EOL in text pasted
from the clipboard.
By default, all cut/copy/paste operations use LF. If I understand the
clipboard documentation, I should be able to use:
gtk_clipboard_request_text
with the:
(*GtkClipboardTextReceivedFunc) callback
so that when a request to paste text is made, I can call
gtk_clipboard_request_text, pass the callback (which will scan the text in the
clipboard, (and if necessary allocate a larger buffer to handle inserting CR
before LF to make CRLF), pass the EOL flag to determine which to change to as
the 'gpointer *data', and finally returning a pointer to the reformatted
clipboard text through the 'text' parameter to the callback (or NULL if
something fails).
My question is -- does this sound sane? To handle the EOL fix only for text
*pasted* into the textview buffer, or is it better to handle the EOL fix
during copy/paste so the text in the clipboard is formatted for the host OS?
(my thought was to just do it on paste)
Basically, I have a variable that holds (0,1,2) that serves as a flag for
EOL type (based on an 'enum eolorder { LF, CRLF, CR };') that I can pass as
the pointer to the callback to allow the EOL adjustments to be made.
Does this approach sound reasonable, or like one I'll spend 1/2 day coming
to regret?
--
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: Gtk+2 Textview, (editor) compiled on Windows and 'i' interpreted as 'ctrl+i' (indent)?
On 06/21/2017 05:52 AM, David C. Rankin wrote: > Now all I have to do is figure out how to fix > gtk_source_language_manager_set_search_path () on windows so it can find my > sourceview language files in > "C:\opt\gtk2\share\gtksourceview-2.0\language-specs" The search paths problem was the result of an earlier glib version in the windows binaries requiring inclusion of glib-object.h and calling g_type_init(). Resolved by adding a preprocessor check and guard around the init, e.g. #ifndef GLIB236 #include #endif ... #ifndef GLIB236 g_type_init(); #endif Are the windows binaries updated on any type of basis? I guess it's just up to whoever at gnome.org takes an interest. It would be nice to have current gtk+-2.0, 3.0 and glib versions (actually for all versions of binaries at https://download.gnome.org/binaries/win32) Thanks again for your help. -- 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: Gtk+2 Textview, (editor) compiled on Windows and 'i' interpreted as 'ctrl+i' (indent)?
On 06/21/2017 04:11 AM, David C. Rankin wrote: Well, I have identified the problem, and have a work-around, even if I haven't solved it. Here is the code I originally posted which provides 'ctrl+i' for indent and 'shift+ctrl+i' for unindent: > ... > gtk_widget_add_accelerator (indentMi, "activate", mainaccel, > GDK_KEY_i, GDK_CONTROL_MASK, > GTK_ACCEL_VISIBLE); > gtk_widget_add_accelerator (unindentMi, "activate", mainaccel, > GDK_KEY_i, GDK_CONTROL_MASK | GDK_SHIFT_MASK, > GTK_ACCEL_VISIBLE); > The problem was caused by the next set of menu accelerators that make use of 'i' with the GDK_SUPER_MASK. For whatever reason under the great God of coding, setting the following 'win+i' (indent by fixed amount ignoring tabstops) and 'win+shift+i' to unindent a fixed amount, causes the textview to interpret 'i' as 'ctrl+i'. Commenting out the following code restored normal operation to the 'i' and its 'ctrl' combinations, e.g. //~ gtk_widget_add_accelerator (indfixedMi, "activate", mainaccel, //~ GDK_KEY_i, GDK_SUPER_MASK, //~ GTK_ACCEL_VISIBLE); //~ gtk_widget_add_accelerator (undfixedMi, "activate", mainaccel, //~ GDK_KEY_i, GDK_SUPER_MASK | GDK_SHIFT_MASK, //~ GTK_ACCEL_VISIBLE); (indent/unindent work fine) There is no logic that I find that says using GDK_SUPER_MASK + 'i' will screw up your GDK_CONTROL_MASK + 'i' accelerators. This is something funky. I like Joël's thought that it may be a UFT-8, ASCII, (whatever western encoding windows uses) problem, but why simply removing the GDK_SUPER_MASK accelerators fixed my issues doesn't seem encoding related. It just seems like something is wrong if the GDK_SUPER_MASK is assigned in Windows? Given the removal of the GDK_SUPER_MASK resolved the issue, if anyone has any information on what GDK_SUPER_MASK can be used for in gtk on windows (or if it just can't be used), I would appreciate your thoughts or links. --one down one to go-- Now all I have to do is figure out how to fix gtk_source_language_manager_set_search_path () on windows so it can find my sourceview language files in "C:\opt\gtk2\share\gtksourceview-2.0\language-specs" (which isn't the /usr/share/... Linux has). I'll just dump the current defaults and add this to the beginning. I guess there is no accommodation in the gtksourceview package, or guards for win32, that would attempt to handle the language-specs location in a way different from Linux... Thanks again for all your help. -- 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
Gtk+2 Textview, (editor) compiled on Windows and 'i' interpreted as 'ctrl+i' (indent)?
All,
This is a bizarre issue. I have a small editor written in gtk+2 (with
optional build w/gktsourceview) It builds and runs without issue on Linux.
I've built it on windows (and it builds without issue), but when running the
editor, if I type and 'i' in the text view window, it 'indents' the paragraph
as if `ctrl+i` were pressed. Strangely, if I inter 'I' (shift+i), the
paragraph unindents. In either case no 'i' or 'I" ever makes it to the
textview buffer. Huh?
The menu accelerator is set to use 'ctrl+i` for indent and 'ctrl+shift+i` to
unindent. The menu and accelerator (in gtk_menu.c) is as follows:
/* define tools menu */
toolsMi = gtk_menu_item_new_with_mnemonic ("_Tools");
sep = gtk_separator_menu_item_new ();
indentMi = gtk_image_menu_item_new_from_stock (GTK_STOCK_INDENT,
NULL);
gtk_menu_item_set_label (GTK_MENU_ITEM (indentMi), "Incr_ease Indent");
unindentMi = gtk_image_menu_item_new_from_stock (GTK_STOCK_UNINDENT,
NULL);
...
/* create entries under 'Tools' then add to menubar */
gtk_menu_item_set_submenu (GTK_MENU_ITEM (toolsMi), toolsMenu);
gtk_menu_shell_append (GTK_MENU_SHELL (toolsMenu), sep);
gtk_menu_shell_append (GTK_MENU_SHELL (toolsMenu), indentMi);
gtk_menu_shell_append (GTK_MENU_SHELL (toolsMenu), unindentMi);
gtk_menu_shell_append (GTK_MENU_SHELL (toolsMenu),
gtk_separator_menu_item_new());
...
gtk_widget_add_accelerator (indentMi, "activate", mainaccel,
GDK_KEY_i, GDK_CONTROL_MASK, GTK_ACCEL_VISIBLE);
gtk_widget_add_accelerator (unindentMi, "activate", mainaccel,
GDK_KEY_i, GDK_CONTROL_MASK | GDK_SHIFT_MASK,
GTK_ACCEL_VISIBLE);
There is no other keypress_handler intercepting keys other than the default
handler. I can't for the life of my figure out what in the menu accelerator
could be causing every 'i' to be interpreted as 'ctrl+i'. Has anyone seen
similar behavior? The gtk windows binaries are from gnome.org/downloads, e.g.
https://download.gnome.org/binaries/win32/gtk+/2.24/gtk+-bundle_2.24.10-20120208_win32.zip
https://download.gnome.org/binaries/win32/gtksourceview/2.10/gtksourceview-2.10.0.zip
https://download.gnome.org/binaries/win32/gtksourceview/2.10/gtksourceview-dev-2.10.0.zip
http://xmlsoft.org/sources/win32/libxml2-2.7.8.win32.zip
compiled with MinGW gcc and the above.
Any ideas? Let me know if I can send any additional information.
--
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: GFileMonitor - g_signal_handler_block "changed" signal doesn't block handler?
On 04/01/2017 01:04 PM, cecas...@aol.com wrote: > > Hi David, > > Not sure about this one. I tested some code out to see if I could figure it > out. Had the same problem that you had with the "changed" signal not being > blocked. If I change the rate of the file monitor and try to spool out the > events, I can block the "changed" signal. Not something that I would recommend > doing outside of testing so I suspect there is a better way to go about it. > Blocking the "changed" signal isn't going to solve the problem of knowing > where the change is coming from which can come from another process at any > time. Maybe if you had a pid in the "changed" callback, then you could compare > it with your program pid to see if the change is coming from your program or > someplace else. > > The following is what I tried using gedit and the terminal. Hopefully you get > some better ideas. > > Eric > Thank you Eric, I will tinker with what you have tried and see if I can figure out more how GFileMonitor signal handling is different from default GTK. I've gotten some suggestions on StackOverflow, but more simply confirm your and my findings. Since GIO handling of the emission and blocking of "changed" is a big black box without picking though the source code, there are suggestions to just save the file 'stat' information and compare against any changed signal for foreign modification and setting a 'save' flag to ignore the "changed" signal during normal file saves. It's frustrating that the GFileMonitor "changed" signal handler block doesn't follow the normal block/unblock convention based on 'instance' and 'handler_id' alone. That certainly would provide a much more elegant solution. Worse case, I can always resort to the original 'inotify' implementation as the custom signal works fine with block/unblock. I'll just have to play with invoking the read from pselect with a g_idle_add of the callback that does that. I haven't played with that yet (as I've been chasing my tail on the GFileMonitor issue in spare time). -- 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: GFileMonitor - g_signal_handler_block "changed" signal doesn't block handler?
On 03/30/2017 03:39 PM, David C. Rankin wrote: > Let me know what the experts think. There is something funny about the way > block/unblock works with GFileMonitor that I'm missing. For normal signals in > the app, I have no problems with block/unblock. I've posted this complete question to: http://stackoverflow.com/questions/43132025/gfilemonitor-g-signal-handler-block-changed-signal-doesnt-block-handler?noredirect=1#comment73342904_43132025 and I've uploaded the complete source to: https://github.com/drankinatty/gtktest if anyone needs additional detail about the issue. -- 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
GFileMonitor - g_signal_handler_block "changed" signal doesn't block handler?
All
I have implemented a GFileMonitor/g_file_monitor_file watch for respond to
changes to the current file by an external process within an editor[1], but
now issuing g_signal_handler_block to prevent the "changed" signal from being
handled on normal saves, does not prevent the callback from firing.
The basic flow is this, I set the watch with:
GFile *gfile = g_file_new_for_path (app->filename);
...
/* create monitor for app->filename */
app->filemon = g_file_monitor_file (gfile,
G_FILE_MONITOR_NONE,
cancellable, );
...
/* connect changed signal to monitored file saving ID */
app->mfp_handler = g_signal_connect (G_OBJECT(app->filemon), "changed",
G_CALLBACK (file_monitor_on_changed), data);
Both the instance (app->filemon) and handler_id (app->mfp_handler) are
saved. In order to prevent handling of changes during normal save/save as
operations, I created block and unblock functions to prevent the changes to
the file from firing the callback, e.g. show below with debug g_print calls:
void file_monitor_block_changed (gpointer data)
{
kwinst *app = (kwinst *)data;
if (!app->filemon || !app->mfp_handler) return;
g_print ("blocking changed (%lu)\n", app->mfp_handler);
g_signal_handler_block (app->filemon, app->mfp_handler);
}
void file_monitor_unblock_changed (gpointer data)
{
kwinst *app = (kwinst *)data;
if (!app->filemon || !app->mfp_handler) return;
g_print ("unblocking changed (%lu)\n", app->mfp_handler);
g_signal_handler_unblock (app->filemon, app->mfp_handler);
}
To implement the block/unblock, I wrap the file 'save/save as' function in
the block, then save, then unblock, but the callback is still firing on normal
saves. e.g. in the save function I have:
if (app->mfp_handler) /* current file monitor on file */
file_monitor_block_changed (app); /* block "changed" signal */
g_print (" buffer_write_file (app, filename)\n");
buffer_write_file (app, filename); /* write to file app->filename */
if (filename)
file_monitor_add (app); /* setup monitoring on new name */
else if (app->mfp_handler)
file_monitor_unblock_changed (app); /* unblock "changed" signal */
To my disbelief, the callback continues to fire as if I had not called block
at all. For instance when saving the file, the debug output is:
$ ./bin/gtkwrite
blocking changed (669)
buffer_write_file (app, filename)
unblocking changed (669)
Monitor Event: File = /home/david/tmp/foo.txt.UY9IXY
G_FILE_MONITOR_EVENT_DELETED
Monitor Event: File = /home/david/tmp/foo.txt
G_FILE_MONITOR_EVENT_CREATED
Monitor Event: File = /home/david/tmp/foo.txt
G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT
Monitor Event: File = /home/david/tmp/foo.txt
G_FILE_MONITOR_EVENT_ATTRIBUTE_CHANGED
from which I can see the block called, the call to save the file to disk, the
unblock call, and then the callback firing to delete the temp file
'foo.txt.UY9IXY', and create the new 'foo.txt' and then setting the
attributes. Why is this occurring? I get the exact same firing of the callback
if I completely remove the block/unblock calls, so it is not due to gio using
a temp file with the g_file_set_contents call during save.
When I created my custom signal for using inotify directly, I could
block/unblock that signal without any problem, but when using GFileMonitor,
the block/unblock seems like it is completely ignored. All types are correct,
e.g. from the basic struct app:
GFileMonitor*filemon;
gulong mfp_handler;
So what is the trick? How to I prevent the file_monitor_on_changed() callback
from firing in response to the "changed" signal on normal file saves. I
shouldn't have to completely disconnect/reconnect the callback should I? The
block/unblock should be sufficient for temporary use, right?
Let me know what the experts think. There is something funny about the way
block/unblock works with GFileMonitor that I'm missing. For normal signals in
the app, I have no problems with block/unblock.
Footnote [1]: (see earlier post "Howto integrate an inotify watch on editor
file in GTK+2 event loop?")
--
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: Howto integrate an inotify watch on editor file in GTK+2 event loop?
On 03/28/2017 10:38 PM, David C. Rankin wrote: > Emmanuele, > > I need more help. I have implemented the watch with 'g_file_monitor_file' > and registered a callback on the "changed" signal for the file, but I cannot > get it to respond to any changes in the underlying file. I got it -- it was user error (I was passing a relative rather than an absolute filename and then monitoring on a relative name)... -- 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: Howto integrate an inotify watch on editor file in GTK+2 event loop?
On 03/28/2017 01:34 PM, David C. Rankin wrote:
> On 03/28/2017 02:06 AM, Emmanuele Bassi wrote:
>> Use GFileMonitor from GIO instead of directly dealing with inotify.
>>
>> Ciao,
>> Emmanuele.
>>
>
> Now that is the type of answer I was looking for! Thanks Emmanuele. That
> definitely keeps it much cleaner.
>
Emmanuele,
I need more help. I have implemented the watch with 'g_file_monitor_file'
and registered a callback on the "changed" signal for the file, but I cannot
get it to respond to any changes in the underlying file.
Specifically, I created the GFileMonitor with:
GFileMonitor *file_monitor_add (const gchar *fn)
{
GFile *gfile = g_file_new_for_path (fn);
GCancellable *cancellable = g_cancellable_new();
GError *err=NULL;
GFileMonitor *filemon = g_file_monitor_file (gfile,
G_FILE_MONITOR_NONE,
cancellable, );
if (!filemon) {
err_dialog (err->message);
g_error_free (err);
g_object_unref (gfile);
return NULL;
}
g_print ("added watch for '%s'\n", fn);
// g_signal_connect (G_OBJECT(filemon), "changed",
// G_CALLBACK (file_monitor_on_changed), NULL);
g_object_unref (gfile);
return filemon;
}
NOTE: the first attempt to connect was shown above, but then according to the
documentation "The signal will be emitted in the thread-default main context
of the thread that the monitor was created". That has me confused (in addition
to the fact that the "changed" signal is never caught. I later connect at the
point the file is opened.
The callback used (for testing purposes) is:
void file_monitor_on_changed (GFileMonitor *mon,
GFile *file, GFile *other,
GFileMonitorEvent evtype,
gpointer data)
{
g_print ("Monitor Event: File = %s\n", g_file_get_parse_name (file));
switch (evtype)
{
case G_FILE_MONITOR_EVENT_CHANGED:
dlg_info ("File Changed.", "changed Event Received");
break;
case G_FILE_MONITOR_EVENT_DELETED:
dlg_info ("File Deleted.", "changed Event Received");
break;
default:;
}
if (mon || other || data) {}
}
In the second attempt to connect, I moved connecting to the callback at the
point of file opening:
else { /* opening file */
file_get_stats (filename, app); /* save file mode, UID, GID */
gtk_text_buffer_set_modified (buffer , FALSE);/* opened */
app->modified = FALSE;
status = g_strdup_printf ("loaded : '%s'", app->fname);
gtkwrite_window_set_title (NULL, app); /* set window title */
/* add watch on file */
GFileMonitor *fm = file_monitor_add (app->fname);
g_signal_connect (G_OBJECT(fm), "changed",
G_CALLBACK (file_monitor_on_changed), NULL);
}
I can switch to a terminal and change, delete, move the opened file and the
callback never fires -- what's the trick? At least with the inotify
implementation, there changes were easy to catch. I think I'm stumbling over
the:
"The signal will be emitted in the thread-default main context of the thread
that the monitor was created"
What do I have to do special to insure I'm looking for the signal in the
"thread-default main context". The editor makes no special use of separate
threads. What am I missing here, if anything.
--
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: Howto integrate an inotify watch on editor file in GTK+2 event loop?
On 03/28/2017 02:06 AM, Emmanuele Bassi wrote: > Use GFileMonitor from GIO instead of directly dealing with inotify. > > Ciao, > Emmanuele. > Now that is the type of answer I was looking for! Thanks Emmanuele. That definitely keeps it much cleaner. -- 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
Howto integrate an inotify watch on editor file in GTK+2 event loop?
All, I have a small editor project I've worked on the past several months[1]. I want to add an `inotify` watch on the current filename after each open or save to detect modification by a foreign process. I have the details of adding the watch and polling the file descriptor with `pselect`, creating a new signal to be emitted on the inotify events, and blocking/unblocking the signal for normal saves from within the editor, but where I'm stuck is how to incorporate monitoring `pselect` from the event loop after the `inotify` watchset is created? Where normally, you would simply call a function that would check whether input was available on the file descriptor set monitored by `pselect` in a loop, where in the GTK event loop would you incorporate the call to `pselect`? I may have the answer, but what I'm looking for in an answer is "Yes, that's a logical approach." or a "No, dummy that's going nowhere." From the glib documentation, it appears that one logical vehicle for doing this is the `g_idle_add()` function which "Adds a function to be called whenever there are no higher priority events pending to the default main loop." This seems to match exactly what I'm trying to do. I could pass a flag via the data to control the return of TRUE/FALSE to remove from the list of funcitons called when the filename changes, etc.. and within the function check the return of `pselect` for any input and emit a signal if any changes were made to the file by a foreign process between the last check and now. Is this the proper vehicle for adding/removing a bit of code to the event loop that I could use to monitor `pselect` or is there a better way of doing this? (the code is GTK+2, using the current glib functions, not the old `gtk_idle_add()`, if that makes any difference) What say the experts? footnote 1: https://github.com/drankinatty/gtkwrite -- 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: Split TextView
On 02/23/2017 01:55 PM, Tuur Dutoit wrote: > Ideally, every page would be a TextView, all backed by 1 TextBuffer, but > that doesn't seem to be possible (out of the box)... > > How would you do this? Why wouldn't that be possible? Each text view allows you to test focus on the text view directly do something similar to the following for each text_view window: gtk_text_view_get_visible_rect (GtkTextView *text_view, GdkRectangle *visible_rect); and from that get an iter: gtk_text_view_get_iter_location (GtkTextView *text_view, const GtkTextIter *iter, GdkRectangle *location); Which you can check against the current "insert" mark and iter obtained from: GtkTextMark * gtk_text_buffer_get_insert (GtkTextBuffer *buffer); void gtk_text_buffer_get_iter_at_mark (GtkTextBuffer *buffer, GtkTextIter *iter, GtkTextMark *mark); The text view with the "insert" mark would scroll on its own as you advance the cursor (just as using a single text view would). I don't see any problem switching between the views to control the split-view you are trying to create. -- 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: Howto attach a popup menu to a menubar (gtk2)
On 03/01/2017 08:17 PM, David C. Rankin wrote:
> All,
>
> I have a menubar (working fine) and I want to attach a popup menu to that
> widget to "show/hide" a toolbar below it. I cannot figure out how to attach
> the popup to the 'menubar' itself generically.
>
> GtkWidget *evbox; /* popup menu container */
> GtkWidget *pmenu; /* the menu */
> GtkWidget *pshowtbMI; /* the menu item */
>
> I've tried to attach the popup to the 'menubar' as a container with the
> following code:
>
> evbox = gtk_event_box_new();
> gtk_container_add (GTK_CONTAINER(menubar), evbox);
> pmenu = gtk_menu_new();
> pshowtbMI = gtk_check_menu_item_new_with_label ("Show Toolbar");
> gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM(pshowtbMI), TRUE);
> gtk_menu_shell_append (GTK_MENU_SHELL(pmenu), pshowtbMI);
> g_signal_connect_swapped (G_OBJECT(evbox), "button-press-event",
> G_CALLBACK(show_popup), pmenu);
> g_signal_connect (G_OBJECT(pshowtbMI), "activate",
> G_CALLBACK(menu_showtb_activate), app);
>
> The show_popup is a generic event-handler that responds to the right-mouse
> button (working fine).
>
> What can I do to provide a popup that will respond when I rt-click on a
> blank part of the menubar?
>
Well,
I have made progress. Rather than adding the eventbox container to the menu,
I added the menu to the eventbox container -- now the popup works fine when
right-clicking on the menubar... but clicking on the menus does not open them.
(the accelerators work fine and I can't open the menus with the menu
accelerators (e.g. Alt+F opens the file menu) I suspect this is a problem with
the event_box event-handler that catches the right-click but does not
propagate the left-click to the menu inside it.
The current setup for the popup menu is:
evbox = gtk_event_box_new();
/* modified menu in container - popup works, but menu doesn't */
gtk_container_add (GTK_CONTAINER(evbox), menubar);
pmenu = gtk_menu_new();
pshowtbMI = gtk_check_menu_item_new_with_label ("Show Toolbar");
gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM(pshowtbMI), TRUE);
gtk_menu_shell_append (GTK_MENU_SHELL(pmenu), pshowtbMI);
/* modified menu in container - popup works, but menu doesn't */
g_signal_connect_swapped (G_OBJECT(menubar), "button-press-event",
G_CALLBACK(show_popup), pmenu);
g_signal_connect (G_OBJECT(pshowtbMI), "activate",
G_CALLBACK(menu_showtb_activate), app);
The event handler I'm using 'show_popup' is:
gboolean show_popup(GtkWidget *widget, GdkEvent *event)
{
const guint RIGHT_CLICK = 3;
if (event->type == GDK_BUTTON_PRESS) {
GdkEventButton *bevent = (GdkEventButton *) event;
if (bevent->button == RIGHT_CLICK) {
gtk_menu_popup(GTK_MENU(widget), NULL, NULL, NULL, NULL,
bevent->button, bevent->time);
}
return TRUE;
}
return FALSE;
}
Do I need to somehow explicitly pass the button-press-event to the menubar
within the event_box somehow?
--
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
Howto attach a popup menu to a menubar (gtk2)
All,
I have a menubar (working fine) and I want to attach a popup menu to that
widget to "show/hide" a toolbar below it. I cannot figure out how to attach
the popup to the 'menubar' itself generically.
GtkWidget *evbox; /* popup menu container */
GtkWidget *pmenu; /* the menu */
GtkWidget *pshowtbMI; /* the menu item */
I've tried to attach the popup to the 'menubar' as a container with the
following code:
evbox = gtk_event_box_new();
gtk_container_add (GTK_CONTAINER(menubar), evbox);
pmenu = gtk_menu_new();
pshowtbMI = gtk_check_menu_item_new_with_label ("Show Toolbar");
gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM(pshowtbMI), TRUE);
gtk_menu_shell_append (GTK_MENU_SHELL(pmenu), pshowtbMI);
g_signal_connect_swapped (G_OBJECT(evbox), "button-press-event",
G_CALLBACK(show_popup), pmenu);
g_signal_connect (G_OBJECT(pshowtbMI), "activate",
G_CALLBACK(menu_showtb_activate), app);
The show_popup is a generic event-handler that responds to the right-mouse
button (working fine).
What can I do to provide a popup that will respond when I rt-click on a
blank part of the menubar?
--
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: Does gtk2 provide a case 'in'-sensitive text search via 'gtk_text_iter_..._search'?
On 02/23/2017 12:53 PM, cecas...@aol.com wrote: > > Hi David, > > I tried out gtkedit and it compiled and worked fine. Did a few searches > and it found the words. > When I compiled I got a few warnings like the following. > > gtk_common_dlg.c: In function ‘err_dialog’: > gtk_common_dlg.c:8:9: warning: format not a string literal and no format > arguments [-Wformat-security] > g_warning (errmsg); /* log to terminal window */ > > I don't know if they are coming up on your computer but they are easy ones to > fix. > Are you going to give finding ligatures and accents a try? I am not very > good with languages, stuck with English, but it is pretty interesting how > things are put together with UTF-8 to allow for all different types of > characters in languages. > > Eric Hey Eric, Thanks for trying the editor. What that means is whatever was sent to the err_dialog function was not a string literal (meaning the text the error dialog was supposed to display wasn't text after all). I'll take a look. Go ahead and pull a fresh copy of the gtkedit (now renamed gtkwrite) code. I have the Makefile set to compile 'gtkedit' by default (without GtkSourceView) and it will build 'gtkwrite' if the -DWGTKSOURCEVIEW2 definition is passed to make through the 'with' parameter. e.g to build gtkedit, just type make: $ make to build gtkwrite use make with=-DWGTKSOURCEVIEW2, e.g $ make with=-DWGTKSOURCEVIEW2 You can clone a copy: git clone https://github.com/drankinatty/gtkwrite.git I've added to the README. Just let me know if you find anything else, or drop a bug on github. -- 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: textview widget selection buffer_select_range is cleared when dialog closes (intermittently?)
On 02/22/2017 08:24 AM, Norbert de Jonge wrote: > I can't help you, but after seeing some of your functions I'm > wondering... Setting the search direction (backwards, forwards), > setting/toggling case sensitivity (yes, no), and moving the selection > to whatever matches next; these are functionalities programmers want to > provide users, and that GTK+ could probably deliver with readily > available functions. Norbert, Thanks for the reply. I have gtk+2 and gtk+3 installed as well as lib libgtksourceview-2 and libgtksourceview-3. When looking for functionality, I go though all and draw from what will most closely fit the bill. Fortunately/unfortunately much of the implementation is left to the programmer regardless of the version used. While using gtksourceview provides a native case in-sensitive search, none of the versions provides specific functions for limiting the search range and direction beyond the basic iter_forward_search iter_backward_search, etc... This question however is unrelated to the choice or version of the toolkit used, it's more general in how to prevent closing of a modal dialog, and the associated change in window focus, etc.., from interfering with a highlighted set of words set with select_range immediately after the dialog closes. It may come down to "How do I confirm that a dialog is fully closed (e.g. the widget fully destroyed) before setting the selection to insure there is no possibility of changing focus undoing the selection? I'll keep looking. -- 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: 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: Does gtk2 provide a case 'in'-sensitive text search via 'gtk_text_iter_..._search'?
amp; mend pointing to first & last char in matched text.
*/
if (app->optback) { /* search backward */
if (app->optcase) { /* case sensitive */
found = gtk_text_iter_backward_search (, text, 0,
, , NULL);
}
else { /* case insensitive backwards search */
#ifdef HAVESOURCEVIEW
found = gtk_source_iter_backward_search (, text,
GTK_SOURCE_SEARCH_CASE_INSENSITIVE,
, , NULL);
#else
found = gtk_text_iter_backward_search_nocase (, text, 0,
, );
#endif
}
}
else { /* search forward */
if (app->optcase) { /* case sensitive */
found = gtk_text_iter_forward_search (, text, 0,
, , NULL);
}
else { /* case insensitive forward search */
#ifdef HAVESOURCEVIEW
found = gtk_source_iter_forward_search (, text,
GTK_SOURCE_SEARCH_CASE_INSENSITIVE,
, , NULL);
#else
found = gtk_text_iter_forward_search_nocase (, text, 0,
, );
#endif
}
}
Hope this can help someone else.
--
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: 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
>
Thanks Eric,
I went though the GtkSourceView-3 code and was digesting the folding (slowly
digesting it). Yes, I'm using nothing but US ASCII set, though it is good to
incorporate (as I learn) the UTF-8 handing for other character sets.
I finally hit on something I like. I set several search options. I have
options for forward/backward search, search from cursor, search within
selected text, search whole words only. The following is the forward
case-insensitive search. The search term is provided in 'text' and I basically
just walk an iter over the search bounds and set the start and end iters
bracketing the matching term within the buffer. Seems to work fine:
else { /* search forward */
if (app->optcase) { /* case sensitive */
found = gtk_text_iter_forward_search (, text, 0,
, , NULL);
}
else { /* case insensitive */
gunichar c;
gchar *lctext = g_strdup (text);/* copy search text */
str2lower (lctext); /* convert to lower-case */
found = FALSE;
for (;;) {
gsize len = textlen;/* get char at iter */
c = g_unichar_tolower (gtk_text_iter_get_char ());
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
());
/* compare/advance -- order IS important */
if (c != (gunichar)lctext[i] ||
!gtk_text_iter_forward_char ())
goto next; /* start next search */
}
mend = iter;/* set end iter */
found = TRUE; /* found to true */
break;
}
next:; /* if at end of selecton break */
if (!gtk_text_iter_forward_char ())
break;
}
if (lctext) g_free (lctext);
}
}
--
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: Does gtk2 provide a case 'in'-sensitive text search via 'gtk_text_iter_..._search'?
On 01/26/2017 03:21 PM, cecas...@aol.com wrote:
> I worked on this a little more and tried to make it UTF-8 compliant.
> Highlighted the text also. It should still be efficient since it is only doing
> a single pass over each char. I am sure there are things that I haven't
> considered but it does a little more than the first try at it.
>
> https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/Csamples/search_textbuffer1.c
You rock! Thank you. I actually did something similar, though I will probably
scavenge from your efforts, I basically wrote a generic iterator for selected
text in GtkTextBuffer, and then converted all to lowercase before comparison
manually (I like your UTF-8 compliant g_unichar_tolower() approach compared to)
:
gboolean str2lower (gchar *str)
{
if (!str) return FALSE;
gchar *p = str;
gboolean changed = FALSE;
for (; *p; p++)
if ('A' <= *p && *p <= 'Z') {
*p ^= 32;
changed = TRUE;
}
return changed;
}
Eventually when Gtk+3 stabilizes I'll look at a move to it and GtkSourceView
3X, but currently I'm quite happy with the Gtk+2 stable branch (and the wealth
of good themes available). For most of the added GtkSourceView 3X
functionality that I want, have simply backported the functions to run with
Gtk+2 (e.g. source_view_indent_lines, source_view_unindent_lines, ...)
--
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
SOLVED - sortof [was Re: "mark_set" callback fires 3 or 4 times when using arrow keys/mouse in textview?}
On 12/22/2015 05:13 PM, David C. Rankin wrote:
How can I limit the the execution of the 'on_mark_set' callback to a single
call regardless of whether there is data being entered or if cursor is being
moved with the arrow-keys or mouse? Any help will be greatly appreciated.
OK, I have a solution that is probably not as elegant as desired. Delving into
the "mark_set" signal and multiple firing of the callback opened a small can of
worms regarding a number of considerations associated with GtkTextMark and
GtkTextIter relationships.
The problem can be summarized as follows:
(1) the proper callback prototype to handle the "mark_set" signal is:
void on_mark_set (GtkTextBuffer *buffer, GtkTextIter *iter,
GtkTextMark *mark, context *app)
(2) there are multiple text marks at each iter location.
(3) when responding to the "mark_set" signal, the 'mark' passed to the callback
can be any of the marks at the "iter" location which are passed in "no
particular order" and are passed differently depending on whether normal text is
being entered, arrow-keys are pressed, or whether the mouse is clicked to
reposition to "insert" cursor mark.
(4) This prevents a simple comparison between the "mark" parameter and
gtk_text_buffer_get_insert (buffer) alone from being used to determine whether
to respond to a "mark_set" signal or not.
The short version of a solution to prevent responding to multiple "mark_set"
signals is as follows. (the callback is still fired, but you can test between
'current' and 'new' line:col locations responding only when the values differ)
void on_mark_set (GtkTextBuffer *buffer, GtkTextIter *iter,
GtkTextMark *mark, context *app)
{
gint line, col;
line = gtk_text_iter_get_line (iter);
col = gtk_text_iter_get_line_offset (iter);
if (line == app->line && col == app->col) return;
app->line = line;
app->col = col;
g_print (" line: %3d col: %d\n", app->line + 1, app->col + 1);
if (buffer) {}
if (mark) {}
}
Now for the rest of the story... I am normally reasonably adept at finding this
type of information myself in the documentation or via the web without having to
ask, but in this case there simply isn't much in the way of details on how, what
or in what order "mark_set" callback parameters are passed each time the
callback is fired. I'll leave what I found here to save the next person a bit of
time.
Each time the "mark_set" signal is generated, there can be multiple marks at any
given iter *location*. In the case of normal input (e.g. 'a', 'b', etc...) the
mark passed to the on_mark_set() callback is not necessarily the "insert" mark,
but is apparently simply the last of the marks present at that iter *location*.
(In each case below an anonymous mark is passed as a result of normal text
input) The list of marks at any given iter position can be found by the GSList
of marks returned by gtk_text_iter_get_marks (iter). (*note:* the marks in the
list returned are in *no particular* order -- which is probably the basis for
this whole issue to begin with. See:
https://developer.gnome.org/gtk2/stable/GtkTextIter.html#gtk-text-iter-get-marks) For
example, you can examine the marks with the following debug code:
void on_mark_set (GtkTextBuffer *buffer, GtkTextIter *iter,
GtkTextMark *mark, context *app)
{
gint line, col;
#ifdef DEBUG
g_print (" mark: %p - gtbgi (buffer): %p mark->name: %s\n", mark,
gtk_text_buffer_get_insert (buffer),
gtk_text_mark_get_name (mark));
GSList *marks = gtk_text_iter_get_marks (iter);
GSList *p = marks;
gint i = 0;
while (p) {
const gchar *name = gtk_text_mark_get_name (GTK_TEXT_MARK(p->data));
g_print ("mark[%d] : %p : %s\n", i++, GTK_TEXT_MARK(p->data),
name);
p = p->next;
}
g_slist_free (marks);
#endif
line = gtk_text_iter_get_line (iter);
col = gtk_text_iter_get_line_offset (iter);
if (line == app->line && col == app->col) return;
app->line = line;
app->col = col;
#ifdef DEBUG
g_print (" line: %3d col: %d\n\n", app->line + 1, app->col + 1);
#endif
if (mark) {}
}
Compiling and then using the same (enter 'abc', then Left-Arrow, then
*mouse-click* at the end) fires the on_mark_set() callback for each 'abc' entered:
$ ./bin/text_mcve_dbg
mark: 0x2458880 - gtbgi (buffer): 0x237d600 mark->name: (null)
mark[0] : 0x237d600 : insert
mark[1] : 0x237d620 : selection_bound
mark[2] : 0x237d7a0 : gtk_drag_target
mark[3] : 0x2458880 : (null)
lin
"mark_set" callback fires 3 or 4 times when using arrow keys/mouse in textview?
All,
I am using using the 'mark_set' signal to update the row:col values within my
GtkTextBuffer. I have a simple setup with the textview inside a scrolled window
inside a window:
window
scrolled window
textview
I use a structure to hold the various persistent values for my application,
for example:
typedef struct {
GtkWidget *window;
GtkWidget *view;
GtkTextBuffer *buffer;
GtkWidget *entry;
GtkTextMark *cursor;
gint line;/* line number */
gint col; /* column number */
gint indent;
gint indentlevel;
gint tabsz;
gint winwidth;
gint winheight;
gboolean overwrite;
} context;
All I am trying to do is update the current 'line' and 'col' values in the
instance of the struct used with my application ('app'). Within my main window
create function I initialize the values for 'context app;', create the window,
scrolled window and textview, and connect the 'mark_set' signal to my
'on_mark_set' callback, passing the instance of the struct as the data to the
callback:
g_signal_connect (app->buffer, "mark_set",
G_CALLBACK (on_mark_set), app);
The 'on_mark_set' callback (with g_print for debug purposes):
void on_mark_set (GtkTextBuffer *buffer, context *app)
{
GtkTextIter iter;
app->cursor = gtk_text_buffer_get_insert (buffer);
gtk_text_buffer_get_iter_at_mark (buffer, , app->cursor);
app->line = gtk_text_iter_get_line ();
app->col = gtk_text_iter_get_line_offset ();
g_print (" line: %3d col: %d\n", app->line + 1, app->col + 1);
}
The values for 'app->line' and 'app->col' are correctly set (only once)
following each keypress where input is being provided to the buffer. e.g.
inputting 'abc' into the textview results in:
$ ./bin/text_view_fn
line: 1 col: 2
line: 1 col: 3
line: 1 col: 4
However, when I use the arrow keys to move the input cursor or use the mouse
to reposition it, the callback tripple-fires or quadruple-fires. e.g. pressing
the left-arrow to backup one position results in the following:
line: 1 col: 3
line: 1 col: 3
line: 1 col: 3
or repositioning by clicking the mouse at the beginning results in a
quadruple-fire of the callback:
line: 1 col: 1
line: 1 col: 1
line: 1 col: 1
line: 1 col: 1
How can I limit the the execution of the 'on_mark_set' callback to a single
call regardless of whether there is data being entered or if cursor is being
moved with the arrow-keys or mouse? Any help will be greatly appreciated.
--
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
gtk_text_view_im_context_filter_keypress - howto replace Tab with 4-spaces?
All,
I am having trouble using gtk_text_view_im_context_filter_keypress to catch
the 'Tab' keypress and replace the tab with 4-spaces instead. I can catch the
keypress just fine, but I cannot replace the tab with 4-spaces in my textview
using gtk_text_view_im_context_filter_keypress. I have the following simple setup:
window
scrolled window
textview
Attempting to replace the tab with spaces I connected the "key_press_event"
to my 'on_keypress' callback:
g_signal_connect (G_OBJECT (app->view), "key_press_event",
G_CALLBACK (on_keypress), app);
The on_keypress callback (with a few printf debug statements included) is:
gboolean on_keypress (GtkWidget *widget, GdkEventKey *event, context *app)
{
switch (event->keyval)
{
case GDK_KEY_Tab:
printf ("key pressed: Tab, inserting ''\n");
GtkTextBuffer *buffer;
if (gtk_text_view_im_context_filter_keypress (GTK_TEXT_VIEW
(app->view),
event)) {
printf (" Tab key handled by im_context\n");
buffer = gtk_text_view_get_buffer (GTK_TEXT_VIEW (app->view));
gtk_text_buffer_insert_at_cursor (buffer, "", -1);
return TRUE;
}
else printf (" Tab key handled by default handler\n");
default:
return FALSE;
}
}
The GDK_KEY_Tab is caught as expected. "key pressed: Tab, inserting ''\n"
outputs as expected, but then gtk_text_view_im_context_filter_keypress always
returns 'FALSE'.
Why is the gtk_text_view_im_context_filter_keypress returning FALSE? The
parameters are correct, I can catch the 'Tab' and write 4-spaces to the buffer
simply by removing the if() from before the gtk_text_buffer_insert_at_cursor
call as follows:
gboolean on_keypress (GtkWidget *widget, GdkEventKey *event, context *app)
{
switch (event->keyval)
{
case GDK_KEY_Tab:
GtkTextBuffer *buffer;
buffer = gtk_text_view_get_buffer (GTK_TEXT_VIEW (app->view));
gtk_text_buffer_insert_at_cursor (buffer, "", -1);
return TRUE;
default:
return FALSE;
}
}
This works absolutely fine for what I want to do, but it seems to completely
defeat the purpose of gtk_text_view_im_context_filter_keypress. Is this a proper
way to handle the tab/4-space replacement, or is there some problem that
gtk_text_view_im_context_filter_keypress was intended to fix here? The
documentation says:
"Note that you are expected to call this function from your handler when
overriding key event handling."
That's what I'm trying to do, but when I call the function, it always returns
FALSE -- so what's the point?
What say the experts? Is gtk_text_view_im_context_filter_keypress needed?, or
is doing the tab/4-space replacement without it OK? Thanks.
--
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: gtk_text_view_im_context_filter_keypress - howto replace Tab with 4-spaces?
On 12/21/2015 02:57 AM, Liam R. E. Quin wrote:
On Mon, 2015-12-21 at 02:22 -0600, David C. Rankin wrote:
[...]
if (gtk_text_view_im_context_filter_keypress (GTK_TEXT_VIEW
(app->view),
event)) {
printf (" Tab key handled by im_context\n");
This is the wrong way round. I think that
if gtk_text_view_im_context_filter_keypress returns true you're
supposed to return TRUE without doing anything.
You may find the devhelp program useful - search for this function in
the index and you'll see an example.
Liam
Thank you Liam,
I went back and re-read the documentation again, and then it made sense. If
gtk_text_view_im_context_filter_keypress returns true, as you say, it is telling
you there is nothing more you can do to handle the keypress. It is only when it
returns false that you can further handle the keypress before returning true
telling the default handler that you handled the keypress.
I guess the way it works was just counterintuitive to what I expected and the
2 sentences worth of documentation weren't quite enough to cure the confusion.
Thanks again. I ended up doing the following:
gboolean on_keypress (GtkWidget *widget, GdkEventKey *event, context *app)
{
switch (event->keyval)
{
case GDK_KEY_Tab: /* catch tab, replace with spaces */
if (gtk_text_view_im_context_filter_keypress (GTK_TEXT_VIEW
(app->view),
event)) {
return TRUE;
}
else {
GtkTextBuffer *buffer;
gchar *tab_string;
buffer = gtk_text_view_get_buffer (GTK_TEXT_VIEW (app->view));
tab_string = g_strdup_printf ("%*s", app->tabspaces, " ");
gtk_text_buffer_insert_at_cursor (buffer, tab_string, -1);
g_free (tab_string);
return TRUE;/* return TRUE - no further processing */
}
default: /* indicate default handling should take place */
return FALSE;
}
}
--
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
SOLVED [was Re: Howto set horiz space/padding between vbox and statusbar?]
On 12/07/2015 11:13 PM, David C. Rankin wrote: All, I have been pulling my hair out trying to tweak the padding between a GtkVBox and a GtkStatusbar. I have the following main window layout: main window vbox = gtk_vbox_new (FALSE, 0); menubar scrolled-window textview statusbar The problem is the scrolled-window and textview widgets provide a nice 10 pixel border created with: gtk_text_view_set_left_margin (GTK_TEXT_VIEW (app->view), 5); ... gtk_container_set_border_width (GTK_CONTAINER (scrolled_window), 5); The statusbar however, is positioned snugly against the left border of the main window and vbox at the bottom. I would like to move the statusbar display to the right (pad it on the left) by 10 pixels to match the textview. I have tried adjusting the padding with the following: /* create/pack statusbar at end */ app->statusbar = gtk_statusbar_new (); gboolean expand = 0; gboolean fill = 0; guint pad = 0; GtkPackType packtype = 0; gtk_box_query_child_packing (GTK_BOX (vbox), app->statusbar, , , , ); pad += 10; gtk_box_set_child_packing (GTK_BOX (vbox), app->statusbar, expand, fill, pad, packtype); status_set_default (app); gtk_box_pack_end (GTK_BOX (vbox), app->statusbar, FALSE, FALSE, 0); However, there is no change in the statusbar display. What say the experts? What part of the object hierarchy am I missing/screwing up? Thanks. p.s. sorry if you get 2 copies, the first went to the 'requests' list by mistake. gtk_alignment_new was the key: /* create/pack statusbar at end within gtk_alignment */ guint ptop; guint pbot; guint pleft; guint pright; GtkWidget *sbalign = gtk_alignment_new (0, .5, 1, 1); gtk_alignment_get_padding (GTK_ALIGNMENT (sbalign), , , , ); gtk_alignment_set_padding (GTK_ALIGNMENT (sbalign), ptop, pbot, pleft + 10, pright); app->statusbar = gtk_statusbar_new (); status_set_default (app); gtk_container_add (GTK_CONTAINER (sbalign), app->statusbar); gtk_box_pack_end (GTK_BOX (vbox), sbalign, FALSE, FALSE, 0); Now all things are nice and aligned at the same 10 pixel border. -- 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
Howto set horiz space/padding between vbox and statusbar?
All, I have been pulling my hair out trying to tweak the padding between a GtkVBox and a GtkStatusbar. I have the following main window layout: main window vbox = gtk_vbox_new (FALSE, 0); menubar scrolled-window textview statusbar The problem is the scrolled-window and textview widgets provide a nice 10 pixel border created with: gtk_text_view_set_left_margin (GTK_TEXT_VIEW (app->view), 5); ... gtk_container_set_border_width (GTK_CONTAINER (scrolled_window), 5); The statusbar however, is positioned snugly against the left border of the main window and vbox at the bottom. I would like to move the statusbar display to the right (pad it on the left) by 10 pixels to match the textview. I have tried adjusting the padding with the following: /* create/pack statusbar at end */ app->statusbar = gtk_statusbar_new (); gboolean expand = 0; gboolean fill = 0; guint pad = 0; GtkPackType packtype = 0; gtk_box_query_child_packing (GTK_BOX (vbox), app->statusbar, , , , ); pad += 10; gtk_box_set_child_packing (GTK_BOX (vbox), app->statusbar, expand, fill, pad, packtype); status_set_default (app); gtk_box_pack_end (GTK_BOX (vbox), app->statusbar, FALSE, FALSE, 0); However, there is no change in the statusbar display. What say the experts? What part of the object hierarchy am I missing/screwing up? Thanks. p.s. sorry if you get 2 copies, the first went to the 'requests' list by mistake. -- 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
