Re: Using different signals depending on which row of of a treeview

[Mike Martin]

This is more or less what I did except I added a signal_connect separately
to the visibilty (which is in a cell_data_function on first renderer)

ie: (perl)
my @cells=Treeview->get_column(n)->get_cells;
then
$cells[n]->signal_connect(blah
}
);
(where n is the appropriate number of column/renderer)





On Mon, 29 Apr 2019 at 22:57, Reuben Rissler  wrote:

>
>
> On 04/29/2019 10:36 AM, Mike Martin via gtk-app-devel-list wrote:
> > Has anyone done anything like this?
> I haven't, but you are welcome to my simple Glade mockup:
>
> 
> 
> 
>
>
>  
>
>
>
>
>  
>  
>
>  1
>  one
>
>
>  2
>  two
>
>
>  3
>  three
>
>  
>
>
>  
>
>
>
>
>
>
>
>
>  
>  
>
>  text
>  True
>  False
>  False
>
>
>  combo
>  False
>  True
>  False
>
>
>  toggle
>  False
>  False
>  True
>
>  
>
>
>  False
>  
>
>  
>  
>
>  True
>  True
>  tree_model
>  
>
>  
>  
>
>  column
>  
>
>  True
>
>
>  1
>  0
>
>  
>  
>
>  True
>  combo_model
>  1
>
>
>  2
>  0
>
>  
>  
>
>
>  3
>  3
>
>  
>
>  
>
>  
>
> 
> >
> > Basically the idea is that I push multiple renderers into a treeview
> column
> > , then depending on the row hide/show the appropriate renderer (text,
> > combo, toggle)
> So go ahead and add three different renderers, and use row values to set
> them visible or invisible. In this case we have three different
> column/row cells to set each widget visible.
> >
> > Then call the appropriate signal_connect (edited, changed, toggled)
> You can't really generate a signal on an invisible renderer, can you?
> > ___
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Using different signals depending on which row of of a treeview

[Mike Martin via gtk-app-devel-list]

 This is more or less what I did except I added a signal_connect separately
to the visibilty (which is in a cell_data_function on first renderer)

ie: (perl)
my @cells=Treeview->get_column(n)->get_cells;
then
$cells[n]->signal_connect(blah
}
);
(where n is the appropriate number of column/renderer)

On Mon, 29 Apr 2019 at 22:57, Reuben Rissler  wrote:

>
>
> On 04/29/2019 10:36 AM, Mike Martin via gtk-app-devel-list wrote:
> > Has anyone done anything like this?
> I haven't, but you are welcome to my simple Glade mockup:
>
> 
> 
> 
>
>
>  
>
>
>
>
>  
>  
>
>  1
>  one
>
>
>  2
>  two
>
>
>  3
>  three
>
>  
>
>
>  
>
>
>
>
>
>
>
>
>  
>  
>
>  text
>  True
>  False
>  False
>
>
>  combo
>  False
>  True
>  False
>
>
>  toggle
>  False
>  False
>  True
>
>  
>
>
>  False
>  
>
>  
>  
>
>  True
>  True
>  tree_model
>  
>
>  
>  
>
>  column
>  
>
>  True
>
>
>  1
>  0
>
>  
>  
>
>  True
>  combo_model
>  1
>
>
>  2
>  0
>
>  
>  
>
>
>  3
>  3
>
>  
>
>  
>
>  
>
> 
> >
> > Basically the idea is that I push multiple renderers into a treeview
> column
> > , then depending on the row hide/show the appropriate renderer (text,
> > combo, toggle)
> So go ahead and add three different renderers, and use row values to set
> them visible or invisible. In this case we have three different
> column/row cells to set each widget visible.
> >
> > Then call the appropriate signal_connect (edited, changed, toggled)
> You can't really generate a signal on an invisible renderer, can you?
> > ___
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Using different signals depending on which row of of a treeview

[Reuben Rissler]

On 04/29/2019 10:36 AM, Mike Martin via gtk-app-devel-list wrote:

Has anyone done anything like this?

I haven't, but you are welcome to my simple Glade mockup:




  
  
    
  
  
  
  
    
    
  
    1
    one
  
  
    2
    two
  
  
    3
    three
  
    
  
  
    
  
  
  
  
  
  
  
  
    
    
  
    text
    True
    False
    False
  
  
    combo
    False
    True
    False
  
  
    toggle
    False
    False
    True
  
    
  
  
    False
    
  
    
    
  
    True
    True
    tree_model
    
  
    
    
  
    column
    
  
    True
  
  
    1
    0
  
    
    
  
    True
    combo_model
    1
  
  
    2
    0
  
    
    
  
  
    3
    3
  
    
  
    
  
    
  



Basically the idea is that I push multiple renderers into a treeview column
, then depending on the row hide/show the appropriate renderer (text,
combo, toggle)
So go ahead and add three different renderers, and use row values to set 
them visible or invisible. In this case we have three different 
column/row cells to set each widget visible.


Then call the appropriate signal_connect (edited, changed, toggled)

You can't really generate a signal on an invisible renderer, can you?

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: REMINDER: List moved to Discourse; archival in 1 week

[Osmo Antero via gtk-app-devel-list]

I go down with the boat.

Emmanuele Bassi via gtk-app-devel-list 
escreveu no dia quarta, 24/04/2019 à(s) 12:36:

> Hi all;
>
> next week, on May 1st, this list will be archived[0]. This means no new
> subscriptions, and no new email.
>
> If you have questions about GTK, GLib, and the rest of the core GNOME
> development platform, you can use the Discourse[1] instance hosted on GNOME
> infrastructure; we have a Platform/Core category, and we can use
> appropriate tags that you can watch[2] and filter on.
>
> You can use existing single-sign on systems, like Google and Github, to
> authenticate yourself; if you have a GNOME LDAP account already, you're
> strongly encouraged to use that method of authentication.
>
> You can still use email to interact with Discourse, and a guide is
> available[3] to configure your account.
>
> If you have any questions or feedback on Discourse, please use the
> appropriate category[4].
>
> Ciao,
>  Emmanuele.
>
> [0]:
> https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg00024.html
> [1]: https://discourse.gnome.org
> [2]: https://discourse.gnome.org/t/tags-and-watching/94
> [3]: https://discourse.gnome.org/t/interacting-with-discourse-via-email/46
> [4]: https://discourse.gnome.org/c/site-feedback
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>


-- 
Sent from my PC, laptop or phone with Ubuntu-Linux.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

RE: gtk3 drag and drop sample/demo

[Pankaj Bansal via gtk-app-devel-list]

Hello Emmanaele,

 

Thanks for replying and sorry if I sounded unreasonable to go and check the 
issue. I was referring to look at the issue and reproducer for the issue. 

 

Issue:

In Ubuntu 16.04 (gtk3.18) all works fine for in JavaFX. 

For Ubuntu 18.04 (gtk3.20 or later), the dnd stops working. I have found that 
we are not getting any calls from gtk side. I mean gtk is not calling the event 
callback function. I see that there is only one DragEnter event, one DragMotion 
event and then one DragEnd event. Whereas with gtk 3.18, we get many 
DragMotionm events which is what supposed to happen. 

 

Below is a sample code, which can be used to easily see the issue. It is using 
the JavaFX for dnd.

 

I was hoping to get hands on some dnd native sample/demo which works fine with 
gtk3.20 or later. But if you are saying that nothing has changed, so I have to 
see what makes our code stop working from gtk3.20

 

 

//Sample Fx11draggError.java

 

import javafx.application.Application; 

import javafx.scene.Scene; 

import javafx.scene.control.Button; 

import javafx.scene.input.ClipboardContent; 

import javafx.scene.input.TransferMode; 

import javafx.stage.Stage; 

public class Fx11draggError extends Application{ 

@Override 

public void start(Stage stage) throws Exception { 

   Button button = new Button("test"); 

   button.setOnDragDetected(e -> { 

  System.out.println("Drag detected");

  ClipboardContent content = new 
ClipboardContent(); 

      content.putString("It works"); 

  
button.startDragAndDrop(TransferMode.COPY).setContent(content); 

  e.consume(); 

   }); 

button.setOnDragOver((ev)-> {System.out.println("Drag over"); 
ev.consume();}); 

button.setOnDragDropped((ev)-> {System.out.println("Drag end"); 
ev.consume();}); 

button.setOnDragDone((ev)-> {System.out.println("Drag done"); 
ev.consume();}); 

   stage.setScene(new Scene(button, 200, 200)); 

   stage.show(); 

} 

public static void main(String[] args) { 

launch(); 

} 

}

 

-Pankaj

 

From: Emmanuele Bassi [mailto:eba...@gmail.com] 
Sent: Monday, April 15, 2019 5:26 PM
To: Pankaj Bansal
Cc: gtk-app-devel-list list
Subject: Re: gtk3 drag and drop sample/demo

 

On Mon, 15 Apr 2019 at 12:45, Pankaj Bansal via gtk-app-devel-list mailto:gtk-app-devel-list@gnome.org"gtk-app-devel-list@gnome.org> wrote:

 

I am working with OpenJDK JavaFX dev group and we are facing some problems with 
drag and drop functionality with gtk3.20 or later. You can have a look at the 
bug for more information https://bugs.openjdk.java.net/browse/JDK-8211302. It 
will be great if someone can point out any big change done with respect to drag 
and drop from gtk3.20.

 

First of all, it's kind of rude to ask people to go to a random bug tracker and 
ask for a code review without stating what the issue is.

 

Can you explain what issues are you experiencing?

 

I am looking for a sample/demo for drag and drop functionality using gtk3. I 
can see that there is one demo at [1], but it is not compatible with gtk3 as it 
is using gtk4 specific structs and functions. I am not able to find any other 
working demo/sample working with gtk3. It would be great if anyone can point to 
me to something useful.

 

The drag and drop code in GTK 3 hasn't really changed from the 2.x days, and 
has been substantially reworked for GTK 4.

 

The old drag and drop tutorial may be of help: HYPERLINK 
"https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.gnome.org_Newcomers_DragNDropTutorial&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=nHVEjVI-guB2suhUDbwru96xVVrQOkjZ4oHvLp8rBFo&m=k76mPqvxlua5kHEVFWSnXbdNteF7JdealQN3v-KVELc&s=3cUNH1P03apgAfDvBiT0NPIXKGbGVyAOQ2uhcFlSjzY&e="https://wiki.gnome.org/Newcomers/DragNDropTutorial

 

Ciao,

 Emmanuele.

 

-- 

HYPERLINK 
"https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bassi.io&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=nHVEjVI-guB2suhUDbwru96xVVrQOkjZ4oHvLp8rBFo&m=k76mPqvxlua5kHEVFWSnXbdNteF7JdealQN3v-KVELc&s=adNpmoTJk5ufLg6lUH49hjZcSXWNzTTWCMInMXMuGs4&e="https://www.bassi.io
[@] ebassi [@HYPERLINK 
"https://urldefense.proofpoint.com/v2/url?u=http-3A__gmail.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=nHVEjVI-guB2suhUDbwru96xVVrQOkjZ4oHvLp8rBFo&m=k76mPqvxlua5kHEVFWSnXbdNteF7JdealQN3v-KVELc&s=1HMnpf-boburUX2mA71lOOnlacW-IU1aoV3WwBRXQEY&e="gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk3 drag and drop sample/demo

[Emmanuele Bassi via gtk-app-devel-list]

On Mon, 15 Apr 2019 at 12:45, Pankaj Bansal via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:


> I am working with OpenJDK JavaFX dev group and we are facing some problems
> with drag and drop functionality with gtk3.20 or later. You can have a look
> at the bug for more information
> https://bugs.openjdk.java.net/browse/JDK-8211302. It will be great if
> someone can point out any big change done with respect to drag and drop
> from gtk3.20.
>

First of all, it's kind of rude to ask people to go to a random bug tracker
and ask for a code review without stating what the issue is.

Can you explain what issues are you experiencing?


> I am looking for a sample/demo for drag and drop functionality using gtk3.
> I can see that there is one demo at [1], but it is not compatible with gtk3
> as it is using gtk4 specific structs and functions. I am not able to find
> any other working demo/sample working with gtk3. It would be great if
> anyone can point to me to something useful.
>

The drag and drop code in GTK 3 hasn't really changed from the 2.x days,
and has been substantially reworked for GTK 4.

The old drag and drop tutorial may be of help:
https://wiki.gnome.org/Newcomers/DragNDropTutorial

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: TreeView - set border on individual cells

[Eric Cashon via gtk-app-devel-list]

 
I looked into this a little more. It looks like using an overlay is the easiest 
solution that I could find. You can override the render function of the cell 
renderer but then you will probably need all the code in the text cell 
renderer. This isn't too bad since the text cell renderer is modular and you 
don't have to deal with a tangle of header files. Or you can just make changes 
to the text cell renderer and compile the changes in GTK. Changing the cell 
renderer has the advantage that you can order what you want to draw from back 
to front. A little more flexible than drawing a rectangle over the top.

This does seem something to be useful to be able to do.

Eric
   
//gcc -Wall stripe_list3.c -o stripe_list3 `pkg-config --cflags --libs gtk+-3.0`

#include
#include

enum
{
   ID,
   PROGRAM,
   COLOR,
   COLOR2,
   COLUMNS
};

static gint row_g=0;
static gint column_g=0;

static void get_path(GtkTreeView *tree_view, GtkTreePath *path, 
GtkTreeViewColumn *column, gpointer renderer1)
  {
    g_print("Get Path\n");
    gchar *string=gtk_tree_path_to_string(path);
    g_print("%s %s\n", string, gtk_tree_view_column_get_title(column));
    row_g=atoi(string);
    g_free(string);

    gint c1=0;
    if(g_strcmp0("ID", gtk_tree_view_column_get_title(column))==0) c1=2;
    if(g_strcmp0("Program", gtk_tree_view_column_get_title(column))==0) c1=3;
    column_g=c1-2;

    GtkTreeIter iter;
    GtkTreeModel *tree_model=gtk_tree_view_get_model(tree_view);
    gtk_tree_model_get_iter(tree_model, &iter, path);
    gtk_list_store_set(GTK_LIST_STORE(tree_model), &iter, c1, "SpringGreen", 
-1);
    gtk_widget_queue_draw(GTK_WIDGET(tree_view));
  }
static gboolean draw_rectangle(GtkWidget *overlay, cairo_t *cr, GtkWidget 
*tree_view)
  {
    g_print("Draw Rectangle %i %i\n", row_g, column_g);
    GtkTreePath *path=gtk_tree_path_new_from_indices(row_g, -1);
    GtkTreeViewColumn 
*column=gtk_tree_view_get_column(GTK_TREE_VIEW(tree_view), column_g);

    GdkRectangle rect;
    gint x=0;
    gint y=0;
    gtk_tree_view_convert_bin_window_to_widget_coords(GTK_TREE_VIEW(tree_view), 
0, 0, &x, &y);

    cairo_save(cr);
    cairo_translate(cr, x, y);
    cairo_set_line_width(cr, 2.0);
    cairo_set_source_rgba(cr, 0.0, 0.0, 0.0, 1.0);
    
    gtk_tree_view_get_cell_area(GTK_TREE_VIEW(tree_view), path, column, &rect);
    cairo_rectangle(cr, rect.x+1, rect.y+1, rect.width-1, rect.height-1);
    cairo_stroke(cr);
    cairo_restore(cr);
    
    gtk_tree_path_free(path);

    return FALSE;
  }
int main(int argc, char *argv[])
  {
    gtk_init(&argc, &argv);

    GtkWidget *window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_window_set_title(GTK_WINDOW(window), "Stripes");
    gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
    gtk_window_set_default_size(GTK_WINDOW(window), 300, 300);
    gtk_widget_set_name(window, "main_window");
    g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);

    GtkTreeIter iter;
    GtkListStore *store=gtk_list_store_new(COLUMNS, G_TYPE_UINT, G_TYPE_STRING, 
G_TYPE_STRING, G_TYPE_STRING);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 0, PROGRAM, "Gedit", COLOR, "cyan", 
COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 1, PROGRAM, "Gimp", COLOR,  "yellow", 
COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 2, PROGRAM, "Inkscape", COLOR, "cyan", 
COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 3, PROGRAM, "Firefox", COLOR, 
"yellow", COLOR2, "fuchsia", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 4, PROGRAM, "Calculator", COLOR, 
"cyan", COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 5, PROGRAM, "Devhelp", COLOR, 
"yellow", COLOR2, "chartreuse", -1);

    GtkWidget *tree=gtk_tree_view_new_with_model(GTK_TREE_MODEL(store));
    gtk_widget_set_name(tree, "test_tree");
    gtk_widget_set_hexpand(tree, TRUE);
    gtk_widget_set_vexpand(tree, FALSE);
    g_object_set(tree, "activate-on-single-click", TRUE, NULL);

    GtkTreeSelection 
*selection=gtk_tree_view_get_selection(GTK_TREE_VIEW(tree));
    gtk_tree_selection_set_mode(selection, GTK_SELECTION_NONE);

    GtkCellRenderer *renderer1=gtk_cell_renderer_text_new();
    g_object_set(renderer1, "editable", FALSE, NULL);

    g_signal_connect(tree, "row-activated", G_CALLBACK(get_path), renderer1);
   
    //Bind the COLOR column to the "cell-background" property.
    GtkTreeViewColumn *column1 = gtk_tree_view_column_new_with_attributes("ID", 
renderer1, "text", ID, "cell-background", COLOR, NULL);
    gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column1);    
    GtkTreeViewColumn *column2 = 
