Re: ANNOUNCE: Phasing out GTK mailing lists and move to Discord

2019-03-20 Thread David C. Rankin
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

2019-02-06 Thread David C. Rankin
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?

2018-10-25 Thread David C. Rankin
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

2018-10-23 Thread David C. Rankin
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?

2018-10-01 Thread David C. Rankin
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?

2018-09-26 Thread David C. Rankin
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?

2018-09-16 Thread David C. Rankin
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?

2018-09-16 Thread David C. Rankin
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?

2018-09-16 Thread David C. Rankin
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?

2018-08-28 Thread David C. Rankin
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?

2018-08-28 Thread David C. Rankin
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?

2018-08-27 Thread David C. Rankin
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

2018-08-03 Thread David C. Rankin
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?

2018-07-30 Thread David C. Rankin
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?

2018-07-28 Thread David C. Rankin
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

2018-07-28 Thread David C. Rankin
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?

2018-07-28 Thread David C. Rankin
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?

2018-07-28 Thread David C. Rankin
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)

2018-07-17 Thread David C. Rankin
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)

2018-07-17 Thread David C. Rankin
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.

2017-08-29 Thread David C. Rankin
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.

2017-08-29 Thread David C. Rankin
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.

2017-08-27 Thread David C. Rankin
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'?

2017-08-01 Thread David C. Rankin
 /* 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?

2017-08-01 Thread David C. Rankin
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?

2017-07-31 Thread David C. Rankin
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)?

2017-06-22 Thread David C. Rankin
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)?

2017-06-21 Thread David C. Rankin
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)?

2017-06-21 Thread David C. Rankin
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?

2017-04-01 Thread David C. Rankin
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?

2017-03-31 Thread David C. Rankin
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?

2017-03-30 Thread David C. Rankin
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?

2017-03-28 Thread David C. Rankin
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?

2017-03-28 Thread David C. Rankin
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?

2017-03-28 Thread David C. Rankin
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?

2017-03-28 Thread David C. Rankin
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

2017-03-11 Thread David C. Rankin
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)

2017-03-01 Thread David C. Rankin
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)

2017-03-01 Thread David C. Rankin
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'?

2017-03-01 Thread David C. Rankin
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?)

2017-02-22 Thread David C. Rankin
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?)

2017-02-21 Thread David C. Rankin
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?)

2017-02-21 Thread David C. Rankin
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'?

2017-02-21 Thread David C. Rankin
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'?

2017-02-18 Thread David C. Rankin
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'?

2017-02-17 Thread David C. Rankin
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?}

2015-12-28 Thread David C. Rankin

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?

2015-12-22 Thread David C. Rankin

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?

2015-12-21 Thread David C. Rankin

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?

2015-12-21 Thread David C. Rankin

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?]

2015-12-08 Thread David C. Rankin

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?

2015-12-07 Thread David C. Rankin

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