gtk_tree_view_column_new_with_attributes("Program", renderer1, "text", PROGRAM, 
"cell-background", C

Re: Setting the scroll position of a GtkTextView in GtkScrolledWindow after render

[Andri Möll via gtk-app-devel-list]

Thanks, both!

While I'm not using GtkSourceView but GtkTextView, given the former 
depends on the latter, they're related. Anyway, turns out that 
GtkTextView indeed lays its text out asynchronously without any event to 
notify when it's done.


I did end up creating a GNOME Discourse topic, too, where I dug into 
gtktextview.c and described it at 
https://discourse.gnome.org/t/setting-the-scroll-position-of-a-gtktextview-in-gtkscrolledwindow-after-render/745.


Here's what I wrote for the sake of completeness:

Looking into 
https://gitlab.gnome.org/GNOME/gtk/blob/3.24.7/gtk/gtktextview.c#L4508, 
I can see that it does indeed lay 2000px out at once and does so with 
the priority `GTK_TEXT_VIEW_PRIORITY_VALIDATE` 
(https://gitlab.gnome.org/GNOME/gtk/blob/3.24.7/gtk/gtktextview.c#L4550).


I can also see `incremental_validate_callback` updates the adjustments 
every idle tick until text is laid out. I wonder if through listening 
to those updates I can retry setting the scroll position until it 
finally sticks. From my initial test check it at least seems the upper 
bound of the vertical adjustment is refined downwards. That permits 
differentiating incomplete layouts (where my set position doesn't 
stick) from an invalid scroll point (where my set position is really 
beyond the upper bound). I'll have to play around with this. Feels 
like the web where setting the scroll position is quite a challenge. :P
While setting the scroll in an idle callback is possible, it may be more 
robust to do so immediately after the adjustments are updated. Then 
again, both heavily depend on the implementation details of GtkTextView 
and may break anytime GtkTextView's text layout routines are changed.


Andri

On 4/8/19 3:57 PM, Stefan Salewski wrote:

May that be still this old bug:

https://picheta.me/articles/2013/08/gtk-plus--a-method-to-guarantee-scrolling.html

I think in 2015 I was concerned with that bug, and I asked here, no
response. So I had to apply the old fix mentioned in above link for my
Nim editor. Development of GtkSourceView is not very  active, so that
bug may still exist. And in case you have not noticed yet, the gtk-list
has basically moved to discourse forum.

On 4/8/19 4:56 PM, Reuben Rissler wrote:

On 04/08/2019 09:07 AM, Andri Möll via gtk-app-devel-list wrote:

Hey,

I can't figure out if it's me or something's amiss. I'm trying to set 
the scroll position after rendering a GtkTextView in a 
GtkScrolledWindow, but it's reset to a different value, if it works 
at all. I've so far tried to set the vertical adjustment value both 
after GtkScrolledWindow is mapped or its child (GtkTextView) 
size-allocated. When using a GtkListBox instead of a GtkTextView and 
setting the adjustment's value on "size-allocate", it works. No such 
luck with a GtkTextView, however.


The peculiar thing with the GtkTextView is, while the adjustment 
reports its upper bound to be, for example, 588 and its value 0, 
immediately after setting it to 493, it reports its value as 11. I 
figure "size-allocate" is still the wrong event to use here given the 
adjustment is in flux. What would the right path be to consistently 
set the scroll position after the first render, and later, after 
resetting the GtkTextView's buffer?


You probably are affected by the same problem as 
https://stackoverflow.com/questions/48934458/gtk-sourceview-scroll-to-mark-not-working.


Basically, you need to add a timeout (glib_idle_add or so) to allow 
all render calculations to be done.


Reuben

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Setting the scroll position of a GtkTextView in GtkScrolledWindow after render

[Reuben Rissler]

On 04/08/2019 09:07 AM, Andri Möll via gtk-app-devel-list wrote:

Hey,

I can't figure out if it's me or something's amiss. I'm trying to set 
the scroll position after rendering a GtkTextView in a 
GtkScrolledWindow, but it's reset to a different value, if it works at 
all. I've so far tried to set the vertical adjustment value both after 
GtkScrolledWindow is mapped or its child (GtkTextView) size-allocated. 
When using a GtkListBox instead of a GtkTextView and setting the 
adjustment's value on "size-allocate", it works. No such luck with a 
GtkTextView, however.


The peculiar thing with the GtkTextView is, while the adjustment 
reports its upper bound to be, for example, 588 and its value 0, 
immediately after setting it to 493, it reports its value as 11. I 
figure "size-allocate" is still the wrong event to use here given the 
adjustment is in flux. What would the right path be to consistently 
set the scroll position after the first render, and later, after 
resetting the GtkTextView's buffer?


You probably are affected by the same problem as 
https://stackoverflow.com/questions/48934458/gtk-sourceview-scroll-to-mark-not-working.


Basically, you need to add a timeout (glib_idle_add or so) to allow all 
render calculations to be done.


Reuben
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Setting the scroll position of a GtkTextView in GtkScrolledWindow after render

[Stefan Salewski]

On Mon, 2019-04-08 at 13:07 +, Andri Möll via gtk-app-devel-list
wrote:
> I can't figure out if it's me or something's amiss. I'm trying to
> set 
> the scroll position after rendering a GtkTextView

May that be still this old bug:

https://picheta.me/articles/2013/08/gtk-plus--a-method-to-guarantee-scr
olling.html

I think in 2015 I was concerned with that bug, and I asked here, no
response. So I had to apply the old fix mentioned in above link for my
Nim editor. Development of GtkSourceView is not very  active, so that
bug may still exist. And in case you have not noticed yet, the gtk-list 
has basically moved to discourse forum.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: TreeView - set border on individual cells

[Eric Cashon via gtk-app-devel-list]

I see gtk_cell_renderer_render() in the documentation and it has a cairo_t to 
draw with. I haven't tried to subclass from a treeview and override the 
rendering. Something I should probably figure out. Do you know of an example of 
doing something like this in C? Maybe I can put together a better example.

Eric
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: TreeView - set border on individual cells

[Emmanuele Bassi via gtk-app-devel-list]

On Sat, 6 Apr 2019 at 20:15,  wrote:


> The second cairo_t is used so that the rectangle can be lined up to the
> cell. If I use the cairo_t in the "draw" callback then the rectangle
> doesn't line up.
>

You're still using:

 1. the wrong window to draw on
 2. deprecated API
 3. a slow rendering path

In general, though drawing *on top* of widgets is not encouraged; you're
either going to break things inside GTK, or your own code will break
because GTK may change something in how widgets are drawn.

If you want to change how a cell is rendered, you can subclass the cell
renderer into your own class and override its own draw function; this way,
you're guaranteed you'll be rendering at the right position.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: TreeView - set border on individual cells

[Eric Cashon via gtk-app-devel-list]

 
Hi Emmanuele,

The second cairo_t is used so that the rectangle can be lined up to the cell. 
If I use the cairo_t in the "draw" callback then the rectangle doesn't line up. 

Eric

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: TreeView - set border on individual cells

[Emmanuele Bassi via gtk-app-devel-list]

On Sat, 6 Apr 2019 at 19:05, Eric Cashon via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:



> static gboolean draw_rectangle(GtkWidget *tree_view, cairo_t *cr, gpointer
> data)
>   {
> GtkTreePath *path=gtk_tree_path_new_from_indices(row_g, -1);
>
> g_print("Draw Rectangle %i %i\n", row_g, column_g);
> GdkWindow *win=gtk_tree_view_get_bin_window(GTK_TREE_VIEW(tree_view));
> cairo_t *cr2=gdk_cairo_create(win);
>

Don't ever do this.

There's a reason why you're getting a deprecation warning: you're already
getting a Cairo context from the "draw" signal; use that to draw. There's
no reason whatsoever to create a new Cairo context for a GdkWindow in GTK3.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: TreeView - set border on individual cells

[Eric Cashon via gtk-app-devel-list]

 
Hi Mike,

I gave what you said a try and it looks to work well enough. Then, how do you 
get a box around a selected cell. It seems to me if you let the built in 
renderer do it's thing and then get a cairo_t to just draw a rectangle after, 
it should work, right? OK, a bit of a hack but it works on my computer. 
GTK3.18. On a newer version of GTK I get a deprecated warning about 
gdk_cairo_create() but it still works.

Eric
   
//gcc -Wall stripe_list2.c -o stripe_list2 `pkg-config --cflags --libs gtk+-3.0`

#include
#include

enum
{
   ID,
   PROGRAM,
   COLOR,
   COLOR2,
   COLUMNS
};

static gint row_g=0;
static gint column_g=0;

static void get_path(GtkTreeView *tree_view, GtkTreePath *path, 
GtkTreeViewColumn *column, gpointer renderer1)
  {
    g_print("Get Path\n");
    gchar *string=gtk_tree_path_to_string(path);
    g_print("%s %s\n", string, gtk_tree_view_column_get_title(column));
    row_g=atoi(string);
    g_free(string);

    gint c1=0;
    if(g_strcmp0("ID", gtk_tree_view_column_get_title(column))==0) c1=2;
    if(g_strcmp0("Program", gtk_tree_view_column_get_title(column))==0) c1=3;
    column_g=c1-2;

    GtkTreeIter iter;
    GtkTreeModel *tree_model=gtk_tree_view_get_model(tree_view);
    gtk_tree_model_get_iter(tree_model, &iter, path);
    gtk_list_store_set(GTK_LIST_STORE(tree_model), &iter, c1, "SpringGreen", 
-1);
    gtk_widget_queue_draw(GTK_WIDGET(tree_view));
  }
static gboolean draw_rectangle(GtkWidget *tree_view, cairo_t *cr, gpointer data)
  {
    GtkTreePath *path=gtk_tree_path_new_from_indices(row_g, -1);

    g_print("Draw Rectangle %i %i\n", row_g, column_g);
    GdkWindow *win=gtk_tree_view_get_bin_window(GTK_TREE_VIEW(tree_view));
    cairo_t *cr2=gdk_cairo_create(win);
    GdkRectangle rect;
    cairo_set_line_width(cr2, 4.0);
    cairo_set_source_rgba(cr2, 1.0, 1.0, 1.0, 1.0);
    GtkTreeViewColumn 
*column=gtk_tree_view_get_column(GTK_TREE_VIEW(tree_view), column_g);
    gtk_tree_view_get_cell_area(GTK_TREE_VIEW(tree_view), path, column, &rect);
    cairo_rectangle(cr2, rect.x+2, rect.y+2, rect.width-2, rect.height-2);
    cairo_stroke(cr2);
 
    cairo_destroy(cr2);   
    gtk_tree_path_free(path);

    return TRUE;
  }
int main(int argc, char *argv[])
  {
    gtk_init(&argc, &argv);

    GtkWidget *window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_window_set_title(GTK_WINDOW(window), "Stripes");
    gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
    gtk_window_set_default_size(GTK_WINDOW(window), 300, 300);
    gtk_widget_set_name(window, "main_window");
    g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);

    GtkTreeIter iter;
    GtkListStore *store=gtk_list_store_new(COLUMNS, G_TYPE_UINT, G_TYPE_STRING, 
G_TYPE_STRING, G_TYPE_STRING);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 0, PROGRAM, "Gedit", COLOR, "cyan", 
COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 1, PROGRAM, "Gimp", COLOR,  "yellow", 
COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 2, PROGRAM, "Inkscape", COLOR, "cyan", 
COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 3, PROGRAM, "Firefox", COLOR, 
"yellow", COLOR2, "fuchsia", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 4, PROGRAM, "Calculator", COLOR, 
"cyan", COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 5, PROGRAM, "Devhelp", COLOR, 
"yellow", COLOR2, "chartreuse", -1);

    GtkWidget *tree=gtk_tree_view_new_with_model(GTK_TREE_MODEL(store));
    gtk_widget_set_name(tree, "test_tree");
    gtk_widget_set_hexpand(tree, TRUE);
    gtk_widget_set_vexpand(tree, FALSE);
    g_object_set(tree, "activate-on-single-click", TRUE, NULL);
    g_signal_connect_after(tree, "draw", G_CALLBACK(draw_rectangle), NULL);

    GtkTreeSelection 
*selection=gtk_tree_view_get_selection(GTK_TREE_VIEW(tree));
    gtk_tree_selection_set_mode(selection, GTK_SELECTION_NONE);

    GtkCellRenderer *renderer1=gtk_cell_renderer_text_new();
    g_object_set(renderer1, "editable", FALSE, NULL);

    g_signal_connect(tree, "row-activated", G_CALLBACK(get_path), renderer1);
   
    //Bind the COLOR column to the "cell-background" property.
    GtkTreeViewColumn *column1 = gtk_tree_view_column_new_with_attributes("ID", 
renderer1, "text", ID, "cell-background", COLOR, NULL);
    gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column1);    
    GtkTreeViewColumn *column2 = 
gtk_tree_view_column_new_with_attributes("Program", renderer1, "text", PROGRAM, 
"cell-background", COLOR2, NULL);
    gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column2);

    GtkWidget *label=gtk_label_new("Test Label");
    gtk_widget_set_name(label, "test_label");
    gtk_widget_set_hexpand(label, TRUE);
   
    GtkWidget *grid=gtk_

Re: TreeView - set border on individual cells

[Mike Martin via gtk-app-devel-list]

On Fri, 5 Apr 2019, 12:36 Mike Martin,  wrote:

> Update, I worked out how to get rid of highlight
>
> 1 treeview->set selection mode(none)
> 2 treeview->signal_connect(row_activated =>sub{
> Treeview->set_cursor_on_cell(path,column,cell,true)
> }
> )
>
> Not exact code, but this is process that worked for me
>
> Would still be useful if I could find out about borders though
>
>
>
> On Fri, 5 Apr 2019, 08:03 ,  wrote:
>
>> Am Donnerstag, den 04.04.2019, 23:04 +0100 schrieb Mike Martin via gtk-
>> app-devel-list:
>> > Is this possible?
>> >
>> > I did originally plan to have certain cells have a background colour
>> > to
>> > emphasize that there is a value to change. However as soon as the row
>> > is
>> > selected this is all wiped out by the highlight from selected row
>> >
>> > So is it possible to set the borders on a cell by cell basis, all I
>> > can
>> > find is overall properties for the trreview
>> >
>> > Mike
>>
>> I don't have a definitive answer for you. But just as a headsup: you
>> can inspect every GTK component's CSS properties interactively while
>> running the program. You can even live edit the properties.
>>
>> Here's a guide:
>>
>> https://blog.gtk.org/2017/04/05/the-gtk-inspector/
>>
>>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: TreeView - set border on individual cells

[Mike Martin]

Update, I worked out how to get rid of highlight

1 treeview->set selection mode(none)
2 treeview->signal_connect(row_activated =>sub{
Treeview->set_cursor_on_cell(path,column,cell,true)
}
)

Not exact code, but this is process that worked for me

Would still be useful if I could find out about borders though



On Fri, 5 Apr 2019, 08:03 ,  wrote:

> Am Donnerstag, den 04.04.2019, 23:04 +0100 schrieb Mike Martin via gtk-
> app-devel-list:
> > Is this possible?
> >
> > I did originally plan to have certain cells have a background colour
> > to
> > emphasize that there is a value to change. However as soon as the row
> > is
> > selected this is all wiped out by the highlight from selected row
> >
> > So is it possible to set the borders on a cell by cell basis, all I
> > can
> > find is overall properties for the trreview
> >
> > Mike
>
> I don't have a definitive answer for you. But just as a headsup: you
> can inspect every GTK component's CSS properties interactively while
> running the program. You can even live edit the properties.
>
> Here's a guide:
>
> https://blog.gtk.org/2017/04/05/the-gtk-inspector/
>
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: TreeView - set border on individual cells

[Tilo Villwock via gtk-app-devel-list]

Am Donnerstag, den 04.04.2019, 23:04 +0100 schrieb Mike Martin via gtk-
app-devel-list:
> Is this possible?
> 
> I did originally plan to have certain cells have a background colour
> to
> emphasize that there is a value to change. However as soon as the row
> is
> selected this is all wiped out by the highlight from selected row
> 
> So is it possible to set the borders on a cell by cell basis, all I
> can
> find is overall properties for the trreview
> 
> Mike

I don't have a definitive answer for you. But just as a headsup: you
can inspect every GTK component's CSS properties interactively while
running the program. You can even live edit the properties.

Here's a guide:

https://blog.gtk.org/2017/04/05/the-gtk-inspector/

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Problem with grids and items spanning more than one column

[Mike Martin]

I resolved it by applying
set_halign('start') to only the textview in the layout

Looks like some interaction between the textview and the multicolumn
liststore

On Wed, 3 Apr 2019 at 12:53, Reuben Rissler  wrote:

> On 04/02/2019 05:09 AM, Mike Martin via gtk-app-devel-list wrote:
> > I am using an embedded Gtk grid within a grid , which contains numerous
> > widgets
> > However if I have a widget that spans more than one column it messes up
> the
> > layout of all other widgets , which seem to position themseleves randomly
> > along the width of this widget, causing horribly jagged widget placement
> >
> > Has anyone had this and come up with a solution
> Could you post an example? Post the example inline, because attachments
> are scrubbed.
> >
> > Row 1 Liststore spanning multiple columns
> > Row 2 liststore spanning 1 column and 2 rows , textview , then two
> buttons
> > the textview should line up on the right with the liststore in row 1
> > ___
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Setting attributes per cell in treeview (list store)

[Eric Cashon via gtk-app-devel-list]

 
Hi Mike,

I think that you would need to set up individual color columns so that you can 
color individual cells in the table. For colors, “cell-background-rgba” gives 
better color control but “cell-background” with html basic colors might be 
simpler.

Eric
   
//gcc -Wall stripe_list1.c -o stripe_list1 `pkg-config --cflags --libs gtk+-3.0`

#include

enum
{
   ID,
   PROGRAM,
   COLOR,
   COLOR2,
   COLUMNS
};

int main(int argc, char *argv[])
  {
    gtk_init(&argc, &argv);

    GtkWidget *window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_window_set_title(GTK_WINDOW(window), "Stripes");
    gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
    gtk_window_set_default_size(GTK_WINDOW(window), 300, 300);
    gtk_widget_set_name(window, "main_window");
    g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);

    GtkTreeIter iter;
    GtkListStore *store=gtk_list_store_new(COLUMNS, G_TYPE_UINT, G_TYPE_STRING, 
G_TYPE_STRING, G_TYPE_STRING);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 0, PROGRAM, "Gedit", COLOR, "cyan", 
COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 1, PROGRAM, "Gimp", COLOR,  "yellow", 
COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 2, PROGRAM, "Inkscape", COLOR, "cyan", 
COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 3, PROGRAM, "Firefox", COLOR, 
"yellow", COLOR2, "fuchsia", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 4, PROGRAM, "Calculator", COLOR, 
"cyan", COLOR2, "chartreuse", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 5, PROGRAM, "Devhelp", COLOR, 
"yellow", COLOR2, "chartreuse", -1);

    GtkWidget *tree=gtk_tree_view_new_with_model(GTK_TREE_MODEL(store));
    gtk_widget_set_name(tree, "test_tree");
    gtk_widget_set_hexpand(tree, TRUE);
    gtk_widget_set_vexpand(tree, FALSE);

    GtkCellRenderer *renderer1=gtk_cell_renderer_text_new();
    g_object_set(renderer1, "editable", FALSE, NULL);
   
    //Bind the COLOR column to the "cell-background" property.
    GtkTreeViewColumn *column1 = gtk_tree_view_column_new_with_attributes("ID", 
renderer1, "text", ID, "cell-background", COLOR, NULL);
    gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column1);    
    GtkTreeViewColumn *column2 = 
gtk_tree_view_column_new_with_attributes("Program", renderer1, "text", PROGRAM, 
"cell-background", COLOR2, NULL);
    gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column2);

    GtkWidget *label=gtk_label_new("Test Label");
    gtk_widget_set_name(label, "test_label");
    gtk_widget_set_hexpand(label, TRUE);
   
    GtkWidget *grid=gtk_grid_new();
    gtk_grid_set_row_homogeneous(GTK_GRID(grid), TRUE);
    gtk_widget_set_name(grid, "test_grid");
    gtk_grid_attach(GTK_GRID(grid), tree, 0, 0, 1, 9);
    gtk_grid_attach(GTK_GRID(grid), label, 0, 10, 1, 1);

    gtk_container_add(GTK_CONTAINER(window), grid);

    GError *css_error=NULL;
    //gchar css_string[]="#main_window{background: purple;} 
#test_tree:selected{background: green;}";
    gchar css_string[]="#test_grid{background: purple;} #test_label{background: 
rgba(0, 255, 0, 255);} #test_tree{background: rgba(0, 55, 200, 255);} 
#test_tree:selected{background: red;}";
    GtkCssProvider *provider = gtk_css_provider_new();
    GdkDisplay *display = gdk_display_get_default();
    GdkScreen *screen = gdk_display_get_default_screen(display);
    gtk_style_context_add_provider_for_screen(screen, 
GTK_STYLE_PROVIDER(provider), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
    gtk_css_provider_load_from_data(provider, css_string, -1, &css_error);
    if(css_error!=NULL) g_print("CSS loader error %s\n", css_error->message);
    g_object_unref(provider);
   
    gtk_widget_show_all(window);
    gtk_main();
    return 0;   
  }


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Problem with grids and items spanning more than one column

[Reuben Rissler]

On 04/02/2019 05:09 AM, Mike Martin via gtk-app-devel-list wrote:

I am using an embedded Gtk grid within a grid , which contains numerous
widgets
However if I have a widget that spans more than one column it messes up the
layout of all other widgets , which seem to position themseleves randomly
along the width of this widget, causing horribly jagged widget placement

Has anyone had this and come up with a solution
Could you post an example? Post the example inline, because attachments 
are scrubbed.


Row 1 Liststore spanning multiple columns
Row 2 liststore spanning 1 column and 2 rows , textview , then two buttons
the textview should line up on the right with the liststore in row 1
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

[Adam Tauno Williams]

> The problem for me is clock. I tried Slack for a development project
> I'm  leading, but important messages got lost in the shuffle. Also,
> it wasjust another website to check, another interface to learn.

+1

> Email has been a good aggregator tool to save time--it is just one
> place I have to check. I suppose this discourse instance is OK if gtk
> is all you do, but how many different sites can I visit to keep up on
> what is...

+1

Is it easy in discourse to turn on email, 

Kinda;  its still pretty crumby, and a pain to respond to anything.

E-mail had a great run, solved almost every problem when used
correctly;  then people decided to try something else ... about every
~90 days it seems.   I'm just too tired of it all to learn yet-another-
messaging-platform.  #shrug

-- 
Adam Tauno Williams 
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Treeview (liststore) CSS question

[Mike Martin]

Resolved my issue, turns out I needed some voodoo with properties

$widgetpage{file_scroll}->set('propagate_natural_height','1');
 $widgetpage{file_scroll}->set_vexpand(0);

On Mon, 18 Mar 2019 at 16:01, Mike Martin  wrote:

> Is it possible to set different background for a treestore, with a
> liststore, for populated rows v blank area.
>
> ie: If I have a dynamic treeview I would like to have one background
> colour for the rows and another for the treestore where there are no rows
>
> The particular example has the following tree
> Grid,Notebook,grid,scrolledwindow,treeview
>
> thanks
> Mike
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

[Michael Torrie via gtk-app-devel-list]

Is the subject line of this thread a freudian slip?  We are definitely
moving toward discord, from the complaints!

On 03/21/2019 09:33 AM, Emmanuele Bassi via gtk-app-devel-list wrote:
> On Thu, 21 Mar 2019 at 02:28, Matthew A. Postiff via gtk-app-devel-list <
> gtk-app-devel-list@gnome.org> wrote:
> 
> 
>> Is it easy in discourse to turn on email, either daily digests or
>> "live"? Is there an rss feed that I can subscribe to? A quick howto
>> would be great.
>>
> 
> There is a link on how to use email with Discourse in the original email.

I'm just a lurker here following GTK+ out of personal interest, and the
traditional mailing list format fit that perfectly.  Discourse not so much.

After you mentioned mailing list mode in Discourse, I tried enabling
mailing list mode on another discourse board that I occasionally visit.
The results were not encouraging, unfortunately. Discourse does not
offer any kind of granularity when in mailing list mode; you get
everything on every sub forum across the entire Discourse instance.  The
only way to get granularity is to manually set email notifications on
particular topics, or automatic on topics one has participated in.  From
what I read the Discourse developers acknowledge that the mailing list
mode isn't really that great and never will be as there's just not a 1:1
mapping of how Discourse handles things with email.

Sadly for me, Discourse has all the same limitations and problems as any
other web forum I've used.  An awkward interface requiring logging in, a
lack of threaded messages (at least I can't see anything like threads in
Discourse), and yet another web site to have to visit.

Thanks for all your work on GTK+, Mr Bassi.  And to all the rest of the
GTK+ developers.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

[Emmanuele Bassi via gtk-app-devel-list]

On Thu, 21 Mar 2019 at 02:28, Matthew A. Postiff via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:


> Is it easy in discourse to turn on email, either daily digests or
> "live"? Is there an rss feed that I can subscribe to? A quick howto
> would be great.
>

There is a link on how to use email with Discourse in the original email.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

[Emmanuele Bassi via gtk-app-devel-list]

On Wed, 20 Mar 2019 at 23:59, David C. Rankin <
drankina...@suddenlinkmail.com> wrote:

> 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



> 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.


This is an increasingly out of date position. Maintaining email servers and
mailing lists is getting more and more complicated with every passing year.

Sending thousands of emails to thousands of people every single day, and
rewriting the envelope to make sure that the email comes from gnome.org, is
becoming undistinguishable from spam. While we managed to carve out some
exception using the established mechanisms, large ISPs are not really happy
about all this stuff.


> 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.
>

Splitting the community is not a great plan, so it's not going to happen.

You can interact with Discourse via email, which is the main reason why we
chose it as the platform to replace Mailman.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Treeview (liststore) CSS question

[Mike Martin via gtk-app-devel-list]

apologies I did resolve my issue , posted as wrong person

Resolved my issue, turns out I needed some voodoo with properties

$widgetpage{file_scroll}->set('propagate_natural_height','1');
 $widgetpage{file_scroll}->set_vexpand(0);

On Tue, 19 Mar 2019 at 18:53,  wrote:

>
> Hi Mike,
>
> Have you tried
>
> gtk_widget_set_vexpand(tree, FALSE);
>
> on the treeview? This might work to show a different background color on
> the unused space of the treeview.
>
> I don't know if this is of any help but also remember that you can set
> individual row colors in a treeview by having a color column. That way you
> can add some logic into what color the row is. Also, a selection color is
> easy to set with CSS.
>
> Eric
>
>
> //gcc -Wall stripe_list1.c -o stripe_list1 `pkg-config --cflags --libs
> gtk+-3.0`
>
> #include
>
> enum
> {
>ID,
>PROGRAM,
>COLOR,
>COLUMNS
> };
>
> int main(int argc, char *argv[])
>   {
> gtk_init(&argc, &argv);
>
> GtkWidget *window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
> gtk_window_set_title(GTK_WINDOW(window), "Stripes");
> gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
> gtk_window_set_default_size(GTK_WINDOW(window), 300, 300);
> gtk_widget_set_name(window, "main_window");
> g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
>
> GtkTreeIter iter;
> GtkListStore *store=gtk_list_store_new(COLUMNS, G_TYPE_UINT,
> G_TYPE_STRING, G_TYPE_STRING);
> gtk_list_store_append(store, &iter);
> gtk_list_store_set(store, &iter, ID, 0, PROGRAM, "Gedit", COLOR,
> "cyan",  -1);
> gtk_list_store_append(store, &iter);
> gtk_list_store_set(store, &iter, ID, 1, PROGRAM, "Gimp", COLOR,
> "yellow", -1);
> gtk_list_store_append(store, &iter);
> gtk_list_store_set(store, &iter, ID, 2, PROGRAM, "Inkscape", COLOR,
> "cyan", -1);
> gtk_list_store_append(store, &iter);
> gtk_list_store_set(store, &iter, ID, 3, PROGRAM, "Firefox", COLOR,
> "yellow", -1);
> gtk_list_store_append(store, &iter);
> gtk_list_store_set(store, &iter, ID, 4, PROGRAM, "Calculator", COLOR,
> "cyan", -1);
> gtk_list_store_append(store, &iter);
> gtk_list_store_set(store, &iter, ID, 5, PROGRAM, "Devhelp", COLOR,
> "yellow", -1);
>
> GtkWidget *tree=gtk_tree_view_new_with_model(GTK_TREE_MODEL(store));
> gtk_widget_set_name(tree, "tree_select");
> gtk_widget_set_hexpand(tree, TRUE);
> gtk_widget_set_vexpand(tree, FALSE);
>
> GtkCellRenderer *renderer1=gtk_cell_renderer_text_new();
> g_object_set(renderer1, "editable", FALSE, NULL);
>
> //Bind the COLOR column to the "cell-background" property.
> GtkTreeViewColumn *column1 =
> gtk_tree_view_column_new_with_attributes("ID", renderer1, "text", ID,
> "cell-background", COLOR, NULL);
> gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column1);
> GtkTreeViewColumn *column2 =
> gtk_tree_view_column_new_with_attributes("Program", renderer1, "text",
> PROGRAM, "cell-background", COLOR, NULL);
> gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column2);
>
> GtkWidget *grid=gtk_grid_new();
> gtk_grid_attach(GTK_GRID(grid), tree, 0, 0, 1, 1);
> gtk_container_add(GTK_CONTAINER(window), grid);
>
> GError *css_error=NULL;
> gchar css_string[]="#main_window{background: purple;}
> #tree_select:selected{background: green;}";
> GtkCssProvider *provider = gtk_css_provider_new();
> GdkDisplay *display = gdk_display_get_default();
> GdkScreen *screen = gdk_display_get_default_screen(display);
> gtk_style_context_add_provider_for_screen(screen,
> GTK_STYLE_PROVIDER(provider), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
> gtk_css_provider_load_from_data(provider, css_string, -1, &css_error);
> if(css_error!=NULL) g_print("CSS loader error %s\n",
> css_error->message);
> g_object_unref(provider);
>
> gtk_widget_show_all(window);
> gtk_main();
> return 0;
>   }
>
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

[Liam R E Quin]

On Wed, 2019-03-20 at 21:37 -0400, Reuben Rissler wrote:
> I originally thought I would participate on Discourse via email,
> then email got discouraged in favor of the web UI.
> 
> I don't have that much answers, and neither do I have a lot of 
> questions. Therefore I will just quietly fade away...

Yeah, it become one more in my 200 browser tabs, or, more to the point,
i won’t be looking at all. It’s fairly rare that i can help answer a
question here, and more likely off-list, so if Discord or Discourse
(not sure which) brings more users and more life, maybe it's worth it.

Liam (irc::ankh)


-- 
Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Web slave for vintage clipart http://www.fromoldbooks.org/

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

[Matthew A. Postiff via gtk-app-devel-list]

On 3/20/2019 9:37 PM, Reuben Rissler wrote:

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%.
I will probably not participate in Discourse. I posted on the 'hello' 
page just to get the feel of how Discourse works, but found nothing to 
make me a Discourse type of person. I check StackOverflow on a regular 
basis, but I get rewarded there. Discourse has no reward feature and I 
find it rather impersonal compared to email. The mailing list felt 
like a community, not a QA site. Exactly what Discourse does that bug 
reports on Gitlab and/or StackOverflow haven't covered, I am not sure. 
Fragmentation, maybe?


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.
I originally thought I would participate on Discourse via email, then 
email got discouraged in favor of the web UI.


I don't have that much answers, and neither do I have a lot of 
questions. Therefore I will just quietly fade away...


Reuben


The problem for me is clock. I tried Slack for a development project I'm 
leading, but important messages got lost in the shuffle. Also, it was 
just another website to check, another interface to learn.


Email has been a good aggregator tool to save time--it is just one place 
I have to check. I suppose this discourse instance is OK if gtk is all 
you do, but how many different sites can I visit to keep up on what is 
going on and to learn from what people are doing on all kinds of 
software? Today, people want you to check Slack and Github and 
Stackoverflow and Telegram and WhatsApp and email and this and that 
proprietary forum and a hundred blogs. It's overwhelming and can waste a 
lot of time. Oh yeah, and IRC channelsand what was that thing 
called...usenet newsgroups?...forgot about that.


I'm all for upgrades and using new tech, but in a way it is wearing me out!

Is it easy in discourse to turn on email, either daily digests or 
"live"? Is there an rss feed that I can subscribe to? A quick howto 
would be great.


Just my 2 cents. Thanks for reading,

Matt

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

[Reuben Rissler]

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%.
I will probably not participate in Discourse. I posted on the 'hello' 
page just to get the feel of how Discourse works, but found nothing to 
make me a Discourse type of person. I check StackOverflow on a regular 
basis, but I get rewarded there. Discourse has no reward feature and I 
find it rather impersonal compared to email. The mailing list felt like 
a community, not a QA site. Exactly what Discourse does that bug reports 
on Gitlab and/or StackOverflow haven't covered, I am not sure. 
Fragmentation, maybe?


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.
I originally thought I would participate on Discourse via email, then 
email got discouraged in favor of the web UI.


I don't have that much answers, and neither do I have a lot of 
questions. Therefore I will just quietly fade away...


Reuben


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

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

[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: Treeview (liststore) CSS question

[Eric Cashon via gtk-app-devel-list]

 
Hi Mike,

Have you tried 

gtk_widget_set_vexpand(tree, FALSE);

on the treeview? This might work to show a different background color on the 
unused space of the treeview.

I don't know if this is of any help but also remember that you can set 
individual row colors in a treeview by having a color column. That way you can 
add some logic into what color the row is. Also, a selection color is easy to 
set with CSS.

Eric

   
//gcc -Wall stripe_list1.c -o stripe_list1 `pkg-config --cflags --libs gtk+-3.0`

#include

enum
{
   ID,
   PROGRAM,
   COLOR,
   COLUMNS
};

int main(int argc, char *argv[])
  {
    gtk_init(&argc, &argv);

    GtkWidget *window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_window_set_title(GTK_WINDOW(window), "Stripes");
    gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
    gtk_window_set_default_size(GTK_WINDOW(window), 300, 300);
    gtk_widget_set_name(window, "main_window");
    g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);

    GtkTreeIter iter;
    GtkListStore *store=gtk_list_store_new(COLUMNS, G_TYPE_UINT, G_TYPE_STRING, 
G_TYPE_STRING);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 0, PROGRAM, "Gedit", COLOR, "cyan",  
-1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 1, PROGRAM, "Gimp", COLOR,  "yellow", 
-1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 2, PROGRAM, "Inkscape", COLOR, "cyan", 
-1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 3, PROGRAM, "Firefox", COLOR, 
"yellow", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 4, PROGRAM, "Calculator", COLOR, 
"cyan", -1);
    gtk_list_store_append(store, &iter);
    gtk_list_store_set(store, &iter, ID, 5, PROGRAM, "Devhelp", COLOR, 
"yellow", -1);

    GtkWidget *tree=gtk_tree_view_new_with_model(GTK_TREE_MODEL(store));
    gtk_widget_set_name(tree, "tree_select");
    gtk_widget_set_hexpand(tree, TRUE);
    gtk_widget_set_vexpand(tree, FALSE);

    GtkCellRenderer *renderer1=gtk_cell_renderer_text_new();
    g_object_set(renderer1, "editable", FALSE, NULL);
   
    //Bind the COLOR column to the "cell-background" property.
    GtkTreeViewColumn *column1 = gtk_tree_view_column_new_with_attributes("ID", 
renderer1, "text", ID, "cell-background", COLOR, NULL);
    gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column1);    
    GtkTreeViewColumn *column2 = 
gtk_tree_view_column_new_with_attributes("Program", renderer1, "text", PROGRAM, 
"cell-background", COLOR, NULL);
    gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column2);
   
    GtkWidget *grid=gtk_grid_new();
    gtk_grid_attach(GTK_GRID(grid), tree, 0, 0, 1, 1);
    gtk_container_add(GTK_CONTAINER(window), grid);

    GError *css_error=NULL;
    gchar css_string[]="#main_window{background: purple;} 
#tree_select:selected{background: green;}";
    GtkCssProvider *provider = gtk_css_provider_new();
    GdkDisplay *display = gdk_display_get_default();
    GdkScreen *screen = gdk_display_get_default_screen(display);
    gtk_style_context_add_provider_for_screen(screen, 
GTK_STYLE_PROVIDER(provider), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
    gtk_css_provider_load_from_data(provider, css_string, -1, &css_error);
    if(css_error!=NULL) g_print("CSS loader error %s\n", css_error->message);
    g_object_unref(provider);
   
    gtk_widget_show_all(window);
    gtk_main();
    return 0;   
  }

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Treeview (liststore) CSS question

[Mike Martin via gtk-app-devel-list]

Its not whether the row is empty, its whether it exists

On Mon, 18 Mar 2019 at 23:25, Daniel Kasak  wrote:

> On Tue, Mar 19, 2019 at 3:01 AM Mike Martin via gtk-app-devel-list <
> gtk-app-devel-list@gnome.org> wrote:
>
>> Is it possible to set different background for a treestore, with a
>> liststore, for populated rows v blank area.
>>
>> ie: If I have a dynamic treeview I would like to have one background
>> colour
>> for the rows and another for the treestore where there are no rows
>>
>> The particular example has the following tree
>> Grid,Notebook,grid,scrolledwindow,treeview
>>
>
> Use set_cell_data_func:
>
> https://developer.gnome.org/gtk3/stable/GtkTreeViewColumn.html#gtk-tree-view-column-set-cell-data-func
>
> You'd have to do this for every GtkTreeViewColumn you wanted to colour.
> Your callback would then fetch whatever value you want to use as a test (
> ie to test whether the row is 'empty' or not ), and set the renderer's
> "background' property to whatever colour you're after ( the callback get's
> passed the renderer ).
>
> Dan
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Treeview (liststore) CSS question

[Mike Martin]

Its not whether the row is empty, its whether it exists

On Mon, 18 Mar 2019 at 23:25, Daniel Kasak  wrote:

> On Tue, Mar 19, 2019 at 3:01 AM Mike Martin via gtk-app-devel-list <
> gtk-app-devel-list@gnome.org> wrote:
>
>> Is it possible to set different background for a treestore, with a
>> liststore, for populated rows v blank area.
>>
>> ie: If I have a dynamic treeview I would like to have one background
>> colour
>> for the rows and another for the treestore where there are no rows
>>
>> The particular example has the following tree
>> Grid,Notebook,grid,scrolledwindow,treeview
>>
>
> Use set_cell_data_func:
>
> https://developer.gnome.org/gtk3/stable/GtkTreeViewColumn.html#gtk-tree-view-column-set-cell-data-func
>
> You'd have to do this for every GtkTreeViewColumn you wanted to colour.
> Your callback would then fetch whatever value you want to use as a test (
> ie to test whether the row is 'empty' or not ), and set the renderer's
> "background' property to whatever colour you're after ( the callback get's
> passed the renderer ).
>
> Dan
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Correct way to deallocate an unix signal source

[Philip Withnall]

On Mon, 2019-03-18 at 14:38 +0100, Enrico Mioso wrote:
> Regarding the code, at exit I do the following:
> if (my_state->mainloop) {
>   g_main_loop_unref(my_state->mainloop);
>   my_state->mainloop = NULL;
> }
> 
> if (my_state->ctx) {
>   g_main_context_unref(my_state->ctx);
>   my_state->ctx = NULL;
> }

That looks fine. If you depend on GLib ≥ 2.34, you can instead do:

g_clear_pointer (&my_state->mainloop, g_main_loop_unref);
g_clear_pointer (&my_state->ctx, g_main_context_unref);

which is equivalent, but simplifies things a bit.

Philip
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Correct way to deallocate an unix signal source

[Enrico Mioso via gtk-app-devel-list]

That's great! Thanks! Yeah, I'll keep it on my mind. I currently choose to 
depend on GLib 2.58 to do something like:
g_source_set_callback(lctx->logwatcher, 
G_SOURCE_FUNC(agh_ubus_logstream_channel_io), lctx, NULL);

so there should be no issues in case.

Thank again!!
Enrico


On Mon, 18 Mar 2019, Philip Withnall wrote:


Date: Mon, 18 Mar 2019 14:51:25
From: Philip Withnall 
To: Enrico Mioso 
Cc: gtk-app-devel-list@gnome.org
Subject: Re: Correct way to deallocate an unix signal source

On Mon, 2019-03-18 at 14:38 +0100, Enrico Mioso wrote:

Regarding the code, at exit I do the following:
if (my_state->mainloop) {
g_main_loop_unref(my_state->mainloop);
my_state->mainloop = NULL;
}

if (my_state->ctx) {
g_main_context_unref(my_state->ctx);
my_state->ctx = NULL;
}


That looks fine. If you depend on GLib ≥ 2.34, you can instead do:

g_clear_pointer (&my_state->mainloop, g_main_loop_unref);
g_clear_pointer (&my_state->ctx, g_main_context_unref);

which is equivalent, but simplifies things a bit.

Philip


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Correct way to deallocate an unix signal source

[Enrico Mioso via gtk-app-devel-list]

Dear Philip,

thank you very much for your answer and patience. I will send a patch soon! :)

Regarding the code, at exit I do the following:
if (my_state->mainloop) {
g_main_loop_unref(my_state->mainloop);
my_state->mainloop = NULL;
}

if (my_state->ctx) {
g_main_context_unref(my_state->ctx);
my_state->ctx = NULL;
}


Thank you to all reading this,

Enrico

On Mon, 18 Mar 2019, Philip Withnall wrote:


Date: Mon, 18 Mar 2019 10:42:11
From: Philip Withnall 
To: Enrico Mioso , gtk-app-devel-list@gnome.org
Subject: Re: Correct way to deallocate an unix signal source

Hi,

On Thu, 2019-03-14 at 00:09 +0100, Enrico Mioso wrote:

I am facing an issue, where it seems I am not deallocating correctly
an UNIX signal source. I use
my_state->unix_signals_src = g_unix_signal_source_new(SIGINT);
g_source_set_callback(my_state->unix_signals_src, my_unix_signals_cb,
my_state, NULL);
my_state->unix_signals_src_tag = g_source_attach(my_state-

unix_signals_src, my_state->ctx);

g_source_unref(my_state->unix_signals_src);

then, on the exit path of my program, I have something like:

if (!my_state->sigint_received)
   g_source_destroy(my_state->unix_signals_src);

my_state->unix_signals_src_tag = 0;


This code seems fine to me, within the context you’ve provided. I
assume you’re also correctly unreffing the GMainContext at the end of
your program.


This output can be obtained even using the glib.supp file as found in
glib repository.
Looking at the file specified by valgrind, glib-unix.c, line 222, I
can see:
return _g_main_create_unix_signal_watch (signum);


That valgrind trace looks like an intentional one-time leak, since the
allocation is within pthread_create().

I’d be very happy to accept a patch to GLib to add this to glib.supp. ☺

Philip


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Treeview (liststore) CSS question

[Daniel Kasak via gtk-app-devel-list]

On Tue, Mar 19, 2019 at 3:01 AM Mike Martin via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Is it possible to set different background for a treestore, with a
> liststore, for populated rows v blank area.
>
> ie: If I have a dynamic treeview I would like to have one background colour
> for the rows and another for the treestore where there are no rows
>
> The particular example has the following tree
> Grid,Notebook,grid,scrolledwindow,treeview
>

Use set_cell_data_func:
https://developer.gnome.org/gtk3/stable/GtkTreeViewColumn.html#gtk-tree-view-column-set-cell-data-func

You'd have to do this for every GtkTreeViewColumn you wanted to colour.
Your callback would then fetch whatever value you want to use as a test (
ie to test whether the row is 'empty' or not ), and set the renderer's
"background' property to whatever colour you're after ( the callback get's
passed the renderer ).

Dan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Correct way to deallocate an unix signal source

[Philip Withnall]

Hi,

On Thu, 2019-03-14 at 00:09 +0100, Enrico Mioso wrote:
> I am facing an issue, where it seems I am not deallocating correctly
> an UNIX signal source. I use
> my_state->unix_signals_src = g_unix_signal_source_new(SIGINT);
> g_source_set_callback(my_state->unix_signals_src, my_unix_signals_cb,
> my_state, NULL);
> my_state->unix_signals_src_tag = g_source_attach(my_state-
> >unix_signals_src, my_state->ctx);
> g_source_unref(my_state->unix_signals_src);
> 
> then, on the exit path of my program, I have something like:
> 
> if (!my_state->sigint_received)
>g_source_destroy(my_state->unix_signals_src);
> 
> my_state->unix_signals_src_tag = 0;

This code seems fine to me, within the context you’ve provided. I
assume you’re also correctly unreffing the GMainContext at the end of
your program.

> This output can be obtained even using the glib.supp file as found in
> glib repository.
> Looking at the file specified by valgrind, glib-unix.c, line 222, I
> can see:
> return _g_main_create_unix_signal_watch (signum);

That valgrind trace looks like an intentional one-time leak, since the
allocation is within pthread_create().

I’d be very happy to accept a patch to GLib to add this to glib.supp. ☺

Philip
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Discourse instance

[Amirouche Boubekki]

On 2019-03-01 16:41, Emmanuele Bassi via gtk-list wrote:

Hi all;

after the discussion[1] last month, and the feedback received (both on
list and off), we decided to trial a Discourse instance on the GNOME
infrastructure.


Good idea, Discourse is a good free software.



The Platform/Core sub-category is meant to be used for all discussions
about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the
GNOME stack.


Where the instance hosted? Link?



Email is still allowed for both posting and replying, though I
strongly encourage people to give the web UI a try; it's really nice.

Feedback is very much appreciated.

Ciao,
 Emmanuele.

[1]:
https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html
[1]

--

https://www.bassi.io [2]
[@] ebassi [@gmail.com [3]]

Links:
--
[1] 
https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html

[2] https://www.bassi.io
[3] http://gmail.com

___
gtk-list mailing list
gtk-l...@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list


--
Amirouche ~ amz3 ~ http://www.hyperdev.fr
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Discourse instance

[Ernestas Kulik]

On Fri, 2019-03-01 at 15:41 +, Emmanuele Bassi via gtk-devel-list
wrote:
> Hi all;

Hey.

> after the discussion[1] last month, and the feedback received (both
> on list
> and off), we decided to trial a Discourse instance on the GNOME
> infrastructure.
> 
> The Platform/Core sub-category is meant to be used for all
> discussions
> about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the
> GNOME
> stack.
> 
> Email is still allowed for both posting and replying, though I
> strongly
> encourage people to give the web UI a try; it's really nice.
> 
> Feedback is very much appreciated.
> 
> Ciao,
>  Emmanuele.

I haven’t gone through the tutorial with discobot, but seems that 2FA
is not going to work with LDAP logins, right?

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Discourse instance

[Ryan Gonzalez via gtk-app-devel-list]

Since you forgot the link...

https://discourse.gnome.org/

--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/


On Fri, Mar 1, 2019, 9:42 AM Emmanuele Bassi via gtk-devel-list <
gtk-devel-l...@gnome.org> wrote:

> Hi all;
>
> after the discussion[1] last month, and the feedback received (both on
> list and off), we decided to trial a Discourse instance on the GNOME
> infrastructure.
>
> The Platform/Core sub-category is meant to be used for all discussions
> about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME
> stack.
>
> Email is still allowed for both posting and replying, though I strongly
> encourage people to give the web UI a try; it's really nice.
>
> Feedback is very much appreciated.
>
> Ciao,
>  Emmanuele.
>
> [1]:
> https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> ___
> gtk-devel-list mailing list
> gtk-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Changing font of GtkSourceView changes font of GtkSourceMap

[Mitko Haralanov via gtk-app-devel-list]

More information at:
https://gitlab.gnome.org/GNOME/gtksourceview/commit/0ae462ebc8eceb810f176a21792a63de4efe597b

On Mon, Mar 4, 2019 at 8:41 AM Mitko Haralanov  wrote:
>
> I haven't played with the FontMap but was thinking of going the route
> of using CSS. That, in itself, is a bit of a hassle as I can't seem to
> find a way to convert a PangoFontDescription to CSS but there are some
> patches that I found online that should help.
>
> On Fri, Mar 1, 2019 at 7:16 PM Reuben Rissler  wrote:
> >
> >
> >
> > > I filed the following bug:
> > > https://gitlab.gnome.org/GNOME/gtksourceview/issues/41, which promptly
> > > got close as "expected behavior". Apparently, you'd either have to use
> > > CSS or install a new font map for the GtkSourceMap.
> > Sure is disappointingly helpful.
> >
> > I can't figure out the connection code between the FontMap and the
> > SourceMap.
> > >
> >
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Changing font of GtkSourceView changes font of GtkSourceMap

[Mitko Haralanov via gtk-app-devel-list]

I haven't played with the FontMap but was thinking of going the route
of using CSS. That, in itself, is a bit of a hassle as I can't seem to
find a way to convert a PangoFontDescription to CSS but there are some
patches that I found online that should help.

On Fri, Mar 1, 2019 at 7:16 PM Reuben Rissler  wrote:
>
>
>
> > I filed the following bug:
> > https://gitlab.gnome.org/GNOME/gtksourceview/issues/41, which promptly
> > got close as "expected behavior". Apparently, you'd either have to use
> > CSS or install a new font map for the GtkSourceMap.
> Sure is disappointingly helpful.
>
> I can't figure out the connection code between the FontMap and the
> SourceMap.
> >
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Finding .desktop file and application info

[Osmo Antero via gtk-app-devel-list]

Hello,
Yes,  g_desktop_app_info_search() is exactly what I need.
I will test it later.

Thanks a lot for your help.
// Moma

tito-wolit  escreveu no dia segunda, 4/03/2019 à(s)
06:59:

>
>
> On 3/3/19 9:53 PM, Osmo Antero wrote:
> > Hello Tito,
> > Muito obrigado.
> > Thank you, the call with "kde4-" worked fine.
> >
> > However,  the "DesktopEntry" value from Amarok/DBus does not contain the
> "kde4" part.
> > Please see the MRIS2-spec:
> https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry
> > My application cannot guess that it must include the "kde4" to get a
> valid .desktop file.
> > I think g_desktop_app_info_new() should also browse all sub-directories,
> but is does not.
>
> Hi,
>
> GDesktopAppInfo *app_info =
> g_desktop_app_info_new("org.kde.amarok.desktop");
> if (app_info == NULL )
> app_info = g_desktop_app_info_new("kde-org.kde.amarok.desktop");
> if (app_info == NULL )
> app_info = g_desktop_app_info_new("kde2-org.kde.amarok.desktop");
> if (app_info == NULL )
> app_info = g_desktop_app_info_new("kde3-org.kde.amarok.desktop");
> if (app_info == NULL )
> app_info = g_desktop_app_info_new("kde4-org.kde.amarok.desktop");
> if (app_info == NULL )
> app_info = g_desktop_app_info_new("kde5-org.kde.amarok.desktop");
> else
> puts("can't find org.kde.amarok.desktop")
>
> BTW: debian does set only:
>
> XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share
>
> maybe g_desktop_app_info_search ("amarok");
> and then app_info = g_desktop_app_info_new(**strv);
>
> g_desktop_app_info_search ()
>
> gchar ***
> g_desktop_app_info_search (const gchar *search_string);
>
> Searches desktop files for ones that match search_string .
>
> The return value is an array of strvs. Each strv contains a list of
> applications that matched search_string with an equal score.
> The outer list is sorted by score so that the first strv contains the
> best-matching applications, and so on.
> The algorithm for determining matches is undefined and may change at any
> time.
>
> Ciao,
> Tito
>
> > One possible solutions is this:
> > The application should find the real location and path of
> "org.kde.amarok.desktop".
> > The "locate" command does the same thing.
> > My app cannot call "locate" directly because it depends on "sudo
> updatedb".
> > I will write my own routine that dives to usr/share/applications/ and
> its sub folders.
> > This is my best shot !
> >
> > Then the app can call:
> > GDesktopAppInfo *g_desktop_app_info_new_from_filename(const char
> *filename);
> >
> > My very old app is this: (the latest is v3.0.2)
> > https://launchpad.net/~audio-recorder
> >
> > Thanks,
> > Obrigado e boa noite.
> > // Moma
> > Portugal
> >
> >
> >
> >
> > tito-wolit via gtk-app-devel-list  gtk-app-devel-list@gnome.org>> escreveu no dia domingo, 3/03/2019 à(s)
> 19:42:
> >
> >
> >
> > On 3/3/19 6:36 PM, Osmo Antero via gtk-app-devel-list wrote:
> >  > Hello,
> >  > I have an application that uses g_desktop_app_info_new() function
> to
> >  > find GDesktopAppInfo.
> >  >
> >  > I just wonder why the g_desktop_app_info_new() FAILS to find the
> >  > GDesktopAppInfo if the .desktop file is in a sub directory
> >  > under usr/share/applications/.
> >  >
> >  > So this fails:
> >  > GDesktopAppInfo *app_info =
> g_desktop_app_info_new("org.kde.amarok.desktop")
> >
> > hi,
> > try:
> >
> > GDesktopAppInfo *app_info =
> g_desktop_app_info_new("kde4-org.kde.amarok.desktop")
> >
> > ciao,
> > Tito
> >
> >  > If the "org.kde.amarok.desktop" file is located in:
> >  > /usr/share/applications/kde4/org.kde.amarok.desktop
> >  > This is the default location of Amarok player.
> >  > ---
> >  > Then I move the file "org.kde.amarok.desktop"  to
> /usr/share/applications/.
> >  >
> >  > $ sudo mv /usr/share/applications/kde4/org.kde.amarok.desktop
> >  > /usr/share/applications/org.kde.amarok.desktop
> >  >
> >  > $ sudo updatedb
> >  > $ locate org.kde.amarok.desktop
> >  > /usr/share/applications/org.kde.amarok.desktop
> >  >
> >  > Now the call succeeds. It returns GDesktopAppInfo structure.
> >  > GDesktopAppInfo *app_info =
> g_desktop_app_info_new("org.kde.amarok.desktop")
> >  >
> >  > Something is wrong, because the manual says that the desktop file
> can stay
> >  > in a sub directory:
> >  >
> >  > 
> >  > g_desktop_app_info_new ()
> >  > GDesktopAppInfo * g_desktop_app_info_new (const char *desktop_id);
> >  >
> >  > Creates a new GDesktopAppInfo based on a desktop file id.
> >  >
> >  > A desktop file id is the basename of the desktop file, including
> the
> >  > .desktop extension. GIO is looking for a desktop file with this
> name in the
> >  > applications subdirectories of the XDG data directories (i.e. the
> >  > directories specified in the XDG

Re: Finding .desktop file and application info

[Osmo Antero via gtk-app-devel-list]

Btw:
Totem (GNOME `s Video Player) has very similar problem.
It «lies» about its .desktop file name. It says "totem" instead of
"org.gnome.Totem".
My app asks for it via DBus/MPRIS2 and gets wrong data.

$ locate -i totem | grep ".desktop"
/usr/share/applications/org.gnome.Totem.desktop

It is hard to co-operate on the Desktop when apps do stick to the damn
rules.

Boa noite,
  Moma

Osmo Antero  escreveu no dia domingo, 3/03/2019 à(s)
21:05:

>
> Osmo Antero
> 20:53 (há 11 minutos)
> para tito-wolit
>
> Hello Tito,
> Muito obrigado.
> Thank you, the call with "kde4-" worked fine.
>
> However,  the "DesktopEntry" value from Amarok/DBus does not contain the
> "kde4" part.
> Please see the MRIS2-spec:
> https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry
>
> My application cannot guess that it must include the "kde4" to get a valid
> .desktop file.
> I think g_desktop_app_info_new() should also browse all sub-directories,
> but is does not.
>
> One possible solutions is this:
> The application should find the real location and path of
> "org.kde.amarok.desktop".
> The "locate" command does the same thing.
> My app cannot call "locate" directly because it depends on "sudo
> updatedb".
> I will write my own routine that dives to usr/share/applications/ and its
> sub folders.
> This is my best shot !
>
> Then the app can call:
> GDesktopAppInfo *g_desktop_app_info_new_from_filename(const char
> *filename);
>
> My very old app is this: (the latest is v3.0.2)
> https://launchpad.net/~audio-recorder
>
> Thanks,
> Obrigado e boa noite.
> // Moma
> Portugal
>
> tito-wolit via gtk-app-devel-list  escreveu
> no dia domingo, 3/03/2019 à(s) 19:42:
>
>>
>>
>> On 3/3/19 6:36 PM, Osmo Antero via gtk-app-devel-list wrote:
>> > Hello,
>> > I have an application that uses g_desktop_app_info_new() function to
>> > find GDesktopAppInfo.
>> >
>> > I just wonder why the g_desktop_app_info_new() FAILS to find the
>> > GDesktopAppInfo if the .desktop file is in a sub directory
>> > under usr/share/applications/.
>> >
>> > So this fails:
>> > GDesktopAppInfo *app_info =
>> g_desktop_app_info_new("org.kde.amarok.desktop")
>>
>> hi,
>> try:
>>
>> GDesktopAppInfo *app_info =
>> g_desktop_app_info_new("kde4-org.kde.amarok.desktop")
>>
>> ciao,
>> Tito
>>
>> > If the "org.kde.amarok.desktop" file is located in:
>> > /usr/share/applications/kde4/org.kde.amarok.desktop
>> > This is the default location of Amarok player.
>> > ---
>> > Then I move the file "org.kde.amarok.desktop"  to
>> /usr/share/applications/.
>> >
>> > $ sudo mv /usr/share/applications/kde4/org.kde.amarok.desktop
>> > /usr/share/applications/org.kde.amarok.desktop
>> >
>> > $ sudo updatedb
>> > $ locate org.kde.amarok.desktop
>> > /usr/share/applications/org.kde.amarok.desktop
>> >
>> > Now the call succeeds. It returns GDesktopAppInfo structure.
>> > GDesktopAppInfo *app_info =
>> g_desktop_app_info_new("org.kde.amarok.desktop")
>> >
>> > Something is wrong, because the manual says that the desktop file can
>> stay
>> > in a sub directory:
>> >
>> > 
>> > g_desktop_app_info_new ()
>> > GDesktopAppInfo * g_desktop_app_info_new (const char *desktop_id);
>> >
>> > Creates a new GDesktopAppInfo based on a desktop file id.
>> >
>> > A desktop file id is the basename of the desktop file, including the
>> > .desktop extension. GIO is looking for a desktop file with this name in
>> the
>> > applications subdirectories of the XDG data directories (i.e. the
>> > directories specified in the XDG_DATA_HOME and XDG_DATA_DIRS environment
>> > variables). GIO also supports the prefix-to-subdirectory mapping that is
>> > described in the Menu Spec (i.e. a desktop id of kde-foo.desktop will
>> > match/usr/share/applications/kde/foo.desktop).
>> > 
>> >
>> > Just for info:
>> > My application gets the "org.kde.amarok.desktop" name from Amarok via
>> the
>> > MPRIS2 DBus-interface.  Please see "DesktopEntry" of
>> >
>> https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry
>> >
>> > Please educate me.
>> >
>> > Kindly
>> >Osmo Moma Antero
>> >Portugal
>> >
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>>
>
>
> --
> Sent from my PC, laptop or phone with Ubuntu-Linux.
>


-- 
Sent from my PC, laptop or phone with Ubuntu-Linux.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Finding .desktop file and application info

[Osmo Antero via gtk-app-devel-list]

Osmo Antero
20:53 (há 11 minutos)
para tito-wolit

Hello Tito,
Muito obrigado.
Thank you, the call with "kde4-" worked fine.

However,  the "DesktopEntry" value from Amarok/DBus does not contain the
"kde4" part.
Please see the MRIS2-spec:
https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry

My application cannot guess that it must include the "kde4" to get a valid
.desktop file.
I think g_desktop_app_info_new() should also browse all sub-directories,
but is does not.

One possible solutions is this:
The application should find the real location and path of
"org.kde.amarok.desktop".
The "locate" command does the same thing.
My app cannot call "locate" directly because it depends on "sudo updatedb".
I will write my own routine that dives to usr/share/applications/ and its
sub folders.
This is my best shot !

Then the app can call:
GDesktopAppInfo *g_desktop_app_info_new_from_filename(const char *filename);

My very old app is this: (the latest is v3.0.2)
https://launchpad.net/~audio-recorder

Thanks,
Obrigado e boa noite.
// Moma
Portugal

tito-wolit via gtk-app-devel-list  escreveu
no dia domingo, 3/03/2019 à(s) 19:42:

>
>
> On 3/3/19 6:36 PM, Osmo Antero via gtk-app-devel-list wrote:
> > Hello,
> > I have an application that uses g_desktop_app_info_new() function to
> > find GDesktopAppInfo.
> >
> > I just wonder why the g_desktop_app_info_new() FAILS to find the
> > GDesktopAppInfo if the .desktop file is in a sub directory
> > under usr/share/applications/.
> >
> > So this fails:
> > GDesktopAppInfo *app_info =
> g_desktop_app_info_new("org.kde.amarok.desktop")
>
> hi,
> try:
>
> GDesktopAppInfo *app_info =
> g_desktop_app_info_new("kde4-org.kde.amarok.desktop")
>
> ciao,
> Tito
>
> > If the "org.kde.amarok.desktop" file is located in:
> > /usr/share/applications/kde4/org.kde.amarok.desktop
> > This is the default location of Amarok player.
> > ---
> > Then I move the file "org.kde.amarok.desktop"  to
> /usr/share/applications/.
> >
> > $ sudo mv /usr/share/applications/kde4/org.kde.amarok.desktop
> > /usr/share/applications/org.kde.amarok.desktop
> >
> > $ sudo updatedb
> > $ locate org.kde.amarok.desktop
> > /usr/share/applications/org.kde.amarok.desktop
> >
> > Now the call succeeds. It returns GDesktopAppInfo structure.
> > GDesktopAppInfo *app_info =
> g_desktop_app_info_new("org.kde.amarok.desktop")
> >
> > Something is wrong, because the manual says that the desktop file can
> stay
> > in a sub directory:
> >
> > 
> > g_desktop_app_info_new ()
> > GDesktopAppInfo * g_desktop_app_info_new (const char *desktop_id);
> >
> > Creates a new GDesktopAppInfo based on a desktop file id.
> >
> > A desktop file id is the basename of the desktop file, including the
> > .desktop extension. GIO is looking for a desktop file with this name in
> the
> > applications subdirectories of the XDG data directories (i.e. the
> > directories specified in the XDG_DATA_HOME and XDG_DATA_DIRS environment
> > variables). GIO also supports the prefix-to-subdirectory mapping that is
> > described in the Menu Spec (i.e. a desktop id of kde-foo.desktop will
> > match/usr/share/applications/kde/foo.desktop).
> > 
> >
> > Just for info:
> > My application gets the "org.kde.amarok.desktop" name from Amarok via the
> > MPRIS2 DBus-interface.  Please see "DesktopEntry" of
> >
> https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry
> >
> > Please educate me.
> >
> > Kindly
> >Osmo Moma Antero
> >Portugal
> >
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>


-- 
Sent from my PC, laptop or phone with Ubuntu-Linux.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Finding .desktop file and application info

[tito-wolit via gtk-app-devel-list]

On 3/3/19 6:36 PM, Osmo Antero via gtk-app-devel-list wrote:

Hello,
I have an application that uses g_desktop_app_info_new() function to
find GDesktopAppInfo.

I just wonder why the g_desktop_app_info_new() FAILS to find the
GDesktopAppInfo if the .desktop file is in a sub directory
under usr/share/applications/.

So this fails:
GDesktopAppInfo *app_info = g_desktop_app_info_new("org.kde.amarok.desktop")


hi,
try:

GDesktopAppInfo *app_info = 
g_desktop_app_info_new("kde4-org.kde.amarok.desktop")

ciao,
Tito


If the "org.kde.amarok.desktop" file is located in:
/usr/share/applications/kde4/org.kde.amarok.desktop
This is the default location of Amarok player.
---
Then I move the file "org.kde.amarok.desktop"  to /usr/share/applications/.

$ sudo mv /usr/share/applications/kde4/org.kde.amarok.desktop
/usr/share/applications/org.kde.amarok.desktop

$ sudo updatedb
$ locate org.kde.amarok.desktop
/usr/share/applications/org.kde.amarok.desktop

Now the call succeeds. It returns GDesktopAppInfo structure.
GDesktopAppInfo *app_info = g_desktop_app_info_new("org.kde.amarok.desktop")

Something is wrong, because the manual says that the desktop file can stay
in a sub directory:


g_desktop_app_info_new ()
GDesktopAppInfo * g_desktop_app_info_new (const char *desktop_id);

Creates a new GDesktopAppInfo based on a desktop file id.

A desktop file id is the basename of the desktop file, including the
.desktop extension. GIO is looking for a desktop file with this name in the
applications subdirectories of the XDG data directories (i.e. the
directories specified in the XDG_DATA_HOME and XDG_DATA_DIRS environment
variables). GIO also supports the prefix-to-subdirectory mapping that is
described in the Menu Spec (i.e. a desktop id of kde-foo.desktop will
match/usr/share/applications/kde/foo.desktop).


Just for info:
My application gets the "org.kde.amarok.desktop" name from Amarok via the
MPRIS2 DBus-interface.  Please see "DesktopEntry" of
https://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Property:DesktopEntry

Please educate me.

Kindly
   Osmo Moma Antero
   Portugal


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: liststore issue 1 - iter points to wrong row after sort of column with cellrenderercombo

[Mike Martin via gtk-app-devel-list]

On Thu, 28 Feb 2019 at 18:05, Nicolas Soubeiran 
wrote:

> As you noticed "editing-started" is used at the beginning of editing a
> cell as the documentation states and is defined on the base class
> GtkCellRenderer:
>
> This signal gets emitted when a cell starts to be edited. The intended use
> of this signal is to do special setup on *editable* , e.g. adding a
> GtkEntryCompletion
>  or
> setting up additional columns in a GtkComboBox
> .
> https://developer.gnome.org/gtk3/stable/GtkCellRenderer.html#GtkCellRenderer-editing-started
>
> While "edited" is only available on  GtkCellRendererText and is mainly to
> be used for "simple" edition of text (called when user validates
> https://developer.gnome.org/gtk3/stable/GtkCellRendererText.html#GtkCellRendererText-edited
> In case you have a GtkCellRendererText the signals will be called like
> this:
> - editing-started
> if user validates
>- edited with new_text the string the user entered
> else (user cancel edition)
>- editing-canceled
> In all cases you only have the path of the edited row, since the
> cellrenderer does not "know" the model it is displaying : you have to pass
> it through the signal user_data (then you can build the iter and do your
> edition code)
>
>
> Le jeu. 28 févr. 2019 à 18:43, Mike Martin  a écrit :
>
>> Thanks
>> Though what I don't quite get is the difference in behaviour between
>> editing-started and edited (both using path to get the ITER)
>> On my particular scenario I use editing-started to setup some stuff so I
>> can use the iter created
>>
>> On Thu, 28 Feb 2019, 12:30 Nicolas Soubeiran via gtk-app-devel-list, <
>> gtk-app-devel-list@gnome.org> wrote:
>>
>>> Hello,
>>> after you sort the model, you shall consider that all iter and path
>>> previously stored are wrong :
>>> A path is a representation of the position of the row in the current case
>>> (which you can read by using gtk_tree_path_to_string).
>>>
>>> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-path-to-string
>>>
>>>  Iter are quite the same (but link to a particular GtkTreeModel), such as
>>> list::iterator of C++ STL : they are pointer to row that you can use to
>>> access to data or walk through the models.  You can make an iter from a
>>> path and a model :
>>>
>>> GtkTreePath *path;GtkTreeIter iter;
>>>
>>> GtkTreeModel* model;
>>>
>>> GtkListStore store = gtk_list_store_new(3, G_TYPE_INT,
>>> G_TYPE_STRING,G_TYPE_STRING)
>>>
>>> model = GTK_TREE_MODEL(store);
>>>
>>> path = gtk_tree_path_new_from_string
>>> <
>>> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-path-new-from-string
>>> >
>>> ("3"); // third rowgtk_tree_model_get_iter
>>> <
>>> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-model-get-iter
>>> >
>>> (model, &iter, path); // may be invalid (check return value)
>>>
>>>  If you really want to keep track of a particular row, you have to use
>>> GtkTreeRowReference
>>>
>>> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#GtkTreeRowReference
>>> But GTK will have to keep the reference up to date, so each time your
>>> model change (inserting, deleting, sorting...)
>>> GTK will triggered signal to update your GtkTreeRowReference which may
>>> cause an overhead in your application
>>>
>>> Hope this helps you to understand better the GtkTreeModel paradigm
>>> ___
>>> gtk-app-devel-list mailing list
>>> gtk-app-devel-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>>>
>>

What I suspect is happening is that once a column is sorted, the column is
resorted as soon as a change is made so path never points to the current
row. Though doesn't happen with a plain text renderer.

I have tested this with my code, and this is exactly what is happening

Before the edited function is called, the liststore is sorted again, so the
path string points to the row that is now at the previous position (ie:the
next row)

If the change made does not mean the row is sorted to a different position
then the same row is referenced, example
(where the first is value in column 0 and second is a fixed row indicator)
in both cases this the first row

Sort reorders the rows
/data/staging -> /data/staging2
/data/1staging   2

Sort does not reorder row
/data/staging -> /data/1staging
/data/1staging   1


Mike
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Changing font of GtkSourceView changes font of GtkSourceMap

[Reuben Rissler]

I filed the following bug:
https://gitlab.gnome.org/GNOME/gtksourceview/issues/41, which promptly
got close as "expected behavior". Apparently, you'd either have to use
CSS or install a new font map for the GtkSourceMap.

Sure is disappointingly helpful.

I can't figure out the connection code between the FontMap and the 
SourceMap.




___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Re: Changing font of GtkSourceView changes font of GtkSourceMap

[Mitko Haralanov via gtk-app-devel-list]

So, to close the loop...

I filed the following bug:
https://gitlab.gnome.org/GNOME/gtksourceview/issues/41, which promptly
got close as "expected behavior". Apparently, you'd either have to use
CSS or install a new font map for the GtkSourceMap.

On Fri, Mar 1, 2019 at 2:30 PM Reuben Rissler  wrote:
>
>
> I forgot to cc the list.
>
> On 03/01/2019 03:23 PM, Mitko Haralanov wrote:
> > Thanks for the example.
> >
> > I modified it to illustrate the behavior:
> It verily looks like a bug to me. I can't figure out a way to work
> around this either.
> >
> > import gi
> > gi.require_version('GtkSource', '3.0')
> > gi.require_version('Gtk', '3.0')
> > from gi.repository import Gtk, GtkSource, GObject, Pango
> >
> >
> > def set_font(button, view, map, tag):
> >  font_name = button.get_font_name()
> >  font = Pango.font_description_from_string(font_name)
> >  map_font = font.copy()
> >  map_font.set_size(1*Pango.SCALE)
> >  tag.set_property("font-desc", font)
> >  buffer = view.get_buffer()
> >  buffer.apply_tag(tag, buffer.get_start_iter(), buffer.get_end_iter())
> >  map.set_property("font-desc", map_font)
> >
> > class GUI:
> >  def __init__(self):
> >
> >  GObject.type_register(GtkSource.View)
> >  window = Gtk.Window()
> >  window.connect('destroy', self.on_window_destroy)
> >  box = Gtk.VBox()
> >  window.add(box)
> >  fontchooser = Gtk.FontButton()
> >  box.pack_start(fontchooser, False, True, 0)
> >  pane = Gtk.Paned(orientation=Gtk.Orientation.HORIZONTAL)
> >  box.pack_start(pane, True, True, 0)
> >  s_view = GtkSource.View()
> >  buffer = s_view.get_buffer()
> >  with open("/usr/share/doc/glade/README", 'r') as fd:
> >  buffer.set_text(fd.read())
> >  tag = buffer.create_tag("buffer-font")
> >  pane.pack1(s_view, True, False)
> >  s_map = GtkSource.Map()
> >  s_map.set_view(s_view)
> >  pane.pack2(s_map, True, False)
> >  fontchooser.connect("font-set", set_font, s_view, s_map, tag)
> >  window.show_all()
> >
> >  def on_window_destroy(self, window):
> >  Gtk.main_quit()
> >
> > if __name__ == "__main__":
> >  app = GUI()
> >  Gtk.main()
> >
> > Give it try and change the font of the view. You'll see that the font
> > of the map changes to the same font as the view, including *the same
> > size*.
> >
> > Thank you.
> >
> > On Thu, Feb 28, 2019 at 8:47 AM Reuben Rissler  wrote:
> >> I am not sure if this helps any:
> >>
> >>
> >> #!/usr/bin/env python
> >>
> >> import gi
> >> gi.require_version('GtkSource', '3.0')
> >> gi.require_version('Gtk', '3.0')
> >> from gi.repository import Gtk, GtkSource, GObject, Pango
> >>
> >> class GUI:
> >>   def __init__(self):
> >>
> >>   GObject.type_register(GtkSource.View)
> >>   window = Gtk.Window()
> >>   window.connect('destroy', self.on_window_destroy)
> >>   pane = Gtk.Paned(orientation = Gtk.Orientation.HORIZONTAL)
> >>   window.add(pane)
> >>   s_view = GtkSource.View()
> >>   pane.pack1(s_view)
> >>   s_map = GtkSource.Map()
> >>   s_map.set_view(s_view)
> >>   pane.pack2(s_map)
> >>   s_map.set_property('font-desc',
> >> Pango.font_description_from_string("Sans 3"))
> >>   window.show_all()
> >>
> >>   def on_window_destroy(self, window):
> >>   Gtk.main_quit()
> >>
> >>
> >> if __name__ == "__main__":
> >>   app = GUI()
> >>   Gtk.main()
> >>
> >>
> >>
> >> On 02/27/2019 12:36 PM, Mitko Haralanov via gtk-app-devel-list wrote:
> >>> Still looking for some help on this.
> >>>
> >>> Thank you.
> >>>
> >>> On Mon, Feb 11, 2019 at 9:11 AM Mitko Haralanov  
> >>> wrote:
>  Any help would be appreciated.
> 
>  Thank you.
> 
>  On Tue, Feb 5, 2019 at 2:28 PM Mitko Haralanov  
>  wrote:
> > Forwarding to gtk-app-devel since there appears to be much more 
> > activity related to GtkSourceView.
> >
> > -- Forwarded message -
> > From: Mitko Haralanov 
> > Date: Tue, Feb 5, 2019, 13:42
> > Subject: Changing font of GtkSourceView changes font of GtkSourceMap
> > To: 
> >
> >
> > I can't figure out how to change the font of GtkSourceView and
> > GtkSourceMap in a reasonable way.
> >
> > According to the documentation, the View and the Map should be using
> > the same font but with the Map using a font size of 1pt. To me this
> > implies that when I change the font of the TextBuffer of the View
> > using tags, I can copy the PangoFontDescription to a new object,
> > change the font size to 1pt and set the new PangoFontDescription as
> > the "font-desc" property of the Map.
> >
> > In practice, however, the Map always has the exact same font size as
> > the View. No matter what I do, I can't seem to change the font

Fwd: Re: Changing font of GtkSourceView changes font of GtkSourceMap

[Reuben Rissler]

I forgot to cc the list.

On 03/01/2019 03:23 PM, Mitko Haralanov wrote:

Thanks for the example.

I modified it to illustrate the behavior:

It verily looks like a bug to me. I can't figure out a way to work
around this either.


import gi
gi.require_version('GtkSource', '3.0')
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, GtkSource, GObject, Pango


def set_font(button, view, map, tag):
 font_name = button.get_font_name()
 font = Pango.font_description_from_string(font_name)
 map_font = font.copy()
 map_font.set_size(1*Pango.SCALE)
 tag.set_property("font-desc", font)
 buffer = view.get_buffer()
 buffer.apply_tag(tag, buffer.get_start_iter(), buffer.get_end_iter())
 map.set_property("font-desc", map_font)

class GUI:
 def __init__(self):

 GObject.type_register(GtkSource.View)
 window = Gtk.Window()
 window.connect('destroy', self.on_window_destroy)
 box = Gtk.VBox()
 window.add(box)
 fontchooser = Gtk.FontButton()
 box.pack_start(fontchooser, False, True, 0)
 pane = Gtk.Paned(orientation=Gtk.Orientation.HORIZONTAL)
 box.pack_start(pane, True, True, 0)
 s_view = GtkSource.View()
 buffer = s_view.get_buffer()
 with open("/usr/share/doc/glade/README", 'r') as fd:
 buffer.set_text(fd.read())
 tag = buffer.create_tag("buffer-font")
 pane.pack1(s_view, True, False)
 s_map = GtkSource.Map()
 s_map.set_view(s_view)
 pane.pack2(s_map, True, False)
 fontchooser.connect("font-set", set_font, s_view, s_map, tag)
 window.show_all()

 def on_window_destroy(self, window):
 Gtk.main_quit()

if __name__ == "__main__":
 app = GUI()
 Gtk.main()

Give it try and change the font of the view. You'll see that the font
of the map changes to the same font as the view, including *the same
size*.

Thank you.

On Thu, Feb 28, 2019 at 8:47 AM Reuben Rissler  wrote:

I am not sure if this helps any:


#!/usr/bin/env python

import gi
gi.require_version('GtkSource', '3.0')
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, GtkSource, GObject, Pango

class GUI:
  def __init__(self):

  GObject.type_register(GtkSource.View)
  window = Gtk.Window()
  window.connect('destroy', self.on_window_destroy)
  pane = Gtk.Paned(orientation = Gtk.Orientation.HORIZONTAL)
  window.add(pane)
  s_view = GtkSource.View()
  pane.pack1(s_view)
  s_map = GtkSource.Map()
  s_map.set_view(s_view)
  pane.pack2(s_map)
  s_map.set_property('font-desc',
Pango.font_description_from_string("Sans 3"))
  window.show_all()

  def on_window_destroy(self, window):
  Gtk.main_quit()


if __name__ == "__main__":
  app = GUI()
  Gtk.main()



On 02/27/2019 12:36 PM, Mitko Haralanov via gtk-app-devel-list wrote:

Still looking for some help on this.

Thank you.

On Mon, Feb 11, 2019 at 9:11 AM Mitko Haralanov  wrote:

Any help would be appreciated.

Thank you.

On Tue, Feb 5, 2019 at 2:28 PM Mitko Haralanov  wrote:

Forwarding to gtk-app-devel since there appears to be much more activity 
related to GtkSourceView.

-- Forwarded message -
From: Mitko Haralanov 
Date: Tue, Feb 5, 2019, 13:42
Subject: Changing font of GtkSourceView changes font of GtkSourceMap
To: 


I can't figure out how to change the font of GtkSourceView and
GtkSourceMap in a reasonable way.

According to the documentation, the View and the Map should be using
the same font but with the Map using a font size of 1pt. To me this
implies that when I change the font of the TextBuffer of the View
using tags, I can copy the PangoFontDescription to a new object,
change the font size to 1pt and set the new PangoFontDescription as
the "font-desc" property of the Map.

In practice, however, the Map always has the exact same font size as
the View. No matter what I do, I can't seem to change the font size of
the Map to 1pt, unless I change the font size of the View to 1pt, as
well.

What is the correct processes for changing the font size of both the
View and the Map?

Thank you,
- Mitko

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Changing font of GtkSourceView changes font of GtkSourceMap

[Mitko Haralanov via gtk-app-devel-list]

Thanks for the example.

I modified it to illustrate the behavior:

import gi
gi.require_version('GtkSource', '3.0')
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, GtkSource, GObject, Pango


def set_font(button, view, map, tag):
font_name = button.get_font_name()
font = Pango.font_description_from_string(font_name)
map_font = font.copy()
map_font.set_size(1*Pango.SCALE)
tag.set_property("font-desc", font)
buffer = view.get_buffer()
buffer.apply_tag(tag, buffer.get_start_iter(), buffer.get_end_iter())
map.set_property("font-desc", map_font)

class GUI:
def __init__(self):

GObject.type_register(GtkSource.View)
window = Gtk.Window()
window.connect('destroy', self.on_window_destroy)
box = Gtk.VBox()
window.add(box)
fontchooser = Gtk.FontButton()
box.pack_start(fontchooser, False, True, 0)
pane = Gtk.Paned(orientation=Gtk.Orientation.HORIZONTAL)
box.pack_start(pane, True, True, 0)
s_view = GtkSource.View()
buffer = s_view.get_buffer()
with open("/usr/share/doc/glade/README", 'r') as fd:
buffer.set_text(fd.read())
tag = buffer.create_tag("buffer-font")
pane.pack1(s_view, True, False)
s_map = GtkSource.Map()
s_map.set_view(s_view)
pane.pack2(s_map, True, False)
fontchooser.connect("font-set", set_font, s_view, s_map, tag)
window.show_all()

def on_window_destroy(self, window):
Gtk.main_quit()

if __name__ == "__main__":
app = GUI()
Gtk.main()

Give it try and change the font of the view. You'll see that the font
of the map changes to the same font as the view, including *the same
size*.

Thank you.

On Thu, Feb 28, 2019 at 8:47 AM Reuben Rissler  wrote:
>
> I am not sure if this helps any:
>
>
> #!/usr/bin/env python
>
> import gi
> gi.require_version('GtkSource', '3.0')
> gi.require_version('Gtk', '3.0')
> from gi.repository import Gtk, GtkSource, GObject, Pango
>
> class GUI:
>  def __init__(self):
>
>  GObject.type_register(GtkSource.View)
>  window = Gtk.Window()
>  window.connect('destroy', self.on_window_destroy)
>  pane = Gtk.Paned(orientation = Gtk.Orientation.HORIZONTAL)
>  window.add(pane)
>  s_view = GtkSource.View()
>  pane.pack1(s_view)
>  s_map = GtkSource.Map()
>  s_map.set_view(s_view)
>  pane.pack2(s_map)
>  s_map.set_property('font-desc',
> Pango.font_description_from_string("Sans 3"))
>  window.show_all()
>
>  def on_window_destroy(self, window):
>  Gtk.main_quit()
>
>
> if __name__ == "__main__":
>  app = GUI()
>  Gtk.main()
>
>
>
> On 02/27/2019 12:36 PM, Mitko Haralanov via gtk-app-devel-list wrote:
> > Still looking for some help on this.
> >
> > Thank you.
> >
> > On Mon, Feb 11, 2019 at 9:11 AM Mitko Haralanov  
> > wrote:
> >> Any help would be appreciated.
> >>
> >> Thank you.
> >>
> >> On Tue, Feb 5, 2019 at 2:28 PM Mitko Haralanov  
> >> wrote:
> >>> Forwarding to gtk-app-devel since there appears to be much more activity 
> >>> related to GtkSourceView.
> >>>
> >>> -- Forwarded message -
> >>> From: Mitko Haralanov 
> >>> Date: Tue, Feb 5, 2019, 13:42
> >>> Subject: Changing font of GtkSourceView changes font of GtkSourceMap
> >>> To: 
> >>>
> >>>
> >>> I can't figure out how to change the font of GtkSourceView and
> >>> GtkSourceMap in a reasonable way.
> >>>
> >>> According to the documentation, the View and the Map should be using
> >>> the same font but with the Map using a font size of 1pt. To me this
> >>> implies that when I change the font of the TextBuffer of the View
> >>> using tags, I can copy the PangoFontDescription to a new object,
> >>> change the font size to 1pt and set the new PangoFontDescription as
> >>> the "font-desc" property of the Map.
> >>>
> >>> In practice, however, the Map always has the exact same font size as
> >>> the View. No matter what I do, I can't seem to change the font size of
> >>> the Map to 1pt, unless I change the font size of the View to 1pt, as
> >>> well.
> >>>
> >>> What is the correct processes for changing the font size of both the
> >>> View and the Map?
> >>>
> >>> Thank you,
> >>> - Mitko
> > ___
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Discourse instance

[Emmanuele Bassi via gtk-app-devel-list]

Note: for those who prefer email, we've written down a handy guide on how
to use email with Discourse:

  https://discourse.gnome.org/t/interacting-with-discourse-via-email/46

Ciao,
 Emmanuele.

On Fri, 1 Mar 2019 at 15:50, Emmanuele Bassi  wrote:

> And, of course, I forgot the link: https://discourse.gnome.org
>
> Embarrassing.
>
> Ciao,
>  Emmanuele.
>
> On Fri, 1 Mar 2019 at 15:41, Emmanuele Bassi  wrote:
>
>> Hi all;
>>
>> after the discussion[1] last month, and the feedback received (both on
>> list and off), we decided to trial a Discourse instance on the GNOME
>> infrastructure.
>>
>> The Platform/Core sub-category is meant to be used for all discussions
>> about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME
>> stack.
>>
>> Email is still allowed for both posting and replying, though I strongly
>> encourage people to give the web UI a try; it's really nice.
>>
>> Feedback is very much appreciated.
>>
>> Ciao,
>>  Emmanuele.
>>
>> [1]:
>> https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>>
>
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Discourse instance

[Emmanuele Bassi via gtk-app-devel-list]

And, of course, I forgot the link: https://discourse.gnome.org

Embarrassing.

Ciao,
 Emmanuele.

On Fri, 1 Mar 2019 at 15:41, Emmanuele Bassi  wrote:

> Hi all;
>
> after the discussion[1] last month, and the feedback received (both on
> list and off), we decided to trial a Discourse instance on the GNOME
> infrastructure.
>
> The Platform/Core sub-category is meant to be used for all discussions
> about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME
> stack.
>
> Email is still allowed for both posting and replying, though I strongly
> encourage people to give the web UI a try; it's really nice.
>
> Feedback is very much appreciated.
>
> Ciao,
>  Emmanuele.
>
> [1]:
> https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: liststore issue 1 - iter points to wrong row after sort of column with cellrenderercombo

[Nicolas Soubeiran via gtk-app-devel-list]

As you noticed "editing-started" is used at the beginning of editing a cell
as the documentation states and is defined on the base class
GtkCellRenderer:

This signal gets emitted when a cell starts to be edited. The intended use
of this signal is to do special setup on *editable* , e.g. adding a
GtkEntryCompletion
 or
setting up additional columns in a GtkComboBox
.
https://developer.gnome.org/gtk3/stable/GtkCellRenderer.html#GtkCellRenderer-editing-started

While "edited" is only available on  GtkCellRendererText and is mainly to
be used for "simple" edition of text (called when user validates
https://developer.gnome.org/gtk3/stable/GtkCellRendererText.html#GtkCellRendererText-edited
In case you have a GtkCellRendererText the signals will be called like this:
- editing-started
if user validates
   - edited with new_text the string the user entered
else (user cancel edition)
   - editing-canceled
In all cases you only have the path of the edited row, since the
cellrenderer does not "know" the model it is displaying : you have to pass
it through the signal user_data (then you can build the iter and do your
edition code)


Le jeu. 28 févr. 2019 à 18:43, Mike Martin  a écrit :

> Thanks
> Though what I don't quite get is the difference in behaviour between
> editing-started and edited (both using path to get the ITER)
> On my particular scenario I use editing-started to setup some stuff so I
> can use the iter created
>
> On Thu, 28 Feb 2019, 12:30 Nicolas Soubeiran via gtk-app-devel-list, <
> gtk-app-devel-list@gnome.org> wrote:
>
>> Hello,
>> after you sort the model, you shall consider that all iter and path
>> previously stored are wrong :
>> A path is a representation of the position of the row in the current case
>> (which you can read by using gtk_tree_path_to_string).
>>
>> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-path-to-string
>>
>>  Iter are quite the same (but link to a particular GtkTreeModel), such as
>> list::iterator of C++ STL : they are pointer to row that you can use to
>> access to data or walk through the models.  You can make an iter from a
>> path and a model :
>>
>> GtkTreePath *path;GtkTreeIter iter;
>>
>> GtkTreeModel* model;
>>
>> GtkListStore store = gtk_list_store_new(3, G_TYPE_INT,
>> G_TYPE_STRING,G_TYPE_STRING)
>>
>> model = GTK_TREE_MODEL(store);
>>
>> path = gtk_tree_path_new_from_string
>> <
>> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-path-new-from-string
>> >
>> ("3"); // third rowgtk_tree_model_get_iter
>> <
>> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-model-get-iter
>> >
>> (model, &iter, path); // may be invalid (check return value)
>>
>>  If you really want to keep track of a particular row, you have to use
>> GtkTreeRowReference
>>
>> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#GtkTreeRowReference
>> But GTK will have to keep the reference up to date, so each time your
>> model change (inserting, deleting, sorting...)
>> GTK will triggered signal to update your GtkTreeRowReference which may
>> cause an overhead in your application
>>
>> Hope this helps you to understand better the GtkTreeModel paradigm
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>>
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: liststore issue 1 - iter points to wrong row after sort of column with cellrenderercombo

[Mike Martin via gtk-app-devel-list]

Thanks
Though what I don't quite get is the difference in behaviour between
editing-started and edited (both using path to get the ITER)
On my particular scenario I use editing-started to setup some stuff so I
can use the iter created

On Thu, 28 Feb 2019, 12:30 Nicolas Soubeiran via gtk-app-devel-list, <
gtk-app-devel-list@gnome.org> wrote:

> Hello,
> after you sort the model, you shall consider that all iter and path
> previously stored are wrong :
> A path is a representation of the position of the row in the current case
> (which you can read by using gtk_tree_path_to_string).
>
> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-path-to-string
>
>  Iter are quite the same (but link to a particular GtkTreeModel), such as
> list::iterator of C++ STL : they are pointer to row that you can use to
> access to data or walk through the models.  You can make an iter from a
> path and a model :
>
> GtkTreePath *path;GtkTreeIter iter;
>
> GtkTreeModel* model;
>
> GtkListStore store = gtk_list_store_new(3, G_TYPE_INT,
> G_TYPE_STRING,G_TYPE_STRING)
>
> model = GTK_TREE_MODEL(store);
>
> path = gtk_tree_path_new_from_string
> <
> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-path-new-from-string
> >
> ("3"); // third rowgtk_tree_model_get_iter
> <
> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-model-get-iter
> >
> (model, &iter, path); // may be invalid (check return value)
>
>  If you really want to keep track of a particular row, you have to use
> GtkTreeRowReference
>
> https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#GtkTreeRowReference
> But GTK will have to keep the reference up to date, so each time your
> model change (inserting, deleting, sorting...)
> GTK will triggered signal to update your GtkTreeRowReference which may
> cause an overhead in your application
>
> Hope this helps you to understand better the GtkTreeModel paradigm
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Changing font of GtkSourceView changes font of GtkSourceMap

[Reuben Rissler]

I am not sure if this helps any:


#!/usr/bin/env python

import gi
gi.require_version('GtkSource', '3.0')
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, GtkSource, GObject, Pango

class GUI:
    def __init__(self):

        GObject.type_register(GtkSource.View)
        window = Gtk.Window()
        window.connect('destroy', self.on_window_destroy)
        pane = Gtk.Paned(orientation = Gtk.Orientation.HORIZONTAL)
        window.add(pane)
        s_view = GtkSource.View()
        pane.pack1(s_view)
        s_map = GtkSource.Map()
        s_map.set_view(s_view)
        pane.pack2(s_map)
        s_map.set_property('font-desc', 
Pango.font_description_from_string("Sans 3"))

        window.show_all()

    def on_window_destroy(self, window):
        Gtk.main_quit()


if __name__ == "__main__":
    app = GUI()
    Gtk.main()



On 02/27/2019 12:36 PM, Mitko Haralanov via gtk-app-devel-list wrote:

Still looking for some help on this.

Thank you.

On Mon, Feb 11, 2019 at 9:11 AM Mitko Haralanov  wrote:

Any help would be appreciated.

Thank you.

On Tue, Feb 5, 2019 at 2:28 PM Mitko Haralanov  wrote:

Forwarding to gtk-app-devel since there appears to be much more activity 
related to GtkSourceView.

-- Forwarded message -
From: Mitko Haralanov 
Date: Tue, Feb 5, 2019, 13:42
Subject: Changing font of GtkSourceView changes font of GtkSourceMap
To: 


I can't figure out how to change the font of GtkSourceView and
GtkSourceMap in a reasonable way.

According to the documentation, the View and the Map should be using
the same font but with the Map using a font size of 1pt. To me this
implies that when I change the font of the TextBuffer of the View
using tags, I can copy the PangoFontDescription to a new object,
change the font size to 1pt and set the new PangoFontDescription as
the "font-desc" property of the Map.

In practice, however, the Map always has the exact same font size as
the View. No matter what I do, I can't seem to change the font size of
the Map to 1pt, unless I change the font size of the View to 1pt, as
well.

What is the correct processes for changing the font size of both the
View and the Map?

Thank you,
- Mitko

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: liststore issue 1 - iter points to wrong row after sort of column with cellrenderercombo

[Nicolas Soubeiran via gtk-app-devel-list]

Hello,
after you sort the model, you shall consider that all iter and path
previously stored are wrong :
A path is a representation of the position of the row in the current case
(which you can read by using gtk_tree_path_to_string).
https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-path-to-string

 Iter are quite the same (but link to a particular GtkTreeModel), such as
list::iterator of C++ STL : they are pointer to row that you can use to
access to data or walk through the models.  You can make an iter from a
path and a model :

GtkTreePath *path;GtkTreeIter iter;

GtkTreeModel* model;

GtkListStore store = gtk_list_store_new(3, G_TYPE_INT,
G_TYPE_STRING,G_TYPE_STRING)

model = GTK_TREE_MODEL(store);

path = gtk_tree_path_new_from_string

("3"); // third rowgtk_tree_model_get_iter

(model, &iter, path); // may be invalid (check return value)

 If you really want to keep track of a particular row, you have to use
GtkTreeRowReference
https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#GtkTreeRowReference
But GTK will have to keep the reference up to date, so each time your
model change (inserting, deleting, sorting...)
GTK will triggered signal to update your GtkTreeRowReference which may
cause an overhead in your application

Hope this helps you to understand better the GtkTreeModel paradigm
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Changing font of GtkSourceView changes font of GtkSourceMap

[Mitko Haralanov via gtk-app-devel-list]

Still looking for some help on this.

Thank you.

On Mon, Feb 11, 2019 at 9:11 AM Mitko Haralanov  wrote:
>
> Any help would be appreciated.
>
> Thank you.
>
> On Tue, Feb 5, 2019 at 2:28 PM Mitko Haralanov  wrote:
> >
> > Forwarding to gtk-app-devel since there appears to be much more activity 
> > related to GtkSourceView.
> >
> > -- Forwarded message -
> > From: Mitko Haralanov 
> > Date: Tue, Feb 5, 2019, 13:42
> > Subject: Changing font of GtkSourceView changes font of GtkSourceMap
> > To: 
> >
> >
> > I can't figure out how to change the font of GtkSourceView and
> > GtkSourceMap in a reasonable way.
> >
> > According to the documentation, the View and the Map should be using
> > the same font but with the Map using a font size of 1pt. To me this
> > implies that when I change the font of the TextBuffer of the View
> > using tags, I can copy the PangoFontDescription to a new object,
> > change the font size to 1pt and set the new PangoFontDescription as
> > the "font-desc" property of the Map.
> >
> > In practice, however, the Map always has the exact same font size as
> > the View. No matter what I do, I can't seem to change the font size of
> > the Map to 1pt, unless I change the font size of the View to 1pt, as
> > well.
> >
> > What is the correct processes for changing the font size of both the
> > View and the Map?
> >
> > Thank you,
> > - Mitko
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: liststore issue 2 - which 'path' comes from signal

[Reuben Rissler]

On 02/27/2019 06:51 AM, Mike Martin via gtk-app-devel-list wrote:

according to the docs the path reference is

edited signal = path
editing-started = path

These above two look like something a treeview uses

changed = path_string
And this one I assume to be coming from a CellRendererCombo? So this 
would actually be describing the combo renderer's model path. Which is 
not necessarily the same as the TreeView model.


which I thought meant that path would be a treepath (ie: an object) and
path_string would be a reference to the row (an integer in the case of a
simple liststore)

no, paths are not objects, they are integers telling which row was affected


However in all three cases the value is the same ie: an integer, not an
object

Can anyone clarify this

That is what I found.


thanks

Mike
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: liststore issue 1 - iter points to wrong row after sort of column with cellrenderercombo

[Reuben Rissler]

On 02/27/2019 06:46 AM, Mike Martin via gtk-app-devel-list wrote:

I have come across an issue where the iter points to the wrong row on
edited signal after sorting the column (via clicking header).

This only happens with edited signal and not editing-started (which is
correct)

I don't understand all the nuances, but I learned to get an iter from 
the path and then change the model according to the iter. It seems after 
the model changes (with sort enabled), all the paths are wrong but the 
iters seem to be right.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: textview buffers and primary clipboard issue

[Doug McCasland]

Well I played with some tag table calls and now things work correctly.

Previously I was using:
|  gtk_text_view_new()

which creates a TextView and a buffer, then 
|  buf[i] = gtk_text_view_get_buffer()

to get the buffer object.  Then for each new tag in each buffer: 

|  gtk_text_buffer_create_tag(buf[i],)

That was very inefficient, since I wanted each buffer to have 
all the same tags.  So I re-worked the code so it only created 
the tags once in the first buffer and then I created subsequent 
buffers using that tag set.  Here are the basics of what I did:
|  GtkTextTagTable *main_tag_table;
| tv[0] = gtk_text_view_new();
| buf[0] = gtk_text_view_get_buffer(GTK_TEXT_VIEW(tv[0]);
| main_tag_table = gtk_text_buffer_get_tag_table(buf[0]);

For subsequent buffers:
|  buf[i] = gtk_text_buffer_new(main_tag_table);
| tv[i] = gtk_text_view_new_with_buffer(buf[i]);

Then create new tags only in the first buffer:
|  gtk_text_buffer_create_tag(buf[0], ..., );

I still called:
|  gtk_text_buffer_register_serialize_tagset()

and
|  gtk_text_buffer_register_deserialize_tagset()

in each buffer.

So there's something about not sharing that tag table that makes 
middle-button paste act strangely.  Might have been a GTK bug, 
or some part of my code (always more likely ☺).  However, the 
Primary clipboard after selecting text that is followed by an 
image (in a TextView buffer, that is) still has all that unselected 
image data.  But somehow it doesn't get pasted by middle-button 
click, so that's odd.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: textview buffers and primary clipboard issue

[Doug McCasland]

Some add'l info:

This is using GTK 3.24 in Lubuntu 18.10.

When I select with the mouse and use middle-click to paste in 
the *same* buffer -- with an image below the text, as described 
above -- it does work normally.  So in that case, even though 
the Primary clipboard incorrectly contains non-selected image 
data, TextView is not pasting all of what's on the Primary clipboard, 
apparently.  

--
Doug McCasland, San Francisco  
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Using GTK in proprietary software

[Fontana Nicola]

Il giorno ven, 15/02/2019 alle 10.26 +0100, Jean-Dominique Frattini ha scritto:
> And what if the final program is statically linked with Gtk+ (ie on Windows
> with mingw32) ?

Citing https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic:

"If you statically link against an LGPLed library, you must also
provide your application in an object (not necessarily source)
format, so that a user has the opportunity to modify the library and
relink the application."

On the technical side I heard someone successfully used static linking
with GTK+ but I personally never see such an application. I do not use
windows though.

Ciao.
-- 
Nicola


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Force liststore to update when leaving treeview

[Reuben Rissler]

On 02/12/2019 11:32 AM, Mike Martin via gtk-app-devel-list wrote:

Is this possible?
Yes. I did this a while back, but would need to find an archive to 
provide you with exact code.


I have a (for example) a grid which contains
Various action widgets
And a Treeview based on a liststore

Is there any way to make sure that the changes made to a cell in the
liststore are "committed" if I click on one of the other widgets

I cant find anything to do this and if I leave the cell without pressing
enter or clicking on another cell, all changes are lost
Connect to the GtkCellRenderer "editing-started" signal. In that 
callback, you will have an GtkEntry (GtkCellEditable) object. Connect to 
the Entry's "changed" signal and keep a permanent string around with the 
text the user is typing. Also preserve the path and column being edited 
(obtained with "editing-started").


Also connect to GtkCellRenderer "editing-canceled" signal. In this 
callback, use the path, column, and text you retained from 
"editing-started", and update the ListStore.


thanks

Mike
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Scrolling to a line in GtkTextView

[Reuben Rissler]

On 02/12/2019 12:47 PM, Mitko Haralanov via gtk-app-devel-list wrote:

Hi,

In my application, I would like to have a GtkTextView be scrolled to a
particular line after the GtkTextBuffer is loaded.
This was already discussed 
https://stackoverflow.com/questions/48934458/gtk-sourceview-scroll-to-mark-not-working.


Basically, the GUI calculations are not done and the lines aren't 
calculated, therefore you need to scroll after the GUI rendering is 
finished. Use idle_add or timeout_add.


According to the documentation, I can use gtk_text_view_scroll_to_mark() in
order to reliably scroll to the desired line after the line height
computation has been completed. In practice that doesn't work reliably.
Below is the code snippet that I am using:


while (delay++ < 100)
g_main_context_iteration(NULL, FALSE);
debug("Scrolling to line: %lu", lineno);
gtk_text_buffer_get_iter_at_line(GTK_TEXT_BUFFER(priv->sourceBuf),
&iter, (gint)(lineno - 1));
debug("Line: %d, offset: %d", gtk_text_iter_get_line(&iter),
   gtk_text_iter_get_offset(&iter));
gtk_text_buffer_place_cursor(GTK_TEXT_BUFFER(priv->sourceBuf), &iter);
mark = gtk_text_buffer_get_mark(GTK_TEXT_BUFFER(priv->sourceBuf),
"result-view-search");
gtk_text_buffer_move_mark(GTK_TEXT_BUFFER(priv->sourceBuf), mark,
   &iter);
gtk_text_view_scroll_to_mark(GTK_TEXT_VIEW(priv->sourceView), mark, 0.0,
  TRUE, 0.0, 0.5);

What I am noticing is that the reliability of this highly depends on the
line number to which I want to scroll and the length of the busy loop in
the beginning - the higher the line number, the longer the busy loop needs
to be in order to reliably scroll to that line.

If the busy loop is not long enough, the text view does scroll but not the
correct line.

What is the proper way to correctly and reliably scroll a GtkTextView to a
certain line?

Thank you,
Mitko
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Force liststore to update when leaving treeview

[Reuben Rissler]

On 02/12/2019 12:25 PM, Mitko Haralanov via gtk-app-devel-list wrote:

One idea is to hook the widget to the "leave-notify-event", which will
be triggered when the mouse leaves the widget.
Have you used this with a GtkTreeView? I mean, actually implemented what 
Mike Martin is requesting?


On Tue, Feb 12, 2019 at 8:32 AM Mike Martin via gtk-app-devel-list
 wrote:

Is this possible?

I have a (for example) a grid which contains
Various action widgets
And a Treeview based on a liststore

Is there any way to make sure that the changes made to a cell in the
liststore are "committed" if I click on one of the other widgets

I cant find anything to do this and if I leave the cell without pressing
enter or clicking on another cell, all changes are lost

thanks

Mike
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Force liststore to update when leaving treeview

[Mitko Haralanov via gtk-app-devel-list]

One idea is to hook the widget to the "leave-notify-event", which will
be triggered when the mouse leaves the widget.

On Tue, Feb 12, 2019 at 8:32 AM Mike Martin via gtk-app-devel-list
 wrote:
>
> Is this possible?
>
> I have a (for example) a grid which contains
> Various action widgets
> And a Treeview based on a liststore
>
> Is there any way to make sure that the changes made to a cell in the
> liststore are "committed" if I click on one of the other widgets
>
> I cant find anything to do this and if I leave the cell without pressing
> enter or clicking on another cell, all changes are lost
>
> thanks
>
> Mike
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Changing font of GtkSourceView changes font of GtkSourceMap

[Mitko Haralanov via gtk-app-devel-list]

Any help would be appreciated.

Thank you.

On Tue, Feb 5, 2019 at 2:28 PM Mitko Haralanov  wrote:
>
> Forwarding to gtk-app-devel since there appears to be much more activity 
> related to GtkSourceView.
>
> -- Forwarded message -
> From: Mitko Haralanov 
> Date: Tue, Feb 5, 2019, 13:42
> Subject: Changing font of GtkSourceView changes font of GtkSourceMap
> To: 
>
>
> I can't figure out how to change the font of GtkSourceView and
> GtkSourceMap in a reasonable way.
>
> According to the documentation, the View and the Map should be using
> the same font but with the Map using a font size of 1pt. To me this
> implies that when I change the font of the TextBuffer of the View
> using tags, I can copy the PangoFontDescription to a new object,
> change the font size to 1pt and set the new PangoFontDescription as
> the "font-desc" property of the Map.
>
> In practice, however, the Map always has the exact same font size as
> the View. No matter what I do, I can't seem to change the font size of
> the Map to 1pt, unless I change the font size of the View to 1pt, as
> well.
>
> What is the correct processes for changing the font size of both the
> View and the Map?
>
> Thank you,
> - Mitko
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Using GTK in proprietary software

[Fontana Nicola]

Il giorno ven, 08/02/2019 alle 18.45 +, asrs ha scritto:
> Dear Nicola,
> 
> Thankyou for your informative response,
> I would like to know if I may use "GTK" as a suffix in the name of my
> commercial product.

There already are plenty of applications with GTK in their names, see
e.g.:

https://www.linux-apps.com/search/projectSearchText/gtk

All that said, IANAL. Anyway I really doubt you will find a name not
already picked up by some project and IMO this is just bikeshedding.

Ciao.
-- 
Nicola


___
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

[Tilo Villwock via gtk-app-devel-list]

Am Mittwoch, den 06.02.2019, 12:46 +0100 schrieb Emmanuele Bassi via
gtk-app-devel-list:
> [Cross-posted to various relevant mailing lists; please, reply to
> gtk-devel-list]
> 
> As part of an attempt at making GTK more friendly to newcomers, I and
> other
> core developers were thinking of moving the mailing lists from the
> current
> mailman installation to Discourse:
> 
>   https://discourse.org/
> 
> Possibly still hosted on GNOME infrastructure, depending on the
> requirements for our sysadmins.
> 
> The GTK project would have various sub-topics, mostly around
> development
> with and of GTK. Having a better archive search, a better moderation
> system, and a decent web UI are the major selling points for
> switching to
> Discourse. The fact that the project is also open source is neatly
> aligned
> with our values.
> 
> 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.

I'd very much welcome such a change. Being able to inline screenshots
would greatly improve discussions around certain problems IMHO.

--Tilo

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Using GTK in proprietary software

[Fontana Nicola]

Il giorno mer, 06/02/2019 alle 16.25 +, asrs via gtk-app-devel-list ha
scritto:
> Dear GTK developers,
> 
> I want to redistrbute GTK (and its LGPL) unabridged with proprietary software,
> to make a graphical application.

Ciao,

if you use shared linking (AFAIK the only way officially supported) you
wont have any problem. Of course you must still comply with the other
terms, e.g. you cannot sneakily modify the GTK+ source code:
https://gitlab.gnome.org/GNOME/gtk/blob/master/COPYING

> Additionally my program will make calls to routines in GTK objects,
> ...

I do not understand the question: is there any other reason one should
link to a library?

Ciao.
-- 
Nicola


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Migrating away from GtkStock stuff

[Emmanuele Bassi via gtk-app-devel-list]

On Thu, 7 Feb 2019 at 13:30, Gabriele Greco 
wrote:


> (test:77229): Gtk-WARNING **: 14:28:49.162: Could not find the icon
> 'help-about'. The 'hicolor' theme
> was not found either, perhaps you need to install it.
> You can get a copy from:
> http://icon-theme.freedesktop.org/releases
>
> (test:77229): Gtk-WARNING **: 14:28:49.162: Error loading theme icon
> 'help-about' for stock: Icon 'help-about' not present in theme Adwaita
>

GTK uses `help-about` internally, because it doesn't use stock icons.

You need an icon theme for the icons GTK uses, currently, though we're
thinking of shipping a cut down version of Adwaita inside GTK for that
reason: https://gitlab.gnome.org/GNOME/gtk/issues/1235

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Migrating away from GtkStock stuff

[Gabriele Greco via gtk-app-devel-list]

>
>
>> If you're using `edit-find` or `document-save` then you're using a named
> icon from the icon theme, not the stock identifier.
>
> For those, you'll have to ship an icon theme like Adwaita.
>

That's really strange, it seems there is something in my gtk stack that
converts GTK_STOCK_XXX to the icon theme equivalent, anyway they should
show since I've the Adwaita theme installed.

See the following example to see how gtk-about became help-about

#include 

int main(int argc, char *argv[]) {
gtk_init(&argc, &argv);

GtkWidget *w = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_container_add(GTK_CONTAINER(w),
gtk_image_new_from_stock(GTK_STOCK_ABOUT, GTK_ICON_SIZE_LARGE_TOOLBAR));
gtk_widget_show_all(w);
gtk_main();
}


shelob-2 $ grep -r GTK_STOCK_ABOUT /usr/local/gtk/include/gtk-3.0/gtk
/usr/local/gtk/include/gtk-3.0/gtk/deprecated/gtkstock.h: * GTK_STOCK_ABOUT:
/usr/local/gtk/include/gtk-3.0/gtk/deprecated/gtkstock.h:#define
GTK_STOCK_ABOUT((GtkStock)"gtk-about")

shelob-2 $ g++ -o test test.c `pkg-config gtk+-3.0 --cflags --libs`
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior
is deprecated [-Wdeprecated]
test.c:8:34: warning: 'GtkStock' is deprecated [-Wdeprecated-declarations]
gtk_image_new_from_stock(GTK_STOCK_ABOUT,
GTK_ICON_SIZE_LARGE_TOOLBAR));
 ^
/usr/local/gtk/include/gtk-3.0/gtk/deprecated/gtkstock.h:123:38: note:
expanded from macro 'GTK_STOCK_ABOUT'
#define GTK_STOCK_ABOUT((GtkStock)"gtk-about")
 ^
/usr/local/gtk/include/gtk-3.0/gtk/deprecated/gtkstock.h:105:1: note:
'GtkStock' has been explicitly marked deprecated here
G_DEPRECATED
^
/usr/local/gtk/include/glib-2.0/glib/gmacros.h:432:37: note: expanded from
macro 'G_DEPRECATED'
#define G_DEPRECATED __attribute__((__deprecated__))
^
test.c:8:9: warning: 'gtk_image_new_from_stock' is deprecated
[-Wdeprecated-declarations]
gtk_image_new_from_stock(GTK_STOCK_ABOUT,
GTK_ICON_SIZE_LARGE_TOOLBAR));
^
/usr/local/gtk/include/gtk-3.0/gtk/gtkimage.h:121:1: note:
'gtk_image_new_from_stock' has been explicitly marked deprecated here
GDK_DEPRECATED_IN_3_10_FOR(gtk_image_new_from_icon_name)
^
/usr/local/gtk/include/gtk-3.0/gdk/gdkversionmacros.h:329:47: note:
expanded from macro 'GDK_DEPRECATED_IN_3_10_FOR'
# define GDK_DEPRECATED_IN_3_10_FOR(f)GDK_DEPRECATED_FOR(f)
  ^
/usr/local/gtk/include/gtk-3.0/gdk/gdkversionmacros.h:49:31: note: expanded
from macro 'GDK_DEPRECATED_FOR'
#define GDK_DEPRECATED_FOR(f) G_DEPRECATED_FOR(f) _GDK_EXTERN
  ^
/usr/local/gtk/include/glib-2.0/glib/gmacros.h:444:29: note: expanded from
macro 'G_DEPRECATED_FOR'
#define G_DEPRECATED_FOR(f) G_DEPRECATED
^
/usr/local/gtk/include/glib-2.0/glib/gmacros.h:432:37: note: expanded from
macro 'G_DEPRECATED'
#define G_DEPRECATED __attribute__((__deprecated__))
^
2 warnings generated.

shelob-2 $ ./test

(process:77229): Gtk-WARNING **: 14:28:48.629: Locale not supported by C
library.
Using the fallback 'C' locale.

(test:77229): Gtk-WARNING **: 14:28:49.162: Could not find the icon
'help-about'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases

(test:77229): Gtk-WARNING **: 14:28:49.162: Error loading theme icon
'help-about' for stock: Icon 'help-about' not present in theme Adwaita

 --
Ciao,
 Gabry

-- 


Le informazioni contenute nella presente comunicazione e i relativi 
allegati possono essere riservate e sono, comunque, destinate 
esclusivamente alle persone o alla Società sopraindicati e non sono da 
considerarsi comunicazioni personali, quindi eventuali risposte potranno 
essere conosciute da persone appartenenti all’azienda. La diffusione, 
distribuzione e/o copiatura del documento trasmesso da parte di qualsiasi 
soggetto diverso dal destinatario è proibita ai sensi dell’art. 616 c.p. I 
dati forniti verranno trattati ai sensi dell'art. 13 del Regolamento UE 
2016/679 (normativa sulla privacy). Se ha ricevuto questo messaggio per 
errore Ti preghiamo di distruggerlo e di informarci immediatamente 
contattandoci mandando una mail a priv...@wyscout.com 
. Copia integrale dell’informativa potrà essere 
visionata presso le nostre sedi. 

Any information herein included (even 
any attachments) shall be considered confidential and/or privileged 
material and meant to be only for the abovementioned persons and/or 
Company, therefore such communication is intended to be for the addressee 
only. Such information is not personal, that is why this e-mail and any 
replies may be known exclusively by people belonging to the company. It is 
expressively not allowed communicate, disclose and/or copy any 
documentation transmitted by a person other than the rec

Re: Migrating away from GtkStock stuff

[Emmanuele Bassi via gtk-app-devel-list]

On Thu, 7 Feb 2019 at 11:52, Gabriele Greco via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Hi guys,
>
> I'm in the process of migrating a big code base from GTK 2.x to GTK 3.x,
> I've done most of the work, but I'm facing now some problems with GTK stock
> stuff.
>
> I used stock stuff a lot to reduce the localizable strings needed in my
> code and to reduce the number of images to ship.
>
> From what I've seen there are no more stock items in GTK 3 (3.24.2 at the
> moment), since they have been deprecated in 3.10.
>
>
That's not correct: GTK still ships the stock icons. You can find them in
the tree as `gtk/icons///`. The icons themselves are built
into the GTK shared library as GResources.

The labels are still there, but you're strongly encouraged to ship your own
strings, with your own mnemonics; GTK cannot know which mnemonics you or
your translators use, so there will inevitably be conflicts, which will
make your application look bad, or behave worse.


> It's more a removal than a deprecation since my code compiles but the
> program seems to fail to find at least the icons pointed by the stock item:
>
> (:75970): Gtk-WARNING **: 12:47:16.541: Error loading theme icon
> 'document-new' for stock: Icon 'document-new' not present in theme Adwaita
> (:75970): Gtk-WARNING **: 12:47:16.598: Error loading theme icon
> 'document-open' for stock: Icon 'document-open' not present in theme
> Adwaita
> (:75970): Gtk-WARNING **: 12:47:16.599: Error loading theme icon
> 'document-save' for stock: Icon 'document-save' not present in theme
> Adwaita
> (:75970): Gtk-WARNING **: 12:47:16.599: Error loading theme icon
> 'edit-find' for stock: Icon 'edit-find' not present in theme Adwaita
>
>
If you're using `edit-find` or `document-save` then you're using a named
icon from the icon theme, not the stock identifier.

For those, you'll have to ship an icon theme like Adwaita.

There is a stack overflow post that suggests how to handle the migration
> from a GtkStock item to a "named icon" or a "gtk localized label":
>
>
> https://stackoverflow.com/questions/36805505/gtk-stock-is-deprecated-whats-the-alternative
>
> ... but what about toolbar or buttons that given the theme may have icons,
> labels or both?
>

You are strongly encouraged to reduce the number of icons in your UI to
begin with; icons need to be extremely recognisable if you want to reduce
the mental load on users, and if you're showing both text and icons, users
will use the text, not the icon, to know what ai UI element does—if they
don't memorise the spatial location of the UI element, in which case
they'll use spatial memory instead of icon/text memory:

https://uxmyths.com/post/715009009/myth-icons-enhance-usability

In any case, if you wish to move away from stock elements, the
recommendation is to move to icon theme names (GTK deprecation notes will
tell you what to use instead, if there is a replacement). If you don't want
to ship a whole icon theme, because of disk/download size constraints, or
build a list of icon assets you know you are using, and then you can either
take the Adwaita icon theme and remove everything you don't use, or create
the same file system layout as the icon theme but under your own
application's data directory:

https://wiki.gnome.org/DraftSpecs/ThemableAppSpecificIcons

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Detecting the gdk backend

[rastersoft]

Hi:

You have the GDK_IS_WAYLAND_DISPLAY() C macro. You have an example in my 
program Terminus ( https://gitlab.com/rastersoft/terminus ), in the 
'checkwayland.c' and 'checkwayland.vapi' files (which is also an example 
of how to do it in Vala, BTW).


El 8/2/19 a las 6:28, Daniel Kasak via gtk-app-devel-list escribió:

Hi all. Is there a way to detect the gdk backend an app is using? I know
about the environment variable - GDK_BACKEND. But often this is not set,
and gtk just picks whatever's available. I need ever-so-slightly different
app behaviour, depending on the backend. Any ideas?

Dan
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


--
Nos leemos
 RASTER(Linux user #228804)
ras...@rastersoft.com  http://www.rastersoft.com

___
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

[Ryan Gonzalez via gtk-app-devel-list]

As a side note, Python has also opened a Discourse instance (in addition to
their Zulip experiment), and the results have pretty much been positive.
I've also been on Fedora's for quite some time, and it's great.

On Wed, Feb 6, 2019 at 5:46 AM Emmanuele Bassi via gtk-devel-list <
gtk-devel-l...@gnome.org> wrote:

> [Cross-posted to various relevant mailing lists; please, reply to
> gtk-devel-list]
>
> As part of an attempt at making GTK more friendly to newcomers, I and
> other core developers were thinking of moving the mailing lists from the
> current mailman installation to Discourse:
>
>   https://discourse.org/
>
> Possibly still hosted on GNOME infrastructure, depending on the
> requirements for our sysadmins.
>
> The GTK project would have various sub-topics, mostly around development
> with and of GTK. Having a better archive search, a better moderation
> system, and a decent web UI are the major selling points for switching to
> Discourse. The fact that the project is also open source is neatly aligned
> with our values.
>
> 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.
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> ___
> gtk-devel-list mailing list
> gtk-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>


-- 
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
___
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

[Niels De Graef via gtk-app-devel-list]

Hi all,

I'm very much in favor! Being able to still use e-mail while also
having a convenient and pretty-looking interface is something I look
*really* forward to.

My only question is: what happens to the old archives? Do we keep them
online as-is, or is there a plan to also migrate them? The former
means of course less effort, but the latter would keep everything
unified in one UI for example.
I'm fine with whatever you choose :-)

Thanks in any case for taking this up, Emmanuele!

Cheers,
nielsdg

On Wed, Feb 6, 2019 at 3:42 PM Emmanuele Bassi via gtk-devel-list
 wrote:
>
> More information on Discourse:
>
>   - About: https://www.discourse.org/about
>   - Features: https://www.discourse.org/features
>
> Discourse is a forum software that has multiple ways to access it: web, 
> native apps, and email. It's not a mailing list software with a web frontend.
>
> The interesting (to me) parts are:
>
>  - 2FA instead of Mailman's plaintext password
>  - real moderation tools, that can scale with the community and encourage 
> civility and code of conduct compliant behaviour
>  - anti-spam measures
>  - open source software (kind of a pre-requisite)
>  - good UI for reading and replying to topics
>
> The Fedora (Silverblue) and Ubuntu communities already use Discourse, for 
> instance; the SDL community also does.
>
> Ciao,
>  Emmanuele.
>
>
> On Wed, 6 Feb 2019 at 12:46, Emmanuele Bassi  wrote:
>>
>> [Cross-posted to various relevant mailing lists; please, reply to 
>> gtk-devel-list]
>>
>> As part of an attempt at making GTK more friendly to newcomers, I and other 
>> core developers were thinking of moving the mailing lists from the current 
>> mailman installation to Discourse:
>>
>>   https://discourse.org/
>>
>> Possibly still hosted on GNOME infrastructure, depending on the requirements 
>> for our sysadmins.
>>
>> The GTK project would have various sub-topics, mostly around development 
>> with and of GTK. Having a better archive search, a better moderation system, 
>> and a decent web UI are the major selling points for switching to Discourse. 
>> The fact that the project is also open source is neatly aligned with our 
>> values.
>>
>> 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.
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>
>
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> ___
> gtk-devel-list mailing list
> gtk-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
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

[Paul Davis]

Emmaneule,

at ardour.org, we recently switched from using Drupal forums to Discourse.
The results have been delightful. We managed to get single sign on
integration with our existing site working, which was important for us, but
probably not so much for a GTK Discourse. More notably, once you figure out
how to get the settings right, the integration with email was also a
pleasure. The move has definitely made our forums more active, easier to
manage, nicer to interact with and has also largely solved the spam
problems that we had before, even when we used Mollum. So ... although our
needs and goals were slightly different from yours, I can say that for us,
the move was very successful and we like Discourse very much.

--p


On Wed, Feb 6, 2019 at 4:46 AM Emmanuele Bassi via gtk-list <
gtk-l...@gnome.org> wrote:

> [Cross-posted to various relevant mailing lists; please, reply to
> gtk-devel-list]
>
> As part of an attempt at making GTK more friendly to newcomers, I and
> other core developers were thinking of moving the mailing lists from the
> current mailman installation to Discourse:
>
>   https://discourse.org/
>
> Possibly still hosted on GNOME infrastructure, depending on the
> requirements for our sysadmins.
>
> The GTK project would have various sub-topics, mostly around development
> with and of GTK. Having a better archive search, a better moderation
> system, and a decent web UI are the major selling points for switching to
> Discourse. The fact that the project is also open source is neatly aligned
> with our values.
>
> 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.
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> ___
> gtk-list mailing list
> gtk-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Detecting the gdk backend

[Luca Bacci via gtk-app-devel-list]

Hi! There is some reference code here:
https://developer.gnome.org/gdk3/stable/gdk3-Wayland-Interaction.html
https://developer.gnome.org/gdk3/stable/gdk3-X-Window-System-Interaction.html

   - Include the backend specific headers: gdk/gdkx.h, gdk/gdkwayland.h
   - Link with backend specific libs: gdk-x11-3.0.pc, gdk-wayland-3.0.pc
   - Check the backend for the default display: if
   (GDK_IS_X11_DISPLAY(gdk_display_get_default())) { /*...*/ }

Here is an example:

/* compile with
cc -o print-gdk-backend print-gdk-backend.c \
$(pkg-config --cflags --libs gtk+-3.0 gdk-x11-3.0 gdk-wayland-3.0)
*/

#include 
#ifdef GDK_WINDOWING_X11
#include 
#endif
#ifdef GDK_WINDOWING_WAYLAND
#include 
#endif
/*
   GDK_WINDOWING macros are defined in header
   /usr/include/gtk-3.0/gdk/gdkconfig.h
*/

int main() {
  gtk_init(NULL, NULL);

#ifdef GDK_WINDOWING_X11
  if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) {
g_print("X11 backend\n");
  }
#endif
#ifdef GDK_WINDOWING_WAYLAND
  if (GDK_IS_WAYLAND_DISPLAY(gdk_display_get_default())) {
g_print("Wayland backend\n");
  }
#endif

  return 0;
}


Il giorno gio 7 feb 2019 alle ore 06:28 Daniel Kasak via gtk-app-devel-list
 ha scritto:

> Hi all. Is there a way to detect the gdk backend an app is using? I know
> about the environment variable - GDK_BACKEND. But often this is not set,
> and gtk just picks whatever's available. I need ever-so-slightly different
> app behaviour, depending on the backend. Any ideas?
>
> Dan
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GObject properties and g_value_set_string()

[Joël Krähemann via gtk-app-devel-list]

Hi again,

Yes, g_value_set_string() does call g_strdup().

bests,
Joël

On Thu, Feb 7, 2019 at 5:20 AM Joël Krähemann  wrote:
>
> Hi all,
>
> Currently, I do my properties like following:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/lib/ags_turtle.c?h=2.1.x#n175
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/lib/ags_turtle.c?h=2.1.x#n218
>
> Is it ok to do g_strdup() and pass it to g_value_set_string()?
> Or does g_value_set_string() duplicate the string for me?
>
> Does the following make any sense?
>
> g_value_set_string(value, g_strdup(turtle->filename));
>
> This sample code is from GLib-2.0 API Reference Manual:
>
> 
>
> gint intval;
> gchar *strval;
> GObject *objval;
>
> g_object_get (my_object,
>   "int-property", &intval,
>   "str-property", &strval,
>   "obj-property", &objval,
>   NULL);
>
> // Do something with intval, strval, objval
>
> g_free (strval);
> g_object_unref (objval);
>
> 
>
> Since I have to free the string, I just wonder if I need to g_strdup() it.
>
> bests,
> Joël
___
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

[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

Re: Moving from mailing lists to Discourse

[Emmanuele Bassi via gtk-app-devel-list]

More information on Discourse:

  - About: https://www.discourse.org/about
  - Features: https://www.discourse.org/features

Discourse is a forum software that has multiple ways to access it: web,
native apps, and email. It's not a mailing list software with a web
frontend.

The interesting (to me) parts are:

 - 2FA instead of Mailman's plaintext password
 - real moderation tools, that can scale with the community and encourage
civility and code of conduct compliant behaviour
 - anti-spam measures
 - open source software (kind of a pre-requisite)
 - good UI for reading and replying to topics

The Fedora (Silverblue) and Ubuntu communities already use Discourse, for
instance; the SDL community also does.

Ciao,
 Emmanuele.


On Wed, 6 Feb 2019 at 12:46, Emmanuele Bassi  wrote:

> [Cross-posted to various relevant mailing lists; please, reply to
> gtk-devel-list]
>
> As part of an attempt at making GTK more friendly to newcomers, I and
> other core developers were thinking of moving the mailing lists from the
> current mailman installation to Discourse:
>
>   https://discourse.org/
>
> Possibly still hosted on GNOME infrastructure, depending on the
> requirements for our sysadmins.
>
> The GTK project would have various sub-topics, mostly around development
> with and of GTK. Having a better archive search, a better moderation
> system, and a decent web UI are the major selling points for switching to
> Discourse. The fact that the project is also open source is neatly aligned
> with our values.
>
> 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.
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Problem with sizes of pixbuf in left gutter

[Eric Cashon via gtk-app-devel-list]

 
It looks like the pixbuf sizes rendered are going to be tied to the size of the 
font in the sourceview. If the pixbufs are bigger than the gutter has space for 
then they get clipped. I don't know how the sourceview works very well myself. 
Gave it a try. Maybe it will help.
Eric
//gcc -Wall source_view2.c -o source_view2 `pkg-config --cflags --libs gtk+-3.0 
gtksourceview-3.0`
//Tested with GTK3.18 and Ubuntu16.04

#include
#include

static GdkPixbuf* draw_pixbuf1();
static GdkPixbuf* draw_pixbuf2();
static void redraw_gutter(GtkWidget *button, gpointer renderer);
static void check_renderer1(GtkSourceGutterRenderer *renderer, GtkTextIter 
*start, GtkTextIter *end, GtkSourceGutterRendererState state, GdkPixbuf 
*pixbufs[2]);

int main (int argc, char *argv[])
  {
    gtk_init(&argc, &argv);

    GtkWidget *window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
    gtk_window_set_title(GTK_WINDOW(window), "Source View");
    gtk_window_set_default_size(GTK_WINDOW(window), 400, 400);
    gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
    g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
    
    //Highlight for the C language.
    GtkSourceLanguageManager *lm=gtk_source_language_manager_get_default();
    GtkSourceLanguage *language=gtk_source_language_manager_get_language(lm, 
"c");
    GtkSourceBuffer *s_buffer=gtk_source_buffer_new_with_language(language);
    gtk_source_buffer_set_language(s_buffer, language);
    gtk_source_buffer_set_highlight_syntax(s_buffer, TRUE);

    GtkWidget *source_view=gtk_source_view_new_with_buffer(s_buffer);
    gtk_source_view_set_show_line_numbers(GTK_SOURCE_VIEW(source_view), TRUE);
    gtk_source_view_set_show_line_marks(GTK_SOURCE_VIEW(source_view), TRUE);
    gtk_source_view_set_highlight_current_line(GTK_SOURCE_VIEW(source_view), 
TRUE);
    gtk_widget_set_vexpand(source_view, TRUE);
    gtk_widget_set_hexpand(source_view, TRUE);

    //Get some pixbufs to test.
    GdkPixbuf *pixbuf1=draw_pixbuf1();
    GdkPixbuf *pixbuf2=draw_pixbuf2();
    GdkPixbuf *pixbufs[2]={pixbuf1, pixbuf2};

    //Get the left gutter.
    GtkSourceGutter 
*gutter=gtk_source_view_get_gutter(GTK_SOURCE_VIEW(source_view), 
GTK_TEXT_WINDOW_LEFT);

    GtkSourceGutterRenderer *renderer1=gtk_source_gutter_renderer_pixbuf_new();
    g_signal_connect(renderer1, "query-data", G_CALLBACK(check_renderer1), 
pixbufs);
    gtk_source_gutter_renderer_set_alignment_mode(renderer1, 
GTK_SOURCE_GUTTER_RENDERER_ALIGNMENT_MODE_FIRST);
    gtk_source_gutter_renderer_set_size(renderer1, 32);
    gtk_source_gutter_insert(gutter, GTK_SOURCE_GUTTER_RENDERER(renderer1), 0);

    //Create a mark on the first line.
    GtkTextIter start;
    gtk_text_buffer_get_start_iter(GTK_TEXT_BUFFER(s_buffer), &start);
    gtk_source_buffer_create_source_mark(s_buffer, "mark_name", 
"mark_category", &start);
    
    //Color the first line green.
    GdkRGBA bg;
    gdk_rgba_parse(&bg, "#00FF00");
    GtkSourceMarkAttributes *att=gtk_source_mark_attributes_new();
    gtk_source_mark_attributes_set_background(att, &bg);
    gtk_source_view_set_mark_attributes(GTK_SOURCE_VIEW(source_view), 
"mark_category", att, 1);

    gtk_text_buffer_set_text(GTK_TEXT_BUFFER(s_buffer), "//gcc -Wall hello1.c 
-o hello1\n#include\n\nint main()\n  {\n    printf(\"Hello 
World\\n\");\n    return 0;\n  }\n", -1);

    GtkWidget *button=gtk_button_new_with_label("Redraw Gutter");
    gtk_widget_set_hexpand(button, TRUE);
    g_signal_connect(button, "clicked", G_CALLBACK(redraw_gutter), renderer1);

    GtkWidget *grid=gtk_grid_new();
    gtk_grid_attach(GTK_GRID(grid), source_view, 0, 0, 1, 1);
    gtk_grid_attach(GTK_GRID(grid), button, 0, 1, 1, 1);
    
    gtk_container_add(GTK_CONTAINER(window), grid);

 //Setup CSS for the program.
    GError *css_error=NULL;
    gint minor_version=gtk_get_minor_version();
    gchar *css_string1=NULL;
    //GTK CSS changed in 3.20.
    if(minor_version>20)
  {
    css_string1=g_strdup("textview{background-color: blue; color: yellow; 
font-size: 26px;}");
  }
    else
  {
    //On GTK3.18 background works and background-color doesn't.
    css_string1=g_strdup("GtkTextView{background: blue; color: yellow; 
font-size: 26px;}");
  }
    GtkCssProvider *provider=gtk_css_provider_new();
    GdkDisplay *display=gdk_display_get_default();
    GdkScreen *screen=gdk_display_get_default_screen(display);
    gtk_style_context_add_provider_for_screen(screen, 
GTK_STYLE_PROVIDER(provider), GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
    gtk_css_provider_load_from_data(provider, css_string1, -1, &css_error);
    //Print out the provider for some help.
    if(css_error==NULL)
  {
    gchar *string=gtk_css_provider_to_string(provider);
    g_print("%s\n", string);
    g_free(string);
  }
    else
  {
    g_print("CSS loader error %s\n", css_error->message);
    g_error_free(css_error);
  }
    g_object_unref(provider);
    g_free(css

Re: string interpolation

[Joël Krähemann via gtk-app-devel-list]

Hi,
As you set a string property of a Gtk+ widget, the string is usually
duplicated. However don't call any Gtk+ function outside the main loop,
i.e. from a different thread.

Bests,
Joël

On Fri, Dec 21, 2018 at 9:49 AM Lutz Lümken  wrote:
>
> Hello,
>
> does GTK have some kind of string interpolation or can I safely display
> user input strings in the widgets without anything unexpected (code
> injection, formatting etc.) to happen?
>
> Best regards,
> Lutz Lümken
> --
> Lutz Lümkenluem...@pre-sense.de
> PRESENSE Technologies GmbHSachsenstr. 5, D-20097 HH
> Geschäftsführer/Managing Directors   AG Hamburg, HRB 107844
> Till Dörges, Jürgen Sander   USt-IdNr.: DE263765024
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Searching for text in PDF files is wrong

[Osmo Antero via gtk-app-devel-list]

Re-hi,

I think the mark_text(...) function can be simplified.
Check also open_page(...).

Ref: https://pastebin.com/52dU2kv8

Feliz Natal
Moma

Osmo Antero  escreveu no dia quarta, 19/12/2018 à(s)
20:08:

> Hello,
>
> This code might work even you resize the window.
> Please see: https://pastebin.com/GJMPwLU3
>
> It draws the selected text in the "draw" event.
>
> ps. I hard coded the PDF_DOC and FIND_TEXT values.
>
> Feliz Natal,
>   moma, Portugal
>
> Marius Gedminas  escreveu no dia segunda, 3/12/2018
> à(s) 17:12:
>
>> On Fri, Nov 30, 2018 at 09:56:12PM +0100, Радомир Хаџић via
>> gtk-app-devel-list wrote:
>> > I use poppler_page_find_text() to find text in PDF files. This returns
>> > GList of pointers to PopplerRectangles. Then I use
>> > poppler_page_render_selection() to mark the found text.
>> >
>> > What is wrong is that PopplerRectangles returned by
>> > poppler_page_find_text() are incompatible with those that
>> > poppler_page_render_selection() requests, which is why the wrong text
>> > is selected.
>> >
>> > I have found that to make those two compatible, I have to do the
>> > following to PopplerRectangles returned by poppler_page_find_text():
>> > 1) SWAP(rectangle.x1, rectangle.x2);
>> > 2) SWAP(rectangle.y1, rectangle.y2);
>> > 3) rectangle.y1 = page_height - rectangle.y1;
>> > 4) rectangle.y2 = page_height - rectangle.y2;
>> > But this does not solve the problem because the marked text cycles
>> > between right and wrong again while resizing the window.
>>
>> > is: https://pastebin.com/h3F56Yv7
>>
>> You're doing in-place coordinate conversions in your drawing code.
>> Every expose event will change the coordinates event, which is why
>> you're seeing the flip-flopping.
>>
>> Do the conversion only once, or use a local temporary PopplerRectangle
>> variable and avoid in-place conversions.
>>
>> (I'm not familiar with poppler's APIs and cannot say if your conversion
>> code is correct.)
>>
>> HTH,
>> Marius Gedminas
>> --
>> Lutetium is the heaviest and hardest of the rare earth metals, and is
>> used in
>> the production of umlauts and other fraktur font features.
>> -- Charles Stross
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>
>
> --
> Sent from my PC, laptop or phone with Ubuntu-Linux.
>


-- 
Sent from my PC, laptop or phone with Ubuntu-Linux.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Searching for text in PDF files is wrong

[Osmo Antero via gtk-app-devel-list]

Hello,

This code might work even you resize the window.
Please see: https://pastebin.com/GJMPwLU3

It draws the selected text in the "draw" event.

ps. I hard coded the PDF_DOC and FIND_TEXT values.

Feliz Natal,
  moma, Portugal

Marius Gedminas  escreveu no dia segunda, 3/12/2018 à(s)
17:12:

> On Fri, Nov 30, 2018 at 09:56:12PM +0100, Радомир Хаџић via
> gtk-app-devel-list wrote:
> > I use poppler_page_find_text() to find text in PDF files. This returns
> > GList of pointers to PopplerRectangles. Then I use
> > poppler_page_render_selection() to mark the found text.
> >
> > What is wrong is that PopplerRectangles returned by
> > poppler_page_find_text() are incompatible with those that
> > poppler_page_render_selection() requests, which is why the wrong text
> > is selected.
> >
> > I have found that to make those two compatible, I have to do the
> > following to PopplerRectangles returned by poppler_page_find_text():
> > 1) SWAP(rectangle.x1, rectangle.x2);
> > 2) SWAP(rectangle.y1, rectangle.y2);
> > 3) rectangle.y1 = page_height - rectangle.y1;
> > 4) rectangle.y2 = page_height - rectangle.y2;
> > But this does not solve the problem because the marked text cycles
> > between right and wrong again while resizing the window.
>
> > is: https://pastebin.com/h3F56Yv7
>
> You're doing in-place coordinate conversions in your drawing code.
> Every expose event will change the coordinates event, which is why
> you're seeing the flip-flopping.
>
> Do the conversion only once, or use a local temporary PopplerRectangle
> variable and avoid in-place conversions.
>
> (I'm not familiar with poppler's APIs and cannot say if your conversion
> code is correct.)
>
> HTH,
> Marius Gedminas
> --
> Lutetium is the heaviest and hardest of the rare earth metals, and is used
> in
> the production of umlauts and other fraktur font features.
> -- Charles Stross
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



-- 
Sent from my PC, laptop or phone with Ubuntu-Linux.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Python3, GObject objects & models

[Marius Gedminas]

On Tue, Dec 18, 2018 at 01:01:45PM -0500, Adam Tauno Williams wrote:
> I have created, and registered, a custom GObject type [an object].  I
> can place that type into a ListModel: aka model =
> Gtk.ListModel(MyClass).
> 
> One of the advantages of creating a GObject is the whole property
> system - - - and most notably change signals.
> 
> What I have not been able to find is how to connect/map something like
> a Gtk.CellRendererText to a property, such that having a type in a
> model has some advantage [vs. a model like (int, str, str)].  ???

I think you have to use Gtk.TreeViewColumn.set_cell_data_func(), but I
also fail to see any advantages you'd get of doing that instead of using
plain data types in the model.

Marius Gedminas
-- 
Remember the... the... uhh.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Python3, GObject objects & models

[Reuben Rissler]

So I am assuming that you are looking for a discussion and not for a 
specific problem to be solved. If this is not the case, please post the 
code that is not working for you, delete my email and forgive me.



On 12/18/2018 01:01 PM, Adam Tauno Williams wrote:

I have created, and registered, a custom GObject type [an object].  I
can place that type into a ListModel: aka model =
Gtk.ListModel(MyClass).

One of the advantages of creating a GObject is the whole property
system - - - and most notably change signals.
And how exactly does that improve on the /model.connect("row-changed")/, 
and the signal family already in place?


What I have not been able to find is how to connect/map something like
a Gtk.CellRendererText to a property, such that having a type in a
model has some advantage [vs. a model like (int, str, str)].  ???
For myself, I use Glade for all the Treeviews I can as I would rather 
see the Treeview I build than try to memorize the construction of code. 
My few attempts in trying to subclass Treeview components got more messy 
than just hooking into their signal system and tweaking the data as it 
goes from point A to point B.


In the case I have in mind, I was trying to add a autocomplete feature 
to a Gtk.CellRendererCombo. I finally discovered that Gtk already has a 
provision for that by providing a /editing-started/ signal to add the 
autocomplete object to the entry inside the combo.


With that said, I have tens of Treeviews in my accounting system, and am 
always on the lookout for more fluent/better ways of showing data.


One other case worth mentioning was trying to get a Decimal column to 
play nicely in a Treeview (floats are not acceptable in accounting). I 
could use a PyObject type and display it using cell renderer display 
functions. However, when filtering and sorting, all manner of extra code 
had to be added to work with the Decimals. In the end it was faster and 
easier to use a two column approach, a /str/ for display and an /float/ 
for sorting. Then all the calculations are done in SQL, server side.


Yours,
Reuben
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Async Callbacks w/Python 3 + Gtk3

[Marius Gedminas]

On Mon, Dec 17, 2018 at 04:09:27PM -0500, Adam Tauno Williams wrote:
> I'm rebuilding an old application in Python3+Gtk.
> 
> The applications makes calls to remote services which I'd like to have
> be asynchronous.  I've search around the interwebz and found a wide
> variety of answers to this question [Gtk.mainloop + async(other-
> loop?)];  almost all of them are pretty old.
> 
> Is there an "official" / endorsed / classical way to handle this?
> 
> None of the "official" HOWTOs I have found address this - - - unless I
> have missed one [entirley possible]

There are two main approaches:

- use async APIs that integrate with the glib main loop
  (e.g. Gio has classes for talking to sockets/subprocesses, which is
  low level, then there's Soap that gives you a higher level async HTTP
  wrappers.)

- use threads, being very careful never to call GTK+ APIs from them
  directly (use GLib.idle_add() to register callbacks to be executed
  from the main thread, whenever a background thread does something
  interesting that needs to be reflected in the UI).

https://wiki.gnome.org/Projects/PyGObject/Threading has examples of
both threads and using Goo.File.load_contents_async() to download a
file over HTTP asyncronously.

HTH,
Marius Gedminas
-- 
PCMCIA - People Can't Memorize Computer Industry Acronyms
___
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 replace gtk_widget_modify_text() with CSS?

[Nate Bargmann]

Thank you very much for this comprehensive reply, Luca.  This gives me a
lot to work with and many good ideas.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: http://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB
___
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 replace gtk_widget_modify_text() with CSS?

[Luca Bacci via gtk-app-devel-list]

Hi Nate,
based on my experience, you have 3 ways:

1) First, see if there are standard CSS classes provided by the theme for
your use case. For example, GtkButton
 has the
*.suggegsted-action* and *.destructive-action* CSS classes, which all
themes shall provide. GtkEntry has *.warning* and *.error* CSS classes.
This blends nicely with every theme you may use.

You use gtk_widget_get_style_context() and gtk_style_context_add_class().
In one line it is:
gtk_style_context_add_class(gtk_widget_get_style_context(button),
"suggested-action");

See:
https://stackoverflow.com/a/37628324
https://wiki.gnome.org/HowDoI/Buttons.

2) Create one CSS where you define *your own* CSS classes. It can be either
a string in your source file, an external .css file that you load at
runtime, or a .css file embedded as a GResource
). Load your custom
CSS at startup:

void setup_application_css() {
  const gchar *css_string = ".red_text { color: red; }";

  GtkCssProvider *css = gtk_css_provider_new();
  gtk_css_provider_load_from_data(css, css_string, -1, NULL);
  gtk_style_context_add_provider_for_screen(gdk_screen_get_default(),
GTK_STYLE_PROVIDER(css),

GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
  g_object_unref(css);
}

int main(int argc, char **argv) {
  gtk_init(&argc, &argv);
  setup_application_css();

  init();
  gtk_main();
  return 0;
}

then apply the class to any widget you want:
GtkEntry *entry = gtk_entry_new();
gtk_style_context_add_class(gtk_widget_get_style_context(entry),
"red_text");

NOTE: if you want to work with CSS id, just change the css string to:

const gchar *css_string = "#myentry1 { color: red; }";

then set the CSS id to the entry:
GtkEntry *entry = gtk_entry_new();
gtk_widget_set_name(entry, "myentry1");

3) If you have to style just a few widgets, it's best to style them
directly at creation site, without loading a CSS globally:

GtkEntry* create_entry() {
  GtkEntry *entry = gtk_entry_new();

  const gchar *css_string = "entry { color: red; }";
  GtkCssProvider *css = gtk_css_provider_new();
  gtk_css_provider_load_from_data(css, css_string, -1, NULL);
  gtk_style_context_add_provider(gtk_widget_get_style_context(entry),
 GTK_STYLE_PROVIDER(css),
 GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
  g_object_unref(css);

  return entry;
}

I suggest you use the Gtk Inspector
 to
experiment with all that at runtime. You can write live CSS and you can
also set properties of your widgets like name, classes. See also
https://blog.gtk.org/2017/04/05/the-gtk-inspector/

I have attached examples for all three points.
Luca

Il giorno lun 17 dic 2018 alle ore 15:46 Nate Bargmann  ha
scritto:

> Greetings to the list.
>
> Several years ago I took over maintainership of a useful amateur radio
> application written for GTK+ 2.  As a winter project I've decided to
> port it to GTK+ 3 and have used the transition guide to accomplish
> much.  I set the build system to generate warnings for deprecated
> constructs and one of the things that has me stumped is how to replace a
> call to GTK+ 2's gtk_widget_modify_text() with CSS in GTK+ 3.  Now, I'm
> not a complete newcomer to CSS having used it with HTML years back so
> that is not the issue.
>
> In the program source there are lines like this which merely set the
> foreground color of some text based on a default or some later user
> preference:
>
> gtk_widget_modify_text(highentry1, GTK_STATE_NORMAL,
> &preferences.highcolor1);
>
> Building now generates this warning (I have a lot of these):
>
>   CC   main.o
> ../../xdx/src/main.c: In function ‘main’:
> ../../xdx/src/main.c:332:5: warning: ‘gtk_widget_modify_text’ is
> deprecated: Use 'CSS style classes' instead [-Wdeprecated-declarations]
>  gtk_widget_modify_text(highentry1, GTK_STATE_NORMAL,
> &preferences.highcolor1);
>  ^~
>
> I have been looking through the reference documentation and various
> examples to find something relatively simple to change the foreground
> color of the text.  Right now what I am looking for is a clue of how to
> get from "here" to "there".  What I am finding seems to be rather
> complicated and involved.  Hopefully my impression is incorrect.
>
> Is there a function that I've missed that can apply CSS inline similar
> to this deprecated function?
>
> TIA
>
> - Nate
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
>
> Web: http://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
#include 

void load_application_css() {
  const gchar 

Re: GdkKeymap default for Display problem

[Richard Shann]

Following this up:

> Using Gtk 3.22.11 under Debian stable I get a different keymap than
> the
> one the application was launched with on calling 
> 
> gdk_keymap_get_for_display(gdk_display_get_default ())
> 
> This shows up when there are two keymaps available and I select the
> alternative one for a terminal, launch the application and then use 
> 
> gdk_keymap_translate_keyboard_state ()
> 
> what happens is that it is *not* translated using the keymap that was
> used to launch the application (and which shows up in GtkEntry etc
> widgets). Instead it is translated using the "default" keymap for the
> Desktop.
> This lead me to look at the documentation and I see that there is
> nothing to suggest you can access the GdkKeymap that the GtkWidgets
> are
> using - indeed there is nothing to suggest you can create a GdkKeymap
> other than getting this "default for display" keymap.
> 
> Is there something I've missed here?
> 
> Richard Shann

I've created a minimal example of the problem:

//gcc -Wall KeyMap-test.c -o KeyMapTest `pkg-config --cflags --libs gtk+-3.0`
//Tested on debian stable and GTK3.22.18

#include
static void callback (GtkWidget * widget, GdkEventKey * event)
{
   guint keyval;
   g_print ("key press event: keyval %d (%s)\n", event->keyval, 
gdk_keyval_name(event->keyval));
   gdk_keymap_translate_keyboard_state (gdk_keymap_get_default (), 
event->hardware_keycode,0,0, &keyval, NULL, NULL, NULL); 
   g_print ("After keymap translate keyval %d (%s)\n", keyval, 
gdk_keyval_name(keyval));
}
int main(int argc, char **argv)
 {
   gtk_init(&argc, &argv);

   GtkWidget *top_window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
   g_signal_connect (top_window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
   g_signal_connect (G_OBJECT(top_window), "key-press-event", G_CALLBACK 
(callback), NULL);
   gtk_widget_show_all (top_window);

   gtk_main();

   return 0;  
 }

The output on setting a US keyboard in the terminal with a UK keyboard
as the desktop default and pressing the key code 51

rshann@debian:~$ ./KeyMapTest 
key press event: keyval 92 (backslash)
After keymap translate keyval 35 (numbersign)

The US key map is used for the GtkWindow widget to provide the keyval
92 but then the UK keymap is used for the call to
gdk_keymap_translate_keyboard_state() giving the keyval 35

Is this a bug in Gtk 3.22?

Richard




___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Searching for text in PDF files is wrong

[Marius Gedminas]

On Fri, Nov 30, 2018 at 09:56:12PM +0100, Радомир Хаџић via gtk-app-devel-list 
wrote:
> I use poppler_page_find_text() to find text in PDF files. This returns
> GList of pointers to PopplerRectangles. Then I use
> poppler_page_render_selection() to mark the found text.
> 
> What is wrong is that PopplerRectangles returned by
> poppler_page_find_text() are incompatible with those that
> poppler_page_render_selection() requests, which is why the wrong text
> is selected.
> 
> I have found that to make those two compatible, I have to do the
> following to PopplerRectangles returned by poppler_page_find_text():
> 1) SWAP(rectangle.x1, rectangle.x2);
> 2) SWAP(rectangle.y1, rectangle.y2);
> 3) rectangle.y1 = page_height - rectangle.y1;
> 4) rectangle.y2 = page_height - rectangle.y2;
> But this does not solve the problem because the marked text cycles
> between right and wrong again while resizing the window.

> is: https://pastebin.com/h3F56Yv7

You're doing in-place coordinate conversions in your drawing code.
Every expose event will change the coordinates event, which is why
you're seeing the flip-flopping.

Do the conversion only once, or use a local temporary PopplerRectangle
variable and avoid in-place conversions.

(I'm not familiar with poppler's APIs and cannot say if your conversion
code is correct.)

HTH,
Marius Gedminas
-- 
Lutetium is the heaviest and hardest of the rare earth metals, and is used in
the production of umlauts and other fraktur font features.
-- Charles Stross
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Searching for text in PDF files is wrong

[Emmanuele Bassi via gtk-app-devel-list]

Hi;

this list is for the development of applications with GTK; your question
relates to Poppler, so you should ask on a Poppler-related mailing list or
developers forum, e.g.
https://lists.freedesktop.org/mailman/listinfo/poppler

Ciao,
 Emmanuele.

On Fri, 30 Nov 2018 at 20:56, Радомир Хаџић via gtk-app-devel-list <
gtk-app-devel-list@gnome.org> wrote:

> Hi.
>
> I use poppler_page_find_text() to find text in PDF files. This returns
> GList of pointers to PopplerRectangles. Then I use
> poppler_page_render_selection() to mark the found text.
>
> What is wrong is that PopplerRectangles returned by
> poppler_page_find_text() are incompatible with those that
> poppler_page_render_selection() requests, which is why the wrong text
> is selected.
>
> I have found that to make those two compatible, I have to do the
> following to PopplerRectangles returned by poppler_page_find_text():
> 1) SWAP(rectangle.x1, rectangle.x2);
> 2) SWAP(rectangle.y1, rectangle.y2);
> 3) rectangle.y1 = page_height - rectangle.y1;
> 4) rectangle.y2 = page_height - rectangle.y2;
> But this does not solve the problem because the marked text cycles
> between right and wrong again while resizing the window.
>
> I have created a small program that illustrates the problem. Here it
> is: https://pastebin.com/h3F56Yv7 (I've also sent an attachment but
> last time you didn't get it so this paste is a fallback in case you
> don't get it again.)
> You ought to supply two arguments when running the program: the
> absolute path to a PDF file and the text you want to search for,
> respectively. Pay attention to the selected text with and without
> lines 54-57.
>
> How can I make the found text to be marked properly? This "workaround"
> does not work very well and it is an ugly solution anyway.
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: PDF page not rendering properly if the page is changed

[Eric Cashon via gtk-app-devel-list]

 

Didn't get an attachment either. Try something like the following and see if it 
makes any difference.

...
    GtkWidget *da=gtk_drawing_area_new();
    //Request a large drawing area.
    gtk_widget_set_size_request(da, 1, 1);

    GtkWidget *scroll=gtk_scrolled_window_new(NULL, NULL);
    gtk_widget_set_hexpand(scroll, TRUE);
    gtk_widget_set_vexpand(scroll, TRUE);
    gtk_container_add(GTK_CONTAINER(scroll), da);
...

Eric
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: PDF page not rendering properly if the page is changed

[Germán Poo-Caamaño]

On Wed, 2018-11-28 at 17:17 +0100, Радомир Хаџић via gtk-app-devel-list 
wrote:
> Hello.
> 
> I've sent as an attachment a code for a very simple PDF viewer. It is
> not that well written but that's because I wanted it to be simple and
> easy to understand. The purpose of the program is to illustrate a
> problem that I'm having with my larger project.
> 
> The problem is that if a user changes page (by clicking "Previous
> Page" or "Next Page") and the page when scaled accordingly is bigger
> than the visible portion of the page rendering area (GtkDrawingArea),
> then only the part of the page will render. You can try this
> yourself:
> 1. Open a document 2. Make sure that the next page is not completely
> visible on the screen (so the scrollbars appear, this can be usually
> achieved by clicking "Fit Width") 3. Click "Next page" and try
> scrolling. You'll notice that one part of the page is not rendered.
> 
> So, why is this happening and how can I solve it? What also confuses
> me is that rendering() function is definitely called when I scroll
> but
> the page does not render (though it does render as it should when I
> scroll the first page of a just opened document) properly, but if I
> then resize the window the page renders properly.

I do not see any attachment.

My guess is: the page maybe cached somewhere, and it is reloaded (re-
rendered) when the view size changes.

-- 
Germán Poo-Caamaño
http://calcifer.org/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Issue using the "gtk_widget_get_allocated_height" instruction

[Sébastien Le Roux]

Le 24/11/2018 à 15:59, Luca Bacci a écrit :
Probably it's a consequence of this work for porting GtkMenuBar to use 
css gadgets internally:

https://gitlab.gnome.org/GNOME/gtk/commit/700286c6

You should be able to get the appropriate size if you add menu items 
to the bar, i.e. as long as the
menubar is not empty you get the appropriate height with 
gtk_widget_get_allocated_height().


Luca
Thank you very much for your reply, it works nicely with the "invisible" 
item.


I do have in my code objects (GtkColorBar, GtkButtton) for which I 
created css

properties my self to match some specifics using:


void provide_gtk_css (gchar * css)
{
  GtkCssProvider * provider = gtk_css_provider_new ();
  gtk_css_provider_load_from_data (provider, css, -1, NULL);
  gtk_style_context_add_provider_for_screen (gdk_screen_get_default (),
 GTK_STYLE_PROVIDER(provider),
 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
  g_object_unref (provider);
}


About what I understand this is now automatic (somewhat) for many (all 
?) widgets,


Out of curiosity do you think that there is anyway to get that heigh 
value from
a query to the css properties of that menu bar ? is there anyway to send 
query to the css ?



Best


Sébastien

--
===
Dr. Sébastien Le Roux
Ingénieur de Recherche CNRS
Institut de Physique et Chimie des Matériaux de Strasbourg
Département des Matériaux Organiques
23, rue du Loess
BP 43
F-67034 Strasbourg Cedex 2, France
E-mail: sebastien.ler...@ipcms.unistra.fr
Webpage: http://www-ipcms.u-strasbg.fr/spip.php?article1771
RINGS project: http://rings-code.sourceforge.net/
ISAACS project: http://isaacs.sourceforge.net/
Fax:   +33 3 88 10 72 46
Phone: +33 3 88 10 71 62
===

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Issue using the "gtk_widget_get_allocated_height" instruction

[Luca Bacci via gtk-app-devel-list]

Hi Sébastien!
It's not simple, but you may try with combinations of

GtkStyleContext *style = gtk_widget_get_style_context(widget);
GValue value = G_VALUE_INIT;
gtk_style_context_get_style_property(style, "prop-name", &value);
//or
gtk_style_context_get_property(style, "prop-name", &value);
/*
...
*/
g_value_unset(&value) //free memory

Unfortunately, that's all I can say, I'm not expert in this area.
Probably it's going to be rather complicated.

Luca

Il giorno lun 26 nov 2018 alle ore 16:34 Sébastien Le Roux <
sebastien.ler...@ipcms.unistra.fr> ha scritto:

> Le 24/11/2018 à 15:59, Luca Bacci a écrit :
>
> Probably it's a consequence of this work for porting GtkMenuBar to use css
> gadgets internally:
> https://gitlab.gnome.org/GNOME/gtk/commit/700286c6
>
> You should be able to get the appropriate size if you add menu items to
> the bar, i.e. as long as the
> menubar is not empty you get the appropriate height with
> gtk_widget_get_allocated_height().
>
> Luca
>
> Thank you very much for your reply, it works nicely with the "invisible"
> item.
>
> I do have in my code objects (GtkColorBar, GtkButtton) for which I created
> css
> properties my self to match some specifics using:
>
>
> void provide_gtk_css (gchar * css)
> {
>   GtkCssProvider * provider = gtk_css_provider_new ();
>   gtk_css_provider_load_from_data (provider, css, -1, NULL);
>   gtk_style_context_add_provider_for_screen (gdk_screen_get_default (),
>  GTK_STYLE_PROVIDER(provider),
>  
> GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
>   g_object_unref (provider);
> }
>
>
> About what I understand this is now automatic (somewhat) for many (all ?)
> widgets,
>
> Out of curiosity do you think that there is anyway to get that heigh value
> from
> a query to the css properties of that menu bar ? is there anyway to send
> query to the css ?
>
>
> Best
>
>
> Sébastien
>
> --
> ===
> Dr. Sébastien Le Roux
> Ingénieur de Recherche CNRS
> Institut de Physique et Chimie des Matériaux de Strasbourg
> Département des Matériaux Organiques
> 23, rue du Loess
> BP 43
> F-67034 Strasbourg Cedex 2, France
> E-mail: sebastien.ler...@ipcms.unistra.fr
> Webpage: http://www-ipcms.u-strasbg.fr/spip.php?article1771
> RINGS project: http://rings-code.sourceforge.net/
> ISAACS project: http://isaacs.sourceforge.net/
> Fax:   +33 3 88 10 72 46
> Phone: +33 3 88 10 71 62
> ===
>
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list